Обновить

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

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

Поддерживаю (автор сам ответил "токены - стоят денег").

"Не завалим ли себя с головой" - в статье есть ответ - "вайб-кодинг" (и отмечено, что "Чем нативнее-чище, тем - меньше заморочек").

Продвигаю две мысли:
1. Аксиома: AI (в т.ч. с известными недостатками LLM) - принципиально новая технология (в нашем случае - процесса "разработки ПО (продукта)"; а в широком смысле - получения конечного результата: т.е., в случае ИТ - "оказания услуг" массам).

1.1. Сейчас - все "дружно движутся" по пути добавления (восстановления "недостающего" - "качества": "снижения ошибок", "повышения внимания"), для продолжения Старой концепции/системы/методики/инструментария "Разработка").

Чем "задирают в облака" Сложность (системы, ее цену. Или, просто, тут - действует "Закон сохранения энергии").

1.2. А надо:
1) начать (научиться, находить - что делать "первым этапом") Упрощать (точнее, "не допускать усложнения") процесс создания/получения результата;
2) чтобы (сохранить преимущества AI - возможность) Убыстрять получение результата (и Удешевление - как конкурентный фактор).

Т.е. нужна/нужны новые концепции - "Разработка на AI".
Для вайб-кодинга - "в области принятия (заказчиком, разработчиком, получателем, пользователем) рисков (провала качества, "руками" AI), и их Управления".
И первый (и основной) способ - "Принятие" (там, где это допустимо).

(т.е. пока "отдельные фирмы" - придумывают (бесконечные) Костыли, некоторые уже - стали "Передовиками (производства СССР)", отбросив "устаревшее", и "не лезя в медицину, и финансы".
Либо используют уже существующие LLM-модели, которые "никогда не врут".
А когда такие модели станут массовыми - они тоже "останутся при деле")

2. Пора уже внедрять понятие "Контракт" - описание того, что гарантирует продукт ("РФ. Бухгалтерия. Расчет ЗРП. Премия. 2026.08-0001").

Это позволит "ограничивать" стороны (в статье - это называется "границами") в своих ожиданиях.
Пользователи будут понимать:
- если будешь "забивать гвозди" (спрашивать "Кто президент США?" - вопрос, на который проваливается большинство моделей, отвечу, но) - могу и соврать (разработчик - не несет ответственности - не проверяет это, и не обвешивает валидацией);
- а вот полезную "проводку" - выполнит точно (без врак).

2.1. Такой Контракт - позволит AI-ассистентам принимать его на входе (как угодно - через файл/ Skills/MCP/ACP/A2A), чтобы "не объяснять" то, что "уже есть" (а только "измени то-то").
И вместе с новым Продуктом, Контракт - будет сохранен под новой версией.

2.2. Выложив контракты (настоящие, псевдо-, meta-) в аля "Википедию" - можно будет (нам, всем! - разработчикам и пользователям) "не объяснять" (разрабам, каждый новый проект - ассистенту; а пользователям - особенности продукта).

2.3. Т.к., (в очередной раз) есть ожидание "LLM-разработку - для домохозяек".
Напрашивается предоставить доступ и массам (например, на "добавление": без редактирования, как блокчейн).

если политика существует как большой текст, то да, ее обслуживание легко станет дороже разработки. но нормальная политика должна исполняться как код: запрет путей, обязательные тесты, лимиты, права. тогда это уже не еще один документ, а автоматический review который одинаково работает с любой моделью

Модели не всегда следуют инструкциям как и люди и не все проверки можно алгоритмизировать.

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

Публикации