Обновить

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

Уровень сложностиСредний
Время на прочтение16 мин
Охват и читатели7K
Всего голосов 1: ↑1 и ↓0+1
Комментарии3

Комментарии 3

вот можно было без всей это непонятной вайбодерам многословицы, дать волшебный промп:

"дорогой клодушка, работаем по SDLC строго".

и все..

Электрики и менеджеры с клодом (и китайсами llm) выдают продукт как опытный архитектор и кодер (ну и немного терпения в черном экране до готовой crm\erp)

Дальше вся магия и "открытия гейтов", "конформансы"... как из рога изобилия обучающей базы llm даже китайцы выдают.


Соглашусь с фактической частью. Промпт уровня работаем по SDLC строго правда заводит проект: порог упал, и человек без инженерного прошлого сегодня соберёт что-то работающее, вплоть до несложной CRM. Для одноразовой вещи этого процесса достаточно, никакие ворота там не нужны, и в статье об этом сказано прямо.

«Выдают продукт»: агент выдаёт то, что запускается и проходит собственные тесты, и сам сообщает, что сделал по SDLC. Это нельзя проверить изнутри: код, тесты и документацию писал один и тот же агент, они согласованы между собой и могут все вместе не соответствовать задаче. Запуск и зелёные тесты ещё не значат, что результат правильный (а результат тут понятие широкое, от архитектуры до понимания задачи: что там агент мог додумать или где схалтурить).

Ворота нужны не для того, чтобы объяснить модели слова gate и conformance, их она знает из обучающей базы. Они закрывают то, что нельзя поручить модели: задать критерии приёмки до работы и проверить результат независимо после. Напомню про Османи (The 70% problem): модель закрывает основную часть задачи и спотыкается на остатке, и остаток как раз про корректность, а не про то, что код запустился.

Личный инструмент или прототип голым промптом собрать можно, тут методология не нужна, и в статье это сказано. А сложную CRM или ERP качественно так не собрать. Промпт даёт то, что запускается и проходит демо. Качество держится не на модели, а на инженерной дисциплине вокруг неё: те же критерии приёмки и независимая проверка. Применять её можно руками, можно через инструмент, чтобы не пропускать шаги. Без неё на выходе прототип, который до рабочей системы не дотягивает, и разница не видна, пока система не пошла в продакшн или в доработку. Дальше без структурного управления разработкой (притом любой в общем-то) просто снежный ком проблем.

Я тут немного всё же акцентирую ещё внимание - в моем мире на текущий момент и состояние ИИ есть два понятия - “вайб-кодинг” и “агентно-ориентированная разработка” - соответственно и отличия характерны. В первом случае можно играть в лотерею и вне зависимости от результата стрелять себе в ногу путем промпт-инженеринга, во втором - всё же полагаться на чёткое планирование и понятный и предсказуемый насколько это возможно результат.

Да, вы правы, с моей стороны это было отчасти шутка, что ИИ теперь и дисциплину доставляет то, чему раньше были носители лишь инженеры. Конечно менеджер теперь может много больше + волшебные промпты. Да если он не строил ERP, будет проходить то, что проходили мы на своих платформах вручную, выстрадав понимание, что владеть продуктом, сильно сложнее лишь его создания.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации