FurtherAI says merges per engineer grew about 5x with coding agents

An author at FurtherAI shared, in a Twitter/X thread, lessons from the last nine months of building an AI-native engineering organization. The thread begins with a reply the author wrote to Will Larson (@Lethain), who had asked how leaders evaluate engineering managers for AI skills; that list of questions drew many bookmarks. The thread then broadens into a two-part account.

Part 1 is about how shipping changed. Since January, the number of code changes each engineer merges per day has grown about 5x, while the revert rate stayed under half a percent. The author says that handing engineers coding agents did not produce this on its own: every time one step sped up, work piled up at the next. So the team went through the whole shipping process one step at a time.

The steps, by month: Code (March): agents write the code and engineers steer them. There is no clean starting number, because early tools only occasionally marked a change, but the author says agent-written code is now almost 100% of changes. Tests (April): agents write tests alongside code, and 91% of changes now include tests, up from 15%. Review (May): AI reviews 99% of changes before a person does, up from 60%, so human reviewers can focus on parts that need judgment. CI (June): tests were parallelized and only those affected by a change are run; CI now runs 20 times the tests in the same 17 minutes. Bug reports (July): the team uses ClaudeTag to automate bug intake. Anyone can report a bug in Slack, and ClaudeTag finds duplicates, files a ticket and assigns it to the right person. It now files 60% of bug tickets. Rules (August): when a bug or review comment exposed a rule only engineers knew, it became a small Python check that runs on every commit and PR, fails the build and prints the fix. Agents hit these checks, fix their own code and move on. The count went from zero to 21 rules. Merging (August): low-risk changes that pass tests, automated checks and AI review merge on their own, and up to a third of changes now merge without a person involved. Code channels (September): anyone can open a Slack channel, describe a change to an agent and have it open a PR, with several people steering the same agent. There is no clean number for this yet. The team also uses Devin's cloud sessions heavily to collaborate.

The team also runs in-house agents called Poirot and Sherlock to investigate and resolve issues across production and staging, with access to logs, metrics, traces and read-only database access. The author describes ClaudeTag triaging a request, Devin doing the work and Poirot pulling internal data. A side effect: non-engineers now ship code. The designer has merged about 50 changes since August, including the ones that built the design system, and people in deployment and customer-facing roles make UI tweaks from Slack.

The author says none of this was free. Through the summer much engineering effort went into tests and tooling, and customer-facing changes per engineer stayed between 17 and 30 a month. In September that jumped to 45, and October is on pace for 48.

Part 2 is about what changes in the team. The author says the company got much faster at writing code but not nearly as fast at deciding what to build. A simplified example: a feature that took ten days (three to plan, six to build, one to review) gets only 1.75x faster if agents make building 3.5x faster and planning and review stay the same. Planning and review then take 70% of the time, up from 40%. Decisions have traditionally flowed through engineering managers, PMs and designers, which gets harder as engineers speed up.

FurtherAI's bet is to push more ownership to engineers rather than add layers of management. For engineers, the author is starting to think of seniority as how much of a problem someone can own end to end: a junior builds with an agent and can tell when it is wrong; a senior plans and reviews their own work; a staff engineer takes a vague problem, makes the tradeoffs and owns the number that says whether it worked. Engineers also need to be closer to customers, owning the work from understanding the problem to verifying success and handling regressions in production.

For managers, the author sets two expectations. First, be in the work: understand what is being built and why, and try features on staging as an end user would, not just check that code was reviewed. The aim is to develop engineers who make the right decisions themselves, so managers step in only where their judgment is needed. Second, be more product-savvy: understand customers, hold strong product opinions and make product decisions, not just technical ones, and help engineers build that judgment. The author says a PM or designer should not be needed for every small product decision.

The author closes by saying the first part of the year went into making engineers faster, and the next challenge is making the whole organization move at that speed, which the author suspects will be harder than automating code, tests and reviews. They add that the team is still early with a lot not figured out, ask what broke first for other teams, and say FurtherAI is hiring an Engineering Manager / Director.

Key facts

FurtherAI says the number of code changes each engineer merges per day has grown about 5x since January, with a revert rate under half a percent (company-reported).
The team automated shipping step by step from March to September: 91% of changes now include tests (up from 15%), AI reviews 99% of changes before a person (up from 60%), and CI runs 20 times the tests in the same 17 minutes.
Up to a third of changes now merge without a person involved, helped by 21 Python check rules; ClaudeTag files 60% of bug tickets.
Customer-facing changes per engineer stayed between 17 and 30 a month through the summer, then reached 45 in September, with October on pace for 48.
The author says the new bottleneck is deciding what to build, and expects engineers to own more end to end and managers to use the product and make product decisions.

Why it matters

The thread is a concrete, step-by-step account of what one team did after giving engineers coding agents. Its central point is that agents alone did not deliver the speedup: each time one step got faster, work piled up at the next, so the team rebuilt tests, review, CI, bug intake, rules and merging in turn. The second point is that once code is cheap to write, deciding what to build becomes the constraint. The author's simplified example shows a 3.5x faster build phase yielding only a 1.75x faster feature.

Who it affects

Engineering leaders and managers weighing how to organize teams around coding agents are the direct audience; the thread began as a reply to Will Larson's question about evaluating engineering managers for AI skills. Engineers are affected through the proposed seniority model (junior, senior, staff by how much of a problem they own end to end) and the push to work closer to customers. Non-engineers are affected too: the designer has merged about 50 changes since August, and deployment and customer-facing staff make UI tweaks from Slack.

How to use it

The thread offers a sequence rather than a product. Go through the shipping process one step at a time and remove the next bottleneck: agents writing code, then tests, then AI review before human review, then faster CI that runs only affected tests, then automated bug intake from Slack. Turn knowledge only engineers hold into small checks that run on every commit and PR, fail the build and print the fix, so agents can correct their own code. Let low-risk changes that pass tests, checks and AI review merge on their own. For managers, the author wants them to try features on staging as an end user would and to hold product opinions. Tools named include ClaudeTag, Devin cloud sessions and in-house agents Poirot and Sherlock.

How solid is it

This is a first-person thread from a company author, not an independent study. All figures are the company's own: the 5x growth in merged changes per engineer per day has no absolute baseline, and the revert rate is stated only as under half a percent. The 1.75x, 70% and 40% numbers come from the author's simplified example, not measured data. The seniority model is stated as something the author is starting to think, and the claim that organization-wide speed will be harder than automating code is a suspicion, not a finding.

Risks and caveats

The 5x figure counts merged code changes per engineer per day; customer-facing changes stayed between 17 and 30 a month through the summer, then reached 45 in September, and October's 48 is a pace, not a final figure. The author says none of it was free: much of the summer's engineering effort went into tests and tooling. Up to a third of changes merging without a person is an upper bound, and the share of agent-written code has no clean starting point. The thread gives no figure for the code-channels step, and the author says the team is still early with a lot not figured out. The thread also ends with a hiring call for an Engineering Manager / Director at FurtherAI.

“We got much faster at writing code, but not nearly as fast at deciding what to build.”

— Author of the thread, FurtherAI