Author: Daniel Martin, Sr. Director of Engineering, Developer Productivity
In February 2026, we paused normal engineering delivery for a week and asked over 800 engineers to use agentic AI to take real tasks from ideation through implementation, testing, and code review. We made a deliberate bet that agentic tools had matured enough to change how we work, and that adopting them well would require rethinking the systems around them.
This post covers how we got to a place where over 60% of our pull requests (PRs) are agent-assisted: why we did it, how we prepared, what the week looked like, what broke, and what we are investing in now as a result.
Why We Did It
Affirm has built a credit network that delivers honest financial products at a scale of over 130 million transactions a year. Further scaling of that network depends on our capacity to ship quality software, but we operate under several constraints on our speed. We move money, so mistakes are costly and quality is contractually non-negotiable. We build on a twelve-year-old monorepo with structural bottlenecks: bloated test suites, manual code review, unstable CI, and deploy infrastructure not made for the pace we need.
I lead Developer Productivity, the organization that exists to remove those bottlenecks. Throughout 2025, we had already invested in AI-assisted development and, by December, over 80% of our engineering team was a weekly active user in an AI assisted developer tool. But around that time, a new class of tool had crossed a threshold. Models like Anthropic’s Opus 4.5 made agentic AI development practical: coding agents could now reliably search a codebase, plan an approach, write code, run tests, and iterate on failures with minimal human intervention. Our data and interviews showed that a few dozen engineers were already using these tools effectively on our codebase and it was transforming how they worked. The question was how to bring that same acceleration to another 800 developers at Affirm.
In mid-January, our President sent a company-wide message: agentic AI development would become a core part of how we build software.
The message also set a date for AI Retooling Week. All non-essential meetings would be suspended, product delivery dates delayed, and every engineer and manager asked to complete a fully agentic workflow — from task to submitted PR — by the end of the week. We chose a dedicated week over a gradual rollout because the gap between the engineers already using these tools effectively and their peers was growing and we wanted to close it fast.
Building the Foundation
In the buildup to Retooling, we assembled a working group of nine engineers. Their mandate: in two weeks produce a repeatable agentic workflow that allows the average developer at Affirm to automate most of their coding work without bespoke setup or expert knowledge.
The group made three decisions that shaped everything that followed. First, a single default toolchain. We chose Claude Code as our default agentic coding tool and wrote the entire workflow against its primitives, so engineers had a clear starting point on day one. Second, local-first development, because the tooling landscape had not converged on a centralized platform and we wanted engineers to be productive immediately. Third, explicit human checkpoints where judgment matters: providing intent, approving plans, reviewing code, and merging. Outside those checkpoints, we automated as much toil as we could safely remove.
“Default” tooling did not mean “mandatory.” It meant lowered friction to get started. Engineers who preferred other tools could reuse most of the same artifacts with light translation. Where the defaults did not fit, Tech Leads owned the adaptation for their team. The mental model we taught was simple and tool-agnostic: Plan, Review, Execute, Verify, Review, Deliver.
The Workflow
The workflow we delivered was built around the principle one task equals one agent session equals one PR.
A key insight was to move decision-making earlier. Rather than going back and forth with an agent at implementation time, you make the architectural and scoping decisions upfront during planning, then hand the agent a tightly scoped task. This lets engineers work through multiple tasks in parallel on separate worktrees, each a self-contained unit of work.
We built custom tooling for each stage of the loop:
Press enter or click to view image in full size
- Plan — an agent-assisted planning skill transforms requirements into a structured implementation plan and breaks it into well-scoped tasks.
- Review — the engineer reviews and approves the plan before any code is written.
- Execute — the agent implements a single task on a dedicated worktree.
- Verify — the agent runs tests and linters, fixes what it finds, and reviews its own code. When CI fails, it fetches build logs, correlates failures, and proposes fixes. This loop repeats until CI passes.
- Review — the engineer reviews and edits the agent’s output. One rule we were explicit about: do not send unreviewed AI output to your coworkers. Reviewers use agents too, pointing the review tool at the PR along with their team’s architectural context. But the reviewer reads the code, applies their own judgment, and catches what the agent misses.
- Deliver — the engineer receives human approval and merges.
Underlying all of this was a system of context files maintained at multiple levels of the codebase: conventions, domain knowledge, and team decisions where agents could find them. We distributed the tooling through an internal plugin with a central marketplace where teams could build and share their own skills.
Retooling Week
The week was structured to balance learning with doing. Monday opened with a leadership kickoff and a live demo of the full workflow on a real task. Tuesday featured “art of the possible” sessions held in-person and remotely, where engineers saw the tools tested on real-world tasks. Wednesday was heads-down time. Thursday was team-led demos. Friday was the big show: org-wide demos of the best work from the week, selected by engineering leaders and voted on by the whole organization.
Throughout the week we staffed dedicated support channels by timezone, ran helpdesk sessions for anyone who was stuck, and tracked a leaderboard of agentic PR submissions by team.
We acknowledged that progress would be lumpy, that some codebases and types of tasks would be harder than others, and we asked teams to give each other grace. The emphasis was on experimentation over perfection.
What We Found
We measured everything. Adoption rate by team and workflow step, PR volume, opened versus merged PR count. We set a budget of nearly $200k (around $250/engineer) for the week’s token usage and monitored spend daily, investigated outlier patterns, and landed at around 70% of budget. By the end of the week, 92% of the engineering organization, including managers, had submitted at least one agentic PR, most many more. We surveyed every team. Engineers who had been unsure about agentic tools were finding them useful by mid-week, and teams were already asking how to keep the momentum going after the week ended. But the most valuable output was a candid picture of what did not work. Several bottlenecks stood out:
Press enter or click to view image in full size
Our change review process was the single most-cited friction point in the engineering-wide survey we ran, with roughly 40% of respondents raising it unprompted. PRs often sit at this stage for days, and as volume scaled manual review processes became a chokepoint.
CI speed and reliability were a major constraint. Our unit test suite at p75 ran in ~8 minutes, but full end to end regression suites on our ephemeral test environments took an excruciating 100+ minutes. It was not designed for the change-validate-fix-revalidate loops that agentic development demands.
Tool integrations created unexpected friction. Engineers wanted to connect agents to internal systems through dozens of MCPs. Central management of those integrations is a security requirement, but the volume of requests overwhelmed our review process. Each new integration expanded the security surface in ways that required careful evaluation. CLIs — where they were available — proved more reliable than MCPs for many of the same tasks. But without standardized configuration, ownership, and service level agreements, the integrations that were supposed to make agents more capable became a drag.
Documentation accessibility blocked progress. Affirm has over a decade of technical and product specs spread across multiple documentation platforms and in code. That fragmentation is somewhat navigable for humans, but agents need clear, consolidated context to produce quality output. Some platforms had MCP integrations, others did not, and the experience was inconsistent enough that engineers frequently had to bridge the gaps manually.
Without fast local validation, engineers pushed to CI for signal. Enough agents submitting PRs in rapid succession increased pressure on Buildkite, driving up queue wait times. In one case weeks after Retooling, the load brought down our internal test quarantine service and CI pipeline.
Agentic coding amplified every existing friction point in the development pipeline. When code generation is near-instant, manual review, inaccessible documentation, weak local testing, and slow CI go from annoyances developers will work around to show stoppers.
Closing the Gaps
We came out of Retooling Week with a clear list of problems and the organizational will to fix them. So we launched a dedicated program to close the gaps, with three areas of focus: context, enablement, and validation.
Centralizing Context and Best Practices
We want agents to start with better inputs. If architectural decisions, domain context, and best practices are stored where agents can find them before implementation starts, the output quality goes up and the review burden goes down. Our Architecture group is leading this work.
Enablement and Governance
We turned the sprint team that ran retooling week into a permanent team. Their job is to keep the tooling healthy as adoption grows: managing integrations, improving tool discoverability, building a support model, and making sure we understand what we’re spending and that spend is deriving value.
Agent Friendly Continuous Integration
Validation is the largest investment. Agents can produce code fast, but that only matters if you can verify it fast and effectively. The first thing we are tackling is CI noise. When a build fails, engineers need to know immediately whether it was their code, a flaky test, or an infrastructure issue. Today that takes manual investigation. We are automating that classification so agents (and humans) can act on failures without digging through logs. We are also maturing local testing to give agents and engineers signal before anything hits CI. And we are right-sizing our test suites so that most coverage lives in faster, cheaper layers closer to the code.
One problem we find especially worth solving is independent validation for agent-generated code. When an agent generates both implementation and tests in the same session, a misunderstanding of requirements can produce code and tests that confirm each other’s errors. Tests pass, coverage looks strong, and the defect ships. We are piloting a system that cross-references PR diffs against acceptance criteria and multiple models as an independent check.
What We’ve Learned Since
Forcing functions work. A dedicated week with suspended meetings and leadership backing created more adoption in five days than months of gradual rollout would have. It created the space for engineers to commit focused time to learning, and it gave the entire organization a shared baseline to build on.
The enablement team matters as much as the tools. A dedicated group of passionate engineers built the paved path, staffed support, and iterated on feedback in real-time. Without that, we might have given access to a tool, shipped a wiki page, and hoped for the best.
Pick one tool and write the workflow against it. Engineers needed clear answers: what tool should I use, what does a good workflow look like, and where do I start. Providing those answers, while leaving room for teams to adapt, was one of the highest-leverage decisions we made.
You have to watch for second-order problems. Scaling agent-authored code introduces failure modes that compound over time: codebase bloat, bottlenecks in review and release, skill and context sprawl, and the erosion of human understanding of the systems we operate.
And culture sets the ceiling. Leadership conviction, explicit expectations, the psychological safety to experiment, and clear accountability for outcomes created the conditions where engineers were willing to change how they work.
What Comes Next
Agentic development is now a permanent change in how Affirm builds software. As of April 2026, over 60% of PRs at Affirm are agent-assisted — meaning very likely entirely written by Claude — up from near zero four months ago. Weekly PR merged volume is up 58% year over year, and climbing. Retooling week was the catalyst and now we’re following through with a sustained investment. The work ahead is closing the gaps in context architecture, enablement, and testing that determine whether this transformation compounds or stalls.
The window to retool is now open, while the models are capable and the costs are low. That window will not stay open forever. We believe the companies that leap will stay ahead, the ones that wait will be leapt over.
If your organization is navigating similar challenges, driving agentic productivity while maintaining guardrails around availability, regulatory requirements, financial SLAs, or other high-stakes constraints, we would love to compare notes. Reach out to us by leaving a comment below.