When John Harbison talks about his engineering team′s success with AI-augmented development, he keeps coming back to foundations.
Today, PrescriberPoint′s engineering team hasn′t written code manually in 12 months, their weekly pull request throughput has tripled, and they′re delivering value to customers faster than ever.
But this story doesn′t start with AI agents creating 30,000-line pull requests (though it does end up there). It starts seven months earlier, with something far more mundane: improving Jira hygiene and establishing working agreements in Swarmia.
First, they needed to understand their baseline. Then, they could go all-in on AI.
Exposing the cracks in the foundation
Even pre-AI, PrescriberPoint was shipping faster than most — in the realm of 5 to 10 deployments to production daily.
However, they bounced between Kanban and Scrum and experimented with story points and t-shirt sizes, in an attempt to predict throughput and velocity. This approach didn′t lead to a great deal of success, causing some frustration between the business and engineering.
When you′re moving with that velocity, it′s very hard to do any type of forecasting or be able to know if the day is going to end well or predict what can be accomplished in a period of time.
Head of Product Engineering
But after connecting their tools to Swarmia, John was able to surface process breakdowns and patterns he wouldn′t have been able to see elsewhere.
Swarmia was very quick to expose where we had process breakdown, and what to do about it.
Head of Product Engineering
So the team started with working agreements. They set expectations around work in progress limits, code reviews, and commitments — which gave them shared language and clear standards.
When we first started with Swarmia, we used working agreements very heavily. We found a lot of value in them and it helped to keep the work in progress and the commitments and the time frames aligned.
Head of Product Engineering
The working agreements worked because everyone bought into the data: engineers had control over their own improvement, and leadership could see the impact.
″Everyone was always very open to it,″ John says about introducing engineering metrics. ″They want to know what′s going on and they want to address any problems. The engineers have participated in Swarmia training, they′ve asked questions, and they all have access and use it.″
That foundation made everything that came next possible.
The year they stopped coding
Over the course of about a year, PrescriberPoint′s engineering team stopped writing code manually. The workflow evolved gradually from chat-based AI assistance, to semi-attended work, to fully autonomous agents handling entire features.
″Even my juniors looked at the outputs and said, ′Six months from now, we′re never writing code again,′″ John recalls. The prediction turned out to be accurate.
″No one is writing code now. We′re done with it,″ says John.
Interestingly, John isn′t of the opinion that you should replace your engineers with AI agents. In fact, the team kept the same headcount.
The way we viewed it is that AI is either a huge unlock for cost and our margins are going to become amazing, or we can ship a whole lot more product to market. We didn′t think of this as a workforce reduction exercise.
Head of Product Engineering
Redefining what engineering means
PrescriberPoint′s use of AI-augmented development required totally reimagining what engineers do day-to-day.
They invested heavily in their design system, building a comprehensive component library that gave engineers enough context to start work before high-fidelity designs were finished. They brought engineers into product ideation from day one, so they understood not just what to build but why it mattered.
Engineers aren′t just there to be the tech check anymore. They′re applying their business knowledge to the solution. They understand the domain and can make product decisions, not just technical ones.
Head of Product Engineering
This meant focusing on business and product knowledge as core engineering skills. Engineers started hearing about strategic priorities and business impact daily. Senior engineers became UAT experts who could evaluate whether AI-generated features actually solved the right problems.
The cultural foundation (willingness to experiment, permission to fail, trust in the process) mattered as much as the technical changes. ″You have to allow room to learn,″ John says. ″We started with a small team, proved out the method, and then rolled it out.″
How Swarmia evolved with the team
The way John′s team works now doesn′t adhere to most (or any) traditional engineering benchmarks:
- Pull requests with 30,000 lines violate every best practice about keeping changes small
- Time to first review became less meaningful when AI does the first review
- Cycle time matters less when the question became ″did you ship the feature to standards, on time?″ rather than ″how fast did you merge the PR?″
And as their workflows evolved, so did how they used Swarmia. Working agreements, which helped establish standards and shared language during the foundation-building phase, became less relevant.
Investment balance validates quality at speed
One of the best parts about investment balance is that it′s infinitely configurable. John sets theirs up in two ways: one view using a variant of the classic balance framework, where ′Improving things′ for John means rework, and another view simply showing planned vs. unplanned.
What stands out most is that their ′improving things′ number has stayed remarkably low, but not because they′re cutting corners. Their AI workflow shifts when the iteration happens. When Claude generates code, engineers test and refine it immediately before moving on. Issues get caught and fixed in the moment, not weeks later.
This real-time feedback loop means they′re building quality into the process rather than fixing problems after the fact. Swarmia′s investment balance data proved they′re not accumulating technical debt, despite their unconventional workflows.
Initiatives connect work to business outcomes
Can the team commit to features and ship them on time? Swarmia′s initiatives view helps answer those questions. John can see the completeness and effort scale of each initiative, and communicate it clearly to business stakeholders.
Where we get a lot of value now is from the initiatives view, because I want to understand the completeness of an initiative and the effort we′ve spent. Those are two really valuable things to me.
Head of Product Engineering
Work log reveals different patterns now
With AI increasing the volume of everyone′s output, the work log shows areas of saturation — who′s overloaded, where bottlenecks are forming, and whether there′s been unplanned work due to an issue in production.
What engineering leaders can learn
PrescriberPoint′s transformation offers lessons for engineering leaders at any stage of AI adoption, whether you′re just starting to experiment or already seeing productivity gains.
- Fix your data quality first. Process breakdowns compound when you accelerate, and you can′t outrun them by adding more AI. Swarmia helped PrescriberPoint identify and fix issues with their foundations, which paid off in the long run.
- Build shared understanding. Working agreements gave PrescriberPoint′s team common language and clear standards. The cultural foundation — trust in metrics, willingness to be measured — mattered as much as the technical changes.
- Invest in product and business knowledge. As AI handles more of the technical execution, engineers need deeper understanding of the problems they′re solving. PrescriberPoint brings engineers into product and design conversations from day one.
- Use data to validate your approach. Swarmia gave PrescriberPoint proof that their somewhat radical approach was working. Minimal rework validated that speed wasn′t creating hidden problems. Without that data, how would they know?
Fix the foundation, then go all-in
Most engineering leaders reading this won′t take their teams full agentic next quarter, and that′s fine. PrescriberPoint′s story isn′t prescriptive, but it does show what′s possible when you build the right foundation.
The key to succeeding with this stuff is to allow room to learn. And if you′re that nervous about it, start with a smaller team. Let them prove out your method, and go from there.
Head of Product Engineering
So before you accelerate, understand where you are. Fix the breakdowns, build a shared language, and create trust in the metrics. Then, when you′re ready to transform how you build software, you′ll have the data to know if it′s actually working.
