Six Weeks to One: What AI Agents Actually Changed in How We Ship

By Adam Sieders, Director of Engineering and AI, Health Roads

Six weeks to one. That is how long a single-feature epic now takes us from kickoff to release. Complex epics went from twelve weeks to three, and our cost per feature release is about a quarter of what it used to be.

People ask me how we did it, and the honest answer is less exciting than they expect. The model is not the secret. The process around it is.

We brought Anthropic’s Claude Code into our engineering workflow across the whole lifecycle: requirements verification, development, testing, version control, and DevOps. Our engineers still own the design decisions, the reviews, and the call on what ships. That part did not change, and it is not going to.

What made this hard for us, and worth writing about, is what we build. Health Roads makes revenue cycle management and interoperability software for healthcare and social care. When we get it wrong, real organizations lose real time and money, and the data involved is some of the most sensitive there is.

Why we did it

Our customers keep asking for more complex workflows, and they are right to. Revenue cycle management lives or dies on accurate documentation and reliable processing. Interoperability only works when data lands in a shape the other system can use. A small mistake in either place turns into hours of cleanup for the people relying on us.

We are also a growing company. Demand moves faster than headcount, and every engineering dollar has to count.

So I set three goals: ship features faster, take on harder work without giving up quality or reliability, and bring down the cost of each release.

There was a fourth goal underneath all of them. Speed could not come at the price of technical debt. If our own engineers cannot read and maintain what gets built, we have not saved anything. We have just moved the cost to later.

The first rule: no PHI, ever

Before any agent wrote a line of code, we drew a hard line. No protected health information or other sensitive data goes into the AI coding environment. Not in prompts, not in test fixtures, not in a pasted log.

Our agents work in a controlled engineering environment against synthetic data. They can work through the logic of a claim, an eligibility check, or a data exchange without ever touching the real people behind those workflows.

The rule gets tested hardest at the integrations. Our agents connect to Jira, Confluence, and our Git repositories so they can read approved requirements, documentation, and code. Every one of those connections lives under the same restriction. A support ticket or a requirements page cannot become a side door for patient information.

To be clear, keeping PHI out of coding agents is one safeguard, not a compliance program. HIPAA, and 42 CFR Part 2 where it applies, still govern the systems we build and how we build them. Adopting an AI tool does not make anyone compliant. Doing the work does.

Agents need a process to follow

The biggest lesson from this transition: an agent is only as good as the process you put it in. Drop one into an undocumented workflow and you get fast, confident, inconsistent work.

So we started with a documented SDLC and gave the agents a defined role at every stage of it.

Work begins with requirements verification. Agents read the requested behavior, check it against stated priorities, and flag the ambiguities. A person resolves them. That step has saved us more rework than anything else, because the cheapest bug is the one caught before the code exists.

From there, agents help write the code, build and run tests against synthetic data, and handle the version control and DevOps work that used to eat engineering time just moving things from one stage to the next.

We also keep the work small. Features get broken into small, independently completable pieces so one blocked item never holds up everything around it. Small pieces are easier for an agent to get right and easier for a person to review.

None of this replaces human-centered design. A feature can pass every test and still be awkward for the person using it. Understanding the user’s task, and deciding whether we actually served it, is still our job.

People own the review gates

I do not trust AI-generated code by default, and I do not want my team to either. An agent can misread a requirement, skip an edge case, or produce something that looks right and behaves wrong.

Every change goes through human review, and nothing merges without an engineer approving it. Reviewers ask the same questions they always have. Does this do what the requirement asked? Does it fit the system? Will someone understand it a year from now?

Agent self-testing helps, but a model grading its own work does not prove anything. We pair it with human review and stress testing on synthetic data, so we see how the code behaves under load and on the bad paths, not just the happy one.

What reviewers find goes back into the workflow. A misunderstood requirement or a missing test case becomes an update to the instructions that guide the next round. The process gets a little better every cycle.

None of this makes mistakes impossible. No model, test suite, or reviewer can promise that. What it does is catch them earlier and more often.