К предыдущей части

Kicker: Главный риск: потеря наблюдаемости

Есть ещё одна проблема, о которой почти никто не говорит. Когда код пишет человек, то он хотя бы примерно понимает где что лежит в репозитории, как связаны сущности, куда смотреть при инциденте. А вот когда код пишет агентная система, появляются сотни тысяч строк и логика приложения в таком случае размазана по слоям, потому что порой решения принимались неявно. И в какой-то момент никто уже, кроме самого AI-интсрумента, не понимает систему.

В итоге мы приходим к тому, что первая же ошибка на production окружении приведет к ряду вопросов: – а где собственно баг и в чем он заключается? – а это архитектура или реализация? – а это requirement issue или code issue?

Человек уже не сможет ответит на эти вопросы и единственная мысль будет: “надо спросить у AI-агента”. В итоге мы получаем не рабочую эксплуатационную модель, а неконтролируемую стохастику в виде лотереи.

Но (и это важно) — агентные системы реально работают.

И я не хочу тут сразу сгущать краски и покрывать все хейтом. Потому что это будет неправда. Я сам использую такие пайплайны и вижу, что при правильном подходе: 1. они ускоряют исследование 2. помогают в декомпозиции 3. реально улучшают TDD 4. позволяют быстро перебирать архитектурные варианты

И да, существуют команды, использующие AI, без “классического” бэкграунда, которые читают документацию, понимают ограничения. Они используют готовые agent stacks и делают работающие продукты. Это факт. Но важно немного другое.

Necessary vs Sufficient

Наличие Claude Code, MCP и набора агентов, модного skill-based пайплайна — это не достаточное условие. Это максимум необходимое. А вот достаточное в данном случае это: понимание SDLC и умение валидировать каждую фазу, контроль спецификации к разработке и контроль архитектуры, а также контроль тестовой модели. Ну и самое главное — это умение остановить агента и сказать: “ты сейчас несёшь ЕРЕСЬ”

Про “замену инженеров” или “AI убийца профессии программист”

Сейчас продаётся часто идея “один продукт + агенты заменят команду”. Нет, этого не случится, потому что на каждом этапе остаётся необходимость: – анализа (глубокого) – валидации (квалифицированной) – принятия решений (с ответственностью)

Что поменялось? Теперь аналитик должен понимать, как работают LLM, архитектор теперь должен уметь оркестровать AI агентов, разработчик должен грамотно управлять генерацией кода и его документированием, а QA инженер должен валидировать не только код, но и пайплайн. Требования к сотрудникам в разных ролях растут, но сами роли не исчезают.

Итог

Первая волна AI была про “напиши код”. Вторая волна про “собери систему агентами”. Но суть не изменилась: если у вас нет инженерной дисциплины, вы просто быстрее строите более сложную проблему. А если есть — вы получаете кратный буст и существенно повысите Time to Market вашего продукта

#ии #ai #агенты #claudecode #mcp #sdlc #tdd #тестирование #qa #архитектура