Пост для тех, кто задается вопросами эффективности промтов, думает о том, как-бы очередной важный токен не оказался тем самым потерянным в середине (lost in the middle) и в целом заботится о гигиене контекста.

Если верить тому же Андрею Карпатому - мы на пороге перехода парадигмы от Software 1.0 (пишу код) через Software 2.0 (кода нет, есть веса, обученные на данных) к Software 3.0 (промпт + агентная среда = новый исходник, который исполняет LLM).

А что, если большинство инженеров давно не работают с моделями напрямую? Сможет ли такой инженер составлять промты как SE3-специалист?

Мое резюме: без ML-инженерного минимума не сможет. Понимание того, как ведут себя модели, навык построения evals, управление контекстом и верификация недетерминированного вывода дадут вам “более стабильные промты”, а не “просто красивые”.

По сети гуляют ложные трактовки Карпатова: мол, получишь продукт, если есть четкое понимание того, что ты хочешь, а техническими знаниями можно пренебречь. ИМХО, Карпатый говорит строго об обратном: промпты недетерминированы, их не отладишь как код (пока), роль инженера не исчезает - она смещается к проектированию среды и контролю.

Я начал реализацию XDLC фрейма на базе AI-Disrupt PDLC именно с целью ускорения процесса проектирования среды и ее контроля. И уже на первых этапах согласен с Меньшовым: это прямое изменение всех бизнес-процессов разработки, от Waterfall -> Agile -> DevOps -> к "агентный цикл работает без меня -> я вношу изменения в “начальные намерения” только по мере необходимости".

Лично для меня это революционный подход. Что он несет в процессы:

1. Unit of work больше не коммит. Unit of work - это ваши “намерения”. Теперь мы версионируем super-абстрагированный юнит входа: промпты, скиллы, БЗ, спецификации, документацию. Код еще лежит рядом, но уже не как “точка истины” - он становится побочным артефактом работы среды. В будущем это кандидат в gitignore, как vendor/node_modules/etc.

2. Code review вырождается в intent review. Ревьюер будущего смотрит не на “что изменилось”, а на “сохранилось ли исходное намерение в реализации”. Плюс LLM-as-judge и дифференциальное тестирование (старый код vs агентный вывод на одних и тех же кейсах) - один из возможных CI будущего.

3. Верификация - новое узкое горлышко. Агент пишет быстро, человек проверяет медленно. Кто построит жесткую инфраструктуру верификации (тесты как гейты, трассировка от намерения к изменению, аудит) - тот и получит Dark Factory. Кто не построит - получит стохастический конвейер с неизвестной долей брака в “продукте”.

Поясню на примере “земли”. Представьте пресловутый Dark Factory (“темный завод” - цеха работают без постоянного присутствия человека): на входе инструкции/сырье/спецификации, на выходе готовый к дистрибьюции продукт. В PDLC-подходе тоже самое, только утрировано “до нельзя”: 100500 артефактов/скиллов/БЗ и прочей макулатуры - все это в конце концов “намерение”, тот самый юнит входа.

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

К чему я все это? Если я не знаю, как ведет себя модель под нагрузкой, как деградирует retrieval, как врать evals - я буду писать “намерения”, которые красиво звучат и тихо ломают будущий прод.

Принцип отбора в команду SE: вам недостаточно быть хорошими программистами + DevOps-ерами и продуктологами. Вам нужен ML-инженерный минимум: поведение моделей, evals, управление контекстом, проектирование среды и контроль агентов.

Но закроет ли это образование и курсы? Анализирую рынок. Пока, к сожалению, не уверен.

Дак откуда страна возьмет таких инженеров? Вам придется ими стать, нет команде /выгорать! 😂 (с)

#IT #AI #ИИ #XDLC #SDD #агенты #метрики #автоматизация #импортозамещение