PFF compared two engineers using agent-driven development with a team of ten on the same codebase and customers, and the smaller team deployed 25 times more often.
2
The new workflow moves from a spec to a lightweight design document, then automatically creates tickets and pull requests, removing sprint planning, standups, and much of the coordination work.
3
Agents handle deterministic implementation, style-focused code review, and staging QA, while engineers remain responsible for system design, product feel, security, and engineering constraints.
Summary
Mike Spitz describes a three-month PFF case study in which two engineers worked with coding agents against a team of ten. The two engineers deployed five times a day, while the larger team deployed once every five days. After adjusting for ticket count and code complexity, Spitz says the smaller team produced 10x the output, and customer satisfaction rose from an earlier average of roughly 7 to 7.5 to 8.6 out of 10. PFF removed Scrum ceremonies that depended on engineers as the bottleneck. Its workflow runs from an agent-assisted spec to a lightweight design document, automatically generated tickets, and pull requests. Agents also update ticket status, review naming and style, and run acceptance checks on staging after merges. Human review remains important for system design, product feel, security, and controlling over-engineering. Spitz recommends a slow rollout that starts with experienced engineers and low-risk, repetitive work.
PFF optimized agent speed instead of trying to make engineers work faster
Spitz began with a different question: instead of asking how to increase engineer output, ask how to make the agents quicker. He argues that software organizations historically optimized around engineers because they were the bottleneck, adding perks and processes to support them. PFF tested a different setup with two strong engineers, one focused on front end and one on full stack work. The experiment started with small proof-of-concept features before moving into a product that receives 100 million annual page views. The change was organizational as much as technical because the team redesigned its process around what agents could complete quickly.
The two-engineer team deployed far more often and produced more complex work
The two engineers deployed five times every day, while a team of about ten deployed once every five days. Spitz acknowledges that a smaller team will usually move faster, but says the two engineers still had to coordinate their daily deployments with the larger team. PFF did not use pull request count or lines of code as its main output measure. It combined ticket counts with code complexity and found that the smaller team produced 10x the output. Features that had been estimated at four months were built in under two months. One engineer became unblocked in under a month, while the old process had left both engineers blocked for three months.
Customer satisfaction mattered more than deployment volume
Spitz rejects deployment frequency and raw output as sufficient evidence that the experiment worked. PFF surveyed customers and recorded an average quality score of 8.6 out of 10. Before using AI, the company had averaged about 7 to 7.5. For Spitz, the point of producing more features was whether customers were happier with what they received. The case study therefore measured delivery speed alongside ticket complexity and customer feedback. He is explicit that more pull requests or more code would not, by themselves, prove that the engineering model was useful.
PFF replaced Scrum ceremonies with short feedback huddles and an automated work flow
Scrum did not survive the experiment. PFF removed sprint planning because estimating tickets no longer made much difference when engineers were not the main bottleneck. Standups became unnecessary because tickets update automatically from pull request state: an open pull request moves a ticket to in progress, review updates it again, and a merge closes it. Sprint refinement moved into the specification and design process. PFF kept short huddles every other day, with engineers, product, and design discussing recent work and giving immediate feedback. The team aimed to release an MVP quickly and learn from production feedback.
The development path runs from a spec through design documents to tickets and pull requests
The process starts with an agent interviewing the engineer about a spec. The team reviews that spec, then the agent creates a lightweight design document based on previous documents and the organization's established patterns. Engineers provide feedback on those documents before the system automatically creates tickets. The tickets are structured so that they do not block one another where parallel work is possible, and dependencies are flagged when they exist. This replaces much of sprint refinement and planning with decisions made earlier in the engineering lifecycle. Spitz says the design document is also where the team can define the intended implementation before agents begin generating code.
Agents should handle deterministic work and the least useful parts of code review
Spitz recommends giving agents tasks that can be checked clearly. At PFF, examples include feature flags, trunk-based development work, interactive elements, and analytics for those elements. PFF also uses agents for code review feedback that engineers dislike receiving, such as variable naming, style mismatches, and other opinionated details. Engineers continue to review system design and the larger architecture. This division removes some emotional friction from review and lets human reviewers spend more time on the decisions that require broader context. Spitz still places heavy human involvement in the spec and lightweight design document.
Engineering work can be decomposed into reusable skills, like stations in a factory
Spitz asks teams to view the engineering lifecycle as a factory made from small, composable elements. A car factory might have separate steps for building a door and fitting a steering wheel. In software, a team can encode repeated work such as branch naming, feature-flag creation, or a particular API design pattern. These patterns become reusable skills for agents. Spitz warns against importing skills that contain software opinions unlike the team's own conventions, because the mismatch creates problems. The goal is to make the organization's patterns explicit so autonomous work follows the same design choices as work done by engineers.
Automated staging QA could let agents repair failed acceptance criteria
After a pull request merges, PFF automatically deploys it to staging. A QA agent then reads the related tickets and their acceptance criteria and checks the staged result against them. It reports which acceptance criteria have not passed. Spitz wants the next step to be automatic: an agent would inspect the failed ticket, determine what is missing, and create a pull request to fix it. That would create a self-healing loop in which implementation, QA, and repair happen in parallel. The current process still depends on human trust and oversight, especially because agents can take shortcuts.
A careful rollout starts with experienced engineers and low-risk work
Spitz says the engineers most likely to thrive are curious people who can investigate how a system was built without needing every detail prescribed in advance. Engineers who require highly prescriptive specifications may struggle. He recommends starting with the strongest engineers, moving slowly, and testing first in non-critical systems. Teams should automate boring, repetitive tasks that engineers dislike, remove processes whose purpose is unclear, encode local patterns in skills, and make sure guardrails work before going autonomous. He advises against giving everyone coding assistance at once or treating a hackathon as a complete rollout. Smaller organizations can scale the approach more easily than companies with hundreds or thousands of engineers.
