Agents Don't Do Standups: Building the Post-Engineer Engineering Org — Mike Spitz, PFF

A case study from PFF reveals how a two-engineer team, by leveraging AI agents, achieved a 25x increase in deployment frequency and 10x the output of a ten-engineer team. CTO Mike Spitz explains their core principle: shifting focus from making engineers faster to making AI agents faster. This talk deconstructs the resulting transformation, which eliminated traditional agile ceremonies like stand-ups and sprint planning in favor of an automated, spec-to-PR workflow, redefining the roles of engineers and processes in a modern software organization.

May 15, 2026 4 min read

Agents Don't Do Standups: Building the Post-Engineer Engineering Org — Mike Spitz, PFF — source: https://www.youtube.com/watch?v=VMemhtlsoNk

At PFF, a sports data company, we conducted a case study to explore a new model for software development centered on AI agents. The central idea was a reframe: instead of asking how to help engineers produce more, we asked, “How do we make the agents quicker?” This shift acknowledges that with powerful AI assistants, the human engineer is no longer the primary bottleneck in the development lifecycle.

The experiment pitted two of our strongest engineers (one front-end, one full-stack) against a traditional team of ten. The results were dramatic.

Case Study Results: A Quantitative Leap

Deployment Frequency: The two-engineer team deployed five times per day, while the ten-engineer team deployed once every five days—a 25x increase. While smaller teams are inherently faster, the agent-powered team still had to coordinate with the larger team, making the result significant.
Productivity Output: Measuring output by blending ticket volume with code complexity, we found the two-person team had a 10x higher output.
Project Velocity: A feature set estimated to take four months was completed in under two. This created a compounding effect, as one engineer was unblocked within a month to begin other work, whereas in the old model, both would have been blocked for the project’s duration.
Customer Satisfaction: This is the most critical metric. Our average quality score from statistically significant customer surveys rose from a pre-AI average of 7-7.5 to 8.6 out of 10.

The New Development Lifecycle: Process Automation

The traditional Scrum framework did not survive. We eliminated ceremonies that were designed to manage the human bottleneck, as that bottleneck no longer existed.

No More Stand-ups: Tickets are automatically updated based on PR status (e.g., “In Progress” when a PR is opened, “In Review,” “Closed” on merge).
No More Sprint Planning: Estimating tickets is irrelevant when the agent does the bulk of the work. The only future estimation might be for the token expenditure of a given task.
No More Refinement: This process is now embedded in the initial “spec and LDD” flow. Tickets are automatically generated in a structured, non-blocking manner.
No More Retrospectives: We rely on direct customer feedback and a culture of immediate issue flagging rather than waiting for a ceremony at the end of a sprint.

Our new workflow is streamlined and agent-driven:

Huddles: We hold 30-60 minute huddles every other day with engineers, product, and design to review work and get instant feedback.
Specification (Spec): An agent “interviews” the product owner or engineer to create a detailed spec.
Lightweight Design Document (LDD): The agent generates an LDD, analyzing our past documents to ensure the new system aligns with our existing engineering ethos and patterns.
Feedback Loop: Engineers review the LDD and provide feedback.
Autonomous Execution: From the approved LDD, the system automatically creates tickets and subsequent PRs.

Redefining Roles: Engineers and Agents

This new paradigm changes the nature of engineering work and how we use AI.

The Evolving Engineer

Not every engineer thrives in this environment. The analogy is, “not everyone can drive a sports car.” The engineers who excel are curious systems thinkers who can operate without a highly prescriptive spec. Their primary role shifts from writing boilerplate code to high-level system design and architectural oversight.

Agent-Assisted Tasks

Agentic Code Review: We don’t use agents for high-level system design reviews. Instead, agents handle the tasks engineers dislike giving or receiving feedback on: variable naming, style guide adherence, and other opinionated details. This removes the emotional friction from code reviews and lets engineers focus on the big picture.
Automated QA: After every merge to staging, a QA agent spins up. It reads the acceptance criteria from the associated tickets and verifies the implementation. Failures are flagged. The next step is to enable a “self-healing” capability, where an agent automatically creates a PR to fix the identified regression.

How to Implement This Model

Start Small and Smart: Begin with your best engineers who possess deep system knowledge. They are best equipped to guide and validate the agents.
Use a Phased Approach: Don’t give every engineer an AI tool at once. Roll it out slowly, starting with non-critical systems to experiment safely.
Codify Your Culture: Your engineering lifecycle should be broken down into small, composable “skills” for the agent. If you use a specific design pattern (e.g., the service repository pattern for APIs), encode that into a skill. Be cautious about consuming third-party skills that conflict with your internal software opinions.
Establish Guardrails: Ensure security, product feel, and scalability are considered. Humans are still essential for reviewing the agent’s work, especially in these areas, as agents can sometimes “use shortcuts” or over-engineer simple problems.
Don’t Be Too Conservative: The compounding advantage of this model is significant. A few months behind today could mean a year behind in the near future. It’s crucial to start the transition, especially for smaller, more agile companies that can adapt faster than large enterprises.