Защо vibe coding е само началото, а не краят на пътя

Замисли се за следното: един предприемач ми показа уеб приложение, което направила за уикенд с AI инструменти. Без диплома по computer science, без bootcamp - просто ясна идея и добри промптове. Наистина впечатляващо. За 72 часа имала система за вход, dashboard и съхранение на данни.

После ме помоли да й помогна да го пусне при реални потребители.

И тук започнаха проблемите.

Прототипът работеше, защото тя беше единственият потребител. Щом добавихме втори човек, излязоха бъгове с едновременен достъп. Базата данни не поддържаше миграции, така че връщане назад щеше да изтрие информация. Нямаше тестове - всяко преправяне беше като обезвреждане на бомба със затворени очи. Deployment-ът пък беше ръчен процес без никаква документация.

Създаденият за уикенд проект беше страхотно доказателство на концепцията. Но не беше софтуер готов за production.

Това е разликата, която разговорът за "vibe coding" продължава да подминава. Инструментите са реални, скоростта е реална, а демократизацията на създаването на софтуер е наистина вълнуваща. Но има разлика между генериране на код и инженерство на софтуер. И тази разлика има значение повече, отколкото повечето хора осъзнават - чак докато седят пред 3 часа през нощта пред проблем в production.

Каквато и метрика да използваш

Ето въпросът, който си задавам, когато виждам AI-генериран код: може ли това безопасно да бъде интегрирано в споделена кодова база?

Не "работи ли". Не "демото мина ли". Безопасно за сливане. Тази дума носи много тежест. Тя означава, че кодът може да бъде прегледан от човек, който не го е писал. Че тестовете проверяват поведение, а не просто дали нещо се счупва. Че връщане назад е възможно без загуба на данни. Че промяната е достатъчно тясна, за да бъде разбрана и обяснена.

Когато vibe coder-ът мери успех, обикновено мери времето до първата работеща версия. Това е полезна метрика за проучване и създаване на прототипи. Но когато софтуерът влезе в споделена среда, тази метрика вече не е полезна. Сега мериш time to safe merge, а това включва цената на прегледа, качеството на тестовете, риска от deployment, координационните разходи и бъдещото натоварване за поддръжка.

Софтуерният инженер мисли за целия този жизнен цикъл от самото начало. Vibe coder-ът често открива тези проблеми по-късно - когато те струват повече за отстраняване.

Генериране срещу Притежание на код

Има една фина, но критична промяна, която настъпва, когато AI генерира твоя код. Изходът не е още твоя работа. Това е начална точка, която трябва да бъде трансформирана в нещо, което реално притежаваш.

Притежание означава няколко неща. Можеш да обясниш всяко важно решение в промяната. Разбираш защо съществува всеки файл и какво прави. Си обусловил промяната точно до необходимото - без излишен boilerplate или почистване на несвързани неща. Написал или проверил си тестове, които проверяват поведение, а не просто метрики за покритие. Помислил си за пътя за rollback.

Това е работата, която AI не може да свърши вместо теб. AI генерира. Ти решаваш. А "решаваш" означава, че си помислил за алтернативи, преценил си компромисите и си разбрал последиците.

Когато гледам AI-генериран код, който не е бил правилно притежаван, често виждам едни и същи проблеми. Промени, твърде големи, защото моделът е генерирал повече от необходимото. Пакети, добавени без ясна обосновка. Тестове, които изглеждат написани, за да задоволят инструмент за покритие, а не да хващат реални бъгове. Boilerplate, който съществува, защото моделът по подразбиране генерира scaffolding, вместо простота.

Никое от тези неща не е вина на AI. Те са резултат от автор, който е третирал генерирания изход като прогрес, а не като суровина.

Проблемът с прегледа, за който никой не говори

Ето нещо, което ме тормози: AI-генерираният код променя уравнението на прегледа.

Когато човешки инженер пише код, обикновено има следа от решения. Може да не си съгласен с техните избори, но поне има такива. Можеш да попиташ защо са използвали тази абстракция, защо валидацията е там, защо са избрали точно тази библиотека. Отговорите могат да са "не съм се замислял" или "изглеждаше разумно по онова време", но поне има кого да попиташ.

При AI-генериран код обаче част от тези "решения" изобщо не са решения. Те са довършвания. Моделът е избрал даден шаблон, защото е бил статистически вероятен, а не защото е бил правилният избор за твоя проблем. И ако авторът не е преобразил това довършване в работа, която притежава, прегледът става много по-труден проблем.

Не можеш да попиташ модела защо е избрал този подход. Не можеш да попиташ автора защо е направил това решение, ако той всъщност не знае. Така че прегледът или разкрива проблемите чрез болезнено тестване, или изобщо не се случва.

Затова вярвам, че най-важното умение в ерата на AI-assisted development не е писането на промптове. То е способността да вземеш генерирания изход и да го превърнеш в код, който разбираш достатъчно дълбоко, за да го притежаваш, обясниш и поддържаш.

Какво означава това за твоя екип

Ако строиш прототип, за да тестваш идея, vibe coding е легитимен подход. Скоростта на учене има значение, когато все още валидираш предположения. Използвай инструментите, движи се бързо, направи нещо, което да покажеш на хората.

Но ако този прототип ще стане реален продукт, в даден момент генерираният код трябва да премине през филтъра на човек, който мисли като инженер. Не за да gatekeep-ва. Не за да забавя нещата. А за да гарантира, че това, което се пуска, е код, който екипът може да разбере, поддържа и на който да се довери.

В NameOcean виждаме този модел непрекъснато. Стартъпи, които се движат бързо с AI инструменти, за да валидират идеите си, след което удрят стена, когато трябва да мащабират. Добрите ones качват инженерна помощ в този момент. Лошите продължават да натрупват функции върху кодова база, която никой не разбира истински.

Целта не е да избягваме AI-assisted development. Целта е да сме честни къде работата започва и къде свършва. AI може да генерира код. Ти трябва да инженерстваш софтуера.

Накратко

Vibe coding е фантастична начална точка. Това е начин бързо да тестваш идеи, да разбереш какво е възможно и да преминеш от концепция към нещо конкретно без месеци традиционна разработка.

Но софтуерното инженерство е за целия жизнен цикъл. За код, който екипът ти може да прегледа, поддържа и на който да се довери, когато нещата се счупят в 2 през нощта. За промени, достатъчно тесни, за да бъдат разбрани и върнати при нужда. За поемане на отговорност за решенията - дори когато тези решения са били подсказани от AI.

Най-добрите разработчици, които познавам, използват AI инструменти в огромна степен. Те просто го правят с отворени очи. Знаят, че генерираният код е суровина, а не завършен продукт. И знаят, че в даден момент някой трябва да свърши инженерната работа, която прави разликата между готино демо и софтуер, който реално можеш да пуснеш.

Така че да, vibe code-вай на воля. Строи бързо, експериментирай свободно, използвай всякакви налични инструменти. Просто знай кога е моментът да преминеш от vibe към инженерство. Твоето бъдещо аз и бъдещият ти екип ще са ти благодарни.