Nutgraph: Агентная разработка — это не серебряная пуля. Но и не игрушка

После первой части мне справедливо прилетело: “Ты прав, но ты всё же упростил”. И это правда, потому что с момента, когда мы говорили “не путайте prompt с разработкой”, индустрия уже сделала следующий шаг — агентные системы, MCP, оркестрация, skill-based пайплайны. И вот здесь важно не впасть в другую крайность.

Kicker: Проблема не решилась. Она усложнилась

– Раньше было просто: человек без опыта -> пишет prompt -> получает мусор (но в своем блоге в Instagram или YouTube всем рассказывает какой он красавец и как это здорово, классно, просто и доступно все “навайбкодить” – Теперь стало сложнее: человек без опыта -> поднимает MCP -> подключает 10+ агентов -> запускает “research → design → plan → code → test”… И получает… уже НЕ мусор.

Во втором случае человек получает правдоподобную систему, которая: – выглядит архитектурно осмысленной – покрыта тестами – разбита на компоненты – даже местами следует best practices

И вот это уже опаснее. Почему? Потому что теперь ошибка не очевидна.

Где на самом деле ломается агентная модель

Даже в хороших сетапах (типа get-shit-done): 1. есть исследование 2. есть дизайн 3. есть планирование 4. есть тестирование требований (!) 5. есть генерация тестов

И только потом кодю Причем можно еще применит ряд скиллов для код-ревю, UAT на преднастрроенном окружении и есть еще ряд самопроверок у оркестратора агентов, которыми он может как будто бы посмотреть на поделие и понять “а не дурак ли я? а не ошибся ли я?..”

Звучит почти как SDLC. Но ключевой вопрос не изменился: кто валидирует каждый слой? Потому что в реальности происходит следующее: агент-аналитик сгенерировал требования -> агент-архитектор их “понял” -> агент-разработчик что-то реализовал -> агент-тестировщик что-то проверил. И всё это может быть внутренне консистентно, но неверно. Почему? Да потому что это самая неприятная категория ошибок — разрабатываемая система согласована сама с собой, но не с реальностью. Spec Driven становится не просто важным — он становится критическим. В первой части я говорил, что без спецификации никуда.

💡И я еще раз усилю свой тезис: “Без формализованной, валидированной спецификации агентная разработка становится генератором согласованной галлюцинации.”

То, что должно всегда присутствовать в вашей AI-разработке: – явная модель требований (не “текстик”, а структура) – валидация требований (людьми) – тестовая модель (до кода, а не после) – маппинг: требования → тесты → код И вот тут мы приходим к следующему шагу - Test-Driven Development (TDD).

TDD — это не “потом”. Это фундамент

Я хочу подсветить еще раз одну важную вещь. Если агент не умеет строить тестовую модель, генерировать тест-кейсы из требований, валидировать покрытие — всё остальное не имеет смысла, потому что: 1. код можно сгенерировать 2. архитектуру можно “придумать” 3. но корректность можно проверить только через тестовую модель И да, это не только unit-тесты, это еще API тесты и контрактные тесты, security-тесты, UI тесты, а также нагрузочное тестирование (о котором, кстати, большинство вайбкодеров и Instagram гуру просто забывают или не знают). Если перечисленного нет, то “поздравляю“ у вас есть тесты, но их наличие = иллюзия контроля.

Продолжение в ч.3

#ии #ai #агенты #claudecode #mcp #sdlc #specdrivendevelopment #tdd #тестирование #qa #архитектура #аналитика #разработка #инженерия