Почему GenAI в кодинге работает круто, а в энтерпрайзе побед меньше

Мне кажется любой, кто занимается внедрением GenAI в энтерпрайз сталкивается с тейком «вон клод уже сам написал компилятор С, а у нас до сих пор тысячи людей в операциях сидят. Давайте развернем, значит, OpenClaw и…». И на самом интересно, а почему в кодинге победы, а в энтерпрайзе нет? Питер Тиль говорил, что именно за такими противоречиями и скрываются миллиардные компании. У меня хоть масштаб и не такой, но вопрос стоит не менее остро.

Для начала: а что мы вообще хотим от агентов? Принимать хорошие решения. И на низком уровне: какую mcp ручку дернуть и кнопку нажать на каждом конкретном шаге. И на высоком: как помочь клиенту, который не может сделать перевод в таджиктстан. Чтобы принимать хорошие решения мы опираемся на факты, комбинируя которые здравым смыслом, предсказываем, что произойдет с миром и нами от нашего выбора.

Факты бывают разные. Верхнеуровневые: «мы не умеем переводить деньги в таджикистан», «если послать человека в жопу, он обидится». Низкоуровневые: «кнопка «платежи» на главной, открывает экран со всеми платежами, включая трансграничные», «если написать console.log(“hello”) в коде, то в логе появится запись hello». Общие для всех: «import “x.h”» добавит в модуль сигнатуры внешних объектов». Специфичные для организации: «лучше всех на второй линии проблемы с комплаенсом решает Иван Андреевич». Неизменные во времени: «Т-Банк основал Олег Тиньков». И изменяющиеся: «Сбером управляем Герман Греф».

К чему я. Чтобы LLM смогла качественно решить проблему ей нужны ВСЕ верхнеуроаневые и низкоуровневые факты, необходимые для правильного решения. Эти факты могут лежать либо в весах, либо в контексте. Других вариантов нет.

И именно в SDLC покрытие фактов в силу природы задачи самое хорошее: вся информация о языках программирования и инструментарии живет в весах LLM. Вся специфика задачи закодирована самой кодовой базой + инструкциями со стороны инженера, управляющего агентом. Остается сделать правильную организацию работы со всем этим контекстом, чтобы поехало.

А в энтерпрайзе не так. Там половина регламентов живет в головах и передается из уст в уста. Базы знаний устаревают и противоречат реальному положению дел. Нет дешевых аналогов юнит и интеграционных тестов систем (а значит и reward сред). Так что просто дать модели все доступные ручки и накинуть RL не получится. Нет, она придумает бизнес процесс за вас, только результат вам не понравится.

Что делать? Мы с командой уже несколько лет занимаемся внедрением ллм в операционные процессы и выработали очень простой rule-of-the-thumb. Хочешь успех: своди задачу к in-context. Думай как преобразовать процесс так, чтобы в каждый момент времени у модели была перед глазами вся необходимая информация для принятия решения. Переписывайте базы знаний, записывайте регламенты, дробите процессы на более простые. Стройте системы контекст инженеринга, которые все это подтягивают в горячий контекст. Именно это должно быть фокусом инженера, а не модные харнессы и архитектуры.

Это мне кажется само по сеье интернсно: код - часто самая лучшая документация реальных бизнес процессов организации. «Банда четырех» в контексте прикладной разработки - это не столько про код per-se, сколько про управление сложностью. И мне кажется именно поэтому лучших результатов во внедрении GenAI добиваются именно инженеры (в широком смысле): все те вызовы, которые нужно решить внедряторам ИИ, мы уже сто раз видели в области software development. И когда я стал смотреть на плохие бизнес процессы, как на говнокод, внезапно все паттерны разработки софта оказались супер полезными метафорами и инструментами.

Возвращаясь к оригинальному вопросу: разница именно в том, что в SDLC мы научились структурировать и описывать сложные процессы гораздо точнее, чем в классическом бизнесе. У мира софта очевидные ограничения - не любую проблему можно решить инженеркой. Но именно эта среда наиболее благодатна для агентизации. Как только ваш бизнес процесс станет похож на софтверную систему, он приобретает это же приятное свойство.