Playbook
Tasteful Skills
“Tasteful Skills” argues that the best agent skills are not documentation or best-practice lists.
Back to Podcast Digest
Agents Don't Do Standups: Building the Post-Engineer Engineering Org — Mike Spitz, PFF
TL;DR
Two engineers outpaced a 10-person team by a wide margin — At PFF, a two-engineer AI-heavy squad shipped about 25x more deployments and roughly 10x more output than a larger team, finishing in under two months what had been estimated at four.
Customer happiness, not code volume, was the real scoreboard — Mike Spitz says the post-AI process only matters because statistically significant user surveys came back at 8.6/10 quality, up from PFF’s prior 7 to 7.5 range.
Scrum largely disappeared because agents made the ceremonies redundant — Sprint planning, standups, refinement, and retros were replaced by specs, agent-written lightweight design docs, auto-created tickets, PR-linked status updates, and every-other-day huddles with product and design.
The bottleneck has shifted from engineers to agent throughput and system design — Spitz’s framing is blunt: stop asking how to make engineers output more, and start asking how to make agents quicker, while humans stay focused on product feel, security, and complexity control.
The winning pattern was not ‘give everyone Copilot’ but encode your org into skills — PFF turned repeatable work like feature flags, branch naming, API patterns, and LDD generation into composable skills tailored to its own engineering culture instead of relying on generic external workflows.
Adoption should start with your best systems thinkers, not the whole org — Spitz argues that curious engineers thrive in this model, while more prescriptive engineers may struggle, so teams should phase rollout slowly, begin on non-critical systems, and avoid company-wide AI hackathon theater.
The Breakdown
The setup: a sports data company that felt itself slipping
Mike Spitz opens with a very practical problem: PFF, a sports data company serving NFL and NCAA teams plus fantasy and betting consumers, had 200 employees, about 20 engineers, and was falling behind competitors. This is not a toy environment either — he cites 100 million annual page views and 9 million drafts a year — and the team is fully distributed across India, Spain, and the US.
The key question changed: optimize agents, not engineers
Spitz says the old software world optimized around engineers because they were the bottleneck, which is why the industry accumulated everything from Agile doctrine to foosball tables and sleeping pods. His new framing is the punchline of the talk: instead of asking how to help engineers produce more, ask how to make the agents quicker.
The case study numbers that made everyone pay attention
The experiment started with two strong engineers — one top frontend, one top full-stack — and the results were dramatic. Their team deployed roughly five times a day versus the larger 10-person team’s one deploy every five days, and even with the obvious small-team advantage, Spitz says they still had to coordinate with the larger org. Using a blended measure of ticket count and code complexity, he estimates output at 10x, with a project finished in under two months instead of the four months previously expected.
Faster shipping mattered because users actually liked the result
Spitz is careful not to equate more PRs with success. The metric he keeps returning to is customer response: statistically significant surveys put quality at 8.6 out of 10, compared with PFF’s earlier average around 7 to 7.5. He also highlights a compounding effect: once one engineer gets unblocked in under a month, they start building the next thing instead of waiting three months in lockstep.
Scrum didn’t survive, but huddles did
This is where the talk gets spicy: “Scrum did not survive.” PFF dropped project-manager-heavy ceremony in favor of every-other-day huddles with engineering, product, and design, using them to review what was built, get instant feedback, and push MVPs to production quickly. Standups disappeared because ticket status now updates automatically from PR states, while planning and refinement got absorbed into the spec and LDD flow.
The new workflow: spec, agent interview, LDD, tickets, PRs
The flow is tightly structured: write a spec, have the agent interview the team, generate a lightweight design document based on prior company patterns, collect feedback, then auto-create tickets and PRs. Spitz keeps emphasizing that the LDD is the control point — the thing that prevents agents from taking “shortcuts,” over-engineering, or producing the thousand-line mess everyone has seen.
What agents should do, and what humans still own
PFF uses agents for deterministic, verifiable tasks and for code review comments humans hate — naming, style, nitpicks, opinionated consistency issues. Humans still own product feel, security, and the higher-order engineering judgment that keeps AI-built features from feeling like generic “cloud code” instead of something that matches the company’s actual brand and product ethos.
Build it like a factory, then roll it out carefully
Spitz recommends treating the engineering lifecycle like a factory made of composable steps: branch naming, feature flags, API design patterns, analytics, QA, and eventually self-healing PR creation when acceptance criteria fail. But his warning is just as strong as his enthusiasm: don’t hand everyone the tools at once, don’t assume a hackathon changes behavior, and don’t move too slowly either, because in his view a few months behind now can compound into a year behind surprisingly fast.
Share
Keep Reading
Two Ways to Follow
The Weekly Echo. The inbox-shaped summary of what mattered.
New editorials announced here.
