Why the best teams are getting
smaller, not bigger

A year ago, shipping a feature meant coordinating three people. A product manager wrote the spec. A designer mocked it up. An engineer built it. The handoffs between them took longer than the actual work.

That process assumed implementation was the expensive part. Writing code took weeks. Getting it right took longer. So companies hired specialists and built processes to make sure every line of code was justified before anyone opened an editor.

Coding agents changed the equation. When a working prototype can be generated in minutes, the bottleneck moves from “can we build it?” to “should we build it?” And most organizations haven't caught up.

The waterfall that nobody called a waterfall

Even teams that consider themselves agile often follow a hidden sequence: idea, product requirements document, design mockup, engineering ticket, code, review, ship. Each step requires a handoff. Each handoff introduces delay, translation loss, and the chance for misalignment.

This made sense when implementation was slow. You wouldn't let an engineer spend two weeks building something that the designer hadn't validated. The cost of a wrong implementation was too high.

With coding agents, that cost drops to nearly zero. An engineer (or a PM, or a designer) can describe what they want and have a working version in front of them within an hour. Not a wireframe. Not a clickable prototype in Figma. Running code that you can test with real data.

The formal PRD is not the starting gun anymore. The starting gun is an idea and thirty minutes with an agent.

This doesn't mean PRDs are dead. It means they serve a different purpose. Instead of being a permission slip for engineering to start work, they become a record of intent: why this feature exists, what problem it solves, what trade-offs were accepted. That documentation is more important than ever when agents are generating the code, because reviewers need context about what “correct” even looks like.

The new bottleneck: review, not implementation

Here is the uncomfortable truth that the data makes clear. According to research from Anthropic, developers now use AI in roughly 60% of their work, but they can fully delegate only 0 to 20% of tasks. The gap between “AI helped me write this” and “AI handled this end to end” is enormous.

What fills that gap? Human review. And review is now the most constrained resource in every engineering organization.

The numbers from LogRocket tell the story: AI-generated pull requests are 1,700% larger than human-written ones. Review times have nearly tripled. PR volume has increased 98%. Teams that used to be bottlenecked on writing code are now bottlenecked on reading it.

And the review that matters is not just “does this code work?” It spans three domains:

• Engineering review: Is this scalable? Is it secure? Does it follow the architecture? Will it break under load?
• Product review: Does this solve the right problem? Does it match user expectations? Will anyone actually use this?
• Design review: Is this intuitive? Does the flow make sense? Is the experience consistent with the rest of the product?

When a three-person team divides these reviews across three specialists, each one only sees their slice. The engineer approves the code quality without questioning whether the feature should exist. The PM approves the intent without noticing the performance implications. The designer critiques the UI without understanding the technical constraints.

The best reviewers hold all three perspectives simultaneously.

Every role is changing. Here's how.

The shift is not that any of these roles disappears. It is that what each role does day to day looks fundamentally different. The core skills matter more than ever. The mechanics of the job have changed.

Engineering: from author to architect

The engineer's primary output is no longer code. It is judgment about code. Boris Tane from Cloudflare describes engineers who started their careers with AI tools and have never experienced sprint planning or story points. Their workflow is: describe intent, let the agent execute, observe the result, iterate. The traditional SDLC phases have collapsed into a tight loop.

But that loop only works when the engineer has strong mental models of system architecture, security boundaries, and performance characteristics. Without those models, you can't evaluate what the agent produces. You just accept it and hope for the best.

Product: from specifier to curator

Product managers who spent most of their time writing detailed specifications now spend it evaluating working software. The volume of things to evaluate has exploded. When any team member can produce a prototype in an afternoon, the PM's job becomes curation: which of these prototypes solves a real problem? Which ones should die before they gain momentum?

This is harder than writing a PRD. It requires taste, user empathy, and the discipline to kill ideas that look impressive but don't serve a genuine need.

Design: from deliverable to direction

Designers who handed off pixel-perfect mockups now sit in the iteration loop with the agent. They prompt, evaluate, adjust, and refine. The feedback cycle that used to take days (designer mocks it up, engineer builds it, designer reviews, engineer revises) now happens in real time.

The risk is that design gets reduced to surface aesthetics. The opportunity is that designers with systems thinking can influence architecture, information hierarchy, and interaction patterns directly in working code. The designer who understands frontend constraints builds better products than one who only works in Figma.

Generalists win. Specialists still matter.

The most effective person in an agent-augmented team is the one who can hold engineering, product, and design context simultaneously. Not because they are the best engineer, the best PM, or the best designer. Because they can evaluate a prototype from all three angles without waiting for three separate reviews.

One generalist with an agent moves faster than a three-person specialist team with the same agent. There is no handoff. No translation. No meeting to align perspectives. The generalist sees the prototype, knows whether the architecture is sound, whether it solves the right problem, and whether it feels right to use.

This does not mean specialists are obsolete. Deep expertise in distributed systems, accessibility, or data modeling remains essential for complex problems. But the day-to-day work of shipping features increasingly favors people with broad, practical fluency across disciplines.

Addy Osmani points to data showing junior developer employment dropping 9 to 10% with AI adoption. The roles that disappear first are the ones that were primarily about translating specifications into code. The roles that grow are the ones that require judgment across boundaries.

System thinking is the skill that compounds

When execution becomes cheap, the quality of your thinking determines the quality of your output. An agent can build anything you describe. The question is whether what you describe is worth building, and whether it fits into the larger system you are creating.

