Мы дали ИИ-агентам доступ к задачам, коду и документации. Вот где они помогли, а где начали мешать

Я долго скептически смотрел на корпоративные рассказы про ИИ. Обычно они звучат одинаково: компания «внедрила искусственный интеллект», сотрудники «стали эффективнее», а где именно стало легче — непонятно. Где-то в презентации обязательно появляется робот, график роста и фраза про будущее. У нас всё началось куда скучнее. В Paladin Engineering накопилась обычная для разработки проблема: слишком много мелкой ручной работы вокруг нормальной инженерии. Не сама разработка съедала больше всего нервов, а то, что вокруг неё. Разобрать входящий запрос. Понять, что клиент имел в виду в ТЗ. Вытащить противоречия из переписки. Обновить документацию после изменений. Проверить, не сломал ли новый код старые договорённости. Составить список вопросов перед созвоном. Вернуться к задаче трёхмесячной давности и вспомнить, почему тогда приняли именно такое решение. Ничего героического. Просто вязкая операционная рутина, которая каждый день откусывает по кусочку внимания. Сначала мы, как и многие, пробовали решать это через обычные LLM-инструменты: ChatGPT, Claude, Copilot, локальные модели, разные обёртки. Помогало, но странно. Один человек получал хороший результат, другой тратил 20 минут на промпт и всё равно шёл переписывать руками. Контекст надо было копировать. Ответы надо было проверять. История терялась. Ответственность всё равно оставалась на человеке, только теперь у него появился ещё один чат, куда нужно носить куски работы. В какой-то момент стало понятно: нам не нужен «умный чат». Нам нужна система, которая сама живёт внутри процесса.Так мы пришли к OpenClaw.

Чат-бот хорош, когда у тебя разовая задача: переписать письмо, накидать структуру, объяснить кусок кода. Но в компании задачи редко живут отдельно.Заявка от клиента связана с договорённостями в CRM. ТЗ связано с оценкой. Оценка связана с кодовой базой. Код связан с документацией. Документация связана с тем, что менеджер обещал на звонке две недели назад. Обычный чат этого не знает. Ему надо всё принести. Причём каждый раз заново. Мы довольно быстро упёрлись в три ограничения. Первое: контекст. Если модель не видит проект, она красиво фантазирует. Иногда даже убедительно. Это хуже, чем просто ошибка. Второе: действие. Чат может посоветовать, но не может сам пройти по таскам, сверить документы, открыть нужные файлы, подготовить комментарий в задачу и передать его человеку. Третье: память. В живой разработке важно не только «что сейчас», но и «почему мы так решили». Без этого ИИ превращается в стажёра с отличной речью и амнезией.OpenClaw мы внедряли именно как систему агентов, а не как ещё один интерфейс к модели.

Если коротко, OpenClaw у нас работает как слой между людьми, проектами и инструментами. Внутри несколько агентов. У каждого своя роль, доступы и зона ответственности. Мы специально не стали делать одного универсального «суперсотрудника». Это соблазнительно, но плохо работает. Такой агент начинает хвататься за всё сразу, теряет фокус и слишком уверенно лезет туда, где должен остановиться. Поэтому мы разрезали систему на роли.Есть агент-аналитик. Он разбирает входящие материалы, ищет противоречия, вытаскивает вопросы и готовит черновик структуры задачи.Есть агент-разработчик. Он помогает с рутинным кодом, тестами, миграциями, мелкими рефакторингами. Не пушит всё сам в прод без спроса, конечно. Мы не настолько смелые. Есть агент-ревьюер. Его работа — быть занудой. Он смотрит на изменения и спрашивает: «А это точно не ломает старую логику?» Иногда раздражает. Иногда спасает. Есть агент-документатор. После изменений он готовит обновления для внутренней документации, README, описаний API и пользовательских инструкций. Есть агент-проектный помощник. Он следит за задачами, зависимостями, открытыми вопросами и тем, что обещали клиенту. Отдельно есть агент базы знаний. Вот его мы сначала недооценили. А зря.

