Когато AI агент прецака production – и какво научих от това

Искам да ти разкажа за момента, в който разбрах, че трябва да променя изцяло начина, по който работя с AI агенти за кодене.

Бях затънал в дебъгване на "проста" функционалност. Агентът беше commit-нал промени, push-нал към production и дори оставил жизнерадостно съобщение, че задачата е изпълнена. Единственият проблем: кодът беше напълно сбъркан. Не просто с бъгове – ами принципно не разбираше какво се опитваме да построим.

Този инцидент счупи нещо в главата ми. Дотогава третирах тези агенти като полезни junior разработчици, на които им трябва насоки. Но junior разработчици не качват нетестван код в production, докато ти спиш.

Затова смених метафората напълно.

Рамката на подизпълнителя

Вместо да третирам AI агентите като служители или асистенти, сега ги третирам като подизпълнители. Ето какво означава това на практика:

Подизпълнителят няма ключове за сградата ти. Не се появява неканен. Свършва своята работа и ти изпраща фактура – която ти преглеждаш преди да платиш. Ако работата е под стандарта, я връщаш.

Става дума не за недоверие. Става дума за подравняване на стимулите и отговорността. Когато подизпълнителят разбере, че ролята му е да достави завършен артефакт за твоя преглед – не да взима еднолични решения – той се представя по-добре. Фокусиран е. Продуктивен е в рамките на зададените граници.

Техническото изпълнение

Тази ментална рамка се нуждае от технически зъби. За моите проекти това означава:

Scoped токените са всичко

Моите агенти работят с credentials, които физически не могат да докоснат production. Имат read достъп до основния код и write достъп до отделно staging хранилище. Това не е политика – това е криптографско ограничение. Дори ако агентът полудее или генерира измислени git команди, той не може да промени production код. Токените просто няма да го допуснат.

Staging хранилището е пощенска кутия

Нищо не се merge-ва от staging автоматично. Default branch-ът на staging repoто буквално е гробен камък – branch с име "no-main", който съдържа само README с текст "моля, използвайте main branch-а на оригиналното хранилище".

Агентите push-ват готовата си работа тук. Уведомяват ме когато branch-овете са готови. След това аз преглеждам, cherry-pick-вам това, което работи, и интегрирам ръчно. Изглежда досадно – докато не осъзнаеш: точно така работи Linux ядрото от двайсет години. Contributors изпращат patch-ове. Maintainers ги прилагат.

Прегледът не подлежи на преговори

Никой агент никога не merge-ва собствения си код. Точка. Branch не се изтрива, докато не съм проверил – независимо, програмно – че неговите commits са безопасно в production. "Довери се, но провери" не е достатъчно, когато проверката е безплатна.

Защо това работи за самостоятелни разработчици

Ето каквото трябва да знаеш за самостоятелния разработчик или малкия екип: ти не само строиш софтуер. Ти поддържаш контекст, който не съществува никъде в кодовата база. Твоята история от инциденти. Твоите edge cases. Клиентът с особената конфигурация. Трите неща, които опита и не станаха.

Агентите нямат достъп до този контекст. Четат файлове, но не разбират твоя свят. Затова целта не е да им дадеш повече автономия – а да максимизираш работата, която могат да свършат безопасно в рамките на твоя bandwidth за преглед.

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

Практическата полза

Веднъж щом приемеш отношенията подизпълнител, нещо неочаквано се случва: започваш да поемаш повече рискове. Готов си да пуснеш онази експериментална функционалност, защото downside-ът е ограничен. Агентът не може да счупи production. Може да достави нещо изненадващо грешно или изненадващо добро – но и в двата случая го хващаш преди да е станало проблем.

Започнах повече странични проекти в последните шест месеца, отколкото в предишните две години. Не защото работя повече – защото делегирам агресивно в безопасни граници.

Как да го вградиш в работния си процес

Ако използваш AI агенти за разработка, попитай се:

1. Какво може да пипа агентът ти в момента? Ако отговорът е "production" – това е проблем.
2. Има ли техническо ограничение, което предотвратява грешни действия, или само политика?
3. Кой merge-ва кода? Ако не е човек – защо?

Инструментите съществуват. Scoped токени, отделни staging хранилища, branch protection – това не са екзотични Git workflow-та. Това е разликата между AI-assisted development и AI-accidental disasters.

Ние в NameOcean мислим много за това, докато изграждаме vibe coding поддръжка в нашата хостинг среда. Целта не е да автоматизираме всичко – а да създадем пространства, където AI може да бъде наистина полезен, без да създава нови категории рискове.

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

Строй съответно.