Как мы в ZeBrains перешли на агентную разработку и что из этого вышло

Всем привет, на связи команда ZeBrains. Этот текст про то, как мы перестали просто использовать ИИ и начали с ним работать по-настоящему. Про настоящие проекты, настоящие шишки и один файл, который изменил всё.

Спойлер: один разработчик теперь закрывает полный цикл от ТЗ до прода. Без дизайнера, без аналитика, без DevOps. За месяц. Но путь к этому был не таким прямым, как кажется.

Сначала — честно о том, где мы были

Мы не были первопроходцами. Долгое время ИИ в ZeBrains использовался ровно так, как его используют большинство команд: как умный автокомплит. Написал строчку и Copilot подсказал следующую. Спросил у ChatGPT, как называется тот метод у массивов и получил ответ. Полезно, но не революционно.

Потом кто-то в команде попробовал Cursor, потом другой Windsurf. Каждый использовал как умел, каждый со своими промптами и своим пониманием. 

Примерно в начале 2025 года пришло осознание: мы не используем ИИ мы с ним балуемся. И тогда же появился первый проект, который поставил вопрос ребром.

Исходная точка: к нам пришёл проект с условием

Клиент поставил жёсткий порог: делаем только средствами ИИ, срок месяц, в команде один разработчик. Без дизайнера, без аналитика, без DevOps.

На тот момент наш коллега уже достаточно поигрался с Cursor, знал, что он умеет писать код. Но построить полноценную систему с нуля было новым вызовом.

Кейс 1: фармацевтика — система сверки медицинских материалов

Задача: автоматически сверять промоматериалы фармацевтического клиента с содержимым сайтов. Проверять, не перевирают ли факты, корректно ли написан текст. На входе расплывчатое ТЗ в одном docx. На выходе микросервисная система из пяти сервисов с асинхронной очередью.

Архитектура:

• Site Parser — обходит сайты, собирает контент

• OCR/VLM Extractor — распознаёт текст из PDF (сначала был OCR, потом заменили на VLM)

• Text Comparer — сравнивает материалы через LLM

• Backend на Keystone — API, задачи, результаты

• Frontend на Vue 3 — интерфейс оператора

Как это строилось:

1. Взял ТЗ, сконвертировал в маркдаун

2. Вместе с ИИ обсудили реализацию, выбрали оптимальную

3. Сформулировали список уточняющих вопросов заказчику

4. Получили ответы → создали два документа: архитектурную документацию для ИИ и уточнённое ТЗ для заказчика

5. Нарезал задачи с помощью ИИ в отдельные .md-файлы

6. Выдавал задачи одну за другой. Никакой ручной реализации — максимум наблюдение

Через две недели был MVP. Кривой и косой, но рабочий. Система до сих пор развивается.

Но вот что нашли внутри:

Когда начали смотреть глубже, поняли что ИИ создал лишний код. Лишние поля в базе, ненужные связи, переусложнённую логику. Процентов 40 можно было безболезненно удалить. Началась полуручная подгонка: разработчик проходился по файлам, прописывал TODO прямо в коде что убрать, как упростить. Потратил кучу токенов на то, чтобы ИИ удалил свою же работу.

Урок №1: ИИ отличный исполнитель, а не архитектор.

Без чётких правил получаем код, который работает, но на 40% лишний. И второй момент в том, что задачи надо нарезать не под человека, а под ИИ. Мы бы для обычного спеца делили бэк и фронт. Для ИИ лучше мыслить фичами: «реализуй такую-то фичу от базы до интерфейса». Это его суперсила, он может писать сразу в несколько сервисов и слоёв одновременно, сам разберётся с контрактом между ними.

Кейс 2: внутренний проект — смена стека без потерь

Один из наших внутренних продуктов жил на Strapi. Schema-first система, и ИИ при доработке постоянно упирался в себя и создавал баги. Решил переехать на Keystone (code-first, GraphQL из коробки), переписать бота с Go на TypeScript, перенести админку прямо во Vue.