Я думал, что главный эффект будет в разработке. Ну логично же: агент пишет код, делает ревью, ускоряет инженеров. Красиво звучит.На практике самым полезным оказался агент, который просто помнит.Он отвечает на вопросы вроде: «Почему здесь очередь, а не прямой вызов?» «Где обсуждали интеграцию с 1С?» «Кто и когда решил, что в MVP не будет личного кабинета для второго типа пользователя?» «Почему этот эндпоинт возвращает такой странный статус?» Раньше такие вопросы шли к тимлиду или менеджеру. Человек отвлекался, открывал старые задачи, искал переписку, вспоминал. Иногда вспоминал неправильно. Теперь агент поднимает связанные задачи, комментарии, документы и выдаёт ответ со ссылками. Не всегда идеально. Но достаточно часто, чтобы перестать дёргать людей по пустякам.И вот это оказалось важнее, чем генерация кода. Код можно написать. Потерянный контекст восстановить сложнее.

Самый понятный сценарий — входящий запрос. Раньше он выглядел так: клиент присылает письмо, презентацию, пару файлов и голосовое «мы примерно хотим вот это». Менеджер читает, пытается собрать картину, зовёт аналитика, потом разработчика, потом возвращается к клиенту с уточнениями. Сейчас первый проход делает агент.Он разбирает материалы и собирает короткую выжимку:что клиент хочет сделать;какие роли пользователей упоминаются;какие интеграции нужны;где требования конфликтуют друг с другом;что нужно уточнить до оценки;какие похожие проекты у нас уже были.Важно: он не заменяет аналитика. Он просто убирает первый слой грязной работы. Аналитик приходит не к пустому листу, а к черновику, который можно править, ругать, дополнять.Тут есть забавный момент. Когда агент ошибается, это раздражает меньше, чем когда он вообще не используется. Потому что ошибка в черновике видна сразу. А вот пустой лист всё равно приходится заполнять человеку.Второй сценарий — подготовка к созвонам.Агент собирает историю по клиенту: последние договорённости, открытые вопросы, зависшие задачи, риски, обещания с прошлых встреч. Перед звонком менеджер получает нормальную шпаргалку, а не лезет в пять вкладок.Это звучит мелко. Но именно из таких мелочей складывается ощущение, что процесс наконец перестал скрипеть.

В разработке мы долго искали границу. Хотелось дать агентам больше свободы, но не хотелось получить хаос в репозиториях.Поэтому начали с безопасных задач. Первое — тесты. Агент хорошо пишет черновики тестов по уже существующей логике. Не всегда идеально, но быстро. Разработчик потом проходит глазами, поправляет ожидания, добавляет граничные случаи. Это всё равно быстрее, чем начинать с нуля. Второе — документация к коду. Разработчики обычно не против документации как идеи. Они против момента, когда надо остановиться и описать то, что ты только что держал в голове. Агент здесь полезен: он видит diff, понимает, какие публичные методы или API поменялись, и предлагает обновление.Третье — первичное ревью. Не вместо человека. До человека.Агент смотрит на очевидные вещи: несостыковки в названиях, забытые проверки, странные миграции, несовпадения между API и документацией, места, где новый код противоречит старым паттернам проекта. Иногда он пишет ерунду. Такое бывает. Но иногда ловит то, что человек пропустил бы просто потому, что устал. Один из первых случаев, после которого к системе стали относиться спокойнее: агент заметил, что изменение в миграции базы ломает сценарий отката для старой версии сервиса. Не драматичная история для пресс-релиза, зато очень понятная для разработчиков. Никто не любит чинить миграции ночью.

