Коротко. AI умножает то, что уже есть. Если процесс описан — умножит результат. Если не описан — умножит хаос, причём быстрее, потому что на хаос не нужно согласований. Прорыв дают не модели, а качество формализации.
Я занимаюсь системным анализом платформы генеративного AI. Ниже — не обзор исследований, а то, что видно изнутри: где именно ломается работа команды, когда в неё приходит агент, и почему это ломается не там, где ждали.
С генерацией давно нет проблем. Модели пишут код, тесты, документацию — и делают это быстро.
Ломается всё, что вокруг неё. Контекст, которого не хватает в структурированном виде. Ревью, которое не справляется с выросшим потоком. Качество, которое так и осталось функцией в конце цепочки. И обучение — задачи, на которых росли новички, уходят агенту первыми.
Дальше — про первое, потому что остальные три следуют из него.
Человек собирает картину по фрагментам. Из переписок, из памяти о прошлых решениях, из истории релизов, из того, что никто никогда не записывал, но все помнят.
Агент видит ровно то, что ему дали.
У нас был показательный случай. Агент сгенерировал корректный код по спецификации, которая устарела. В репозитории лежали обе версии, и ничто не указывало, какая живая.
Разбор и переработка заняли вдвое больше времени, чем занял бы обычный путь.
Модель не ошиблась. Ошибся контекст, который мы ей дали. И вот это — не сбой инструмента, а структурная особенность: агент не умеет достраивать то, чего нет в его входных данных, а человек умеет и делает это незаметно для себя.
Отсюда простая модель. Каждый раз, когда контекст разорван, агент платит налог. Чем длиннее цепочка «задача → анализ → реализация → проверка → интеграция», тем выше налог.
Налог платится не в момент генерации. Он платится потом: на разборе, на переделке, на объяснении, почему сделано не то.
Выгода появляется там, где команда умеет этот налог снижать. Хорошо сформулированные задачи. Полный контекст. Понятные критерии приёмки. Автоматизированная проверка.
Ничего из этого не про модель.
Здесь важное различие, которое мы не сразу увидели.
Ошибку в коде разработчик находит сам. Он в этом эксперт, у него есть чем проверить.
А ошибку в бизнес-логике он проверить не может. Не потому что не хочет — у него нет источника истины.
Что происходит дальше. Разработчик замечает, что что-то не так. Пишет аналитику. Аналитик проверяет. Возвращает ответ. Разработчик правит. Полный круг коммуникации — на каждую такую ошибку.
С кодом это случается редко. С логикой — часто.
И вот вывод, который стоит унести: код стал дешевле, а цикл проверки смысла остался человеческим и дорогим. Именно поэтому AI-ускорение бьёт не туда, куда ожидаешь.
Два изменения, оба не про модель.
Второй агент в цепочке проверки. Схема простая: агент пишет, второй агент проверяет, человек смотрит последним.
Но работает она не потому, что проверок стало три. Мы заметили, что два агента, написанные разными людьми, проверяют по-разному. В каждом остался отпечаток автора: что он считает проблемой, на что смотрит первым, что готов пропустить.
Сначала это выглядело как недостаток — хотелось единообразия. Потом стало понятно, что это ровно то, ради чего в командах делают ревью несколькими людьми. Разные взгляды ловят разные классы ошибок.
Практический вывод: не поручайте настройку всех агентов одному человеку. Вы получите один взгляд, размноженный на несколько итераций.
Пост-наблюдение. И здесь тоже не то, что обычно имеют в виду.
Обычный мониторинг отвечает на вопрос «что сломалось». Это реакция. Наше наблюдение отвечает на вопрос «что можно улучшить» — и это планирование.
На выходе не отчёт об ошибках, а отчёт об оптимизации. Он идёт в груминг наравне с задачами от продукта и превращается в задачи разработки.
Контур замкнулся: разработка — релиз — наблюдение — груминг — снова разработка. Эксплуатация перестала быть источником только инцидентов и стала источником работы по улучшению.
Есть кейс, который я привожу на выступлениях, и он объясняет всё сказанное лучше моего опыта.
Финтех-компания делала финансовые интеграции — вручную, силами большой команды. Они заметили простую вещь: экспертной выглядела форма работы, а содержание было повторяемым. Около восьмидесяти процентов интеграций оказались вариациями знакомых паттернов.
Дальше они пошли не за инструментом. Они пошли за формализацией. Переписали техзадание так, чтобы оно содержало всё нужное для генерации кода. Разобрали, как описание API заказчика связано с реализацией. Собрали каталог исключений.
Сначала описали процесс. Потом сделали его воспроизводимым.
И только после этого построили конвейер: агент аналитики, агент разработки, агент тестирования, агент релиза. Стало быстрее, надёжнее и прозрачнее. Команда сократилась на порядок.
Обратите внимание, что здесь произошло. Прорыв случился не потому, что модели поумнели. Он случился из-за качества формализации. AI здесь — последний шаг, а не первый.
Если вы думаете, что внедрение агентов ускорит вашу команду — проверьте сначала, что у вас описано.
Не «есть ли документация» — она обычно есть и обычно устарела. А описано ли то, из чего принимаются решения: почему сделано именно так, какие альтернативы отбросили, что уже пробовали и обожглись, кто и на каком основании согласовал.
Это то, что человек достраивает молча и что агент достроить не может.
AI умножает то, что есть. Формализовано — умножит результат. Не формализовано — умножит хаос. Причём хаос он умножит быстрее, потому что на него не нужно согласований.
Мой опыт — это одна команда. Выборка маленькая, и обобщать её на всех я не могу.
Кроме того, я не отделяю эффект агентов от эффекта организационной перестройки, которая шла параллельно. Возможно, часть выигрыша дала именно она.
Если через год окажется, что выигрывают команды, которые ничего не формализовали, а просто дали людям инструменты, — я вернусь и скажу это вслух. Пока вижу обратное.