A coding agent takes a whole task, reads and edits several files, runs the tests and hands back a reviewable change. On our .NET 10 and React work it cuts 20 to 40 percent of the build time for well-specified pieces. It still fails, confidently, on business rules, concurrency, security and anything Persian-specific. This is the workflow that made it safe on a 130-table CRM.

What changed between 2024 and 2026

Until 2024, AI in the editor meant completion: the next line, the next function, accepted or rejected keystroke by keystroke. Useful, and mostly a typing accelerator.

An agent is a different tool. You describe a task in the language of the domain ("add an amount-change history to contracts, recorded with user and timestamp, surfaced in the monthly report") and it finds the relevant files, follows the project's conventions, writes the entity, the migration, the endpoint and the tests, runs them, fixes what fails and returns one coherent change. Claude Code, GitHub Copilot's coding agent, Cursor and Codex all work this way now.

Three concrete shifts made this real:

  1. Context got large and cheap. The agent reads a whole module and learns the conventions from the code itself, not from our description of it.
  2. Tools became a standard. With MCP, the agent talks to the database, the docs, the ticket system and a browser without everything being pasted into a prompt.
  3. Running the build and the tests is part of the loop. A change that does not compile or breaks a test is fixed before a human sees it.

What did not change: the agent knows nothing about your business. If the rule "vendor settlement runs 14 days after delivery" is not in the code or the docs it can read, it invents a reasonable rule, and it will be wrong with complete confidence.

The codebase we learned this on

Idepoo CRM is an ASP.NET Core 10 modular monolith: 130 tables, 48 numbered migrations, a hand-rolled mediator, Quartz jobs, and a set of structural tests that fail the build on any deviation from the architecture. It is the kind of codebase where an agent can do a lot of damage quickly, which made it the right place to find out what actually works. The same workflow now runs on client projects, including PlazMarket, a marketplace whose compliance rules live in the domain model.

The five-step workflow

  1. A specification, not a wish. Every task starts with a short document: what, for whom, which rules, what must not change. "Build a good report" never reaches the agent; "the monthly contractual-commitment report with these three columns, sorted by Jalali date" does.
  2. Project constraints live in the repository. A guide file states where things go, which patterns are mandatory and which libraries are banned. The agent reads it before every task. Constraints in a person's head do not exist as far as the agent is concerned.
  3. Architecture tests, not only unit tests. One test in the CRM scans the compiled IL and fails if any domain code throws a general exception instead of the domain exception type. Another asserts the exact count of applied migrations, because a migration shipped without its attribute is invisible to EF and would pass a softer check. These tests were written for humans. They became essential for agents.
  4. Review the change, not the code. The reviewer reads the diff, but the question is not "is this code good"; it is "is this what we asked for, and is the business rule right". Code that has tests and follows the patterns is technically trustworthy. It is not yet trustworthy about the domain.
  5. No secrets in reach. Keys and passwords live in environment variables or a vault and never in files the agent reads. This rule has no exceptions.

Where it genuinely saves time

From a year of tracking our own tasks, the largest savings were:

  • Structural boilerplate: entities, EF configurations, DTOs, endpoints that follow the existing pattern. The agent is nearly error-free here because it copies the neighbours.
  • Migrations and schema changes, including the dependent test updates.
  • Tests for existing code, especially boundary cases nobody enjoys writing.
  • Safe refactors: renames, module moves, dead-code removal, with tests proving behaviour is unchanged.
  • Documentation and localisation: extracting strings, building translation files, writing API guides.
  • Audits: "list every place this rule is not applied" or "explain the difference between these two schema versions".

A task that took a day typically finishes in two or three hours including review.

Where it fails and how we catch it

  • Business rules. The agent takes them from code and docs; where they are absent, it makes them up. Fix: rules live in documentation and tests, not in a project manager's memory.
  • Persian and locale specifics. Jalali calendars, normalising Arabic and Persian variants of the same letters, Persian digits, right-to-left PDF layout. Models have seen less of this and make small, confident mistakes. Every search normalisation function in our e-commerce work has its own test for that reason.
  • Concurrency and money. Two buyers taking the last unit at once; a payment confirmed but its SMS never sent. The agent writes the textbook solution, correct under light load and wrong under contention. We catch these with concurrency tests, not reviews; Testing the money paths covers the specifics.
  • Security. An authorisation check left "for later", a credential hard-coded in a test, a dependency two years old. Static analysis and a dependency policy catch these. We do not rely on the reviewer.
  • Misplaced confidence. The agent never says "I am not sure". Every "done" is verified by a test or by direct observation. Our rule after a change: check twice.

The honest effect on cost and schedule

For custom software projects, 20 to 40 percent of the build time on well-specified parts is gone. But a project is not only code:

  • Discovery and analysis take the same time; someone still has to sit with the client and understand the settlement rule.
  • UX and interface design prototype faster; the decisions remain human.
  • Acceptance testing, deployment, training and support are roughly unchanged.

A four-month project from 2024 is about three months now, not one. Anyone promising ten times faster and ten times cheaper either has not shipped a real project this way or has quietly removed part of the scope.

What to ask a vendor

  1. Who reviews the code, and which tests catch agent mistakes?
  2. Where are my business rules written down so the agent does not guess?
  3. Which parts are agent-built, which are hand-built, and why?
  4. Do my keys or data reach an external AI service?
  5. Is the source delivered with tests and documentation? (With us: yes, and the source is yours.)

Is agent-written code lower quality than human code?

Not inherently. In a project with clear patterns and adequate tests, agent code is more uniform than a multi-person team's. Without patterns and tests, yes, and it degrades faster.

Do you still need senior engineers?

Yes, with a different job: specification, architecture, review and accountability. A project without an experienced engineer is a project where nobody owns the mistakes.

Does my code go to a third party?

With a cloud model, the code the agent reads is sent to the provider. Where that is unacceptable we run open-weight models on our own hardware: slower and less capable, but local. We decide this with you before the first task.

Summary

Coding agents are real and we use them daily. Their value is in well-specified work with tests; their risk is in business rules, security and locale detail. The difference between a team that uses them well and one that merely produces mistakes faster is specification, architecture tests and review. If you are planning a .NET and React build, the team that wrote this is the team that ships it.

Sources