Новий термін «Claude Hole», або що нас чекає найближчим часом (якщо не вже)

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Натрапив на Reddit на файний пост про те, що нас чекає найближчим часом (або вже непомітно підкралося). У ньому автор ділиться історією, через яку в них на роботі з’явився новий термін — Claude Hole.

Це термін, який описує ситуацію, коли інженер працює з LLM, дебажить або пише код, не до кінця розуміючи, що відбувається, і в результаті йде зовсім не в той бік від реальної проблеми. Начебто починалося з дрібної помилки, а закінчилося масштабними змінами, які взагалі не мали стосунку до першопричини.

В оригінальному пості все почалося з банальної помилки в конфігурації. Інженер неправильно вказав AWS account ID в анотації service account у CNPG-шаблоні, в результаті чого кластер сипав IAM-помилками. Але замість точкового фіксу людина з допомогою LLM дійшла до радикального рішення — відкрила PR із заміною OIDC для кожного service account в усій організації. PR, звісно, заблокували, а SRE ще довго намагалися зрозуміти логіку цього рішення.

А ви вже потрапляли в «пастку Клода»? Як вибиралися з неї? Чи сильно ШІ вам пришвидшує роботу, чи все-таки зазвичай лише водить манівцями?
👍ПодобаєтьсяСподобалось5
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Оо, цьому ефекту і назву вже придумали:)

Поділюся своїм досвідом пет-проекту з вайб-кодингом. Задача: створити електронний девайс на базі мікроконтролера, який буде опрацьовувати дані з 8ми енкодерів і керувати світлом на 2х довгих смарт rgb-лентах — певний світловий паттерн який керується з енкодерів. Обрав звичний Atmega, так як багато працював з ними)
Написання коду поклав повністю на ChatGPT 5.2 (20 долорів 😑) код писався ітеративним методом, поступово розширюючи функціонал. В якийсь момент — зіткнувся з проблемою, що так як енкодери потрібно опрацьовувати з високою частотою, і керувати лед-лентою теж, і масиви даних великі, то вперся в памʼять-швидкість. Далі — спроби оптимізувати, розділити на два девайси з комунікацією, розділити на різні контролери для ленти і енкодерів, знову спроби оптимізувати, переписати, оптимізувати. І кожна пропозиція ШІ — з обіцянкою «на цей раз точно виправить». Спочатку вівся, але десь після 10го разу перестав вірити :)
І головне — що все маайже працює, час потрачено, а на переписування з нуля самому — піде не менше часу.

Результат: тиждень потрачених вечорів, задачу виконано, але я не задоволений, так як інженерне рішення не красиве

В підсумку, на запит проаналізувати нашу розмову — скільки разів він обіцяв що після цього патчу все ТОЧНО запрацює — 17 разів !))) (при діалозі більше 500 повідомлень)

Помилка: покласти написання коду без занурення в нього на чат гпт, і головне — покладання на інженерні рішення запропоновані ним

Висновок:
Прості і рутинні речі — справляється на ура, при написанні складних але з чітко заданими умовами — теж окей, тільки треба обовʼязкове ревʼю. Інженерні і «творчі» рішення, або коли треба переглянути проблему і підійти з іншої сторони — абсолютно не працює, бо вирішує все в лоб брутфорсом. Урок засвоєно 🥲

PS: якщо що — я розумію, що початково невірно обраний контролер — це провтик людини а не машини :) але суть якраз в тому, що поклавшись на машину — все заїхало в якісь дєбрі замість того, щоб самому порозкинути мізками і обрати достатньо потужний контролер який би все нормально опрацьовував, і написати на нього код — самому чи з «AI»

Так це у людей і без ШІ буває, саме тому є код ревью і тім\тех ліди що допомгають із сис дизайном ящо для сторі потрібні великі зміни. Вже стільки раз помічав якщо даєл людині велику сторю то треба робити регулярні зідзовни бо люди закопуються в якихось кейсах котрі можнуть буди не потрібні, або забувають основну ціль сторі\єпіка і починають робити трохи не те що потрібно. Особливо це коли рефакторінг чи іще щось подібне...

