Agents Don't Do Standups: Building the Post-Engineer Engineering Org

How does an engineering team catch up when it has been building the wrong things quickly enough to stay busy, but not quickly enough to satisfy customers? At PFF, Mike Spitz’s January–March case study began with that problem. The company supplies sports data to NFL and NCAA teams and serves consumers interested in fantasy football, sports betting and simulated drafts. Its engineering team is distributed across India, Spain and the United States.

Spitz reports 100 million annual page views and nine million annual drafts. Yet a company of roughly 200 employees, including about 20 engineers, was falling behind competitors. Engineering attention had gone toward sports betting while many consumers wanted more from the draft tool. Personal experimentation around November, which Spitz associates with Claude Opus, grew into a pilot staffed by the company’s strongest frontend engineer and one of its strongest full-stack engineers.

The organizing question changed from helping engineers produce more to helping agents move faster. Spitz places the Agile Manifesto, software craftsmanship and even engineering perks—from foosball tables to sleeping pods—in a history of optimizing around scarce human engineering capacity. If that bottleneck moves, the organization’s processes need to move with it.

Spitz reports a 25× increase in team deployment frequency: the two-engineer pilot deployed five times a day, compared with roughly ten engineers deploying once every five days. The arithmetic compares team delivery rates, not individual productivity. He explicitly attributes an unspecified part of the difference to the smaller team: small groups already move faster. The pilot still had to coordinate its deployments with the larger team, so it had not escaped the surrounding organization’s coordination costs.

Deployment frequency is visible, but useful output is harder to measure. Counting pull requests or lines of code does not establish that customers received something valuable. Using a blend of ticket counts and code complexity, Spitz reports 10× output per engineer. The slide labels the result per engineer; the talk does not supply the weighting formula needed to reproduce that measure.

For the feature set discussed in the talk, Spitz reports completion by two engineers in under two months, against an estimated four months using the previous approach. That comparison is an observed delivery against a planning estimate, rather than two executions of the same project. The more consequential change appears inside the schedule: one engineer became available for other work in under a month, whereas the old plan would have kept both occupied for three months.

The capacity gain begins before the project ends. Once one engineer is unblocked, the next piece of work can start while the other engineer finishes the current project. Faster completion therefore changes more than the date on one delivery plan; it brings subsequent work forward. This is the compounding effect Spitz wants the audience to notice.

Neither output nor deployment counts settle whether the work was worthwhile. Spitz reports an average customer quality score of 8.6/10, compared with a pre-AI average he estimates at 7–7.5/10. He describes the surveys as statistically significant, but does not provide sample sizes, questions or statistical methods. The result matters to his account because the pilot was meant to close a gap between what PFF built and what customers wanted.

Scrum ceremonies did not survive the pilot. Spitz removed the project-manager role from this workflow and reduced the handoffs through which requirements and feedback could become a game of telephone. This was a change to the team’s operating process, not a rejection of the Agile Manifesto’s values. The replacement was deliberately small: huddles every other day, lasting roughly half an hour to an hour, with engineers, product and data science discussing what had been built over the preceding days. The team sought immediate feedback and deployed minimum viable versions to production as quickly as possible to get more of it.

Implementation began with a specification, but the agent helped discover what belonged in it. The workflow moved through these stages:

1. Interview: the agent questioned the humans to develop the spec.
2. Spec feedback: participants reviewed and refined what the team intended to build.
3. Lightweight design document: an agent skill produced an LDD, drawing on previous LDDs to preserve the organization’s engineering approach.
4. Engineering feedback: the LDD circulated to the engineers before implementation work was generated.
5. Tickets and pull requests: the workflow automatically created tickets, followed by PRs.

The LDD was an organizational design artifact, not something specific to Claude Code. Its value came from carrying existing engineering decisions into the next piece of work, then exposing those decisions for review before code generation.

Sprint planning disappeared because spending an hour estimating tickets no longer materially helped this team decide what to do. Spitz raises a different possible planning constraint: estimating token expenditure to decide whether a task is worth its cost. That was a future possibility, contingent on his expectation that token subsidization would end, not a practice the pilot already used.

Daily standups lost their status-reporting function because the tickets followed PR events automatically:

For example, a ticket already linked to a PR needs only the event-to-status mapping below. These are illustrative identifiers for the rules Spitz describes:

type PrEvent = "opened" | "review" | "merged";
type TicketStatus = "in-progress" | "in-review" | "closed";
type Ticket = { id: string; status: TicketStatus };

const statusByEvent: Record<PrEvent, TicketStatus> = {
  opened: "in-progress",
  review: "in-review",
  merged: "closed",
};

function applyPrEvent(ticket: Ticket, event: PrEvent): Ticket {
  return { ...ticket, status: statusByEvent[event] };
}

const ticket: Ticket = { id: "DRAFT-42", status: "in-progress" };
const updatedTicket = applyPrEvent(ticket, "review");
// { id: "DRAFT-42", status: "in-review" }

This automation was possible before coding agents. Spitz’s claim is that it has become easier to put in place, making a meeting to reconstruct the same information less useful.

Refinement moved into the spec and LDD. Generated tickets were structured to avoid blocking one another where possible; dependencies that could not be removed were flagged explicitly. The aim was to expose coordination needs before parallel implementation ran into them.

The replacement for a scheduled retrospective was a combination of customer satisfaction, customer surveys, normal delivery metrics such as deployment frequency, and immediate escalation by engineers. Problems were supposed to be raised when they appeared, rather than held until the sprint ended. That timing matters: feedback delivered after the relevant work has moved on can feel stale or unheard.

