Як я перейшов на вайб-кодинг

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

Стрибок у глибоку воду

9 місяців тому ми почали працювати над новим проєктом. Було зрозуміло, що на ринку є прогалина, але через декілька місяців її закриє купа рішень. Тож швидко згенерували MVP, потім перегенерували його декілька разів після отримання фідбеків. Відтоді я перестав писати код самостійно.

Виклики на старті

Згенерований код був жахливої якості — неструктуровані скрипти на тисячу рядків. Але він працював; зовні рішення виглядало добре та досягло вау-ефекту у стейкхолдерів. Тож почали його розвивати та поступово покращувати якість.

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

Кількість паралельних змін суттєво зросла. У короткий термін код змінювався настільки, що втрачалася його впізнаваність. Під час обговорень доводилося додатково перевіряти деталі реалізації. Це призвело до втрати відчуття «володіння кодом» (ownership).

Що реально працює

Я використовую GitHub Copilot, тому всі подальші рекомендації базуються на досвіді роботи саме з цим інструментом. Розумію, що з іншими тулами оптимальні підходи можуть відрізнятися. До того ж усе дуже швидко змінюється.

1. Важливо розуміти можливості та нюанси роботи обраного інструменту. Паралельно з початком проєкту я пройшов сертифікацію по GitHub Copilot. Це якісно змінило підхід та ефективність роботи.
2. Набагато зручніше працювати з монорепозиторієм, коли всі частини рішення, включаючи документацію, знаходяться разом. Це полегшує пошук потрібної інформації для агентів та дає змогу генерувати функціонал end-to-end.
3. У проєкті має бути файл AGENTS.md. Це для агентів як README.md для розробників. Він має бути невеликий за розміром, із чіткою структурою та посиланнями на окремі документи щодо кожного аспекту архітектури чи прийнятих конвенцій. Це покращує якість згенерованого коду та мінімізує використання токенів.
4. Важливо вчасно перемикатися між агентами: Ask, Plan, Agent.
   • Ask. Коли працюєш у команді, змін настільки багато, що перестаєш знати код. Потрібно прояснювати поточні деталі реалізації перед початком роботи над новою фічею. Інша справа, коли працюєш самостійно. Наприклад, при роботі з власним хобі-проєктом (якщо цікаво, YOWAY: піші прогулянки містами з аудіо) я майже не потребую Ask-агента.
   • Plan. (❗️❗️❗️) Для мене це найважливіший етап реалізації будь-яких змін — від маленьких виправлень до великих сторіс. Надаю вимоги, отримую детальний план реалізації, коригую все, що не влаштовує, включаючи назви та структури об’єктів, різні архітектурні моменти тощо. І тільки після цього стартую реалізацію. З таким підходом правки згенерованого коду мінімальні.
   • Agent. Якщо попередні кроки зроблені якісно, на цьому етапі немає жодних проблем. Коли бачу пости, що розробникам не подобається згенерований код, гадаю, вони пропускають планування і одразу заряджають промпт на реалізацію. Я і сам так робив на початку. 😁
5. Важливо тримати поточний контекст під контролем: чітко розділяти розмови за темами, відкривати релевантні файли та закривати інші в межах розмов, тегати в промптах потрібні файли та об’єкти. Усе це покращує якість згенерованого коду та мінімізує використання токенів.
6. Не можна піддаватися спокусі пропускати зміни без рев’ю і розуміння деталей.
7. Не менш важливе — оптимальне планування: розподілені в команді задачі мають бути end-to-end і не перетинатися між собою для полегшення мержингу.

Відчуття після переходу

Чую в розмовах та бачу в постах супротив і незадоволення розробників.

«Генерує неякісний код»

Це вирішується плануванням перед реалізацією. Рівень якості коду відповідає рівню заданих інструкцій при плануванні змін.

«Стало нецікаво, втрачаю відчуття авторства»

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

Майбутнє

Читаємо в інтернеті повний спектр думок: від

«Це ніякий не інтелект, він лише підбирає найбільш імовірне продовження»

чи

«З ШІ виходить довше та дорожче»

до

«Ера розробників закінчилася, і нас всіх звільнять»

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

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

Тож входимо в епоху співавторства (co-creation) та співнавчання (co-learning) із ШІ.