The Bottleneck in Agentic Engineering Was Never the AI

A few weeks ago, one of our engineers shipped a Zango module in an afternoon that would have taken most of a week last year. A multi-step patient enrolment workflow, complex order schemes, the tests, the docs — an AI agent did the bulk of the typing while he steered. Our first reaction was the obvious one: this is the productivity story everyone's talking about.

Our second reaction, the one that's stuck with us, was less comfortable. The thing that made that afternoon possible wasn't the agent. It was the six months Zelthy had spent building the rails the agent ran on. And almost nobody talks about that part.

One small example: the agent got the enrollment flow broadly right, but it initially missed a rule that mattered in Zelthy's world — an edge case around when a patient's documentation status should block the next order action. The code looked clean. The UI worked. A casual demo would have passed. But the written plan had that rule explicitly captured, and the review agent flagged the mismatch before it reached a human reviewer.

That was the moment the lesson became obvious to us. The win was not that the agent wrote working code. The win was that Zelthy had made "correct" specific enough that something else could challenge it.

What most engineering leaders are getting wrong

The conversation about agentic coding right now is overwhelmingly about horsepower. Which model? How many pull requests per week. How many lines shipped with zero human keystrokes. The benchmark numbers are real and they're genuinely staggering — teams reporting hundreds of thousands of engineering hours saved, agent fleets opening thousands of merged PRs a week.

But if you run engineering for anything that touches a regulated environment — and in pharma, everything does — those numbers should make you nervous, not excited. Here's the arithmetic that actually matters:

So the velocity framing has it backwards. When you give a team a tool that writes code ten times faster, you haven't solved your engineering problem. You've moved it — from how fast we can write code to how fast we can verify code we didn't write. And most organizations have invested almost nothing in the second thing.

This is where we think the industry's vocabulary actually helped for once. The shift from "vibe coding" to "agentic engineering" isn't branding. Vibe coding is describing what you want and hoping. That's fine for a prototype and catastrophic for a system a top-10 pharma runs a million patient journeys through.

Agentic engineering assumes the agent will confidently produce something plausible and wrong — and builds the entire process around catching it before a customer does.

You're not managing an AI. You're designing a system that contains one.

Once you accept that, the job changes completely — and in a direction that should reassure good engineers rather than threaten them.

The skill that matters most is no longer writing the code. It's specifying intent precisely, designing the constraints the agent operates inside, and building the feedback loops that make its output verifiable. Zelthy has found the ten minutes spent writing a real spec before an agent touches anything saves hours of rework downstream — and more importantly, it's the only version of the work that produces an audit trail. A vague prompt leaves no trace of what "correct" was supposed to mean. A written plan is a contract you can check the output against, and in Zelthy's world, "show me where the requirement was defined" is a question regulators actually ask.

The second thing that changes: you stop thinking about one all-powerful agent and start thinking about a team of narrow ones. The same separation of concerns Zelthy has always believed in, applied to a workforce that happens to be made of models.

The Zelthy loop: research → plan → execute → verify → ship. Specialized agents do the work between gates; humans own the gates.

An agent that writes the implementation. A separate one that generates tests. One that reviews the diff against the plan and reports only the gaps that affect correctness or security — not style opinions, because a reviewer told to find problems will always find some, and chasing all of them just buries you in defensive over-engineering. A security scanner that runs on every change, because manual review genuinely cannot keep pace with agent-speed output.

And the part nobody finds glamorous: the context. The convention files, the architectural rules, the skills that encode "here's how we build a PSP enrollment flow on Zango." That's the unsexy infrastructure that decided whether the engineer's afternoon was a triumph or a mess. Zelthy learned — the hard way, more than once — that when an agent's output quality drops, the instinct to blame the model is almost always wrong. The context was stale, or the spec was thin. Fix the harness before you fault the agent.

Zelthy got this wrong in the beginning. When output quality dropped, the team's first instinct was to switch models or rewrite prompts. In most cases, that was wasted effort. The real issue was usually more boring: a convention file that still reflected an older Zango pattern, a missing example for a workflow type, or a spec that said "validate eligibility" without spelling out what eligibility meant. Once the team updated the context, the same model suddenly looked much smarter.

What this means if you run engineering

If you're an engineering leader staring at the agentic-coding wave wondering where to start, an honest advice is to resist starting with the model question. The model is the part that's improving on its own, weekly, without your help. Start with the things that compound instead.

• Spec before prompt. Every time, no exceptions. It's your contract and your audit trail.
• Encode conventions where the agent reads them. Keep that file lean — bloated context degrades agents the way it degrades onboarding docs for humans.
• Automate the gates. Tests, security scans, an architecture check — all passing before a human ever sees the diff. At Zelthy, that also means the reviewer should not be asked a vague question like "is this good?" Narrower questions: does the diff match the plan, did it introduce a permission gap, did it bypass an audit log, did it change a patient-facing workflow without a test? The narrower the gate, the more useful the agent becomes.
• Keep accountability bright. The engineer who merges agent-written code owns it completely. "The agent wrote it" is no one's explanation for a defect.

Zelthy has written up the full version of how it structures this internally — the workflow, the agent roles, the governance gates — as a process document its own teams run on. We will share more of the specifics in a follow-up.

We don't think any of this is settled. Zelthy is still finding the edges of where agents help and where they quietly make things worse — coordinated changes across services still need a human holding the map, and genuinely novel architecture decisions still default to generic patterns that don't fit. We don't have a clean answer for all of it yet.

But we are convinced of one thing. The teams that win the next few years in regulated software won't be the ones with the best agent — everyone will have that. They'll be the ones who built the better engineering process around it. In Zelthy's world, shipping faster was never the hard part. Shipping faster and being able to prove it's correct is the whole game.

Common questions about agentic engineering

What is agentic engineering?

Agentic engineering is the practice of building the process — specs, automated gates, and human sign-off — around an AI coding agent, rather than trusting its output directly. It assumes the agent will confidently produce something plausible and wrong, and is designed to catch that before it reaches a customer.

What's the difference between vibe coding and agentic engineering?

Vibe coding means describing what you want to an AI agent and hoping the result is correct, with no written spec and no audit trail. Agentic engineering starts from a written plan, routes the agent's output through narrow automated gates — tests, a diff-versus-plan review, a security scan — and keeps a human accountable for every merge. Vibe coding is fine for a prototype; regulated, patient-facing software needs the second approach.

Why does AI-generated code need extra verification in regulated industries like pharma?

A team shipping 1,000 AI-assisted changes a week at even a 1% defect rate is introducing roughly 10 new problems a week — a backlog no manual review process can keep up with. In pharma, where software touches patient-facing workflows and regulators can ask "show me where this requirement was defined," an unverified defect carries compliance and patient-safety risk, not just a support ticket. The process has to assume the agent will occasionally be confidently wrong, and build verification in as a default, not an afterthought.

How does Zelthy structure its AI-agent code review process?

Every change starts with a written spec, since a vague prompt leaves no trace of what "correct" was supposed to mean. From there, specialized agents handle implementation, test generation, and a plan-versus-diff review, with a security scanner running on every change. All gates have to pass before a human — the engineer who owns the merge — ever looks at the diff, and that engineer remains fully accountable for what ships.