Less Queue, More Craft

Rethinking Assumptions argued that when agents write most of the code, the assumptions behind our tooling break: tickets, PRs, sprints, and branches were built for a world where humans were the scarce resource. That post focused on tools. This one asks: what does that shift mean for teams? Product and engineering don't just use the tools - they are organized around the same assumptions. If we don't update how we work together, we'll keep forcing agent-era output through human-era structures and blame the wrong thing when it hurts.

There's an upside worth aiming for. When the bottleneck shifts from "can we build it?" to "do we want it? is it right?", product and tech can finally focus on the work that only humans can do: strategy, judgment, coherence, and learning. Less queue management, more craft. The teams that lean into that shift don't just survive the transition - they get to play a better game.

In this post we look at team-level assumptions and tensions, team size (including the "tiny team" angle), what product and tech need to own, the IC and PM in the new loop, the bridge from prototype to production, and a practical stance.

The Team-Level Mirror of the Same Assumptions

Engineering capacity was the bottleneck. Roadmaps and backlogs were sized to "how much can we build?" Product prioritized ruthlessly because saying yes to everything was impossible. When agents multiply effective capacity, the constraint moves. The bottleneck is no longer "can we build it?" but "do we want it? is it right? can we maintain it?"

Product "owns" the queue. Specs, tickets, and acceptance criteria exist to direct scarce engineering time. If work can be dispatched to agents in near real time, the queue is less about rationing and more about coherence: what are we optimizing for? What's in scope? The product role shifts from allocating capacity to defining intent and verifying outcomes.

Tech "owns" the implementation. Engineers were the ones typing the code, so they owned quality, architecture, and tech debt. When agents generate the code, ownership gets fuzzy. Who is responsible when the agent's output is wrong? When it's right but brittle? When it fits the ticket and breaks the system? "We shipped what was asked" is no longer a clear boundary.

Tensions That Show Up in Practice

Old dynamic	New reality	Tension
Product prioritizes; eng executes	Both can "execute" via agents	Who decides what gets built first when the cost of wrong order drops?
Eng says "we don't have time"	Capacity is less scarce	Saying "no" must shift from capacity to alignment and quality - harder to defend.
Reviews catch mistakes	Volume of changes explodes	Review becomes intent- and risk-based; teams argue over what "counts" as reviewed.
Roadmaps are quarterly	Work can be triggered continuously	Roadmaps risk becoming fiction; strategy and sequencing need new rituals.
Tech debt is "when we have time"	Agents can churn out more code fast	Debt can compound faster than humans ever could; someone must own the "no."

These aren't theoretical. They show up in sprint planning ("why can't we just have the agent do it?"), in post-incident blameless reviews ("the agent changed it"), and in product debates ("we can try it and see" - with who maintaining it?).

What It Means for Team Size

When implementation capacity is less scarce, the naive question is: do we need fewer people? The better question is: what are we sizing for? Teams were historically sized for output - how much can we build? If agents multiply output, the constraint shifts to intent, verification, and coherence. So team size might not shrink; it might shift in composition. You may need relatively more people who excel at defining intent, verifying outcomes, and owning the bridge from prototype to production - product, design, tech leads - and relatively fewer purely for implementation throughput. Or you keep the same headcount but each pod owns more surface area because orchestration and agents let them deliver what used to require a larger team.

The trap is shrinking headcount before the team has learned to work in the new way. If you cut before intent, verification, and the bridge are solid, you get the same volume of agent output with fewer people to steer it - chaos, not efficiency. The upside: once the team has shifted, smaller groups can genuinely deliver more. Team size becomes a function of how much judgment and coherence you need, not how many hands you need to type. That can mean smaller teams. It can also mean the same size team doing more valuable work. Either way, the driver is the work that only humans can do.

