Software Team When the Spec Is the New Code

For 20 years, the rule was one product manager per 6 to 10 engineers (Marty Cagan, Inspired, 2007). Last year Andrew Ng mentioned a team that asked for two PMs per engineer (Andrew Ng on X, 2025). And this July, Gartner predicted that 60% of organizations will run "tiny teams" by 2029, with an ideal composition of a product manager, a designer, and one AI-native engineer (Gartner press release, July 7, 2026).

But the numbers are the least interesting part. Whether the new ratio is 2:1, 1:1, or something more conservative, the direction seems clear. As Andrew Ng put it: "Writing software, especially prototypes, is becoming cheaper. This will lead to increased demand for people who can decide what to build."

So, who are the "people who can decide what to build"? Is this just the traditional PM job, scaled to serve a different reality? Or should qualifications change with the ratio? Does deciding what to build now mean writing it down precisely enough for a literal-minded machine? Should the expectations include prototyping a requirement before defending or explaining it in a meeting?

Definition moved upstream and got heavier

With the AI-first approach to software development, the definition work didn't shrink; it moved upstream and got heavier. Dev teams assigned to a project are getting smaller because each dev can presumably accomplish more, but those devs now demand tighter specs, resolved edge cases, error states, acceptance criteria that double as tests, more detailed storyboards, and they want it faster.

Some would say the queue simply flipped. Where engineering used to hold the scarcity and product used to queue up requests and wait for capacity, now developers armed with agents are consuming definition faster than product can produce it. But if the queue has flipped, the implication is not that product needs to write faster or that engineering needs to wait better. It is that the old boundary between "definition" and "delivery" is no longer a useful organizing principle.

In a micro-team intended for an AI-first approach, each internal boundary becomes a gap, and AI tends to fill these gaps confidently with nonsense. Deflecting the burden of ownership within the eight-person squad was a manageable luxury. In a micro-team, collaboration is no longer just a cultural aspiration; it's a fundamental operational necessity.

If engineers are just waiting for specs precise enough to hand off to an agent, while product teams, equipped with AI themselves, churn out volumes of high-level user stories and expect the promised AI velocity, the bottlenecks just reproduce themselves.

If an organization has never made an effort to design cohesive teams optimized for an AI-first approach and capable of genuine joint effort around product decisions, then no AI will solve that, and no efficiency will materialize from any tool budget.

Structure around the decision load

The "PM" and "DEV" in every ratio argument are idealized units: the mythical man-month, reincarnated as job roles. But counting cycles measured in truly productive human effort, roughly two units of product thinking for every one of engineering sounds about right for a truly AI-first team. Who carries those cycles is the team and process design question.

I believe we need to structure the teams around the decision load, not the role expectations. An AI-first micro-team exists to convert ambiguity into precise, testable decisions. Product thinking can come from an engineer in discovery, and building can come from a PM in prototyping.

Some principles worth considering:

• The spec is the shared source code. Nobody "writes requirements for" anyone; the spec is jointly owned. One co-authored artifact chain: intent → executable spec → evals and acceptance criteria → agent build → review.
• Agents provide capacity; humans provide decisions. Treat human attention as the scarce input, spent almost entirely on deciding and verifying.
• Instrument and measure. Team-level delivery metrics are the truth; self-reports are for discovering friction only.

How do you structure teams optimized for AI-first product development? What do you think the ratio of product thinking to pure engineering work is that makes sense?

References

• Marty Cagan, Inspired: How to Create Tech Products Customers Love (SVPG / Wiley, 2007; 2nd ed. 2018).
• Andrew Ng, post on X, January 2025.
• Gartner, "Gartner Predicts 60% of Organizations Will Adopt Smaller Software Engineering Teams by 2029," press release, July 7, 2026.
• Frederick P. Brooks Jr., The Mythical Man-Month (Addison-Wesley, 1975).
• Liu Shangqi (Thoughtworks), "Spec-driven development," December 2025.
• Google Cloud, 2025 DORA Report announcement.
• CircleCI, 2026 State of Software Delivery Report.
• METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," July 2025.
• Gaby Prechner, "When Code Writes Itself, Product Managers Become the Real Bottleneck," Forbes Tech Council, March 2026.
• Marty Cagan / SVPG, "The Product Operating Model: An Introduction" (companion to Transformed, 2024).