SberDevices Builds Frontend Agents on GigaChat to Review Merge Requests

SberDevices decided not to send its code to external services for review and built its own agent system for the frontend. The off-the-shelf GitHub Copilot Code Review and GigaCode Agent from GitVerse did not fit: both are external, and the team does not want to open its repositories to them. Avrora, who is responsible for frontend infrastructure at the company, described the architecture on Habr. The announcement contains no metrics, so what follows covers what is confirmed, plus the engineering logic behind the decisions.

Why build in-house instead of buying

The issue with trusting external tools is not model quality but the security perimeter. A reviewer reads diffs, project structure, internal libraries and conventions. For a large company, that is exactly the code that does not leave its perimeter. Avrora describes the typical path of large teams as building their own "bicycle with the right number of wheels and pedals." It is a deliberate choice: external products solve a general problem, while an internal stack is tailored to specific repositories and processes.

The system is built on GigaChat. The title of the original post sets agents "with and without GigaChat" against each other, that is, automation with a model versus classic approaches.

Two modes in one system

The key architectural decision: the team combined two approaches rather than picking one.

• Agentic loop. The model gets a goal and a set of tools, then decides for itself which steps to take. It is flexible but less predictable.
• Deterministic workflow. The model performs individual, bounded tasks within a fixed sequence. The results are easier to verify and reproduce.

The hybrid looks sensible here. Reviewing a merge request consists of narrow operations: finding a common error, checking a convention, assessing a specific fragment. It makes more sense to hard-wire these into a rigid scenario. Open-ended tasks like "figure it out and suggest a fix" are better handed to a loop with tools. The first gives stability, the second gives coverage.

What the full write-up promises

The author highlights three topics:

• error statistics for frontend developers based on AI reviewer data, that is, which defects recur most often;
• a parser that narrows the model's context so it sees only the relevant code;
• a system feature that "suddenly" turned out to be the most popular.

The parser deserves attention. Frontend code is noisy: markup, styles, configs, generated files. If you feed the model everything, cost and response time rise while the quality of its comments drops. Pre-filtering by code structure helps define the task more precisely and fit within the context window.

The announcement does not say which feature became the most popular. We will have to wait for the full text.

What to take away

If you are building an internal AI reviewer or a development agent, there are a few things you can borrow from SberDevices' approach.

Split tasks by degree of freedom. Anything that a clear algorithm can handle should be a deterministic workflow, and the agentic loop should be reserved for open-ended tasks.

Don't feed the model the whole repository. Narrow the context first with a parser or static analysis, then call the LLM.

Collect statistics on the reviewer's comments. They reveal the team's recurring mistakes, and it is often cheaper to eliminate those with a linter or a template than to comment on them in every merge request.

Watch what people use most. The author openly admits that the most popular feature was not the one they expected. Build telemetry into the system from the start.

For the market, this is one more example of large companies moving away from external AI services toward internal agent platforms. The reasons are practical: control over the code and the ability to tailor behavior to their own processes.