З людьми таке теж трапляється.

Коли я працював в Амазон раз на пів року знаходився новенький superstar інженер який казав «а чому Х зроблена таким дивним чином? Я все виправлю!»
Активна робота, тисячі змінених файлів, але десь через місяць цей PR глох і людині давали справжню задачу.

Я прямо не запитував, але мені здається це толерували тому що це дозволяло новачку глибоко розібратися з тим як працює система, що є цінністью.

З LLM же недолік в тому що він не навчиться; але і ціна такої спроби буде в десятки разів менша

Вот таких треба навпаки цінити. Набагато гірше коли приходить, працює по скрипту, в 17:00 уходить. 0 ініціативи, 0 амбіцій, такі тільки сидять і чекають коли їм таску на тарілочці принесуть, в ідеалі так, щоб ніочго ресьорчити не треба і копати. По скрипту і агент може працювати, і чим далі тим складніший тип задач, які зможе вирішшувати.

А вот ініціативні люди, які хочуть десь щось розібратися, покращити, вирішити якісь проблеми, зробити щось поверх того, що від нього вимагається — на вагу золота. Може у нього ще недостатньо знань проекту і чуйка не розвинута щоб визначити проблеми і їх пріоритети, але це покращиться. І правильно зробили що дали йому працювати і не зарубили провальну ідею. І те, що він зрозумів що PR говно і далі не продвигав — також хороший знак, і повна протилежність чувака і PR в топіку.

Вот таких треба навпаки цінити

бизнес не ценит это качество и максимально подавляет. причем лет до 30 с тобой играют в игры, делая то что Сергей описал и другие варианты, а потом, когда тебя перестанут ассоциировать с ребенком, игры резко кончаются. судя по твоему посту ты еще в первой группе, когда попадешь во вторую скорее всего станешь перед выбором работать по скрипту до 17:00 или майн капмф

а вообще мне сложно понять почему ты осуждаешь чуваков, которые выбрали конформизм. последние 10 лет подавляющее большинство программистов это свитчеры из курьеров, барист и барменов. от них никогда не было инициативы и амбиций

Вот таких треба навпаки цінити. Набагато гірше коли приходить, працює по скрипту, в 17:00 уходить. 0 ініціативи, 0 амбіцій, такі тільки сидять і чекають коли їм таску на тарілочці принесуть, в ідеалі так, щоб ніочго ресьорчити не треба і копати

Такі люди пройшли:
1. Тестове
2. Інтерв’ю з HR
3. Одне чи декілька технічних інтерв’ю.
4. Випробуальний термін

Або компанії були потрібні саме такі люди, або такими вони стали завдяки процесам у компанії.

І правильно зробили що дали йому працювати і не зарубили провальну ідею

Звісно. Він же безкоштовно місяцями перформив.

Може у нього ще недостатньо знань проекту і чуйка не розвинута щоб визначити проблеми і їх пріоритети, але це покращиться

В українських реаліях людина візьме другий фултайм, бо нікому немає діла що вона робить.

Набагато гірше коли приходить, працює по скрипту, в 17:00 уходить

Це стабільність і прогнозованність. Те, що бізнес цінує у першу чергу. І те, заради чого намагається загнати усіх до офісів.

це не тільки в амазонах, а кожному великому проекті де працює команда. І зазвичай це просто «тут так прийнято» і «моє улюблене болото». Безспірно, через ххх годин колупання над помилкою можна зрозуміти що це не костиль, а хребет і без глобального виправлення всього немає сенсу вібрувати. Але ще частіше рішення дійсно виправляє проблему чи покращує ситуацію, но це потрібно дивитись, перевіряти і тестити, а навіть якшо все ок то потім «звикати» до нового.
З досвіду десь 5% це реально «пуста праця» і знайомство с проектом. 60-70% це «зайва праця» з точки зору тимліду/команди/етс так як це потрібно не тупо в мастер лити. І 25% (моє «улюблене») це «ні значить ні». Причому чим більше «стариків» на проекті (і це я не про вік або стаж) які відповідають за те, що крім них ніхто не розуміє, тим сильніший тиск проти оптимізацій виправлення кривих реалізацій.