The "tiny team" angle. This lines up with the "tiny team" concept that shows up in practitioner playbooks and in analyst work (e.g. Gartner's predictions on flatter, AI-augmented organizations): small, high-trust crews that punch above their weight because the bottleneck is no longer implementation but coordination, intent, and judgment. In that world, "more millions in ARR than employees" is an aspiration; the enabling condition is that the team has learned to work with agents and with each other - clear intent, verification, and coherence. Tiny teams only work when the humans in them are doing the right kind of work. Our framing (intent, verification, bridge, composition) is what makes "tiny" sustainable instead of just understaffed.

What Product Teams Need to Own

Intent, not just requirements. When implementation is cheap, the scarce skill is deciding what to build and why. Product must get better at articulating outcomes, success criteria, and boundaries - not just feature lists. Agents are good at fulfilling specs; they're not good at deciding whether the spec is the right one.

Outcome verification. If we move from "review every line" to "review for intent," product has a bigger role in checking that the result matches the goal. That means clearer definitions of "done," more involvement in acceptance and rollout, and less hiding behind "eng will figure it out."

Saying no (and why). When "we don't have capacity" is weaker, "we're not doing that because it doesn't fit our strategy / creates unacceptable risk / worsens debt" has to carry the weight. Product and tech together need a shared language for refusing work - one that isn't just capacity.

What Tech Teams Need to Own

Architecture and constraints. Agents will fill in whatever space they're given. If no one defines boundaries - modules, APIs, patterns, "do not touch" zones - agent output will drift. Tech must own the guardrails: what's in scope for automation, what requires human design, what gets reviewed at what depth.

Quality and debt. When changes are abundant, the risk is more bad code and more debt, not less. Tech must own standards (lint, tests, security), thresholds for auto-merge, and when to block or roll back. "The agent did it" cannot become an excuse for lowering the bar.

When to slow down. Not everything should be "send an agent, ship fast." Some changes need design, discussion, or human judgment. Tech needs to be able to say "this one we do the old way" and have that be a legitimate, respected choice - not seen as resistance.

The Individual Contributor - Orchestrating Long-Running Agents

Team-level shifts land on someone. For the IC who's now orchestrating long-running agents, the job is different. You're not the one typing most of the code; you're the one deciding what to run, when to look, when to redirect, and when to accept or reject the result. Your day is less "implement this" and more "direct this, then verify it."

Attention is the new bottleneck. You can have several agents running in parallel - refactoring a module, fixing a bug, exploring an approach. But you have limited attention. Do you watch the run in real time or check back when it's done? Do you interrupt when you see it heading the wrong way, or let it finish and then correct? Long-running agents force you to decide where to put your eyes and when to step in. The skill is less "how do I write this?" and more "how do I supervise this without becoming the bottleneck or going on autopilot?" Tools that expose when to show the agent's thinking and when to allow interruption matter here - but so does your own discipline: which runs deserve live attention, and which can be reviewed at the end.

Intent up front, verification after. The better you specify what you want and what "done" looks like, the less you'll waste on misdirected runs. The flip side: when the agent comes back with output, you own the decision to merge, request changes, or kill it. That verification step is where your judgment shows up. If you rubber-stamp because there's too much volume, quality and coherence slip. If you review everything line-by-line, you're back to being the bottleneck. Intent-based review helps - approve the logic and the outcome, drill into the diff when it matters - but the IC has to be willing to own that call.

The trap and the upside. The trap: feeling like a glorified task dispatcher who's lost touch with the code, or like a bottleneck who can't keep up with what the agents produced. The upside: you can run parallel workstreams, delegate the tedious implementation, and focus on the bits that need human judgment - architecture, edge cases, product fit, "should we do this at all?" The teams that support this (clear intent from product, guardrails from tech) make orchestration sustainable. The ones that don't - vague tickets, no boundaries, review-everything culture - leave the IC stuck between too many agents and too little clarity. For the individual contributor, "less queue, more craft" means your craft is increasingly orchestration and judgment, not just typing. That can be more interesting. It can also be disorienting until the role and the expectations catch up.

The User-Facing PM - When You Can Prototype Use Cases Quickly

The same forces that let engineers orchestrate agents let user-facing PMs prototype use cases quickly: agents, no-code tools, or AI-assisted flows can turn an idea into something clickable in hours instead of waiting for a sprint. That's a real shift. The PM is no longer only the person who writes the spec and waits for eng to build it; they can put a concrete thing in front of users and learn before a single ticket is filed.

Faster learning, fuzzier handoffs. When the PM can prototype, the loop tightens: idea → prototype → user feedback → iterate. You learn what resonates and what doesn't without burning eng capacity. But then what? Is the prototype a throwaway to inform a spec, or the seed of the real product? Who productionizes it - eng rebuilding from the prototype's intent, or eng inheriting the prototype's code? If that's unclear, you get duplicate work, mixed expectations, or prototypes that users saw and now expect, while eng is building something else. The user-facing PM needs to be explicit: "this is for learning" vs "this is the direction we're committing to; eng will own the build."

Ownership of the user experience. Because the PM is user-facing, they're the one showing prototypes in demos, in user research, in "what if we did this?" conversations. That puts them on the hook for consistency: the prototype sets expectations. If the production version diverges (because eng had to simplify, or scale, or fix), the PM has to own that story - why it changed, what we kept, what we traded. The skill is not just "I can prototype fast" but "I can articulate what we're testing, what we learned, and what we're committing to build for real." Intent and outcome verification apply to the PM too: when you hand off to eng (or to an agent), the clearer your intent and success criteria, the less rework and the less drift.

The trap and the upside. The trap: prototype proliferation - lots of demos, nothing production-ready, and eng either drowning in "make it like the prototype" or ignoring it and building from the spec (or prioritization blurring because every idea becomes a prototype). The upside: the PM can validate with users earlier, write better specs because they've felt the flow, and shorten the telephone game between "what users need" and "what we're building." Eng gets intent that's been stress-tested with real use cases, not just bullet points. The user-facing PM who can prototype quickly is most valuable when they use that power to learn and communicate intent, not to bypass eng or to create a parallel universe of prototypes that never become product.

The Bridge Between Prototype and Production

Prototypes validate intent and flow; production releases require reliability, scale, security, maintainability, and clear ownership. The bridge is the deliberate step that turns "we learned something we want to ship" into "we're shipping it for real."

What production-ready means. A prototype can be rough edges, happy paths, and "good enough to learn from." Production-ready means: it fits the architecture, it's tested and observable, it meets security and compliance bar, it's documented and maintainable, and someone owns it after launch. Those aren't nice-to-haves - they're the criteria that prevent prototypes from becoming technical debt or user-facing promises you can't keep. The bridge is the set of gates that something must pass before it's allowed into production. Teams need to define those gates explicitly: what does "done for production" mean for us? Who signs off?

Intent as the thread. The prototype answered "is this the right thing?" The production build answers "can we ship it properly?" The bridge is the translation: the PM (or whoever owned the prototype) hands off intent - what we learned, what we're committing to, what success looks like, what's in and out of scope - and tech (eng or agents) owns turning that into production-ready code. The prototype might inform the spec; it might be thrown away and rebuilt from intent. It might, in some cases, be refactored and hardened. What matters is that the handoff is explicit: "here's what we're building and why," not "make it like the prototype" without clarity on constraints and tradeoffs.

Who owns the bridge, and how it stays visible. If no one owns the step from prototype to production, prototypes pile up and either never ship or ship half-baked. The bridge needs an owner - usually tech, with product defining acceptance - accountable for production criteria and for saying "this can't be productionized as-is; here's what we'd need to change." In a world where both PMs and eng can spin up artifacts quickly, "prototype" and "production" can blur; teams benefit from making the bridge visible: a ritual ("production track" vs "exploration"), a checklist, or a handoff moment ("ready for productionization; here's the intent"). The bridge is the filter that keeps the system coherent - prototypes stay cheap and fast, production stays intentional and maintainable.

When It Clicks

Imagine a team that has made the shift. Product doesn't spend cycles fighting over backlog order or "we only have two sprints" - they spend them on what we're optimizing for and how we'll know we're right. They can run more real experiments: hypothesis → agent-assisted implementation → measure → learn, in days instead of quarters. Tech doesn't spend most of their time turning tickets into code; they spend it on architecture, constraints, and the few changes that need human design. The IC orchestrates and verifies; the PM prototypes, learns, and hands off intent; the bridge from prototype to production is explicit, so explorations become releases without chaos. Review becomes a conversation about intent and risk, not a line-count grind. Roadmaps stay alive because they're about direction and outcomes, not a fixed list of deliverables. The team feels less like a factory and more like a group that decides what's worth building, then builds it with clarity.

That's not guaranteed. It's what becomes possible when product and tech own the right things and drop the rituals that only made sense when capacity was scarce. The inspiration is simple: the work gets more interesting. The bottleneck becomes judgment and coherence - exactly the work that benefits from human attention.

The Risk of Superficial "Speed"

A critical trap: treating agent-assisted workflows as pure acceleration. If product and tech don't change how they work, "faster" can mean:

• More output, same clarity. We ship more features that don't cohere, or that nobody really wanted, because the cost of saying "let's not" wasn't felt.
• Shallower understanding. When agents write the code, engineers can lose the muscle of building from scratch. When something breaks or needs to evolve in a non-obvious way, the team may lack the depth to fix it.
• Accountability dilution. "The agent suggested it." "Product asked for it." "We just merged what passed CI." Responsibility blurs; learning and ownership suffer.

So the goal isn't just "ship faster." It's ship the right things, with the right quality, and with clear ownership. That may mean slowing down some flows (intent definition, architecture decisions, high-risk changes) so that the accelerated parts (implementation, iteration, experiments) don't outrun the team's ability to steer.

A Practical Stance for Teams

Audit your own assumptions. Not just tools - roles. Who do we assume is the bottleneck? Who "owns" quality? Who can say no? Update those assumptions explicitly; otherwise you'll keep optimizing for the old game.

Separate "what we want" from "how we build it." Product focuses on intent, outcomes, and boundaries. Tech focuses on how to build, what's allowed, and what's out of scope. Both need to be strong; neither can hide behind "we're just executing."

Keep some friction on purpose. Not every idea should become a ticket and then agent-generated code. Keep gates for: strategy fit, architectural impact, and "do we really want to maintain this?" Friction in the right places protects coherence and quality.

Invest in intent and review. As in Intent-Based Review, the bottleneck moves to verification. That's not just a constraint - it's an opportunity. When you're forced to get good at reviewing for intent, risk, and outcome, you're forced to get good at the thing that actually differentiates you: judgment. The teams that lean in here will ship with confidence instead of hope.

The original post said: the teams that question their assumptions first will have a head start. For product and tech, that means questioning not only which tools to use, but how we divide responsibility, how we say no, and what we're optimizing for. The tools will keep evolving. The teams that align their structure and norms with the new reality will get more from those tools - without losing coherence, quality, or ownership. More than that: they'll get to spend their time on the work that matters. That's the inspiration. The rest is execution.