Прибирання після «рок-зірок» ШІ: код, який команда не може прочитати

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

Сценарій «рок-зірки»

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

Армія «рок-зірок»

За словами Скіннера, більшість команд сьогодні мають справу з «армією рок-зірок». Кожна нова розмова з LLM — це ризик додати ще одну: агент не пам'ятає, що робив учора, за хвилини генерує десятки тисяч рядків коду й працює з максимальною швидкістю, не переймаючись тим, чи вписується результат у решту системи і чи стає код зрозумілішим. До того ж він приходить із набором «найкращих практик», які можуть не підходити проєкту, і наполягає на надлишкових рішеннях навіть тоді, коли додаткова складність перевищує користь.

У результаті складність системи може зростати експоненційно — іноді до рівня, коли єдиний практичний спосіб її зрозуміти — запитати в самого LLM. Розробники, команди й цілі компанії можуть стати залежними від генеративного ШІ, попереджає він.

Що робити натомість

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

Його порада — тримати LLM у допоміжній ролі: вести інженерію самому, генерувати код невеликими фрагментами й стежити, щоб результат був зрозумілим для всієї команди. Якщо ви не розумієте, що робить модель, пригальмуйте; нормально рухатися повільніше, прибирати надмірну складність і спрощувати, доки архітектура не відповідатиме складності задачі. Іноді варто залишити LLM у шухляді та написати код самому. «Майстерність завжди буде в наших руках», — підсумовує він.