Якщо інженер

дебажить або пише код, не до кінця розуміючи, що відбувається

, то він сам собі злий геній.

До чого тут взагалі Claude? Якби у героя не було Claude Code, то хіба він не отримав би той самий результат? Він почав би гугли і попав би в ті самі топіки на стековерфлоу, на яких навчались Opus і Sonnet, і далі пішов би тим самим «рекомендованим» шляхом модифікації протоколу аутентифікації.

Claude Code та інші по замовченню нічого самі не змінюють і просто пропонують діфи, які інженер має проаналізувати та схвалити. А якщо цей «інженер» налаштував авто-прийняття змін і бездумно кидає пулл-реквести на свого керівника, то навіщо цей «передаст» взагалі потрібен? Лід чи менеджер можуть замість цього інженера «найняти» напряму Claude, бо для них нічого не зміниться і потрібно так само переглядати на вміст дурні кожний новий PR.

Він би не дійшов до кінця. Не кажучи про те, що при самостійному пошуку ти бачиш різні джерела. А коли з LLM працюєш, то за замовчуванням режим зашореної кобили: шлях уперед без сумнівів.

Знову ж таки зазвичай є елемент довіри. Коли тоді за годину дають величезний PR, ти думаєш ну ок, значить так треба. А коли ти це робиш сам, витрачається більше часу, більше рефлексії, ...

А чому ви так впевнені, що цей конкретний інженер вміє аналізувати різні джерела, а не буде безальтернативно слухатись першого ліпшого? Якщо припустимо, що у нього є така навичка, тоді питання чому він такий розумний лише в Інтернеті, але відключає розум в коді, за який має відповідати?

Річ не у відсутності навичок... просто люди так влаштовані. Лінь і когнітивне розвантаження це ж природні механізми виживання мозку, а не брак інтелекту. Мозок завжди обирає шлях найменшого опору, це база... Прокастинація це яскравий приклад проблеми, коли людина вміє а не хоче.

Коли ти витрачає час, ти в процесі. А LLM дає ілюзію готового рішення. Один раз проканало, другий... і це стає звичкою. Людина не стає дурнішою, вона просто делегує роботу алгоритму, бо це дає швидкий результат, закритий тікет та час займатися приємними справами.

Прокрастинація тут теж грає роль... навіщо розбиратися і витрачати ресурс, коли можна розслабитися і натиснути кнопку...

Це ми кудись трохи вбік пішли. Я навіть погоджуюсь з вашими міркуваннями, але не погоджуюсь, що вони тут (як до речу і мої) підходять на 100%. Ми ж особисто не знайомі з цим інженером і робимо припущення про його навички та мотивацію.

Коли ти витрачає час, ти в процесі. А LLM дає ілюзію готового рішення.

Нехай наш інженер зайде на SO і зробить пошук своєї проблеми. В першому найрейтингованішому повідомленні ситуація повністю 1-в-1 з його проблемою (в рамках які йому відомі). В першому комментарі, який зібрав максимум лайків, написано, що напряму проблему не вирішити і треба переписувати протокол аутентифікації (плюс додані приклади коду для копіпасти). В другому комментарі написано, що людина спробувала вирішити проблему інакше і нічого не вийшло, а тому дяка автору першого комментаря — так нарешті получилось.

Чи ця історія не є ілюстрацією приводу для прокрастинації? Ми інстинктивно відчуваємо, що якщо в інженера є критичне мислення, то він не обере одразу це готове рішення з SO та продовжить ресерч. Але хіба цей же інженер з тим же рівнем критичного мислення одразу обере першу відповідь від LLM та не спитає про можливі альтернативи? (я завжди питаю)

Як раз бажав про це написати, але мене випередили:

Andrii Sevastianov: Річ не у відсутності навичок

Справа в упередженості до автоматизації та «не робити щось, якщо це можна не робити» (когнітивне розвантаження). Це ми вже проходили і не один раз. І кожного разу були свої «промахи». Не тому, що у когось погані скіли, а тому, що люди так влаштовані.

Душний та необов’язковий приклад:
якось я грався у одну MMO-др*чильню, і був квест зібрати 6-ти значний код з трьох локацій. А потім я натрапив на сайт, де цей код вже видавали щодня готовим для використання. Наступної спроби пройти квест, я вже не міг запам’яти послідовність. Не тому, що я став тупішим. Просто мій мозок відмовлявся це робити з аргументацією: «Та не розходуй сили даремно, просто подивись на сайті коли треба».

Если рабочему дали молоток и он забивает пальцы вместо гвоздей — это не значит, что молоток плохая вещь)

Якщо ви гадаєте про що це є я вам торочу... Це про перевиробництво. Але цікавим шляхом надання перевиконання (за ваш кошт) Тобто це регрес капіталізма у ще більш шахрайську сторону. Вам, поважним айтішникам треба це пофіксити. Бо інакше пофіксять когось іншого.
От як було раніше? Перевиробництво пхали вам в пузо. А як зараз? Перевиробництво вам прямо у мозок. Ще й з карти автоматично, за самими останніми розцінками за токен.
Зрозумійте нарешті, що щось таки потрібно обмежувати. Щось потрібно контролювати. І чимось треба керувати.

Ідея «закинути одразу весь контекст і миттю отримати потрібну відповідь» має аж нічого спільного з алгоритмом послідовного поступового наближення до відповіді — майже бінарного пошуку.
Мені як пророку у IT не подобається те, що запропоновано зараз. Не зручно і небезпечно через постійні помилки та галлюцінації.
ШІ ще є куди рости і це не в той бік, де у користувачів забирають останні крихти контроля\керування автоматичними шизофазиками.
Навпаки — ніщо так не тішить як відчуття повного контролю над інформаційним простіром — повного CRUD а саме його самовпевнені ШІ і відбирають у покупців — багато продадуть абонементів чи підписок після такого знущання, ага.
Припустимо є скеля і ви її кайлом перетворюєте на статую. Так от — ШІ ні разу не кайло.

Жорстоко ігнорую любі відхилення. Обмежую. Мрію про зручний користувацький інтерфейс керування обмеженнями виводу результатів запитів. Обмеження кількості витрачених вами токенів — хіба це не ваші гроші? Забороніть ШІ впарювати вам зайву інформацію — це ж у інтересах ваших гаманців.
Або ні — якщо переплачувати (шахраям) це все чого ви хочете від життя.

Знову інструмент винуватий.

У мене інколи буває обернена ситуація. Він продовжує тобі вказувати на одне місце а ти ігноруєш, кажеш що там все ок і проблема в іншому місці, і намагаєшся агенітв відести звідти шукати проблему в інших місцях. Потім пів дня ходиш по колу, і в кінці кінців повертаєшся на оригінальне місце і розумієш що ШІ був правий з самого початку і треба було слухатия.

Забавно що інколи він правий з місцем проблеми, але не з причиною.

Знову інструмент винуватий.

это инструмент, который делает людей ленивыми, полностью отключает им мозги и критическое мышление

Ох уж ці міфи. Воно робить лінивимми код писати. Но воно ніяк не впливає на якість коду і якість PR. Навпаки повишає, так як при інших рівних ти ще й через АІ проганяєш.

Ти мабуть такої ж думки про всіх, хто використовує більш високорівневі інструменти ніж С++.
Мабуть це чеше ваше ЧСВ, оправдуєте нехотіння чи неможливість розвиватися, йти далі. Як, водій йогось ВАЗа, рахує себе кращим водієм за водія Мерседеса. Так йому психологічне легше їздиться на ВАЗі.

