Меня зовут Дмитрий Старов, я руковожу департаментом «Инструменты и технологии разработки» в компании «Диасофт». В профессии я уже 28 лет, и все эти годы честно работал в том, что про себя называю «цехом».
Цех – это мы с вами: разработчики, аналитики, тестировщики, архитекторы. За десятилетия мы выстроили для себя очень удобный мир. В этом мире – свой язык, свои ритуалы и своя сложность, в которой со стороны никто не разбирается. Человек из бизнеса смотрит на схему наших микросервисов и хватается за голову, а мы понимающе киваем: так и задумано. Внутри – интересно, комфортно. А остальное человечество давно привыкло к простому правилу: хочешь что-то автоматизировать, иди на поклон к ИТ.
Когда в этот наш мир пришли нейросети, которые пишут код, цех отреагировал так, как реагирует любое сообщество на угрозу. В профессиональных чатах обмен практиками сменился обменом анекдотами. Жанр узнаваемый: то модель выдумает метод, которого нет ни в одной библиотеке, то ассистент уверенно починит падающий тест, закомментировав проверку, то агент с правами на прод распорядится ими по-своему. Подтекст у всех историй один: «хрень это все, ИИ-разработка, этот модный вайб-кодинг скоро помрет».
Я читал эти чаты, в том числе на тг-канале «Департамент разработки». Над какими-то особенно прикольными случаями и сам посмеялся. Но уже тогда для себя решил, что ИИ пришел надолго, если не навсегда. И вопрос не в том, ошибается ли модель, а в том, как с этим жить и как этим управлять. Как сказал кто-то из классиков, если что-то нельзя предотвратить – это нужно возглавить. В итоге, в результате переосмысления подходов, в последний год я практически перестал заглядывать в сгенерированный код. Не потому, что махнул рукой: проверять теперь приходится другое – спецификацию, тесты и то, что система в итоге делает.
Разговор дальше пойдет про мультиагентную разработку, поэтому сразу скажу, что я под этим понимаю. Не «бригаду» нейросетей, которая вместо команды пишет код, а весь путь задачи от потребности до выпуска релиза на прод. Один агент собирает данные о том, что нужно рынку или заказчику, второй извлекает из них бизнес-потребности, третий превращает их в сценарии. Дальше агент продуктового замысла примеряет их к архитектуре системы: что из готового можно переиспользовать. А потом – декомпозиция на отдельные сервисы, техническое проектирование, код, тесты, проверка, что все сделано ровно как задумано, выпуск релиза, доставка и метрики, по которым видно, принесло ли все это пользу. Не каждое звено этой цепочки обязательно делать с помощью нейронки, часть работы спокойно выполняют обычные скрипты. Такую цепочку я дальше буду называть конвейером, и кодирование здесь – лишь одна операция из нескольких десятков.
Кстати, 7 октября мы провели онлайн-показ AI-driven Digital Q – новой версии нашей экосистемы для команд разработки, которая с помощью ИИ ведет проект от бизнес-требований до продакшена. Кому интересно, то вот ссылка на запись с показа.
В этой статье будет про то, в чем скептики правы, как мы заставляем слабую модель работать не хуже сильной, почему главная проблема – не в моделях, а в головах наших же ветеранов, и кому все это не нужно. Спойлер для тех, кто торопится: индустрия не помрет. Но и наш цех в нынешнем виде долго не протянет. Нейросети не хватает не ума, а того, что помнит опытный разработчик, но никогда этого не записывал.
Скептики, вы правы. Почти во всем
Начну с того, где мне нечего возразить.
Вот уже второй год вокруг ИИ-разработки кипят страсти, но я не видел ни одной правдивой истории, где кто-то заработал бы серьезно на одном собственном вайб-кодинге. Попытки есть, неудачных хватает, а устойчивого бизнеса, построенного на фразе «сделай мне приложение», я не встречал. Если вы считаете, что вайб-кодинг как способ промышленной разработки не взлетел, вы правы.
Мы и сами начинали наивно. Раздали программистам и аналитикам Claude Code и Windsurf и стали ждать. Не поменялось почти ничего: код стал писаться быстрее, а релизы ускорились максимум на несколько процентов. Компания начала платить за подписку, а «эффект» первой заметила бухгалтерия, в строке расходов. Примерно полгода ушло на то, чтобы признать очевидное: кодирование не было узким местом. Требование, которое прежде выполнялось два месяца, выполнялось те же два месяца и после, потому что результат долго согласуют, упаковывают, проверяют на уязвимости, раскатывают на стенды, доставляют и учат людей с ним работать. Арифметику этого эффекта подробно разобрал мой коллега Александр Сахаров, повторять не буду.
Еще болезненнее для меня – аргумент про спецификации, ведь на них я строю весь процесс. Андрей Носов, ИИ-архитектор, недавно поставил эксперимент. Он сравнил три способа получить от агента воспроизводимый результат: фреймворк спецификаций OpenSpec, фреймворк SpecKit и обычного агента на Sonnet 4.5 без всякого фреймворка. Критерий был один: чей вывод окажется самым детерминированным. Победил обычный агент на Sonnet. Андрей объясняет это тем, что спецификация хорошо работает, пока ее один раз задали на входе и больше не трогают, как ГОСТ. В живом проекте ее дописывают вместе с кодом, и она начинает дрейфовать вслед за ним. В итоге два человека, восстановив спецификацию по одному и тому же коду, получат две разные. Результат для меня неприятный, но честный. Спорить я не буду, а что мы с этим делаем, расскажу ниже.
Следующая история звучит как комплимент агентам, а на деле – это предупреждение. Егор Дьяченко, ведущий разработчик «ТИМ ФОРС», рассказывает, как в компании десять лет собирались переписать легаси, а потом, в августе, двое ребят с агентами за две недели переписали больше ста тысяч строк. Код никто не читал, а продукт получился качественнее того, что писали десять лет. Результат отличный, и Егор сам признает его обратную сторону: новый код со временем тоже станет легаси, просто написанным агентами. Я бы сказал жестче. Если взять агента и перефигачить старую систему, выйдет то же самое, только не на FoxPro, а на микросервисах, и не на формочках, а в вебе. Техдолг останется прежним, просто одет будет помоднее. А поскольку агент пишет быстрее человека, долг он наращивает тоже быстрее.
Остается самое сильное возражение, на которое у меня нет окончательного ответа. Иван Иванов, генеральный директор компании «Апрель Инновации», исходит из простого наблюдения: генеративный ИИ производит больше, чем человек способен прочитать. Кто и по каким метрикам решит, что это годно? «Черный ящик» из кода, который никто ни разу не открывал, размывает ответственность. Иван называет путь к мультиагентной разработке путем к ереси: по его прогнозу, когда выяснится, что за результат никто не отвечает, эту практику просто запретят, как веру в идолов.
Во всем перечисленном скептики правы. Ошибаются они в выводе, который из этого делают: раз вайб-кодинг не принес денег, а агенты плодят техдолг, значит, вся эта разработка с ИИ скоро умрет. Не помрет. Агенты сделали дешевой автоматизацию задач, за которые раньше никто бы не взялся, и от этой дешевизны бизнес уже не откажется. Для нашего цеха это неприятная новость, потому что меняется то, за что нам платят. Мне кажется, что виртуозный программист на C++, который знает о продукте только классы и утечки памяти, через два-три года станет никому не нужен. Может, и раньше. Нужен будет продакт-инженер, который понимает, зачем продукт существует и с кем конкурирует, и при этом разбирается в технике лучше тех, кто пришел в продукт со стороны.
Как мы заставляем GLM писать как Fable
Теперь о том, что мы делаем с дрейфом, детерминизмом и «черным ящиком». Сначала – о термине, без которого дальше не обойтись. Обвязкой, в англоязычных текстах – harness, я называю все, что окружает модель: спецификации, стандарты, архитектурные паттерны, готовые компоненты платформы, проверки, скрипты и контекст, который модель получает перед каждой задачей.
Мы не устраиваем соревнований Sonnet против Opus. Логика у нас обратная. Сначала получаем результат, который устраивает всех: спецификацию, документацию, эвалы (автоматические оценки качества результата) и тесты. Если для этого нужна сильная модель, берем сильную. А потом настраиваем обвязку до тех пор, пока ровно тот же результат не начнет выдавать слабая модель, развернутая на наших собственных серверах.
Зачем такие сложности, если можно просто платить за фронтир? Меня не устраивает зависимость от чужого релизного цикла. Если качество продукта держится на том, что вендор модели выкатит следующий Fable, это уже не инженерия, а ожидание погоды у моря. Модели у нас в основном развернуты внутри контура, мощности там есть, но скромные, и это одновременно вопрос безопасности. Ну и деньги. Мы, положа руку на сердце, очень запарились стоимостью всего этого. Отчасти поэтому у нас нет одного универсального агента на самой мощной модели. У каждого агента – своя обвязка и своя модель ровно той мощности, которая нужна для его этапа. А детерминированные шаги вроде генерации каркаса сервиса вообще не тратят токенов. Вайб-кодить каждую задачу с нуля дорого и по токенам, и по воспроизводимости: каждый раз получается что-то немного другое.
Одной спецификации для детерминизма мало, тут Носов прав. Поверх нее лежат стандарты и архитектурные паттерны, и это единственное место, где я пока не доверил бы агенту ничего. Каталогизировать их с помощью ИИ можно, но ключевые правила должны быть выжжены железом, и следит за ними человек. Спецификация по-прежнему может дрейфовать, но дрейфует она в коридоре, стенки которого не двигаются.
Есть еще платформа. У «Диасофт» – множество продуктов и годы накопленных модулей, функций, классов, компонентов и сервисов. В одной из последних продуктовых линеек, а теперь постепенно и в остальных, мы учим агентов брать готовое, а не изобретать. Готовые компоненты (в Digital Q они называются PBC, Packaged Business Capabilities) лежат в каталоге, и агент продуктового замысла первым делом сверяется с ним: что уже есть, что доработать, что создать заново. Если нужный метод или микросервис уже существует, фантазировать агенту незачем, он берет и использует. А каркас нового сервиса строит детерминированный генератор платформы, без затрат токенов. Ошибки при этом бывают – ничего страшного, доработаем. Но костяк не ломается. Про экономику переиспользования у нас уже писали, здесь мне важнее другое.
Самое интересное начинается, когда смотришь, чем именно слабая модель отличается от сильной на конкретной задаче. Возьмем банальное: к бизнес-объекту нужно добавить новый признак. Сильной модели часто хватает одной фразы, она сама сообразит, что к чему. Слабой мы расписываем все: добавь поле в таблицу, вытащи его в DTO-класс, протащи через API, в UI-сервисе сделай компонент фильтрации записей по этому признаку, и компонент может быть вот таким или вот таким. После такого разжевывания результат перестает заметно зависеть от того, что стояло «под капотом», Fable или какой-нибудь GLM 5.1.
А теперь посмотрите на это внимательно. Это не промпт-инжиниринг. Это знание, которое у опытного разработчика в голове лежит как само собой разумеющееся. Он никогда его не записывал, потому что ему это не нужно: он просто знает, что новый признак в этой системе всегда тянет за собой поле, DTO, API и фильтр в интерфейсе. Сильная модель угадывает такие вещи за счет знаний, собранных на миллионах чужих репозиториев, но угадывает не всегда и никогда не предупреждает, где именно не угадала. Слабая не угадывает вовсе, и в этом, как ни странно, ее польза: каждая ее ошибка показывает правило, которое вы забыли записать.
Вот так обвязка и выглядит изнутри: это записанная память цеха. Все остальное – детали реализации.
Отсюда и мой ответ на вопрос Ивана о том, кто решит, что результат годен. Не человек, который читает сгенерированный код. Код в этой схеме ценности почти не имеет, его можно перегенерировать. Ценность – в актуальной спецификации, документации, эвалах и агентах-ревьюерах, которые проверяют, работает ли система так, как задумано. Если работает не так, правишь спецификацию, конвейер прогоняет дельта-спецификацию, и получаешь точечную доработку, а не переписываешь все заново.
Снимает ли это вопросы «черного ящика» полностью? Нет. Андрей Носов напоминает, что конвейер Форда держался на двух вещах: декомпозиции и контроле качества. В мультиагентных системах декомпозиция пока у каждого своя, что видно по количеству фреймворков вокруг, а эвалы как отраслевая практика толком не сложились. С этим я согласен. Наша декомпозиция тоже сделана под нас, и стандарта, на который можно было бы сослаться, в отрасли нет.
Самое ценное знание в компании ни разу не компилировалось
Главная задача, с которой мы сейчас бьемся, к моделям почти не относится.
В любой компании с историей есть человек, проработавший в ней лет 20. Он помнит всю архитектуру, все модули, все места, где кто-то когда-то обжегся, упал или наступил на грабли. Он принимает решение, и решение обычно правильное. А спросите, почему именно так, и нередко услышите: ну а как еще.
Философ Майкл Поланьи в 1966 году сформулировал это так: мы знаем больше, чем можем рассказать. Экономисты потом назвали это парадоксом Поланьи и много лет объясняли, почему автоматизация спотыкается на вещах, которые человек делает не задумываясь. В ИИ-разработке парадокс перестал быть философией и превратился в техническое задание. Все, что ветеран знает, но не проговаривает, агенту нужно отдать в виде ограничений, правил и практик. Иначе агент будет честно, быстро и дорого делать не то.
Если этот перенос удастся автоматизировать или хотя бы заметно упростить, это и будет следующий шаг отрасли, куда более важный, чем очередное удешевление моделей. Пока это самое трудное из всего, чем мы занимаемся, и готового рецепта у меня нет.
Вручную это выглядит так. Опытный бэкенд-инженер просматривает задачи, которые прошли конвейер. Код работает, тесты «зеленые», но сервис достает документы из базы по одному в цикле, хотя мог бы взять пачку одним запросом. Раньше инженер просто поправил бы код. Теперь он его не трогает, а пишет для агентов новый навык групповой обработки объектов одного типа: с примерами, как надо и как не надо, и с условием, когда этот навык применять. Потом ставит в конвейер задачу исправить все такие места по этому правилу. Исправлена не одна ошибка, а целый класс ошибок, и в следующий раз агент ее не повторит. Каждый такой навык – это кусочек памяти цеха, вытащенный из головы ветерана. Пока мы делаем это руками, по одному правилу за раз.
Трудность тут – не только в методике, но и в людях. Годами в нашем цехе действовало негласное правило: чем больше ты знаешь такого, чего нет в документации, тем сложнее тебя заменить. Никто его специально не придумывал, так просто сложилось, и держаться за свое знание было вполне естественно. А теперь мы просим этих же людей записать все, что у них в голове, в виде правил для агента. По мнению ветерана, это выглядит так, будто его просят написать подробную инструкцию, как обойтись без него самого. Неудивительно, что дело идет медленно. Документация, которую 20 лет откладывали на потом, внезапно стала самым дорогим активом компании. То самое «потом» наконец наступило.
Егор Дьяченко считает, что как раз поэтому гики никуда не денутся: только они могут объяснить, почему алгоритм в модуле написан именно так еще в 2013 году. Иван Иванов возражает, что гики вымрут вместе с легаси, новых взять будет неоткуда, а модели, которые учатся на контенте, сгенерированном ими же, начнут деградировать. По-моему, правы оба, и вместе их правота дает неприятный вывод. У цеха есть окно, пока носители знания в строю и помнят, почему все устроено так, как устроено. Что не успеем записать, пока они здесь, потом придется восстанавливать буквально археологическими методами.
Вторая нетехническая проблема – в оргструктуре. Иван считает, что мы по привычке переносим на агентов знакомые процессы, а человек в этой схеме – вообще лишнее звено. В его тезисе две половины, и с первой я согласен полностью. Если раздать агентам должности из нынешнего штатного расписания и заставить их передавать задачу друг другу так же, как ее передают отделы, получится та же бюрократия, только автоматизированная. Эффективнее она от этого не становится. Производственный цикл с агентами будет другим, нежели с живыми людьми, и он уже складывается.
Со второй половиной соглашусь наполовину. Каждый живой человек, к которому нужно сбегать за решением, действительно – «узкое горлышко». Если после каждого звена конвейера сидеть и проверять, правильно ли агент собрал данные, не изменится ничего, кроме бюджета на подписки или на содержание дата-центра. Задача в том, чтобы таких точек становилось меньше, а там, где они остаются, человек бы тормозил процесс как можно меньше. Тех 15 человек, которые сидят на встречах и ни за что не отвечают, Иван предлагает отправить на «свалку истории». Я бы для начала занял их полезным делом: творческих задач будет много, ну и следить за конвейером кто-то должен.
В идеале экземпляр процесса пролетает конвейер без человека, а человек сидит «сбоку» и наслаждается жизнью и высокой зарплатой. На самом деле он подтюнивает обвязку, добавляет контекст, снимает метрики, смотрит, как все это конвертируется в деньги и во что обходится. Конвейера, который «шуршит» сам по себе и которым никто не управляет, я при нашей жизни не жду, даже у гигантов индустрии. Кстати, последний человек в этой цепочке – тот, кто решает, покупать результат или нет. Его бы тоже заменить, чтобы деньги выделялись автоматически, и тогда все срастется. Подозреваю, правда, что такого человека заменят последним.
Чья это будет кнопка
Иван Иванов любит описывать конечную точку всей этой истории как кнопку «сделать деньги»: нажал, все прошуршало, на счету прибавилось. По его прогнозу, такой кнопкой будут владеть два-три ИТ-гиганта, потому что компании сами приносят им знание о своем бизнесе, скармливая его фронтир-моделям. Кнопку хотят все, я тоже. Мне непонятно другое: почему владеть ей должны только двое-трое.
Здесь наши позиции неожиданно сходятся. Иван считает, что компания, которая собирает обвязку под собственные практики, по сути, создает свою модель в широком смысле слова. И такие изолированные сущности способны конкурировать друг с другом, а не сдавать свою уникальность в общий котел. Для меня записанная память цеха – не только инструмент, но и актив, который я предпочитаю держать на своих серверах.
У этого выбора есть цена, и ее честно называет Андрей Носов. Крупные отечественные игроки уже лет десять пытаются тренировать собственные модели, и в продакшене те раз за разом уступают фронтиру. Воронка данных у фронтир-моделей, по оценке Андрея, в миллионы раз шире того, что способна собрать отдельная компания, и обвязка, которую их разработчики закладывают внутрь, гибче любой нашей. А когда интегратор приходит на тендер, заказчик хочет «то же самое», но с крыльями, и «крылья» надо показать сразу. Без фронтира это практически нереально.
Тут Андрей прав: быстро впечатлить заказчика наш подход не поможет. Настройка обвязки под слабую модель занимает время, зато потом результат получается стабильным, повторяемым и не зависит от чужих релизов. Для демонстрации на тендере такой обмен невыгоден, для ежедневной работы – очень даже. Любопытно, что для внутренних процессов своей компании Андрей делает ровно то же, что и мы: берет самые маленькие модели, какие только возможно, в идеале настолько маленькие, чтобы крутились прямо на телефоне, потому что так дешевле. Так что быстро впечатлить помогает фронтир, а изо дня в день дешево получать один и тот же результат помогает маленькая модель с хорошей обвязкой.
И тут есть риск, который я считаю более серьезным, чем ИТ-гиганты. В энтерпрайзе сейчас продаются стабильность и ответственность, и только потом – технологии. Заказчики на нашем рынке к новому относятся, мягко говоря, скорее скептически, чем радостно, поэтому конкуренции со стороны вайб-кодеров в энтерпрайзе сейчас нет. Но я ее опасаюсь. Автоматизация полезет туда, куда раньше никто не лез, и там найдутся стартапы, а то и одиночки, которые прогремят с новыми подходами, вырастят на этом продукт и однажды придут на серьезный тендер с качествами, которых нет у больших устоявшихся платформ, в том числе у нашей.
Построить один раз хорошую платформу и дальше «жевать» ею все задачи бизнеса в уверенности, что конкурентов нет, нельзя. Нужны подразделения с сильными моделями и всем доступным инструментарием, которые смотрят, что появляется за пределами энтерпрайза. Nokia тоже продавала стабильность и ответственность, причем очень качественно, вплоть до выхода первого айфона.
Остается вопрос, что будет, если модели завтра отключат. Ничего страшного. У нас останутся спецификации, стандарты и документация, и по ним можно работать руками, причем проще, чем раньше, потому что раньше многое из этого было только в головах. Гораздо хуже другой сценарий, о котором вспоминают реже: из компании уходят ветераны, а их знание так и не записано. Тогда не остается ничего. И такой сценарий, по-моему, вероятнее.
Счастья будет чуть больше
Теперь о том, как все это выглядит со стороны заказчика. Здесь будет история про отказ, и отказ этот, на мой взгляд, разумный.
К нашему счастью, как для разработчиков, крупный бизнес состоит не из идиотов. Хайп не заставляет его забыть весь прошлый опыт и кинуться вайб-кодить самостоятельно. У опытного руководителя большого предприятия на плече сидит чертенок и нашептывает: как минимум, не будь пионером, как максимум, проверь, кто уже заработал на том, что тебе предлагают. Молодые ребята приходят с продуктом, собранным за два дня, и что-то все равно удерживает заказчика от того, чтобы броситься в эту воду и отсечь проверенных вендоров. Со стороны похоже на консерватизм. Я считаю это рациональным поведением.
Потому что ответа на вопрос чертенка пока нет ни у кого. Крупные игроки, и «Сбер» в их числе, объясняют неудачи вайб-кодинга тем, что его неправильно применяли: брали фронтир-модель и просили «сделай мне хорошо», а надо было строить мультиагентный конвейер AI-SDLC. Отчасти я к этой позиции присоединяюсь, мы строим ровно такой конвейер. Но реализации, которую можно вынести как референс в духе «смотрите, ребята сделали и заработали в пять раз больше», в индустрии пока нет. Прирост около 30% мы видим уже сейчас, а кратного эффекта пока не показал никто, и мы тоже. Будет ли счастье? По ощущениям, будет чуть больше, чем сейчас. Но не безграничное.
Андрей Носов в разговоре со мной рассказывал, как быстро сдвигается планка. В 2024 году его команда примерно три месяца делала суммаризатор на дообученной модели, и бизнес был готов столько ждать, потому что ценность казалась невероятной. Сегодня суммаризацию никто не считает фичей, она живет где-то внутри других продуктов, и прийти к заказчику с обещанием «у вас будет суммаризация», значит, не обрадовать никого. Счастья становится чуть больше ровно потому, что технологии шагнули чуть дальше, а вчерашнее чудо перестало быть заметным.
Он же наблюдает два типа компаний, которые к нему приходят. Одни что-то навайбкодили, не особенно этому доверяют, потому что оно почему-то падает, и просят сделать ревью. Другие перестраиваются на каждом шаге: стартуют с полугодового проекта на одной технологии, а заканчивают на другой, и переход делают на лету. Второй путь мне ближе, но он требует ровно того, о чем я писал выше: обвязки, которая переживет смену модели и даже смену парадигмы.
Что получается у нас, скажу без победных реляций. На линейке, где агенты обучены переиспользовать готовые компоненты, мы получаем достаточно детерминированный результат на моделях, которые не входят в число сильнейших. Ошибки бывают, костяк держится. Но работает это потому, что под агентами лежат годы чужого труда: платформы, стандарты, паттерны и люди, которые помнят, зачем все это. И каждое правило, которое делает слабую модель сильной, кто-то сначала должен был вытащить из своей головы и сформулировать. Это самая дорогая часть работы, и в презентациях ее обычно не показывают.
Кому все это не нужно
Если после всего прочитанного вы решили, что мультиагентный конвейер с калиброванной обвязкой вам ни к чему, вполне возможно, вы правы.
Прототип к тендеру к концу недели или новый продукт с чистого листа проще и дешевле сделать на фронтир-модели за ночь. Егор Дьяченко справедливо замечает, что на гринфилде агенты показывают себя блестяще, а аргумент Андрея про «крылья» я уже пересказал. Калибровка под слабую модель в такой ситуации съест недели, которых у вас нет, и принесет стабильность, которую на этом этапе никто не просил.
Маленькой команде с одним продуктом конвейер, скорее всего, тоже не нужен, ей хватит одного агента. Егор Дьяченко оценивает это так: при хорошо подготовленном контексте один агент в паре с человеком закрывает около 80% задач и ускоряет разработку в четыре-пять раз. Исследования, данные которых мне приводят, говорят о том же: каждый следующий агент увеличивает счет за токены, а пользы добавляет все меньше. Второй агент нужен примерно тогда, когда вы позвали бы второго человека: на ревью или чтобы разобраться в чужом старом коде. Его ценность в том, что он приходит со свежей головой и не тащит за собой весь контекст агента первого. Строить из нейросетей копию отдела ради самой структуры смысла нет, и здесь мы с Егором полностью согласны. Для маленькой команды это так. В большом конвейере каждый агент работает на модели ровно нужной мощности и с узким контекстом, а часть шагов вообще обходится без LLM, поэтому на масштабе узкоспециализированные агенты дешевле универсального.
Вот случай неприятнее: у компании нет накопленных компонентов, стандартов и людей, которые помнят, почему все устроено так, как устроено. Тогда калибровать обвязку просто не по чему. Наша схема работает потому, что за ней – годы продуктовых линеек. Без такой базы агенту придется писать с нуля, а вам – проверять за ним тоже с нуля, и никакая слабая модель при этом не заработает как сильная.
Отдельно про тех, кто не готов убрать проверку человеком после каждого шага. Мультиагентность в такой компании превратится в дорогой способ делать то же самое, что и раньше. Честнее купить разработчикам подписки и учитывать их как расходы на комфорт. Это вполне нормальное решение, только не называйте его трансформацией.
Что на самом деле смешного в ошибках нейросетей
Я по-прежнему читаю чаты со смешными ошибками нейросетей, только вижу в них теперь другое. Модель, которая выдумала несуществующий метод, не знала, что нужный метод давно лежит в соседнем модуле. Ассистент, закомментировавший проверку, скорее всего не знал, зачем она там стоит. Ветеран знал. За каждой такой историей – правило, которое кто-то из нас помнил и не записал. Смешная ошибка нейросети чаще всего оказывается дыркой в нашей собственной документации, просто выставленной на публику.
Наш цех не помрет так, как хочется скептикам, и не выживет таким, каким хочется нам. Код дешевеет, узкая специализация дешевеет вместе с ним, а в цене остается то, что у нас в головах. При одном условии: если мы успеем это оттуда достать.
Впервые за всю историю в нашем цехе появился подмастерье, который не устает, не спорит, не увольняется и не просит повышения. Одного он не умеет: учиться, подглядывая через плечо мастера. Все, что мастер не записал, для него не существует. Парадокс Поланьи для этого подмастерья – не философия, а граница мира.
Напишите в комментариях всего две цифры: сколько лет работает в компании человек, без которого вы не принимаете ни одного серьезного архитектурного решения, и сколько страниц его знаний записано так, чтобы по ним мог работать кто-то другой, будь то человек или агент. Подозреваю, что у большинства вторая цифра окажется меньше первой.
Автор: stard