The first participants should be the engineers with the strongest system knowledge: the people colleagues already consult when something is stuck. Spitz recommends expanding access in phases rather than immediately giving everyone coding assistance. His own preparation involved roughly two months of small, non-critical proof-of-concept features pushed to production. Those experiments attracted little usage, limiting the consequences of mistakes before the approach moved to the heavily used draft product.

Spitz compares the transition to driving a sports car: not everyone can immediately handle the extra capability, and that is not a reason to pretend everyone starts from the same place. He expects curious engineers to thrive—people willing to investigate how unfamiliar code works when they do not yet understand it. Engineers accustomed to receiving a fully prescriptive specification may find the shift harder, because the new workflow asks them to help establish intent and resolve ambiguity.

Agent work needs verifiable, deterministic tasks. Tests are one part of that boundary, but checks also need to reflect the product and organization. At PFF, examples include feature flags for trunk-based development, generating interactive elements, and generating analytics for those elements. These are recurring obligations that can be made explicit rather than remembered anew during each implementation.

PFF’s agentic code review targeted a narrower responsibility than replacing an engineer’s review:

• Agents: variable naming, style compliance and other opinionated details that engineers often dislike receiving feedback about.
• Engineers: system design and the larger implications of a change.

Offloading the smaller criticisms reduced their emotional charge and preserved human attention for the big picture. PFF did not rely on agents to supply its system-design judgment.

Human involvement was therefore concentrated heavily in the spec and LDD, where the team decided how the system should be built. It also remained necessary at the product boundary. Spitz uses the idea that anyone can create something in an hour to describe how low the barrier to generating an application has become; the failure mode is a product that feels generically produced by Claude Code. Engineers still had to spend time making the result feel like the company’s other products. Generating a feature does not settle whether it belongs in the product.

Spitz’s model for the development lifecycle is a factory with small, composable operations. A car factory separates building a door from fitting a steering wheel. Engineering can similarly separate branch naming, creating a feature flag for trunk-based development, and building an API according to the organization’s chosen design pattern. Each repeated operation becomes a skill that contributes a specific part of the result.

Composition only helps when the pieces agree. A third-party skill may carry strong software-design opinions that conflict with the team’s own. Importing it can introduce inconsistency even when the individual skill appears useful. Spitz’s requirement is that the skills remain compatible with one another and with the engineering organization’s conventions.

He describes the spec–LDD–ticket–PR path as largely autonomous, alongside the human feedback already built into the design stages. The implemented QA sequence extends that path into a running environment:

1. A PR is merged.
2. The merge automatically deploys to staging.
3. After the staging deployment completes, a QA agent examines the relevant tickets and their acceptance criteria.
4. The agent checks the deployed work against those criteria and flags items that fail.

The ordering matters: acceptance checks run against the staged result after deployment, not merely against an agent’s description of the code it wrote.

The next step was still planned. Spitz wanted another agent to inspect unmet acceptance criteria and automatically create corrective PRs over the following couple of months. That would turn failure reporting into a repair loop: QA identifies a gap, a repair agent proposes a change, and the change can pass through the delivery workflow again. At the time of the talk, automatic corrective PR creation had not been implemented. He connects that proposed self-healing behavior to greater trust in agents and the ability to pursue more work in parallel.

Agents still take shortcuts. Security therefore remains a human concern, along with product feel and whether the scale of the implementation fits the task. Spitz points to sprawling, thousand-line implementations and unnecessary complexity as familiar failure modes. A sufficiently prescriptive LDD can constrain those choices before coding starts, instead of leaving reviewers to unwind an overengineered solution afterward.

For the next stage of adoption, he recommends beginning with boring, repetitive work—especially work engineers dislike—because removing it creates immediate buy-in. Process deserves the same scrutiny as code. A meeting retained for decades still needs an answer to a concrete question: what does it help the team accomplish? That question provides a basis for removing redundant process without assuming every existing practice has become useless.

The organization’s engineering culture then needs to be encoded in its skills. PFF’s concrete API example is the service–repository pattern: the preferred structure should travel with the task instead of depending on an engineer repeatedly restating it. Functional guardrails must precede autonomous operation, and the strongest engineers should establish the initial workflow.

Giving everyone Claude Code or Codex and running a hackathon is not sufficient onboarding. Teams have different engineering styles, and a working transition needs time to absorb those differences. Spitz contrasts expanding the approach across PFF’s roughly 20 engineers with doing so across organizations of 100, 1,000 or 10,000. The small organization’s advantage is not simply access to the tools; it is the smaller coordination problem involved in changing how people work.

A phased rollout does not mean waiting indefinitely. Other companies are moving quickly, and Spitz says he had already felt a few months behind. His earlier capacity argument becomes a competitive warning: if one team starts subsequent work sooner, its advantage can continue to grow. He illustrates that risk as a gap of a few months becoming six months and later twelve, rather than presenting a measured forecast.

The constraint on speed is feedback from the engineers doing the work. They should determine whether adoption can expand faster or needs more time. That leaves the organization with two responsibilities at once: take the compounding opportunity seriously, and expand only as the working process supports it.

Spitz closes by inviting the audience to try the features through an on-screen QR code. The talk has explained the delivery system and its reported outcomes rather than demonstrated the features themselves; the invitation brings the discussion back to the product customers actually use.