«Чому більшість спроб автоматизації зазнають невдач ще до початку?
Чи справді PWA все ще актуальні?
Чи справді ШІ „вбиває“ платформи з онлайн-курсами?
Чи варто нехтувати усталеними практиками заради швидкого результату?
Який чай полюбляєте?
Що б ви зробили б першим ділом, якби вас звільнили?»

Це вибірка за місяць+ від Pavlo Trepytion який Technical Community Manager у DOU.

Провокативні питання, відкриті питання. Чи не бачу я тут retention спроби DOU піддати хайпу та невеликих провокацій заради відвідуваності? А люди тут прям чуби деруть. Головне створити майданчик та хайпову тему.

А чого ви проігнорували мої інші теми?
«„It’s over“: Лінус Торвальдс випробував вайб-кодинг»
«Які маєте лайфхаки, аби зігрітися при відсутності опалення?»
«Anthropic інвестує 1.5 млн доларів у Python Software Foundation»
«Helm-чарти Grafana переїжджають у новий community-репо»
«Чи актуально вчити Jenkins початківцю в 2026 році?»
«Чим би ви займалися, якби вже завтра вийшли на пенсію?»
«Tailwind звільняє своїх інженерів через ШІ, а Google та Vercel спішать на „допомогу“: обговорюємо ситуацію»

І багато, дуже багато іншого.

Я не стану опитувати людей з приводу того, що їм (та й мені самому) не цікаво. Бо:

1) нащо це мені
2) нащо це спільноті

Пишіть теж топіки, які цікаві Вам. Це досить класне заняття, раджу спробувати

Але замість точкового фіксу людина з допомогою LLM дійшла до радикального рішення

Згадуються слова «Spirit of this machine, heed my will»

бісять усі ллм.. клод найменше... від чатджпт вже принципово відмовився

особливо доставляє, коли відповідають щось типу:
ой, вибач, тупанув, щас перероблю... і насипає ще коду..

я і сам не розбираюся... а тут ще й він не розбирається.. блін...

мені і так, щоб надрукувати фразу двома пальцями на ноутбуці без кириличних наклейок... доводиться докладати чималих зусить... а тут ще ці приколи..

пише код, не до кінця розуміючи, що відбувається, і в результаті йде зовсім не в той бік від реальної проблеми. Начебто починалося з дрібної помилки, а закінчилося масштабними змінами, які взагалі не мали стосунку до першопричини.

колись давно вичитав:

«Дворник Е.К.Федорин, чтобы не утруждать себя скалыванием льда, изобрел прибор, отключающий земное притяжение в момент гололеда...»

Як на мене, тут немає нічого ШІ-специфічного. Проблема срібної кулі. В певний момент певна людина через якісь суто психологічні причини починає вірити, що використання певної технології, або концепції, або інструменту само по собі гарантує успіх. В людини з’являється дещо завищений рівень самовпевненості, дещо притупляється увага і зникає креативність. Людина починає не помічати власних помилок, сподіваючись лише на магічну силу срібної кулі. Зрештою з’ясовується, що срібних куль не існує, а помилки коштують дорого і їх треба виправляти якомога раніше. Похмілля, сльози, соплі.

Звичайна історія. Таке регулярно траплялося за багато років до появи навіть перших натяків на штучний інтелект. Ніщо не може перемогти щире бажання людей вірити в дива.

Хіба зі звичайними інженерами такого не буває? Часом не помічаєш простого рішення, аж допоки не пройдеш три кола пекла, щоб зрозуміти де проблема.

Але в згаданій ситуації здається, що ключова проблема тут:

інженер працює з LLM, дебажить або пише код, не до кінця розуміючи, що відбувається

Проблема не в АІ, а в тому що інженер вимкнув мозок

Мозок — штука дуже затратна, людина його вимикає кожного разу, коли їй здається, що можна. Саме тому шкода від ШІ буде так очевидна в інженерії — вимкнутий мозок легко пропустить ШІ-слоп. ШІ створює соціально-прийнятну можливість вимикати мозок.

Підписатись на коментарі