The Agentic Engineering Best Practices Gap

Pick any month in the last two years and you can name a thing agents couldn't do the month before. Hold a whole repo in context. Run for an hour unattended. Write the spec, draft the design, open the PR, review the diff, file the follow-ups. The ceiling on what a fully orchestrated agentic SDLC can do has been climbing on a schedule you can almost set a watch to.

Now walk into a typical engineering org and look at what's actually running. One engineer has gone all the way in — agents wired into everything, a personal rig of prompts and scripts held together with real conviction. The person at the next desk tried it twice, got burned, and went back to doing it by hand. Nobody has agreed on what "using agents here" even means. There's no shared process, no house style for how work moves from idea to production, and whatever good practice does exist lives in one person's head and leaves when they take a Friday off.

That distance — between what the frontier makes possible and what a team actually practices — is the gap I want to name. And the uncomfortable part isn't that it exists. It's that it's getting wider. The ceiling rises every month; the floor moves at the speed of cultural transformation. Changing to the newest frontier model doesn't close the gap, because the gap was never about capability.

What "what teams actually do" looks like

Be honest about the typical case, not the demo. In most orgs, agent adoption is fragmented dev-by-dev. It's not a team capability; it's a collection of individual ones, each shaped by how much a given engineer happens to trust the tools that week. There's no agreed process the way there's an agreed way to cut a release or escalate an incident to SEV-1. Agents get bolted onto whatever workflow someone already had, and the practices that emerge are one-off and personal — clever, sometimes, but rarely hardened into how the team works.

The tell is that none of it compounds. When a great practice lives in one person's workflow, the org doesn't get smarter; that one person does. The next engineer starts from scratch. A team of ten "using agents" can be ten disconnected experiments running in parallel, and the whole is worth less than the sum, because there's no shared surface for the good parts to accumulate on. Capability is something you can buy in an afternoon. Consistency is not.

Why the gap widens instead of closing

Capability compounds at the frontier. The labs ship, the models get better, the tools get sharper, and each improvement stacks on the last.

Adoption doesn't work like that. Adoption is bottlenecked on the least glamorous things in software: process, trust, and shared habits. Those move at human speed — the speed of a team actually agreeing on how it works, building enough confidence to lean on a tool, and turning a good idea into something everyone does the same way. That's linear at best, and it stalls the moment attention moves elsewhere.

Put an exponential curve next to a linear one and you don't get convergence. You get divergence. The frontier pulls away, and "we bought the capability" quietly becomes "we bought the capability and captured a sliver of it." Every month the labs ship, the distance between what your team could be doing and what it is doing gets a little larger, not smaller — unless something deliberately closes it.

The value leaks in the delta

This is expensive in a way that's easy to miss, because nothing breaks. You're paying for the frontier — the seats, the tokens, the time engineers spend wiring it all up — and capturing a fraction of it. The waste doesn't show up as a failure. It shows up as an absence: the review that didn't happen consistently, the spec that sometimes got written, the second pair of eyes that depended on who was on shift.

I wrote in Brakes Before Speed that agents got a bigger engine and no brake — that verification, not generation, is the real bottleneck, and that you don't get to go fast until you can trust the thing to stop. That argument has a direct consequence here. Trust is the precondition for a team to actually commit to running agents deeply integrated in their SDLC. Without it, people do the rational thing: they crawl. They babysit every action, or they quietly stop using the tools for anything that matters. The brakes let the whole team lean into the cutting edge instead of a few brave individuals doing it alone. Where there's no shared, trustworthy way to work, the frontier stays a private hobby and the delta stays wide.

This gap is why we're building Pleach

I'll say it plainly, because it's the reason the company exists. Pleach is built to close the distance between the cutting-edge advances coming out of the frontier labs and the in-the-trenches, day-to-day reality of engineers who just want to focus on building good software.

The frontier will keep raising what's possible; that race takes care of itself. The hard, valuable, unglamorous part is turning that rising capability into a shared, dependable practice a whole team can run. Not a rig one engineer bolts onto their own workflow and defends in code review. Not a lunch-and-learn over Zoom. A way of working where the spec gets written, the design gets considered, the diff gets reviewed, the tests get run, and the release gets checked — every time, for everyone, because the process holds it, not because the right person happened to be paying attention. When good practice lives in the system instead of in someone's head, it compounds. That's the difference between a team that has agents and a team that has actually moved up.

Closing it is a culture change, not a switch

The mistake is thinking this gap closes with a newer model. It doesn't. You can buy every tool at the frontier and still ship the same fragmented, ad-hoc reality, because the thing you're missing isn't a tool — it's maturity. It's the move from "a few individuals use agents in their own way" to "the team runs a shared, orchestrated practice," and that's a climb, not a flip of a switch.

The good news about a climb is that it has rungs. There's a real progression from ad-hoc individual use up to a disciplined, consistent, team-wide practice, and you can locate yourself on it, see the next rung, and take it deliberately. Naming that ladder — what the levels are, how you tell which one you're on, and what it takes to climb — is exactly what I want to do in the next post. Because once you can see the gap for what it is, the useful question stops being "which tool do we buy?" and becomes "how do we level up together?"