Первые версии агентов были слишком разговорчивыми.Они писали длинные отчёты, пересказывали очевидное, добавляли вежливые выводы и иногда звучали как консультанты, которых никто не звал. Это быстро бесит. Пришлось отдельно учить их молчать.Не в смысле «отвечать хуже», а в смысле давать только то, что нужно для следующего действия. Если агент нашёл противоречие, пусть покажет противоречие и ссылку. Не надо эссе про важность согласования требований.Вторая проблема — доступы. Агента легко сделать бесполезным, если он ничего не видит. И так же легко сделать опасным, если он видит слишком много и может слишком много делать. Мы довольно быстро ввели правило: агент может читать больше, чем писать. А писать он может только туда, где есть понятный след и человек на проверке.Третья проблема — доверие команды.Это вообще отдельная тема. Люди не любят, когда сверху спускают новую систему и говорят: «Теперь она будет вам помогать». Обычно это значит: «Теперь у вас будет ещё одна обязанность».Поэтому мы не внедряли OpenClaw как приказ. Мы начали с задач, где боль была очевидной. Разбор старых решений. Черновики тестов. Подготовка к созвонам. Обновление документации.Когда человек сам видит, что агент снял с него полчаса скучной работы, сопротивление падает. Не исчезает, но падает.

Мы не отдаём агентам финальные решения. Агент может предложить архитектурный вариант, но не утверждает архитектуру. Может написать тест, но человек принимает его в код. Может найти риск в задаче, но менеджер решает, как говорить об этом с клиентом. Может обновить документацию, но владелец проекта смотрит, не уехал ли смысл. Это важная граница. Без неё мультиагентная система быстро превращается в автоматизированный источник странных решений. Вообще, если честно, главный навык при внедрении ИИ — не промпты. Главный навык — понимать, где ИИ должен остановиться.

Я не хочу делать вид, что после внедрения OpenClaw компания внезапно стала работать в два раза быстрее. Так не бывает. По крайней мере, у нас не бывает. Но несколько вещей стали заметно лучше. Входящие запросы стали разбираться быстрее. Не потому что агент «понял бизнес лучше аналитика», а потому что он быстро делает первый проход и вытаскивает мусор наверх. Новым разработчикам стало проще входить в проект. Они меньше зависят от устных объяснений и чаще находят ответ сами. Ревью стало спокойнее. Часть мелких замечаний уходит до человека. Человеческое ревью остаётся, но фокус смещается на смысл, а не на очевидные недочёты. Документация стала обновляться чаще. Не идеально, но чаще. Для разработки это уже победа.Менеджеры меньше держат в голове. Это, наверное, главный бытовой эффект. Когда агент напоминает, что по клиенту висит неотвеченный вопрос с прошлого четверга, это не выглядит как магия. Просто меньше шансов забыть.

Мы бы раньше начали с базы знаний. Не с генерации кода. Не с красивых демо. А именно с памяти компании: задачи, решения, документы, переписки, причины изменений. Потому что без нормального контекста агент бесполезен. Он может быть умным, быстрым, дорогим, локальным, облачным, каким угодно. Если он не знает, что происходило в проекте, он будет угадывать. Ещё мы бы раньше ограничили формат ответов. Чем меньше агент похож на блогера, тем лучше. Хороший агент в рабочем процессе не должен производить впечатление. Он должен закрывать кусок работы.И ещё одно: не надо внедрять агентов сразу везде. Это звучит банально, но искушение большое. Хочется нарисовать схему, где агенты бегают по всей компании и всё оптимизируют. На практике лучше взять один противный процесс и довести его до нормального состояния. Например: разбор входящих заявок. Или первичная подготовка тестов. Или поиск решений по старым задачам.Один работающий сценарий лучше, чем десять красивых, которыми никто не пользуется.

Мультиагентная система не нужна компании, где нет повторяемых процессов. Если у вас всё держится на пяти людях, которые сидят в одной комнате и каждый день договариваются голосом, OpenClaw может оказаться лишней сложностью. Она начинает приносить пользу, когда появляются проекты, история решений, много переписок, разные роли, несколько команд и постоянный риск что-то забыть. То есть там, где компания уже не помещается в голове одного человека. Для нас OpenClaw стал не заменой людей, а способом убрать из работы часть шума. Не весь. Шум всё равно остаётся, это разработка. Но теперь хотя бы часть рутины делает система, которая не устаёт, не забывает открыть старую задачу и не стесняется напомнить, что мы опять не обновили документацию.И да, агенты ошибаются. Иногда уверенно. Иногда смешно. Иногда так, что хочется выключить всё и вернуться к блокноту. Но потом они за две минуты находят решение, которое человек искал бы полчаса, и ты такой: ладно, живи. Пока живи...