Пропонується приваблива ідея: від концепції «найкраща документація проєкту — це якісний, грамотно написаний код» перейти до практики «найкращий код — це повноцінна специфікація».

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

Це досягається завдяки поступовому накладанню обмежень та уточненню вимог через діалог із розробником. Як бонус ми маємо повноцінний комплект документації, що однозначно відповідає коду. Код = F(spec).

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

Цікавими є коментарі: від захоплених до радикально-скептичних. Ось один із них:

«Невже замовнику тепер доведеться писати ті самі повні специфікації, про які розробники благали роками? Невже це кінець епохи „зробіть, а там розберемося“? Невже доведеться працювати правильно?»

Звідки стільки скепсису? Що ж може піти не так?

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

По-перше, розробник не навчений створювати специфікацію, його робота — чітко її дотримуватися. Через це її валідація була фактично відсутня.

По-друге, спроба провести верифікацію новостворенного "Плану” показала, що перевірити специфікацію складніше, ніж згенерований код. Я припускаю, що проблема є комплексною. Код простіше токенізувати, розбити на семантичні конструкції, він формалізований і звичний для розробника. Його недоліки очевидні, а для верифікації коду існує звичний інструментарій, що формувався десятиліттями. Специфікація в цьому сильно програє: навіть md-форматування виглядає суцильним текстом порівняно програмним кодом. Додає проблем той факт що один і той самий промпт буде реалізований по-різному різними LLM.

Гадаю, зараз ентузіасти використання ШІ для розробки перебувають у тій самій ситуації, що й перші програмісти епохи перфокарт. Недарма більшість інструментів нагадують консольні застосунки часів PDP-11.

Далі — гірше. Імовірність правильного розв'язання задачі для найкращих моделей коливається в межах 50% (можете самостійно вивчити цей звіт). Наявне завдання проходить кілька етапів, результатом кожного з яких є полотно погано структурованого тексту. Помилки та галюцинації не блокувалися, а перетікали на наступний рівень і змішувалися з новими. Таким чином, для триетапного процесу загальна ймовірність успіху падає до 12,5% (0.5 × 0.5 × 0.5).

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

У підсумку виявилося, що в моєму випадку простіше й надійніше передавати розробнику вимоги у вигляді класичного PRD-файла. В якості агента використовується розширення RooCode для VS Code. Короткий цикл підключає до процесу розробника, а всі доопрацювання відображаються безпосередньо у змінах PRD-файла.

Однак це не означає, що Spec Kit має всі ті самі проблеми. Думаю, я протестую його на одній з найближчих ітерацій і поділюся враженнями.

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

Перший дзвіночок: блукаючі шаблонні рішення

Першим таким дзвіночком став процес рев'ю тестових завдань кандидатів. З певного моменту в них почали з'являтися дивні фрагменти. Цікаво було те, що ці шаблонні рішення кочували з одного завдання в інше, але ніколи не траплялися повним набором — завжди частинами. Стало очевидно, що кандидати систематично застосовують ШІ для генерації коду. Скажемо так, з досить сумнівним результатом.

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

Новий «колега» в команді

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

На риторичне запитання: «Ну і навіщо ти це написав?» — я отримав досить самоіронічну відповідь: — От не знаю, ChatGPT поплутав...

Стало зрозуміло, що в команді з'явився новий «розробник» із високим рівнем авторитету, який не підпорядковується загальним вимогам. Такий собі містер всезнайко. Ігнорувати його появу було щонайменше нерозумно.

Зіткнення з «вайб-кодингом»

Поки ми примірялися: використовувати чи не використовувати, а якщо так — то як, наші колеги вже діяли. Аналітики, DevOps-інженери тощо вже почали вирішувати свої нагальні завдання за допомогою ChatGPT.

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

Все це чудово, поки вам не запропонують взяти такий продукт на баланс, щоб підтримувати й розвивати. У такий код практично неможливо внести контрольовані зміни, і здається що його простіше переписати з нуля. Так створюється новий клас одноразових застосунків. І як з’ясувалося, це тренд, який нам зараз продають через обгортку у вигляді Specs Driven Development. І доведеться скуштувати чергову серебряну кулю, яка всіх нас залишіть без діла :)

Висновок

У якийсь момент прийшло розуміння: скриньку Пандори відкрито, і цей процес вже не зупинити. Найкращим способом адаптації завжди був принцип: не можеш щось зупинити — очоль це.

Наостанок — кілька слів про мене, щоб ви вирішили, чи варто витрачати час на мої дописи.

Я не можу похвалитися роботою у FAANG, проте більшу частину свого життя я працював на невеликі компанії або створював щось для себе. Кілька років тому я почав розвивати напрям навчання нейромереж, коли це ще не було мейнстримом. Це починалося як невеликий R&D-відділ, і своїм головним досягненням я вважаю те, що цей відділ перетворився на повноцінну компанію.

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

У планах — публікувати суміш ретроспективних дописів (щоб можна було поностальгувати) та матеріалів про актуальні експерименти.