Комментарии 3
вот можно было без всей это непонятной вайбодерам многословицы, дать волшебный промп:
"дорогой клодушка, работаем по SDLC строго".
и все..
Электрики и менеджеры с клодом (и китайсами llm) выдают продукт как опытный архитектор и кодер (ну и немного терпения в черном экране до готовой crm\erp)
Дальше вся магия и "открытия гейтов", "конформансы"... как из рога изобилия обучающей базы llm даже китайцы выдают.
Соглашусь с фактической частью. Промпт уровня работаем по SDLC строго правда заводит проект: порог упал, и человек без инженерного прошлого сегодня соберёт что-то работающее, вплоть до несложной CRM. Для одноразовой вещи этого процесса достаточно, никакие ворота там не нужны, и в статье об этом сказано прямо.
«Выдают продукт»: агент выдаёт то, что запускается и проходит собственные тесты, и сам сообщает, что сделал по SDLC. Это нельзя проверить изнутри: код, тесты и документацию писал один и тот же агент, они согласованы между собой и могут все вместе не соответствовать задаче. Запуск и зелёные тесты ещё не значат, что результат правильный (а результат тут понятие широкое, от архитектуры до понимания задачи: что там агент мог додумать или где схалтурить).
Ворота нужны не для того, чтобы объяснить модели слова gate и conformance, их она знает из обучающей базы. Они закрывают то, что нельзя поручить модели: задать критерии приёмки до работы и проверить результат независимо после. Напомню про Османи (The 70% problem): модель закрывает основную часть задачи и спотыкается на остатке, и остаток как раз про корректность, а не про то, что код запустился.
Личный инструмент или прототип голым промптом собрать можно, тут методология не нужна, и в статье это сказано. А сложную CRM или ERP качественно так не собрать. Промпт даёт то, что запускается и проходит демо. Качество держится не на модели, а на инженерной дисциплине вокруг неё: те же критерии приёмки и независимая проверка. Применять её можно руками, можно через инструмент, чтобы не пропускать шаги. Без неё на выходе прототип, который до рабочей системы не дотягивает, и разница не видна, пока система не пошла в продакшн или в доработку. Дальше без структурного управления разработкой (притом любой в общем-то) просто снежный ком проблем.
Я тут немного всё же акцентирую ещё внимание - в моем мире на текущий момент и состояние ИИ есть два понятия - “вайб-кодинг” и “агентно-ориентированная разработка” - соответственно и отличия характерны. В первом случае можно играть в лотерею и вне зависимости от результата стрелять себе в ногу путем промпт-инженеринга, во втором - всё же полагаться на чёткое планирование и понятный и предсказуемый насколько это возможно результат.
Да, вы правы, с моей стороны это было отчасти шутка, что ИИ теперь и дисциплину доставляет то, чему раньше были носители лишь инженеры. Конечно менеджер теперь может много больше + волшебные промпты. Да если он не строил ERP, будет проходить то, что проходили мы на своих платформах вручную, выстрадав понимание, что владеть продуктом, сильно сложнее лишь его создания.

Границы 100% разработки с агентами