The Engineering Team Got 4× Bigger.

Problem

Given the state of AI coding agents today, what can we do to improve product and engineering velocity by 2-5×?

The first hypotheses are usually about workflow:

• Product requirements are underspecified, so give PMs a skill that writes more precise PRDs.
• Decisions get lost between product and engineering, so put an agent in Slack, publish a daily update, turn open questions into Linear issues, and chase people to close the loop.

These remove real friction. They do not explain why velocity isn't 2–5× higher than a year ago. They leave the operating model alone.

flowchart TD
    VP[5 VPs] --> DIR[25 directors]
    DIR --> ENG[2,000 human engineers]

Imagine a company with 5 VPs, 25 directors, 200 teams, and 2,000 engineers. If 6,000 more engineers showed up overnight, would you keep the same leadership structure, team boundaries, product/design model, and on-call system? You would expect the new people to sit idle.

flowchart TD
    VP[5 VPs] --> DIR[20 directors]
    DIR --> H[2,000 human engineers]
    H --> A[6,000 effective agent ICs]
    H --> O[8,000 IC-equivalents of implementation capacity]
    A --> O

A company that grew from 2,000 to 8,000 engineers would revisit product areas, leadership scopes, decision rights, platforms, and team size. I think that is what AI agents are doing now: they are the 6,000 junior employees. Reorganizing around them is how we get the 2–5×.

If implementation multiplies and everything else stays fixed, the bottleneck moves. Better PRDs and a Slack bot will not get us there. The human organization has to be redesigned around abundant execution and scarce judgment.

When coding was expensive, a six-to-ten-person team could cover one product area, and one PM could keep it supplied with decisions.

With agents, that same team runs more work in parallel. Judgment, architecture, reviews, launch, and ops scale with work-in-progress, not with typing speed. Coordination pain can rise even when every engineer is faster, because the org is still built for a slower implementation layer. The new constraints are problem selection, taste, decomposition, tradeoffs, architecture, evaluation, production ownership, and turning what we learn into the next bet.

When execution becomes abundant, unchanged coordination structures turn speed into queues.

Proposed Solution

A six-to-eight-engineer team was large enough to own something and sustain on-call, and small enough to coordinate. If each engineer can now direct several agents, that team has the implementation power that used to take twenty or thirty people. Keeping all six to eight humans in one delivery unit leaves too little independent product surface.

So shrink the build unit to one or two human engineers plus agents, aimed at a defined customer outcome.

That unit still cannot be a one-person operational island. On-call and bus factor stay with a Team of 6–12.

flowchart TD
    P[Team<br/>on-call, architecture, knowledge] --> C1[Pod A<br/>1–2 humans + agents]
    P --> C2[Pod B<br/>1–2 humans + agents]
    P --> C3[Pod C<br/>1–2 humans + agents]

The unit of building should shrink. The unit of ownership should not.

flowchart TD
    V[VP] --> O1[Org]
    V --> O2[Org]

    O1 --> T1[Team]
    O1 --> T2[Team]
    O2 --> T3[Team]
    O2 --> T4[Team]

    T1 --> P1[Pod]
    T1 --> P2[Pod]
    T1 --> P3[Pod]
    T2 --> P4[Pod]
    T2 --> P5[Pod]
    T2 --> P6[Pod]
    T3 --> P7[Pod]
    T3 --> P8[Pod]
    T3 --> P9[Pod]
    T4 --> P10[Pod]
    T4 --> P11[Pod]
    T4 --> P12[Pod]

    X[Shared platform, security,<br/>data, design and reliability] --> T1
    X --> T2
    X --> T3
    X --> T4

A pod exists to change an outcome. Its charter should name the customer, the measurable outcome, the constraints, the decision-maker, the interfaces, the time box, and when to scale, pivot, or stop. Give the pod enough context and authority to decide most things itself.

Roles have to change with the leverage:

4× velocity means more frequent, high-quality changes in customer or business outcomes, without blowing up risk or operating cost. More code is a weak proxy.

AI made implementation abundant and judgment scarce. PRDs and Slack agents leave the operating model unchanged, so the extra speed becomes queues. We need small pods with end-to-end missions, inside teams that still own the services. The useful question is: if the company woke up with four times the implementation capacity, how would we design the company?