AI agents for programming: what do they really speed up in code

What does this solve?

AI agents For programming, the mechanical part of the work is removed - the one where the solution is known, but a lot of time is spent. Understand where a specific field is processed in someone else’s repository; write tests for code that was written without tests; push renaming through eighty files; upgrade the library version and fix broken calls; read a three-hundred-line stacktrace and find your line in it. These tasks do not require invention, they require perseverance and a complete bypass of the code. The acceleration here is measurable, in contrast to the talk about “replacing a developer.”

How it works

Three different formats, which are often called one word.

Addition to the editor. The model sees the open file and neighboring ones, suggests continuation of a line or function. The decision is made by a person at every step.

Agent in the editor or terminal. There is access to the file system, searching the repository, running commands, git. It works in a cycle: read → change → build → run tests → read error → change. Stops when reaching a goal or step limit.

Background agent. Triggered by an event - a fallen pipeline, a new ticket, a comment in a task - and brings the finished branch with changes to review.

The agent has four pillars inside.

Context. Directory tree, text search, reading specific files. The entire repository does not fit into the model, so the agent sees fragments and completes the rest based on a guess. Anything that makes the required fragment cheap to find - meaningful names, types, tests, README next to the module - directly improves the quality of edits.

Tools. Reading and writing files, running commands, git, tests, linter. The set of tools determines the ceiling: an agent without the right to run tests works blindly.

Project Rules. File in the root of the repository with instructions: how to raise the environment, how to run tests and lint, what style to stick to, what not to touch. Such a file is read by the agent at the beginning of work and replaces the repetition of the same instructions in each request.

Insulation. A separate branch or a separate working copy, so that edits are not mixed with others, and so that a rollback costs one command.

The output is always the same - a set of changes that a person reads. The diff review remains part of the cycle no matter how good the agent is.

How to connect

Start with a clean tree and a separate branch. Agent edits on top of uncommitted changes made by others cannot be parsed:

git status --short          # должно быть пусто
git switch -c fix-import-dates

Place the project rules file in the root. The minimum that pays off immediately: dependency installation command, test command, lint command, naming style, list of prohibitions - environment files, dependency directory, migrations, generated code.
Make commands reproducible. One target per action, no long memory lines:

make test
make lint
npm run typecheck

Give the agent the right to run tests and linter locally. Do not give access to combat systems, keys and the sales database: the edit-check cycle should be limited to the local environment.
The first task is small and verifiable. Fix one function, add a test, bring one module into general form. The task of “refactoring the project” produces a large diff that no one will check.
Read the entire changes before accepting:

git diff --stat            # объём: сколько файлов и строк
git diff                   # содержимое

Draft through a merge request so that the normal build pipeline works. Automatic checking catches what the eye misses.

Useful scripts

Orientation in unfamiliar code: where a specific field is processed, who calls the function, what is the path of the request from the entry point to the database.
Tests on existing code: the agent reads the implementation and covers edge cases, including those that people are too lazy to write down.
Mechanical refactoring: renaming, removing repetitions, bringing identical places to a common form throughout the repository.
Version migration: raise dependency and fix broken calls according to the list of build errors.
Analysis of a fallen pipeline: read the log, find the first real error among the consequences, suggest an amendment.
Tying around the task: unloading scripts, format parsing, fixtures, filling with test data.
First pass of the review: go through the diff and write down the obvious - unhandled errors, lost checks, forgotten indexes.

Limitations

The agent sees a fragment of the repository and confidently completes the rest. Hence calls to non-existent methods and parameters that are not in the signature. All calls to internal libraries are checked by source, and not by plausibility.

Conflict merging is a dangerous place. A permission like “rewrite the entire file according to your version” quietly loses someone else’s code, and a syntax check will not show this. Conflicts are dealt with piece by piece, with both sides read.

Green tests do not equal correctness if the tests were written by the same agent based on the same incorrect guess about the behavior. The value of a test is determined by whether it catches a real problem, not by whether it passes.

Architectural forks and implicit requirements are left to the person. The agent will choose an option that looks typical and will not ask about the peculiarity of a particular business, because he does not know about it.

Performance and racing cannot be done without measurements. The agent will suggest plausible optimizations that do not address the real bottleneck until the before and after measurements are available.

The speed of edits is faster than the speed of reviews. The bottleneck moves to the person who reads the diff, and this limits the reasonable task size for a single run.

Secrets and environment files are not shown to the agent. The key values end up in the model context, logs, and run history—access to such files is denied at the project rules level.

Rule: the agent is given what is checked by the team; everything that is verified only by opinion remains to man.

How to check the result

Look at the amount of editing to the content. A problem for one function that produced changes in twenty files is parsed anew:

git diff --stat
git diff --numstat | sort -k2 -nr | head   # где больше всего удалений

Large blocks of deletions should be checked separately - code that the agent considered unnecessary is most often lost there.

Run tests and static checks on a clean copy, and not just in the environment where the agent was running:

git clone --branch fix-import-dates . /tmp/check && cd /tmp/check
make install && make test && make lint

Check the behavior manually using the scenario for which the edit was made: reproduce the original error on the version before the changes and make sure that it is not reproduced after. The coincidence of green tests with uncorrected behavior occurs regularly.

Separately read all the places where the agent touched error handling, access rights and queries to the database. These three categories produce the most expensive unobserved regressions.

Calculate two metrics based on the results of the month: the share of agent edits that were rolled back after the review, and the time from setting the task to the green pipeline. The first shows where the task boundaries are chosen incorrectly, the second shows the real savings, if any.

If the share of rollbacks remains high for a specific type of task, this type is returned to the person and the neighboring ones are left to the agent - code reading, tests, tying.