System thinking means understanding how a feature interacts with the database schema, the API surface, the user flow, the billing model, and the support burden. It means seeing second-order effects before the code ships.

This is not something you learn from a course. It comes from years of building, breaking, and fixing real systems. Engineers who have shipped production software for a decade bring mental models that no amount of AI assistance can replace. The agent generates the code. The experienced builder knows whether the code belongs in the system.

The most dangerous failure mode is not bad code. It is well-written code that solves the wrong problem or creates the wrong abstraction. Agents are excellent at producing clean, well-structured implementations of whatever you ask for. They are not good at telling you that you asked for the wrong thing.

Two roles that define the new team

Every effective team we work with has settled into two distinct modes of contribution. You are either a builder or a reviewer. Most senior people oscillate between both, but the skills are distinct.

Builders transport features from concept to production. They work directly with agents, iterate on prototypes, handle the messy details of making something real. They need taste, technical skill, and the ability to evaluate agent output across engineering, product, and design. A builder with strong fundamentals and good agent skills can ship what used to take a team of five.

Reviewers hold the system in their head. They catch the architectural decision that will cause problems in six months. They see the feature that looks good in isolation but contradicts the product direction. They have deep domain expertise and exceptional systems thinking. Their primary output is not code. It is decisions.

Both roles are essential. Without builders, nothing ships. Without reviewers, the wrong things ship. The ratio depends on the maturity of the product: early-stage teams need more builders, mature products need more reviewers.

Bad ideas are more expensive than ever

There is a counterintuitive consequence of cheap execution. When it takes two weeks to build a feature, a bad idea dies in the planning phase. Someone pushes back on the PRD. The engineering estimate is too high. The idea never makes it to code.

When it takes two hours to build a prototype, bad ideas survive longer. They become real. They get demonstrated. They gain internal momentum. People start saying “well, we already built it” even when the feature should not exist. A PM who generates bad ideas at high volume does not just waste engineering time anymore. They create a review burden that drowns the team and pushes bad features toward production.

The cost of a bad idea is no longer the time to build it. It is the time everyone spends reviewing, debating, and eventually killing it.

Teams that lack the discipline to kill prototypes early end up with feature sprawl, inconsistent products, and reviewers who are too overwhelmed to catch real problems. The cure is not fewer prototypes. It is faster, more ruthless evaluation against clear product principles.

The new development cycle

The traditional software development lifecycle, with its distinct phases of planning, design, implementation, testing, and deployment, is collapsing into something tighter. Boris Tane describes the new cycle as four steps: intent, agent execution, observation, iteration.

• Intent: Describe what you want. This can be a sentence, a sketch, a reference to existing behavior. The clearer the intent, the better the first output.
• Agent execution: The agent generates a working implementation. Not pseudocode. Not a plan. Running software.
• Observation: You evaluate the result across all three dimensions: engineering quality, product fit, and design coherence. This is where most of the human value lives.
• Iteration: You refine. Sometimes that means a prompt adjustment. Sometimes it means rethinking the approach entirely. The cycle is minutes, not weeks.

Engineers who entered the profession after these tools became mainstream have never worked any other way. They have no memory of multi-week sprint cycles or elaborate estimation rituals. Their instinct is to build first and evaluate second. The challenge is making sure the evaluation step is rigorous enough to catch what fast execution misses.

The deskilling trap

There is a real risk that developers who rely on agents from day one never build the foundational understanding that makes good review possible. If you have never debugged a memory leak manually, you will not catch one in agent-generated code. If you have never designed a database schema from scratch, you will not recognize when the agent produces a schema that won't scale.

This is the deskilling problem, and it applies across all three disciplines. A designer who has never wrestled with CSS layout will not know when the agent produces a fragile solution. A PM who has never talked to users directly will not know when a prototype solves a problem nobody has.

The teams that navigate this well invest in two things: deliberate practice (building things from scratch regularly, even when agents could do it faster) and structured review where senior people explain their reasoning, not just their decisions. Junior team members learn by watching how experienced builders evaluate agent output, not by generating more output themselves.

Why this is a venture studio moment

The venture studio model was designed for exactly this shift. When the scarce resource was implementation, startups needed large engineering teams. When the scarce resource is judgment and review, they need experienced builder-reviewers who can evaluate across disciplines.

At Buildway, we bring founding teams the people who have spent years developing the system thinking that agents cannot replace: the ability to look at a prototype and know whether the architecture will hold, whether the product direction is right, and whether the experience is coherent.

A founding team used to need a CTO, a head of product, and a lead designer before writing the first line of code. Now they need one or two people who can do all three at a high enough level, supported by agents that handle the implementation. The value is not in writing code. It is in knowing what to build and recognizing when the output is good enough to ship.

That is the partnership we offer: experienced builders who review what agents produce, shape the architecture, and make the product decisions that determine whether a startup succeeds or fails.

The teams that adapt first compound the advantage

The shift from implementation to review is not coming. It is here. Teams that restructure around it, investing in generalists, building review capacity, and maintaining the discipline to kill bad prototypes, will ship better products with smaller teams.

Teams that keep the old structure, separate PMs writing specs, separate designers producing mockups, separate engineers translating both into code, will find themselves slower than competitors with a fraction of their headcount.

The question is not whether your team will change. It is whether you will lead the change or be forced into it.