# Agents Don't Fix Broken Engineering Practices. They Scale Them

> Before you point coding agents at your codebase, check that it can survive them. Six foundations decide whether agents help you or hurt you faster.

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:

1. **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.
2. **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.
3. **Infrastructure as code with drift detection.** Version-controlled templates, and something that notices when reality diverges from them.
4. **Security scanning integrated into every pipeline run.** Dependency scanning, secret detection, code analysis. Every run, not a quarterly audit.
5. **Branch protection.** Required reviews, status checks, merge restrictions. The boring gate that stops the 4am agent commit from becoming a production incident.
6. **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](/services/devops-engineering) practice runs. Tell us what you are running and [book a discovery call](/contact). [Track'em](/work/trackem) and the [release orchestration system](/services/ai-automation/systems/release-content-orchestration) both show what that delivery discipline looks like once it is actually enforced rather than documented. If you are still choosing the tooling itself, we compared the options in [AI coding agents in 2026](/blog/best-ai-coding-agents-2026).

_Part of our guide to [AI agent development](/blog/ai-agent-development)._

_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._