Gusto's Engineering org doubled developer throughput in six months — not by adopting a better AI model, but through five leadership decisions: making fluency a top-down priority, embedding fluent engineers on every team, converting skeptics through peer proof rather than mandate, hardening CI and automated review to catch AI-generated errors, and building an internal marketplace for sharing agent skills. The piece argues the model itself is a commodity; the real competitive advantage is organizational — how deliberately a company builds fluency, trust, and shared practice around it.
A year ago, most of our engineers spent their day writing code. Today a growing number of them spend it directing a fleet of agents that write most of it for them, and focusing their energy on whether the work is any good.
I want to be honest about what moved, because the interesting part is not that we adopted agentic development tools. We all buy the same frontier models or use solid open-source models, and the people who want to use them are everywhere too. The rare thing that set us apart,was converting all of that into throughput. That took two forces that pull against each other: a hard priority set from the top, and real belief built from the bottom.
What that looks like in practice: our strongest engineers are no longer single-threaded. A small but growing percentage, run several agents at once. They scope the work, hand it off, review what comes back, and keep three or four streams moving. Some of the best results this quarter came from engineers a year or two into their careers, because the thing that used to gate output, deep familiarity with a multi-million-line codebase, got a lot cheaper. The typing got automated. The judgment is the most critical part.
Our throughput has doubled over the last six months, and we are excited to share how that happened.
What we measured, and what we stopped measuring
When we started, we asked a beginner's question about AI: are you using it? That was the right question for about a quarter. Once adoption crossed into the high nineties (we are at roughly 97 percent), it stopped telling us anything. A score everyone passes is not a score.
So we changed the question from "are you using it" to "what can you do now that you could not do before." Adoption became fluency, and fluency is now bending toward impact. I will be straight that we are still finishing that last step, and I will come back to it, because it is the most important open question we have.
The leaderboards were up for a few weeks and then down. Token dashboards, usage rankings, the metrics that look like progress and quietly turn into a game. In their place we put features shipped, production bugs, review cycle time, and customer-facing quality. I think this is exactly where a lot of orgs are stuck right now, admiring a number that measures raw activity.
Five Decisions
Here’s what we did as a team.
1. We made AI fluency a priority from the top.
This did not start top-down. There was real grassroots usage before even I got involved, engineers experimenting on their own time. But it stayed purely bottoms-up until we made AI fluency the main thing. We cancelled an Eng-wide hackathon and gave the time back to AI training. Our Engineering leadership team sent the org an update every week for months. We role modeled the change we wanted to see: everyone building. When the most senior person in the room treats something as the priority rather than a side project, it resets what everyone else optimizes for.
But, top-down only gets you to the starting line. A mandate buys compliance, and compliance is people doing the minimum to be left alone. It does not get you a team that reinvents how work gets done. For that you need the next three.
2. We put our more fluent people next to every team, on real work.
You cannot learn agentic development from a video. You learn it with someone already fluent sitting next to you, working on your actual code, in your actual domain, showing you how they would do the thing you are stuck on. So we took our most fluent engineers, made them trainers for about a month, and embedded them across every team in Engineering (and some teams outside of Engineering). We built a tracker so no team slipped through, and we did not call it done until every team had been through it.
The part I pushed hardest on: train the managers first (we call them people empowerers). Our engineering leads set how their teams work, and a manager who is not fluent will struggle to lead a team that is. The most common failure I hear from other companies is exactly this one. They upskill the individual contributors, leave the managers behind, and the gains stall.
3. We won over the skeptics, and let proof do the rest.
We had holdouts, and they were often our most senior, most respected engineers. That makes sense. They had tried the previous generation of these tools, found them lacking, and reasonably assumed this was the same hype all over again. You do not convert that person with a memo.
What worked was getting one or two of them, the ones their peers actually listen to, to try it seriously on their own work and come out convinced. After that it spread on its own. The reaction I kept hearing was some version of: wait, that engineer is using this now? Okay, now I am paying attention.
4. We cleared the review bottleneck, and leaned on the continuous integration (CI) we built years ago.
When you make coding fast, you do not remove the bottleneck, you move it. Ours moved straight to code review. Far more changes started arriving, and our engineers were drowning in pull requests.
Two things saved us. The first we built years ago and did not fully appreciate until now: a serious investment in CI and automated testing across our monolith. That test suite turned out to be the best defense we had against AI slop, because it does not care whether a human or an agent wrote the code, it just refuses to let broken code through. The companies that are nervous about agentic coding are often not being timid for no reason. They lack the safety net that makes speed safe. We happened to have spent years building ours, and it is now paying dividends.
The second we built this year: an automated code reviewer we call Fresh Eyes, now running on every pull request, catching a large share of what a human used to catch by hand. And we got more aggressive about not putting a human gate where a machine can do the job. The rule we landed on: review rigor should scale with risk, not apply evenly to everything. Payroll and tax code stays human-heavy. Internal and low-risk code leans on the machines. As a company that works in a regulated space, we are serious about safeguarding our software supply chain. AI lets us move faster, yes, but compliance becomes even more important.
5. We made sharing the default.
The highest-compounding move was refusing to let people solve the same problem in private. When one engineer works out how to make an agent reliably navigate our payments domain, or draft an on-call handoff, or generate a compliance-checked form, that knowledge should not die in their terminal history.
So we built an internal marketplace where teams publish reusable agent skills and plugins, and anyone can find and install them. New ones show up every day. The ones that prove themselves get promoted into golden paths, the blessed, quality-checked way to do a thing, so the best practice becomes the path of least resistance instead of a secret you have to know to go looking for. This is where Gusto's culture did real work. We already shared openly by habit, in Slack and in the open, and agentic coding gave that habit something concrete to feed on.
A model upgrade lifts everyone once. A library of shared, vetted skills lifts everyone a little more every week. It is the closest thing to a flywheel we have found.
How throughput actually moved
The honest version has a wobble in it. Measured as throughput per developer, our output went from a pre-agentic baseline up to 115 percent. It actually peaked higher in April, then settled back in May while we untangled what was signal and what was noise in our own measurement. I am showing it with the dip rather than a clean line up and to the right, because the dip is the honest part, and it taught us more than the peak did.
Roughly two-thirds of our pull requests now have AI somewhere in the loop, and on some teams it is far higher. One of our agent-platform teams merged 69 pull requests across 29 contributors in a single five-day stretch, with a median cycle time of just over three hours. You can’t produce this by just working longer hours. You have to change how the work flows.
What shipped
A throughput chart is a series of inputs, not an end in and of itself, so here is some of what the capacity turned into. We delivered a new engineer-onboarding framework in roughly half the time the old way would have taken. We cut one integration's build-and-test cycle by around 40 percent. We built the AI code reviewer in a few weeks, work that on the old clock would have been a multi-quarter project.
The line to customers runs through the same practice. The way we learned to build internally is what let us build and ship Gusto Cofounder, the AI teammate for small businesses we launched this month. That was built in about 11 weeks by a small handful of people. I continue to be surprised and impressed at the pace of customer innovation we are seeing.
What is still hard
We are not finished. Measuring AI fluency and throughput honestly is genuinely hard.
The open question we are working on right now is the one that matters most: is the capacity we unlocked actually landing on customer-facing work, or is some of it being absorbed by internal refactors and cleanup? Has the rest of the pipeline (product, design, and everything downstream of code) sped up to match? We are doing some deep analysis across all of our work to sort what was customer-facing from what was internal, and we will publish what we find.
Where this goes
The next ninety days are about depth. We are past the adoption and fluency phase. Pushing the multi-threaded way of working from the early adopters into the larger engineering population. Hardening the plugin marketplace so quality keeps up with volume. Studying the ROI of all these gains.
If you are leading a team through the same shift, here is the whole thing in a few sentences. The LLM is not your advantage, because your competitor can buy the same one tomorrow. Your advantage is what you decide to do around it: whether you make it a real priority, whether you teach it hands-on, whether you win genuine belief instead of compliance, whether you build the safety net that lets you move fast, and whether you make sharing the default. Those are the choices, make them count.
