На днях мы с семьёй ездили купаться со знакомыми. Среди них был разработчик с большим опытом — человек, который много лет профессионально пишет код.
Разговорились про AI-разработку.
Он сам сейчас активно использует Claude Code, очень им доволен, но сказал интересную вещь:
«Я не готов отвечать за код и проекты, которые написал Claude».
И вот здесь у нас возник спор.
Я сейчас вообще стараюсь не использовать термин «вайб-кодинг» для всей разрабокти через нейронки. Для меня вайб-кодинг — это когда ты просто говоришь нейросети: «сделай мне вот это», особо не понимаешь архитектуру, не контролируешь процесс и ждешь, пока всё заработает.
Мы в своих проектах пытаемся строить совершенно другой подход: разработка с помощью AI по формализованному протоколу.
Как это выглядит у меня.
Сначала появляется задача или новая функция.
Первый этап — подробное ТЗ. Мы раскладываем бизнес-логику, сценарии, ограничения, пограничные случаи, ожидаемое поведение.
Потом Claude идёт непосредственно в существующий проект и проверяет, насколько это ТЗ вообще совместимо с текущей архитектурой.
Если обнаруживаются противоречия, зависимости или проблемы, мы сначала меняем ТЗ и только потом начинаем разработку.
Дальше разработка идёт субагентным методом.
Несколько агентов работают параллельно: пишут код, проверяют изменения, запускают тесты, ищут ошибки, подтверждают их, исправляют и снова тестируют.
После завершения разработки изменения отправляются в работу.
Но на этом процесс не заканчивается.
После крупных/средних изменений я запускаю отдельное глубокое ревью проекта — опять же субагентным методом.
Иногда такое ревью идёт много часов. Мой личный рекорд — 474 запущенных субагента, сутки ревью в рамках проверки одного проекта. Найдено было 12 критических ошибок и что-то около 30 мелких, больше косметических.
Важно, что задача агентов не просто написать список потенциальных проблем.
Если агент считает, что нашёл ошибку, он должен попытаться её воспроизвести и подтвердить. Потенциальные проблемы отделяются от реально подтверждённых.
В конце получается большой отчёт.
После этого подтверждённые ошибки исправляются, изменения снова тестируются, и цикл повторяется.
По сути, у нас постепенно появляется протокол AI-разработки.
И именно через него я смотрю на вопрос ответственности.
Если разработчик обязан:
— нормально подготовить ТЗ;
— проверить его на совместимость с архитектурой;
— соблюдать правила разработки;
— провести тестирование;
— провести обязательное ревью;
— отработать найденные проблемы;
и он всё это сделал, но дефект всё равно прошёл в проект — я не считаю правильным автоматически вешать этот дефект на разработчика.
Он выполнил утверждённый компанией процесс.
Значит, это остаточный технологический риск, который принимает компания.
Если же разработчик решил срезать угол — не провёл ревью, проигнорировал тестирование, не проверил архитектурные последствия или нарушил другой обязательный этап протокола — тогда уже возникает его персональная зона ответственности.
Мне кажется, именно так компаниям стоит подходить к AI-разработке.
Проблема не в вопросе:
«Можно ли доверять коду Claude?»
Это неправильный вопрос.
Мы ведь и человеческому коду не должны просто «доверять».
Правильный вопрос другой:
Какой процесс должен пройти код — независимо от того, написал его человек или AI, — прежде чем компания готова принять связанный с ним риск?
И если этот процесс формализован, появляется сразу две вещи:
- существенно снижается вероятность критической ошибки;
- становится понятно, где заканчивается ответственность разработчика и начинается ответственность компании.
Роль человека в разработке смещается — с «писать код» на «проверять и направлять», почитать можете тут. А значит и ответственность надо считать не по строчкам кода, а по соблюдению процесса.
Относительно нашего спора, сошлись на том, что обсудим наш протокол разработки через ИИ, а там решим ок это или нет.
Спасибо, что дочитали 