На этот раз коллега-первопроходец шёл по-другому. План строил сам, задачи выдавал порционно, проверял каждый шаг.

Неочевидный приём, который нашёл здесь:

Когда встал вопрос миграции базы данных (Strapi-схема — очень неудобная штука, много таблиц и непонятно зачем создаваемых связей), не просил ИИ напрямую перелопатить сотни строк SQL. Попросил его:

1. Проанализировать существующие таблицы и структуру

2. Написать скрипты, которые вытянут данные, преобразуют, соберут дамп для новой структуры с учётом всех связей

Это сработало почти с первого раза. Задепоили код, он собрался и заработал. Без потерь данных.

С тех пор правило: если есть большие файлы (стили, дампы, Markdown, CSV) — проси писать скрипт, а не выполнять работу руками. Результат предсказуемее, и его можно повторять.

Кейс 3: Производство: 40 часов для полной системы

Конвейерная лента, камера, CV, реалтайм. Клиент из мясной промышленности: нужно было анализировать процент мяса на кости в режиме реального времени и сигнализировать о перерасходе. Оператор запускает и останавливает съёмку, смотрит за происходящим.

Взял архитектурную оснастку с предыдущего проекта, доработал. Фронт на Vue + PrimeVue, бэк на Keystone, контракт через GraphQL Codegen. CV-сервисы подключались к бэку по WebSocket.

Ключевое архитектурное решение:

Бэк не знал ни адресов, ни количества конвейеров. CV-сервисы сами подключались по WebSocket. Бэк регистрировал в базе и привязывал к ним сессии и результаты. Изначально подразумевался один конвейер, а получилась легко масштабируемая архитектура.

На весь проект с созвонами и доработками ушло около 40 часов. 1 разработчик. Полная система.

Но всё равно приходилось часто напоминать ИИ о требованиях, ссылаться на файл с архитектурой. Он как бы понимал, но время от времени дублировал логику, выносил компоненты не туда. Хорошая основа, но не идеальная.

Проблема, с которой столкнулся отдел

У каждого разработчика свой ИИ, свой промпт, свой почерк. Кто-то в Cursor, кто-то в Windsurf, кто-то в Copilot. Код из разных рук, от разных ИИ выглядит по-разному. Как добиться единообразия? Как передать ИИ свой стиль мышления, причём не только себе, но и всему отделу?

Решение: MCP-сервер знаний

Посмотрели, как PrimeVue организовал свой MCP-сервер и написали такой же для своего отдела. npm-пакет с набором маркдаун-файлов с явно описанной архитектурой.

Сотни отдельных тем, покрывающих каждый язык программирования и каждый стек, в котором работаем. Базовые знания для UI (Frontend, Mobile, Standalone), Backend, CI/CD, Git Flow. Каждая тема описана с точки зрения разработчика: как именно поступать, каких подходов придерживаться, почему именно так. Её сейчас дополняют все отделы.

Важный момент: речь идёт о самом начале — одном наборе правил для конкретного проекта, конкретного стека и языка. Это была единая тысячестрочная дока. Потом ИИ сам разбил её по удобным файлам с тегированием для структурированного поиска. Этот подход к наполнению базы знаний переняли другие отделы, и сейчас она продолжает расти.

Параллельно создал  шаблонный проект на базе последнего кейса, где все правила из базы знаний уже воплощены в живом коде. Теперь два слоя: текстовые правила и живой эталонный код

Полевые испытания: где всё пошло не так, как ожидалось

Испытание 1: редизайн веб-приложения

Задача — привести фронт к PrimeVue-дизайну. Передал разработчику шаблон и MCP.

Итерация 1, 2, 3 — ИИ игнорирует правила. Работает по-своему. Помогает только явное принуждение: буквально тыкаем носом в MCP. После этого — нужный результат.

Вывод: правила сами по себе не работают. Нужен жёсткий триггер.

Испытание 2: внутренний аналитический инструмент, самый показательный кейс

