The post has been translated automatically. Original language: Russian
A year or two ago, "AI in development" meant code completion. Today we are talking about something else: agents who receive a task, read the repository themselves, write code, run tests, correct errors and open a pull request. We analyze what really changes in the process based on the experience of our team of three engineers.
From piggy bank to agent
The difference between an assistant and an agent is simple. The assistant answers the question and the agent completes the task. It works in a cycle: plan → action (edit file, run command) → check result → correction. One such cycle can take dozens of steps, and a person in it is needed not as a "typing code", but as a task statement and reviewer.
This is already working on real projects: refactoring legacy modules, writing tests, migrations, integration with external APIs. But the quality of the result depends almost entirely on how accurately the agent was told exactly what was needed.
The main problem is not the model, but the problem statement.
We went through a typical path. First, they gave the agent tasks in free form ("add payment through a new gateway") and received code that compiled, passed its own tests and did the wrong thing. Not because the model is weak, but because the task did not have answers to dozens of questions.: how to handle timeouts, which transaction statuses are considered final, where to log in, and what rights are needed.
A human developer would have asked these questions on a daily basis. The agent will come up with the answer himself. And this is the most expensive mistake in working with it.
Spec-driven development: specification as source code
Hence the approach called DevSpecAI: specification first, then code. Not a multi-page TOR, but a structured document that is read by both a person and an agent.:
- The context is what kind of system, what modules are affected, what limitations (stack, performance, security).
- The behavior of the scenario is in the "given/when/then" format, including negative and boundary cases.
- Contracts, API schemas, data structures, and events.
- Acceptance criteria what should be green in order for the task to be considered closed: tests, linters, metrics.
- Prohibitions on what the agent should not do (change the database schema, touch other people's modules, add dependencies without approval).
How it works here: four steps
The process is built like a pipeline with control points. First, the agent collects the specification from the ticket and the context of the codebase, asking clarifying questions where there is not enough data. Then, based on the approved speci, an implementation plan is formed. The plan is divided into atomic tasks with their own acceptance criteria. And only after that, the coding begins task by task, with a test run after each one.
Each transition between steps is a point where a person can stop, correct or reject the result. The specification is approved before the first line of code is written, so the agent implements it against specific criteria, rather than against its own interpretation.
What does this mean in practice?
- Predictability. The agent's first pass lands noticeably closer to expectations, and there are fewer "redo" iterations mostly because the agent drifts off course less often. As a result, generation accuracy has grown significantly, and with it the speed of getting a finished result: fewer correction cycles means a task reaches merge faster. We have not run rigorous measurements yet, but the team's impression is that on some well-bounded tasks development speed increases up to twofold.
- The review becomes a test of compliance with the spec, rather than an attempt to guess what the author meant.
- The specification lives longer than the code. After six months, it's clear why the module is designed that way, and the next agent (or person) can safely change it.
- Onboarding new people and new models: the same speca works for any performer.
What's not working (yet)
Honestly about the limitations. Agents do not cope well with tasks where the requirements are vague (for example, tasks related to legacy code processing) and change along the way, where the specification becomes obsolete faster than it is written. They tend to "green-tune" tests, adapting them to the code if the criteria are not clearly formulated. And they do not replace architectural solutions: the choice of service boundaries, data models, and fault tolerance strategies is up to people.
Cost also matters: long agent cycles on large repositories consume a lot of tokens, and without restrictions on context and the number of steps, the budget flies away quickly.
The trend for the coming year
""According to our observations, the center of gravity in development is shifting from "I can write code" to "I can accurately describe what needs to be done and I can check it." The developer is getting closer to the role of architect and technical lead for the agent team. Companies that build a culture of specifications and automatic verification today will get the most value from agents tomorrow, no matter which model turns out to be the best on the market.
A practical checklist for those who are starting out
- Start with tasks with clear boundaries: tests, migrations, refactoring of a single module.
- Write the specification before the start. If you cannot formulate the acceptance criteria, the task is not ready for the agent yet.
- Give the agent access to running tests and linters — this is his main feedback channel.
- Limit the change area explicitly to a list of files or modules.
- Review not only the code, but also how the agent interpreted the spec — discrepancies will show holes in the specification itself.
We will be happy to discuss in the comments how you integrate agents into your processes and what approaches to setting tasks have worked for you.
Ещё год-два назад «ИИ в разработке» означало автодополнение кода. Сегодня разговор идёт про другое: агентов, которые получают задачу, сами читают репозиторий, пишут код, запускают тесты, правят ошибки и открывают pull request. Разбираем, что реально меняется в процессе на опыте нашей команды из трёх инженеров.
От копилота к агенту
Разница между ассистентом и агентом простая. Ассистент отвечает на вопрос агент выполняет задачу. Он работает в цикле: план → действие (правка файла, запуск команды) → проверка результата → корректировка. Один такой цикл может занимать десятки шагов, и человек в нём нужен не как «печатающий код», а как постановщик задачи и ревьюер.
Это уже работает на реальных проектах: рефакторинг легаси-модулей, написание тестов, миграции, интеграции с внешними API. Но качество результата почти полностью зависит от того, насколько точно агенту объяснили, что именно нужно.
Главная проблема не модель, а постановка задачи
Мы прошли типичный путь. Сначала давали агенту задачи в свободной форме («добавь оплату через новый шлюз») и получали код, который компилировался, проходил свои же тесты и при этом делал не то. Не потому что модель слабая, а потому что в задаче не было ответов на десятки вопросов: как обрабатывать таймауты, какие статусы транзакций считать финальными, где логировать, какие права нужны.
Человек-разработчик эти вопросы задал бы на дейлике. Агент придумает ответ сам. И это самая дорогая ошибка в работе с ним.
Spec-driven development: спецификация как исходный код
Отсюда подход, который называется DevSpecAI: сначала спецификация, потом код. Не многостраничное ТЗ, а структурированный документ, который читают и человек, и агент:
- Контекст что за система, какие модули затрагиваем, какие ограничения (стек, производительность, безопасность).
- Поведение сценарии в формате «дано / когда / тогда», включая негативные и граничные случаи.
- Контракты схемы API, структуры данных, события.
- Критерии приёмки что должно быть зелёным, чтобы задача считалась закрытой: тесты, линтеры, метрики.
- Запреты чего агент делать не должен (менять схему БД, трогать чужие модули, добавлять зависимости без согласования).
Как это устроено у нас: четыре шага
Процесс выстроен как конвейер с контрольными точками. Сначала агент собирает спецификацию из тикета и контекста кодовой базы, задавая уточняющие вопросы там, где данных не хватает. Затем на основе утверждённой спеки формируется план реализации. План разбивается на атомарные задачи с собственными критериями приёмки. И только после этого начинается кодирование задача за задачей, с прогоном тестов после каждой.
Каждый переход между шагами точка, где человек может остановиться, поправить или отклонить результат. Спецификация утверждается до того, как написана первая строка кода, поэтому агент реализует её против конкретных критериев, а не против собственной интерпретации.
Что это даёт на практике
- Предсказуемость. Результат первого прохода агента заметно ближе к ожиданиям, итераций «переделай» стало меньше в основном потому, что агент реже уходит в сторону. В итоге точность генерации значительно выросла, а вместе с ней и скорость получения готового результата: меньше циклов правок быстрее задача доходит до мержа. Строгих замеров мы пока не проводили, но по ощущениям команды на некоторых задачах с чёткими границами скорость разработки в разы.
- Ревью становится проверкой соответствия спеке, а не попыткой угадать, что имел в виду автор.
- Спецификация живёт дольше кода. Через полгода понятно, почему модуль устроен именно так и следующий агент (или человек) может безопасно его менять.
- Онбординг новых людей и новых моделей: одна и та же спека работает для любого исполнителя.
Что не работает (пока)
Честно про ограничения. Агенты плохо справляются с задачами, где требования размыты (например задачи связанные с обработкой legacy кода) и меняются по ходу там спецификация устаревает быстрее, чем пишется. Они склонны «зеленить» тесты, подгоняя их под код, если критерии сформулированы нечётко. И они не заменяют архитектурные решения: выбор границ сервисов, модели данных, стратегии отказоустойчивости остаётся за людьми.
Стоимость тоже имеет значение: длинные агентные циклы на больших репозиториях расходуют много токенов, и без ограничений по контексту и числу шагов бюджет улетает быстро.
Тренд на ближайший год
По нашим наблюдениям, центр тяжести в разработке смещается от «умею писать код» к «умею точно описывать, что должно быть сделано, и умею это проверить». Разработчик становится ближе к роли архитектора и тех-лида для команды агентов. Компании, которые сегодня выстроят культуру спецификаций и автоматической проверки, завтра получат наибольшую отдачу от агентов какая бы модель ни оказалась лучшей на рынке.
Практический чеклист для тех, кто начинает
- Начните с задач с чёткими границами: тесты, миграции, рефакторинг одного модуля.
- Пишите спецификацию до промпта. Если не можете сформулировать критерии приёмки задача ещё не готова для агента.
- Дайте агенту доступ к запуску тестов и линтеров — это его основной канал обратной связи.
- Ограничивайте зону изменений явно, списком файлов или модулей.
- Ревьюйте не только код, но и то, как агент интерпретировал спеку расхождения покажут дыры в самой спецификации.
Будем рады обсудить в комментариях, как вы встраиваете агентов в свои процессы и какие подходы к постановке задач у вас сработали.
Share
