AI agents in software development: what they speed up and where they get in the way

The article template on our own website listed dozens of typography classes while the plugin that creates those classes was not installed. The code looked right, the build passed without errors, and long articles rendered in default browser styles. I noticed it during review? No, only when I opened the page and saw text laid out like it was 1998.

No agent catches an error of that kind, because everything is formally correct. That boundary is what our work with Claude Code, Cursor and Codex is built around. We use them daily, and we keep one rule.

You cannot accept what you cannot verify in minutes

From that follows something which at first glance has nothing to do with AI. The better a project’s checks, the more value agents add. Strict types, fast builds, tests on the critical paths, a linter. All of it used to be hygiene and is now a precondition, because those checks are what reject bad output before it reaches the product.

If a result can only be verified by an experienced person’s eyes, an agent does not speed the work up, it moves the work onto whoever can verify. The bottleneck simply relocates.

Where the gain is obvious

Routine code: components built to an existing pattern, forms, tables, migrations, API wrappers. The correct result is visible immediately. This used to be mechanical typing. Exploring an unfamiliar codebase works just as well: when you inherit somebody else’s project, an agent answers in ten minutes the questions that used to take a day. Where the entry point is, how authentication works, what happens when this form is submitted. Tests for code that already works also land cleanly, and that is exactly the work people postpone for years.

Drafts of documents: estimates, specifications, task descriptions. The word «draft» matters here, because a human cuts afterwards. Not one of those texts has gone to a client in the form an agent produced.

Where we lost time

Architectural decisions. An agent will happily propose a structure and it looks plausible. The cost of a wrong choice shows up months later while verification is impossible today, so we make those decisions ourselves and write the reason next to the code. Integrations with undocumented systems behave the same way. When the question is how somebody else’s accounting system responds to real data, generation does not help at all. Access and a few days of testing do. Nothing better has been invented yet.

Tasks with implicit requirements. If the client has not decided what the result should be, the agent produces a confident version that has to be redone. The speed up is an illusion. You get the wrong thing faster and then spend time working out why it does not fit.

What changes is the process

More time goes into framing the task. «Build a contact form» produces something you rewrite entirely. A description with fields, error states and the destination for the data produces something you can accept. Two minutes of difference when framing, half a day of difference at acceptance. More time goes into review too (the least pleasant part of the change). Reading somebody else’s code is slower than writing your own, and the saving appears only at volume, when there is a lot of routine work. On a three screen project an agent gets in the way.

Deadlines barely move. Faster code generation does not shorten a calendar project proportionally, because it does not touch approvals, credentials or acceptance. We plan from useful developer output, and agents shift that number far less than demos suggest.

What to do before inviting agents into a project

Collect the project rules in one file: stack, folder structure, naming, what must not be done. The trick is the same as with people, a list of prohibitions works better than a description of the ideal. Make sure the build and the tests run with one command. If verifying a result takes ten steps, nobody will verify it, and you will end up back at the story from the first paragraph, only later and more expensively.

And agree inside the team on who owns accepted code. «An agent wrote it» has not yet appeared in any contract I have seen.

What I do not know here

We have no measurements showing a speed up in percent. We never tracked hours before and after. Impressions lie especially badly in this area: the lucky case is what you remember, the average day is not memorable at all.

I am not sure about the shelf life of this text either. How much of the above stays true in a year, I cannot say. Tools change faster than experience with them accumulates, and half the rules here may expire before this article collects its first thousand views. For now they hold. That is all. I am not calling them conclusions for all time.

If you have the measurements we lack, tell us which tasks you measured and what speed up you got: numbers in this area are rarer than opinions.