Разработчик начал с шаблона и MCP. MCP не подключился. ИИ сгенерировал MVP, полностью проигнорировал всю базу знаний, собрал свой дизайн, по-своему переписал бэк и фронт. Cursor rules, Windsurf rules — всё игнорировалось.

Проблему решил один файл в корне проекта — AGENTS.md. Логика простая: всегда лезь в базу знаний, всегда подключайся к MCP.

И это перевернуло всё.

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

Смотреть за вызовами было одно удовольствие. ИИ действовал по тому же флоу, которым пользуешься сам, когда не ленишься.

Вывод: AGENTS.md в корне проекта это необходимость.

Формула передачи стиля мышления

Три компонента, и ИИ ведёт себя как ты:

1. Документированные правила — MCP-сервер с архитектурой отдела. Явно описанная база знаний: паттерны, слои, контракты, примеры. Очевидные вещи тоже нужно описывать — ИИ не догадается.

2. Документация проекта — MD-файлы с ТЗ, фичами, задачами, ADR. Чем больше контекста о проекте, тем лучше результат.

3. Жёсткий триггер — AGENTS.md в корне каждого проекта. Принуждает всегда сверяться, решает проблему игнора. Без него правила просто не работают.

Итог: ИИ пишет в едином стиле, подход масштабируется на весь отдел.

Тест Тьюринга внутри отдела

На внутреннем митинге провели небольшой эксперимент. Показали два функционала, по два файла в каждом. Участников попросили угадать: какой из двух файлов написал человек, а какой ИИ?

В каждом случае было два файла: один с “чистым” кодом, второй — с “грязным”. Участники выбирали, кто написал лучше — человек или ИИ. Вот только суть в том, что сами кейсы были устроены по-разному.

Кейс 1 — оба файла написал ИИ. Обоим давалось одинаковое задание. Разница только в контексте: один ИИ работал с базой знаний, второй вслепую.

Кейс 2 — оба файла написали люди. Оба получили одну задачу написать компонент. Разница в том, что один имел на руках весь проект, а второй писал компонент изолированно, без контекста.

В обоих случаях большинство ошиблось. Участники выбирали между плохим и хорошим кодом, но не угадывали, кто его написал. Потому что вопрос был не в том, человек это или ИИ. Вопрос был в контексте.

Вывод: и ИИ, и разработчик мыслят одинаково, если задачи ставить одинаково. Если дан контекст всего проекта, то напишет как в проекте. Если дан один файл, то уместит всё в одном месте. За этим нужно следить.

Итоговый цикл Agentic Development

Так выглядит наш процесс сейчас:

1. Требования — чёткая задача, ограничения

2. Архитектура — человек + ИИ, фиксируем в документе

3. Декомпозиция на фичи — нарезаем для ИИ, не для человека

4. Делегирование ИИ — выдаём порциями, проверяем каждый шаг

5. Валидация — AI-ревью по базе знаний + живое ревью человека

6. Уточнение базы знаний — MCP пополняется из реального опыта

База знаний это живой артефакт. После каждого проекта она становится лучше. Архитектурное мышление перестаёт жить только в голове ведущего разработчика.

Трансформация роли

Мы перестали быть ремесленниками кода и стали дирижёрами.

Классический разработчик:

• Пишет код строчка за строчкой

• Держит архитектуру в голове

• Зависит от ширины команды

• Масштабируется через людей

Agentic Developer:

• Проектирует системы, не строчки

• Оцифровывает архитектурное мышление

• Создаёт базы знаний и эталонный код

• Руководит ИИ как виртуальной командой

• Масштабируется через лучшие правила

Ручная работа остаётся только для шлифовки тонких моментов, которые требуют живого опыта. Остальные задачи в управлении контекстом и правилами.

С момента описанного опыта флоу работы уточнился, где-то видоизменился — но базис, полученный в рамках этих кейсов, стал фундаментом агентского подхода в ZeBrains. Это не одиночный пост, а хронология: мы намеренно начали с начала, чтобы показать путь целиком. В дальнейших материалах расскажем, к чему пришли сейчас — так что следите за обновлениями.