Team Builds an AI Agent Into Development and Adds Two Review Stages

The agent wrote the code quickly. Now someone has to check whether it changed the right service, queried the right database, and avoided blocking the interface with a long operation. In an article on Habr, the team described how it tackled these problems in its own agent for IntelliJ IDEA. One of the key steps is to approve the specification in a separate pull request before implementation begins. This workflow can also be tried with an agent you already have installed.

The story began in 2024 with a plugin for generating tests. A chat then appeared inside the IDE, and after trying Windsurf in January 2025 the team set about building a full-fledged agent: project search, file editing and running checks. As they used it, it became clear which parts of the work had to be explained again and again and where the tool needed constraints.

Project context: finding the code and choosing the right database

For search, the team used IntelliJ IDEA indexes and PSI, the structural representation of code inside the IDE. Indexes help find classes, methods and files, while PSI shows program elements and the relationships between them. The agent passes this information to the language model.

Imagine a task: change order processing. It helps to find the method itself, its calls and related classes before editing the first suitable file. This is an illustration of the approach; the authors give no concrete measurements of the quality of such search.

For external sources, the team added MCP, a way to connect servers that provide tools to the agent. Through them it is possible to fetch tasks from GitHub, query a database or check a web application in a browser. The available actions depend on the specific server and the permissions granted.

But connecting a database did not by itself solve the context problem. According to the authors, a query once went to the wrong environment and returned a convincing but incorrect result. The agent also confused column names. Developers had to repeat explanations, especially after opening a new chat.

The team packaged recurring procedures as skills: instructions with a sequence of steps and verification conditions. A local project memory was also added for constraints and discovered solutions. Saving credentials is forbidden by the rules, but the text provided does not disclose any technical mechanisms protecting the memory.

Check the task first, then check the implementation

Now work on a feature starts with a specification. The developer drafts it together with the agent and opens a separate pull request. A colleague reviews the document, and implementation begins after approval. Decisions and clarifications stay in the repository so the next contributor can restore the context.

Take an API change. Before any code is generated, the team can agree on response fields, error handling and expected client behavior. The frontend developer receives a description that a colleague has already checked. This creates an early checkpoint: an error in the requirements can be spotted before it spreads across several files.

For code review, the authors used their own comments from past pull requests. While developing the plugin, they often encountered long operations on the EDT interface thread and calls to the IntelliJ API without the required read action. These cases were turned into instructions for the reviewing agent.

Later, the review was split among several subagents with different roles. Results are collected into a single report, after which the developer chooses which fixes to apply. The authors claim familiar errors became less frequent, but they show no statistics, control sample or cost of the checks. The size of the effect cannot be judged from the article.

What you can carry over to your own team

The most practical element of the story is control of actions at the plugin level. A tool can be disabled or required to ask for confirmation before it is called. The decision to run is made by the software shell. This gives the developer a concrete control point when working with commands and external services.

The team also separated the agent logic from the interface and released a CLI. By its description, the terminal version retains work with files, skills, models and MCP. However, the fragment provided cuts off: the product name, access terms and the full picture of operation are missing here.

A practical experiment can start with a recurring error in your own team: write down a review rule, add requirements approval and compare results on the following tasks. It is worth measuring time to an accepted change, the number of review returns and defects after merge. These are exactly the measurements this story still lacks in order to judge whether building your own agent pays off.