Reinventing team flow within AI uncertainty
Avanscoperta Blog ยท article ยท 2026-05-14 source โ Reader ๐ฅ๏ธ
Code Was Never the BottleneckMeasuring AI ImpactOutcome-Based Work Design (vs. Fixed Jobs)Pair & Mob ProgrammingTeam AutonomyToken Throughput
Because large language models can touch nearly every step of software delivery at once rather than one isolated area, teams should respond to AI-driven uncertainty not with individual-level incentives or isolated experiments but with continuous, team-owned experimentation โ resetting rituals, replacing estimation with throughput, and shifting from fixed roles to dynamic contributions โ because the alternative (local, uncoordinated optimization) can make the whole system worse even when each individual change looks like a win.
practical ยท mixed โ Diagnostic/expository in its systems-thinking analysis of how AI destabilizes team flow (Cynefin, Theory of Constraints, roles-vs-contributions), argumentative in its prescription: embrace continuous, team-owned experimentation (Popcorn Flow) instead of individual KPIs or one-off pilots.
Structure
| Part | Role |
|---|---|
| Opening critique of management-imposed AI-usage KPIs and incentives (Tokenmaxxing) | context/counter-position โ sets up what the author argues against |
| Small isolated experiments won't be enough / invalidating assumptions | diagnosis โ AI's impact is systemic, not localized, so local experiments can combine to worsen the system |
| Emptied rituals; From Roles to Contributions; Bottlenecks are likely to move | diagnosis โ names three specific team structures (ceremonies, roles, flow bottlenecks) destabilized by AI |
| Enter continuous experimentation (reset rituals, throughput instead of estimation, Popcorn Flow, assess learning as a team, repeat experiments, think out of the prompt, observe weak signals) | prescription โ the concrete practice recommended to replace both top-down KPIs and uncoordinated individual experimentation |
Key terms
- Tokenmaxxing Token Throughput
Borrowed from Gergely Orosz: the pattern of organizations incentivizing AI usage by measuring token consumption, which the author argues is close to certain to be gamed and is especially unreliable in collaborative settings like pairing. - Cynefin (the complex/chaotic liminal space)
Used to characterize where AI tool adoption places a team's work: not in the 'complex' domain (where probing and sense-making still apply within some structure) but in a liminal space edging toward 'chaotic,' where there is no rulebook and the priority is bringing the team into 'more manageable waters' rather than following a procedure. - Roles vs. contributions
A proposed shift away from organizing work around fixed job titles/roles (which map to salary and specific responsibilities, and create handoffs and defensiveness when challenged) toward organizing around the dynamic contributions individuals actually make in a period where new AI-era skills don't track cleanly onto old seniority or title structures. - Popcorn Flow
Claudio Perrone's kanban-like board for continuous experimentation (states: Problem & Observations, Options, Possible Experiments, Committed, Ongoing, Review, Next), recommended here specifically because it lowers the threshold for starting an experiment to a 'why not?' level and builds in an explicit review step. - Throughput (as replacement for estimation) Measuring AI Impact
The number of items completed per unit time, proposed as the metric of choice once estimates become too variable to be useful under AI-driven uncertainty โ valued because it preserves system observability and guards against local optimizations that clog the real bottleneck, without requiring speculative effort sizing.
Propositions
- explicitManagement-imposed AI-usage KPIs and incentives for individuals and teams are likely to produce gamed or inconsistent results rather than genuine learning, because organizations tend to pick the wrong metric, and individual-level measures like token consumption break down in collaborative settings such as pairing and can also artificially narrow exploration if scoped to one vendor.conf: highextendsAgentics / Tech Things: Tokenmaxxing is dead, long live tokenmaxxing ยท p2 โ Adds a pairing-specific failure mode (individual token consumption is inconsistent to measure when two people share a session) to the general tokenmaxxing-as-gamed-incentive critique.
- explicitUnlike most prior technical improvements, LLM tools have no single area of impact โ they can simultaneously reshape requirements gathering, documentation, coding, design sparring, vulnerability checking, and non-critical specialist work โ which means small, isolated experiments confined to one step risk missing (or actively worsening) systemic effects across the whole development flow.conf: high
- explicitTwo independently reasonable local AI experiments can combine to make the overall system worse โ e.g. a clean LLM-authored specification taken as-is and turned directly into a prompt by a developer, making a supposedly value-adding handoff redundant, or a faster bug-fix cycle that simply clogs an unchanged downstream pull-request approval queue โ a Theory-of-Constraints-style local optimization that worsens whole-system performance.conf: highsupportsSoftware Factories, Light and Dark ยท p6 โ Both describe the same mechanism from opposite ends: Osmani notes that removing the human review step makes perceived throughput jump; this piece gives the concrete downstream consequence โ a faster fix cycle just clogs the unchanged pull-request approval queue, a local win that doesn't improve the system.
- explicitIntroducing AI tools moves a team's day-to-day work from the 'complex' into a liminal space bordering 'chaotic' in Cynefin terms, especially once the impact on team collaboration (not just individual coding) is included โ there is no detailed rulebook for this territory, so the task is to bring the team into more manageable waters, not to follow a known procedure.conf: high
- explicitEstablished ceremonies and rituals (iteration length, planning meetings, retrospectives) were tuned for a pre-AI world โ a different team size and interaction pattern โ and are increasingly dissonant; they need to be explicitly reset and rebuilt to regain legitimacy rather than kept running on autopilot.conf: high
- explicitFixed roles and job titles create friction (more handoffs, defensive protection of role boundaries, especially when tied to bonuses/KPIs) precisely when AI reshuffles which skills matter most; the more useful organizing unit in a period of change is the dynamic contribution an individual makes, because emerging AI-era skills (e.g. decomposing a complex feature into manageable steps) correlate more with attitude than with official seniority or title.conf: highsupportsFrom Async Code Reviews to Co-Creation Patterns ยท p11 โ Both treat pairing/ensemble work as a team-level practice under pressure from AI-era changes to flow, rather than an individual productivity technique.
- explicitA good measurement target for AI's systemic impact has skin in the game and real feedback loops โ a team owning its own features in production is a much better target than a single contributor's delivery of a temporary artifact.conf: high
- explicitcorroboratedAI making coding faster does not establish that coding is the system's bottleneck; the constraint is at least as likely to move downstream (approval queues backing up behind a faster fix cycle) or upstream (product roles sucked into continuous clarification loops with LLMs, or business validation failing to keep pace) as to disappear.conf: highsupports โSoftware Teaming: A Mob Programming, Whole-Team Approach ยท p8 โ The book's queueing/Lean Flow argument (coding was never the bottleneck; separation and handoffs were) is the pre-AI grounding for the claim that AI speeding up coding doesn't establish coding as the system's bottleneck.
- explicitTraditional point estimation becomes close to worthless under AI-driven variability, so throughput is a better metric for tuning the pace of experimentation against strategic deadlines, because it protects system observability without speculative sizing effort and guards against local optimizations that clog the actual bottleneck.conf: high
- explicitPopcorn Flow's board structure (Problem & Observations, Options, Possible Experiments, Committed, Ongoing, Review, Next) is well suited to this situation specifically because it lowers the threshold for starting an experiment to a 'why not?' level and builds an explicit review step into the format.conf: high
- explicitThe consequences of an AI-driven experiment should be assessed by the team as a whole, not left to whoever introduced it, because an AI collaborator has no accountability and no skin in the game, so the team must supply the accountability an individual AI-paired-with-a-human experiment would otherwise lack.conf: high
- explicitA single experiment run is not a valid test of whether an AI-era practice works, because tool versions, prompting techniques, and even small interaction details (e.g. dictation versus typing prompts) change fast enough that 'we tried this and it didn't work' is an unreliable conclusion โ experiments must be repeated and tuned, and the resulting learning should itself be treated as ephemeral.conf: high
- explicitBeyond pre-defined success criteria, teams should watch for weak and slow signals โ including how people feel at the end of an AI-powered working day โ because the cumulative and emotional effects of AI-driven change surface slowly and narrow, upfront success criteria won't capture unexpected outcomes.conf: high
Arguments
Teams should address AI's effects through continuous, team-owned experimentation rather than through individual-level KPIs/incentives or uncoordinated isolated pilots. strength: high
Explicit premises:
- AI's impact is systemic, touching many SDLC steps simultaneously, rather than confined to one area.
- Isolated local experiments โ even individually reasonable ones โ can combine via Theory-of-Constraints-style dynamics to make the whole system worse.
- Individual-level incentives (Tokenmaxxing) are prone to gaming and break down in collaborative settings.
Implicit premises:
- The team, not the individual who introduces a change, bears the downstream consequences of that change, so the team is the correct unit of both experimentation and accountability.
Inferences:
- This implies that management's instinct to impose individual AI-usage KPIs and bonuses is not merely an imperfect proxy but actively counterproductive, since it measures and rewards exactly the wrong unit (the individual's token/output volume) for a systemic, team-level phenomenon.
Teams should reorganize around dynamic contributions rather than fixed roles during this period of AI-driven change. strength: medium
Explicit premises:
- Fixed roles tied to compensation and KPIs create defensive behavior and handoffs that are costly precisely when flexibility is most needed.
- New AI-era skills (e.g. feature decomposition) do not map cleanly onto existing role or seniority structures โ some POs are better at it than some developers.
- A good measurement target (team owning features in production) aligns better with contribution-based organization than with role-based delivery of individual artifacts.
Implicit premises:
- Measurement structure and organizational structure are coupled: you cannot change what you measure (team-level outcomes) without also changing how people are organized (contribution-based, not role-based), or the two will pull against each other.
Inferences:
- Since 'salaries are tied to job titles,' as the piece itself notes, this argument implies that compensation systems โ not just team process โ need to change for the contribution-based model to be more than aspirational; otherwise the same defensive, role-protecting incentives the piece diagnoses will persist underneath any process-level relabeling.
Narratives
- A team uses an LLM during requirements gathering to produce a clean specification; a developer later takes that specification as-is and turns it directly into a prompt, making the human review/translation step that used to add value redundant unless someone is actively supervising the handoff.
โ Concretely supports the proposition that two independently sensible local AI experiments can combine to quietly degrade the overall flow โ it's the piece's clearest worked example of the abstract Theory-of-Constraints claim. - A reference to David Fowler's LinkedIn piece 'AI made us faster, and that's the problem,' cited as giving 'an interesting perspective on how AI can affect team interactions and well-being.'
โ Functions as external corroboration for the 'new team member with no accountability, no skin in the game' framing โ grounding the author's own claim in an independently-arrived-at account from outside the piece.
Questions addressed
- โ
How should a team respond when management pressures it to show AI adoption through usage-based KPIs or incentives?
Resist individual/vendor-scoped usage metrics (Tokenmaxxing-style); replace them with team-owned continuous experimentation measured by throughput, which better withstands gaming and local optimization. - โ
Should a team's existing rituals and ceremonies (iteration length, planning, retrospectives) be preserved as AI tools are introduced?
No โ they should be explicitly reset and rebuilt, because they were tuned for a different team size and interaction pattern and may no longer serve their original purpose. - โ
Should team roles stay fixed while AI reshapes which skills and contributions matter?
No โ shift the organizing principle from roles to dynamic contributions, though the piece stops short of addressing how compensation (tied to job titles) would need to change to support this. - โ
If AI speeds up coding, has the team's bottleneck moved or disappeared?
The bottleneck has very likely moved (downstream to review/approval, or upstream to requirements/business validation), not disappeared โ coding was rarely the true constraint to begin with.
Gaps
- incompleteThe piece explicitly scopes its advice to 'healthy environments,' where curiosity alone should drive experimentation โ but the teams most likely to face top-down AI KPIs and incentives (the behavior the piece opens by criticizing) are plausibly the less healthy ones, where management doesn't trust organic experimentation to happen on its own. The piece doesn't address this chicken-and-egg problem: the team-ownership model it prescribes may be hardest to establish exactly where it's most needed.
Read next: Look for material on introducing team-owned experimentation practices (Popcorn Flow or similar) in low-trust or low-psychological-safety environments, where the precondition the piece assumes doesn't hold. - incomplete'Throughput instead of estimation' is recommended as the system-observability metric, but the piece doesn't specify the level at which throughput should be measured (team? value stream? whole org?) or address the well-known failure modes of throughput-as-a-target shared by any WIP/flow metric โ e.g. reclassifying, splitting, or gaming units of work to inflate apparent flow, the same gaming concern the piece itself raises about Tokenmaxxing.
Read next: Look for flow-metrics literature (Kanban/DORA) on throughput-gaming countermeasures, and whether those apply unchanged in an AI-accelerated context. - incompleteThe piece treats individual experimentation ('individual actions remain valid and don't require any upfront agreement') and team-owned experimentation (Popcorn Flow, assessed as a team) as compatible, coexisting levels, but never works out what happens when they conflict โ e.g. an individual's unilateral habit change (dictation instead of typing prompts) versus a team's committed, board-tracked experiment that assumes a different interaction pattern.
Read next: Look for material on reconciling individual experimentation with team-level process commitments more generally โ where the boundary between 'my own workflow tweak' and 'something the team needs to agree on' actually sits.
Closes gaps elsewhere
- No, AI Did Not Kill Agile ยท g3 โ That piece dismisses sprint-based ceremony as too slow for AI-accelerated work but doesn't propose a replacement container. This piece gives a concrete answer: don't repurpose the existing ritual, deliberately reset cadence and hold a dedicated checkpoint tied to experiment outcomes and learning, separate from the standard retrospective format.
- This Week in AI: Production Viability ยท g3 โ That piece names the wrong metric (individual token consumption / 'tokenmaxxing') but leaves 'what metric should replace it' unanswered. This piece proposes a specific, reasoned replacement: team-level throughput, chosen because it preserves system observability and resists the same local-optimization and gaming failure modes.
Related documents
- From Async Code Reviews to Co-Creation Patterns
- Software Factories, Light and Dark
- Agentics / Tech Things: Tokenmaxxing is dead, long live tokenmaxxing
- The 8 software engineering metrics AI broke
- Agentic Code Review
- AI coding creates two kinds of debt. You're only measuring one
- AI isn't making developers more productive โ it's making them busier
- CannotMeasureProductivity
- Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools
- Measuring AI impact, assessing readiness, and new data trends