Agents Don't Fix Broken Engineering Practices. They Scale Them
The best line written about agentic development this year is that agents do not magically fix broken engineering practices, they scale them. If your tests are thin and your review is a rubber stamp, an agent makes that worse at speed. Here's the readiness check.
Usman Akram · · 5 min read
The single best sentence written about agentic development this year comes from a DevOps playbook on Microsoft's developer blog, and it is this:
"agents do not magically fix broken engineering practices. They scale them."
Everything worth saying about adopting AI coding agents is downstream of that line.
Speed was never the thing protecting you
Here is the uncomfortable mechanism, and it is worth being precise about it because most teams get it backwards.
For twenty years, writing code was the expensive part. That expense acted as an accidental safety mechanism. A weak code review process was survivable because it only ever faced a trickle of changes. Thin test coverage was survivable because changes arrived slowly enough that a human could think about each one. Tribal knowledge living in one person's head was survivable because the pace never exceeded that person's capacity to be asked.
None of those were good. They were merely tolerable, because the input rate was low.
Agents remove the input rate limit. They do not remove any of the liabilities. So the practices that were quietly failing at human speed now fail at machine speed, and the failure arrives before anyone has updated their mental model of how much scrutiny a change is getting.
That is what "they scale them" means. It is not a warning about the agents. It is a warning about what you already had.
The six foundations
The same playbook proposes a foundation checklist to evaluate before scaling agent adoption, and it is a genuinely good list. Six dimensions:
- CI/CD pipelines that are fully automated for build, test, and deploy. Not mostly automated. Not automated except for the one manual step everyone knows about.
- Automated testing with meaningful coverage thresholds. The word doing the work there is "meaningful." A codebase at 80% coverage where the tests assert that functions return without throwing is at 0% coverage in every sense that matters when an agent hands you a subtly wrong implementation.
- Infrastructure as code with drift detection. Version-controlled templates, and something that notices when reality diverges from them.
- Security scanning integrated into every pipeline run. Dependency scanning, secret detection, code analysis. Every run, not a quarterly audit.
- Branch protection. Required reviews, status checks, merge restrictions. The boring gate that stops the 4am agent commit from becoming a production incident.
- Production observability with clear ownership. Logging, monitoring, alerting, and a name attached to each.
Read that list and notice something: not one item is about AI. Every single one is standard engineering discipline that has been recommended for a decade. The agentic era did not invent new requirements. It removed your ability to keep ignoring the old ones.
Most teams are not near the top of this curve
The playbook sets out a four-level maturity model, from Reactive through Foundation, Structured, and Optimized, and its assessment is blunt: most organisations today sit between Levels 1 and 2.
That matches what we see. The typical company asking us about AI coding agents has partial CI, tests that pass because they do not assert much, infrastructure that drifted from its templates some time in 2024, and a review culture where a large diff from a trusted colleague gets approved on vibes.
For that company, adopting agents aggressively is not a productivity strategy. It is an accelerant applied to a system whose brakes were never tested.
The honest advice, which is unpopular because it is slower and less exciting, is that fixing the foundations is the agent strategy. Do the boring work, and the agents become genuinely transformative on top of it. Skip it, and you have bought a faster way to generate changes nobody can verify.
After prompting comes specification
There is a second idea in the playbook worth taking seriously, framed as the next phase: specification-driven development. Rather than crafting prompts, engineers write structured specifications that define what needs to be built, and those specs become durable, versioned, reviewable artefacts instead of chat messages that evaporate.
The practical translation is uncomfortable for most teams. If your requirements currently live in Slack threads, a half-finished Notion page, and the head of the one product manager who was in the original meeting, then that is what is blocking your agent adoption. Not your model choice. Not your tooling budget.
An agent is a machine that turns a specification into an implementation. Feed it an ambiguous specification and you get a confident implementation of the wrong thing, delivered quickly, in a diff too large to review properly. The clarity you were able to skip when a human engineer filled the gaps from context and judgment is exactly the clarity you now have to write down.
I would add one caveat the playbook does not: this is a blog post by an author at Microsoft, and it carries a disclosure that it was partly AI-assisted. It is a point of view, not a standard. But the point of view is correct, and it matches what we see in the field, which is more than I can say for most vendor content on this subject.
What we tell teams before they adopt agents
Three questions, in order.
Would you notice? If an agent introduced a subtly wrong assumption into your codebase today, what would catch it? If the honest answer is "a customer, eventually," you are not ready, and no amount of model capability changes that.
Can you review at the rate you can generate? Generation capacity is about to become effectively unlimited. Review capacity is your senior engineers' attention, which is fixed and expensive. If you scale one without the other, the queue of unreviewed-but-merged changes becomes your new technical debt, and it compounds faster than the old kind.
Can you write down what you want? Not gesture at it. Write it down, in a form another person could implement without asking you a question. If you cannot, an agent will not save you from that. It will just build something.
The good news
Every one of these prerequisites is worth doing on its own merits. Nobody has ever regretted meaningful test coverage or working observability. The agentic era did not create new work so much as it removed the excuse for postponing work that was already overdue.
Teams that did the boring engineering are about to get a very large return on it. Teams that did not are about to find out, faster than they expected.
If you want an honest assessment of whether your codebase and delivery process can actually survive agents at speed, that is the kind of engagement our DevOps Engineering practice runs. Tell us what you are running and book a discovery call.
The quoted line, the six-dimension foundation checklist, the four-level maturity model, and specification-driven development are from the "DevOps Playbook for the Agentic Era" on Microsoft's developer blog (15 April 2026), which carries a disclosure that it was partly AI-assisted. Verified against the primary source on 12 July 2026.
Frequently asked
What does it mean for a codebase to be agent-ready?
It means the automated safety net around the code is strong enough that an agent's mistakes get caught before they reach production. Concretely: a fully automated build, test, and deploy pipeline; test coverage that actually means something rather than hitting a percentage; infrastructure defined as code with drift detection; dependency scanning, secret detection, and code analysis running on every pipeline run; branch protection with required reviews and status checks; and production observability with clear ownership. Agents move fast, and speed is only an asset when the guardrails hold.
Why do AI coding agents make bad engineering practices worse?
Because the constraint that used to protect you was slowness. When writing code was expensive, a weak review process still only had to catch a trickle of changes. When generation becomes nearly free, the same weak process faces a flood. Thin tests, rubber-stamp reviews, and undocumented tribal knowledge were always liabilities, but they were survivable at human speed. Agents remove the speed limit without removing the liability, so the failure arrives sooner and larger.
What is specification-driven development?
It is the idea that structured, versioned specifications should replace ad-hoc prompting as the way work is handed to agents. Instead of crafting a prompt in a chat window and hoping, engineers write a specification that defines what needs to be built, and that spec becomes a durable, reviewable artefact. The practical implication is that if your requirements currently live in Slack threads and someone's memory, that is the thing blocking your agent adoption, not your choice of model.
Should we adopt AI coding agents if our test coverage is poor?
Fix the tests first, or at least fix them in parallel and constrain what the agents touch until you have. This is unfashionable advice because it is slower, but the logic is hard to escape: the value of an agent is the speed at which it produces changes, and the safety of a change rests on your ability to verify it. Adding generation capacity to a system with no verification capacity does not give you faster delivery. It gives you faster accumulation of unverified changes, which is a different thing that feels the same for about a quarter.
CTO, IrenicTech
Usman is the CTO of IrenicTech. He builds AI agents, RAG systems, and automations into web and mobile products, and gets them shipped in weeks instead of quarters. He's focused on AI that learns from the people using it, and that's secure enough to trust with real data.
Connect on LinkedIn
