Code Was Never the Bottleneck

The recurring finding that accelerating code production barely moves end-to-end outcomes because the binding constraints are upstream and downstream — understanding, organization, judgment.

Also known as: the keyboard, code creation, value delivery, bottleneck, speed problem, knowledge problem, AI-paradokset, AI paradox, automation is a lie, Amdahl's Law (applied), lines of code (as throughput proxy)

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (53)

• Nils Brede Moe's Post Nils Brede Moe · 2026-09-23 Reader 🖥️
  Teams that genuinely pursue value from AI-assisted coding may work slower at first, because AI shortens code-writing but does not shorten the harder, team-level work of learning to specify tasks, verify quality, and build a shared practice — so the real productivity gain comes not from AI writing code faster but from the team developing a new, common way of working.
• LLMs Reward Expertise Sean Goedecke · 2026-09-12 source ↗ Reader 🖥️
  The single most important variable in getting valuable output from an LLM is the user's pre-existing domain expertise — not prompting technique — because expertise is what lets a person signal sophistication to the model, evaluate and redirect its output, and supply the human judgment the model itself cannot originate, which means the human, not the model, is increasingly the bottleneck.
• Article: When Spec-Driven Development Pays Off Nitin Garg · 2026-09-10 source ↗ Reader 🖥️
  Treating a specification as a versioned, approved governance baseline does not make code reviewers find more AI-generated bugs, but it does convert each finding from a hunch into an attributable claim tied to a named requirement and an accountable human decision-maker — a benefit real enough to justify its measurable time cost only on hard, multi-constraint work built by capable-but-imperfect models, not as a universal practice.
• Experience Mapping Matters More the Faster You Move Jim Kalbach · 2026-09-08 Reader 🖥️
  Because AI now lets every team execute fast and independently, the real risk facing organizations is uncoordinated speed, not slow speed — so experience maps matter more, not less, because they are one of the few tools that reliably turn scattered, siloed knowledge into a shared, in-the-room conversation that AI cannot produce on its own.
• How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar Ryan Peterman · 2026-09-07 Reader 🖥️
  Inside Anthropic, engineering is already organized around treating Claude as a thought partner wrapped in an increasingly sophisticated harness/loop rather than around hand-writing code, and this shift will diffuse into the rest of the industry — leaving the durable human value in judgment, taste, verification design, and self-directed visibility rather than in code production itself.
• From AI Code to Trusted Software: Harness Engineering in Practice Travis Frisinger · 2026-09-04 Reader 🖥️
  The bottleneck in AI-assisted software delivery has shifted from code generation to verification, so engineering effort should go into 'harness engineering': wiring an organization's standards into the repository itself (fail-closed gates, evidence attached to every change, cross-run observability) so the repository — not the model, and not a document nobody enforces — becomes the mechanism of trust, up to and including the repository taking on the shape of a governed mini-organization.
• The Conductor Developer Rachel Laycock (Thoughtworks CTO; martinfowler.com — Rachel's Ramblings) · 2026-07-31 source ↗ Reader 🖥️
  As AI has removed successive bottlenecks in coding, design, architecture and verification, the constraint that does not move downstream is human attention itself, so the developer's role is shifting from a programmer who protects flow to a conductor who orchestrates parallel AI agents — a shift the industry has not yet redesigned engineering careers or jobs to support.
• GitLab 19.2 Puts AI Agents to Work on the Security Backlog Matt Saunders · 2026-07-21 source ↗ Reader 🖥️
  GitLab 19.2 bets that adding governed AI agents to the security-and-review layer — with a human always making the final call — can close the gap between how much code AI now lets developers generate and how much security and review work humans can actually absorb, though the release's own headline evidence for that bet (a vendor-commissioned ROI study) is far thinner than the governance engineering built around it.
• Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture Stella Berhe, Stephan Bragner, Vikram Maran, Anand Jayaraman · 2026-07-14 source ↗ Reader 🖥️
  Because AI has decoupled writing code from understanding it, engineering organizations must run spec-anchored specification-driven development, test-driven development, and architectural fitness functions together as one verification system so that their combined artifacts form a versioned, queryable "context store" — making comprehension a lifecycle property of evolutionary architecture that both human reviewers and AI agents can draw on, rather than a pre-merge concern that AI-generated speed otherwise outruns.
• Addy Osmani’s Post Addy Osmani · 2026-07-11 source ↗ Reader 🖥️
  As coding agents make solving cheap and abundant, an engineer's durable career value shifts from being the fastest problem-solver to the 'ungradeable' meta-skills that have no answer key — selecting which problems matter, judging quality through earned taste, directing agents rather than doing the work, sprinting the hard last mile, and owning the outcome.
• Who cleans up after the vibe-coding party? Sam Learner · 2026-07-11 Reader 🖥️
  AI coding tools have made producing an open-source contribution nearly free while leaving the cost of reviewing, verifying and maintaining it entirely on human maintainers -- degrading the reputational and communal incentives that sustained volunteer contribution and pushing individual maintainers toward uncoordinated, defensive responses (ending bug bounties, banning AI submissions outright) in the absence of any systemic rebalancing of who does software's unglamorous, chronically undervalued maintenance work.
• Five studies that are changing how I think about AI in software engineering Engineering Enablement · 2026-07-10 Reader 🖥️
  Five methodologically different studies converge on one story: AI has compressed the upstream code-generation work of software engineering, shifting the binding constraint downstream to review, integration, verification, and shared understanding, while our tools, metrics, and team designs have not yet moved with it.
• Podcast: Formal Methods for Every Engineer in an AI-Powered Future Gabriela Moreira (guest); host Shane Hastie (InfoQ) · 2026-07-10 Reader 🖥️
  Formal methods are a practical tool for reasoning about the edge cases of complex distributed and concurrent systems, and because AI in 2026 collapses the historic barriers to writing specifications and the glue code that binds them to real implementations, the profession's enduring human work shifts to defining which system behaviours are correct — the judgment AI cannot take over.
• Presentation: The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation Itamar Friedman · 2026-07-08 source ↗ Reader 🖥️
  To break through the AI 'productivity ceiling' in software development you must stop pouring investment into faster code generation and redirect it toward verification and context — building an adaptive, quality-grounded multi-agent system with an arbiter to resolve agent disagreements, human-observable inter-agent communication, first-class governance, and continuous learning of what quality means for your organization.
• The "funhouse mirror": How AI reflects the hidden truths of your software pipeline Rachel Laycock (interviewed by The New Stack) · 2026-07-07 source ↗ Reader 🖥️
  AI is not a disruptor but an amplifier of your existing pipeline, so because writing code was never the bottleneck, its coding speed turns a velocity multiplier into a debt accelerator wherever software-delivery fundamentals, guardrails, and stewardship of newcomers are not already in place.
• Finding Comfort in the Uncertainty Annie Vella · 2026-07-07 source ↗ Reader 🖥️
  The most valuable takeaway from a gathering of leading software practitioners on AI's impact is that nobody has it figured out — and that this shared uncertainty, together with a convergent set of hard questions the field is only beginning to name, is itself the ground for progress and a source of comfort rather than alarm.
• How Leaders Can Use AI to Solve Real Business Problems Harvard Business Review · 2026-07-07 source ↗ Reader 🖥️
  Successful AI adoption is determined less by which model or vendor an organization chooses than by whether it first identifies a specific, well-understood business problem, hands ownership to domain experts who genuinely care about that problem, builds trust through explainability and honest communication, and resists the frontier labs' self-interested narrative that missing the AI 'wave' is existential.
• Ordinary Engineers, Not Heroic Inventors Tim O'Reilly · 2026-07-07 source ↗ Reader 🖥️
  Technological and economic leadership — for nations and companies alike — is won not by inventing or dominating the 'leading sector' of a new technology but by diffusing a general-purpose technology like AI more broadly and patiently than rivals across ordinary, unglamorous work, a slow organizational (not technical) process that depends on skill infrastructure and on incentives that reward the 'ordinary engineers' who actually do the diffusing.
• We've Stopped Arguing About Whether AI Changes Software Greg Herlein · 2026-07-07 source ↗ Reader 🖥️
  The debate over whether agentic AI transforms software engineering is settled; the transformation is a shift in the center of gravity of the work — from writing code to specifying, verifying, and curating knowledge.
• Agentic Code Review Addy Osmani (addyosmani.com) · 2026-07-06 source ↗ Reader 🖥️
  Because agents made writing code nearly free while understanding it stayed exactly as costly as ever, code review has become the binding constraint on shipping software — and since review must now reconstruct an intent that never existed in any human mind, the right amount of human review is not a fixed rule but a dial set by each change's blast radius.
• SWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. Oren Ellenbogen · 2026-07-06 Reader 🖥️
  As AI reshapes engineering, the decisive leadership work shifts to human judgment applied to fundamentals — reaffirming sound operating principles, justifying AI's now salary-scale cost, and demanding engineering rigor — because AI only amplifies (in magnitude, not direction) whatever practices, clarity, and dysfunction already exist.
• Why did Martin Fowler invite 60 engineers to a ski resort? Ivett Ördög · 2026-07-05 source ↗ Reader 🖥️
  The turn to AI-built software has reopened rather than resolved the foundational questions of the craft — should humans still read code, how do we know it works, does code quality still matter, and how do we manage newly-empowered citizen developers — and the author's connective throughline is an optimistic one: AI democratizes building while the disciplines that make code good for humans remain exactly the ones that make it good for AI.
• The 8 software engineering metrics AI broke Michael Hill · 2026-06-16 source ↗ Reader 🖥️
  Software engineering metrics were built on the assumption that human effort and output move in rough proportion, and AI has severed that link by making activity nearly free — so activity/volume proxies (deployment frequency, cycle time, PR and commit volume, lines of code, satisfaction, efficiency/flow, DevEx/DXI) now measure tool adoption rather than engineering quality, while only outcome-based measures (time to recover, escaped defect rate, delivered value) remain trustworthy, because they measure what happened rather than how much happened.
• Revised rules of engineering leadership. Will Larson (lethain.com) · 2026-06-15 Reader 🖥️
  In an AI-accelerated engineering organization, the scarce resource shifts from code production to judgment and decision-making: individual judgment matters more (because migrations one person can now drive alone have outsized blast radius), durable domain-owning teams matter more (because execution being cheap doesn't make deciding the right thing cheap), and the organization's capacity to make quick, durable, good decisions becomes the actual bottleneck on how much benefit it can realize from AI.
• The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering Addy Osmani, Shubham Saboo, Sokratis Kartakis · 2026-06-15 Reader 🖥️
  As AI increasingly handles code generation itself, what separates production-grade 'agentic engineering' from risky 'vibe coding' is not which AI tool a team uses but how deliberately it designs and maintains the harness, verification (tests + evals), and context around the model — so the discipline a team already has is what AI amplifies, for better or worse.
• AI isn't making developers more productive – it's making them busier Chris Stokel-Walker · 2026-06-11 source ↗ Reader 🖥️
  A large-scale study of 100,000+ GitHub developers reframes the AI-coding story as redistribution rather than acceleration: AI makes developers busier by ballooning code output, but net shipped value barely moves because fixed human review/integration capacity is the binding downstream constraint.
• Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard Fabrice Bernhard · 2026-06-06 Reader 🖥️
  The headline 17.3x speedup that AI async agents produce at the start of the software value stream collapses to a 1.3x increase in release frequency at the end of the stream — because human and organisational bottlenecks (unclear business needs, organisational dependencies) dominate end-to-end throughput; therefore AI creates real value only when it is targeted at the actual bottleneck, and identifying that bottleneck is what Lean Tech is for.
• What OpenAI and Anthropic Think Happens Next With AI AI Daily Brief (Nathan Labenz, beehiiv newsletter) · 2026-06-05 Reader 🖥️
  The leading AI labs and the US federal government are entering an active negotiation over the political settlement of AI — equity stakes, governance frameworks, and pause discourse are three faces of the same bargaining process, premised on a shared (but largely unargued) belief that recursive self-improvement is already underway.
• Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools Mert Demirer, Leon Musolff, Liyuan Yang · 2026-05-27 source ↗ Reader 🖥️
  Across three successive generations of AI coding tools, large task-level productivity gains (up to 180% more commits) attenuate sharply as they propagate up the software production hierarchy to final shipped output (only 20-30% more releases), because AI and downstream human effort are strong complements rather than substitutes (estimated elasticity of substitution of about 0.25) — so increasing automation of code-writing alone yields only bounded gains in what actually reaches users, a pattern that also shows up in aggregate GitHub activity and across four app marketplaces, where new app releases have risen but end-user usage has not.
• Using AI to write better code more slowly Nolan Lawson (Read the Tea Leaves) · 2026-05-25 source ↗ Reader 🖥️
  LLMs are flexible enough to produce either fast, unvetted slop or slower, carefully reviewed and understood code, and deliberately choosing the latter — running multiple different models to hunt for bugs, personally validating and triaging what they find, and refusing to ship a PR you don't fully understand — is a better way to use AI for programming, even without a velocity payoff.
• The Orchestration Tax is You AddyOsmani.com · 2026-05-25 Reader 🖥️
  Because each developer is a single, non-parallelizable serial processor whose attention is the binding constraint on what agent-generated code can actually be merged, the only real fix for the 'orchestration tax' is to deliberately architect your own attention the way you architect any concurrent system — sizing the agent fleet to your review rate, sorting work by judgement-content, batching reviews, offloading verification to machines, and protecting your serial time.
• Reinventing team flow within AI uncertainty Avanscoperta Blog · 2026-05-14 source ↗ Reader 🖥️
  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.
• The AI paradox: More automation, more humans, more work | Dan Shipper Lenny Rachitsky (host); Dan Shipper (guest, CEO Every) · 2026-05 Reader 🖥️
  Despite radically improving model capabilities, the agentic era will paradoxically generate more work for more humans — because every agent needs a human gardener, SaaS persists (with users bringing their own tokens via Codex/Claude Code), and progress merely commoditizes yesterday's competence and pushes humans further up the value chain to define what is worth doing next.
• Henrik Kniberg's Post Henrik Kniberg · 2026-04-20 Reader 🖥️
  A system of specialized AI agents collaborating with human engineers — handling not just coding but backlog management, release management, and stakeholder requests — enables daily releases and lets humans focus on higher-level design, architecture, and UX.
• Presentation: Leadership in AI-Assisted Engineering Justin Reock · 2026-04-20 Reader 🖥️
  Engineering leaders who frame AI as a throughput multiplier rather than a cost-cutting tool — and back that framing with clear policies, learning time, psychological safety, oppositional measurement, and SDLC-wide integration — are the ones whose organizations see positive ROI from AI adoption, while top-down utilization mandates reliably backfire.
• The Organization Is the Bottleneck Sarah Wells · 2026-04-20 Reader 🖥️
  AI coding agents amplify an organization's existing engineering maturity rather than substituting for it; the same foundations that made microservices succeed — guardrails, deployment pipelines, engineering enablement — are prerequisites for succeeding with AI agents, so the real bottleneck is organizational, not technological.
• The keyboard was never the bottleneck Mike Amundsen · 2026-04-16 source ↗ Reader 🖥️
  Generative AI commoditizes the lowest levels of programming work — producing code for known problems under fixed assumptions — but the harder, higher-level challenges of designing systems that survive change remain untouched and are now more visibly important.
• Elizabeth Ayer on Mastodon — "The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know" Elizabeth Ayer · 2026-04-10 Reader 🖥️
  The absence of visible improvement in software quality and innovation, despite the rise of AI code generation tools, demonstrates that code creation was never the bottleneck for delivering software value.
• TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier John Cutler · 2026-04-09 source ↗ Reader 🖥️
  How teams should operate is determined by the mix of demand they face and how they shape that demand — and AI will not fix your funnel but will reveal and amplify whatever version of it you are already running, accelerating both functional and dysfunctional patterns.
• Measuring AI impact, assessing readiness, and new data trends DX · 2026-04-03 source ↗ Reader 🖥️
  Engineering leaders should move beyond naive AI adoption metrics toward longitudinal measurement that distinguishes amplification (making humans more productive) from augmentation (agents as additional capacity), while recognizing that the real bottlenecks to AI ROI are not code generation but developer experience, human judgment, and organizational readiness -- the same problems that preceded AI.
• No, AI Did Not Kill Agile Andrea Laforgia · 2026-04-00 source ↗ Reader 🖥️
  AI accelerates building software but does not reduce the epistemic uncertainty about what to build, so the iterative learning loop at the core of Agile becomes more important, not less, when coding is nearly free.
• Head of Claude Code: What happens after coding is solved | Boris Cherny Lenny's Podcast · 2026-02-19 source ↗ Reader 🖥️
  A year after Claude Code's launch, coding itself is — in Boris Cherny's own, carefully qualified words — 'largely solved' for the kind of programming he does, which has pushed both the bottleneck and the interesting work for Anthropic's Claude Code team upstream: from writing code to reviewing/prioritizing it, from engineering as a distinct discipline to a convergence of engineering/product/design, and from building for today's model to deliberately betting on, and designing for, the model that will exist six months from now.
• Fragments: February 18 Martin Fowler · 2026-02-18 source ↗ Reader 🖥️
  AI-assisted software development is best understood as an amplifier of a team's existing practices rather than a disruptive break, so the field's real work is rebuilding the human-era practices that are predictably breaking—through emerging disciplines like the supervisory middle loop, risk tiering, TDD-as-prompt-engineering, and platform 'bullet trains'—amid far more shared uncertainty than settled answers.
• The third golden age of software engineering – thanks to AI, with Grady Booch The Pragmatic Engineer (Gergely Orosz, host; Grady Booch, guest) · 2026-02-04 Reader 🖥️
  Software engineering is entering a historically recurring pattern — a rise in the dominant level of abstraction — rather than being automated out of existence, because 'software engineering' has always meant balancing human, economic, legal, and ethical forces (not just writing code), and today's AI tools only automate the coding layer, which is itself bounded by the already-seen patterns they were trained on.
• 9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-01-19 source ↗ Reader 🖥️
  The promised productivity gains from AI in software development will not materialize at the organizational level unless teams deliberately slow down — investing in psychological safety, structured reflection, and joint experimentation — because software development is fundamentally a learning process and AI threatens the learning even as it accelerates the output.
• Automatisert KI-koding vil endre alt ("Automated AI coding will change everything") Henning Meese · 2026-01-09 source ↗ Reader 🖥️
  AI's eventual takeover of most coding work is near-certain and the industry is already betting on it ('all in'), but the specific timeline keeps sliding later than predicted — illustrated by LessWrong's own 'superhuman coder' threshold estimate being pushed back 3.5 to 5 years in a single revision — so human developers are not about to become unemployed en masse in the near term, even though what role they will play once that threshold does arrive remains genuinely open.
• When AI Writes Almost All Code, What Happens To Software Engineering? Gergely Orosz · 2026-01-06 Reader 🖥️
  As AI crosses a real capability threshold and starts writing the large majority of code for many developers and teams, the part of software engineering that was always about judgment, verification, architecture, and accountability — not typing syntax — becomes more valuable, not less, while the raw ability to write code in a given language stops being a differentiator at all.
• Thomas Nys' Post Thomas Nys · 2025-12 Reader 🖥️
  Organizations can't get AI initiatives to scale because a large, usually invisible share of engineering capacity (the author cites 20-40% industry estimates) is already consumed maintaining accumulated technical-debt shortcuts, so AI pilots stall not for lack of model quality or team size but because they're being layered on fragile, duct-taped foundations that were never fixed first.
• The Future of Work by Henrik Kniberg Jfokus · 2025-02-09 source ↗ Reader 🖥️
  AI agents are rapidly maturing from autocomplete tools into autonomous colleagues capable of researching, coding, communicating, and even improving their own platform via human-reviewed pull requests — shifting the developer's job from writing code to directing, evaluating, and choosing where to spend increasingly scarce attention.
• The End of Programming as We Know It Tim O'Reilly · 2025-02-04 source ↗ Reader 🖥️
  AI will not end programming or cause mass programmer unemployment; it is the latest in a long series of abstraction shifts that each redefined what 'programming' means and historically increased, not decreased, the number of programmers and the scope of what gets built — provided organizations and individuals invest in the 'learning by doing' needed to convert raw AI capability into deployed productivity.
• How AI coding companions will change the way developers work Dr Werner Vogels (interviewing Doug Seven and Sandeep Pokkunuri, Amazon CodeWhisperer) · 2023-04-27 source ↗ Reader 🖥️
  AI coding companions (as embodied by Amazon CodeWhisperer in 2023) remove the 'undifferentiated heavy lifting' of programming — boilerplate, documentation lookup, unfamiliar-API scaffolding — without replacing developer expertise or control, returning developers' time to the creative, higher-value parts of the job (problem framing, design, customer value) while keeping them fully responsible for reviewing, verifying, and shipping whatever the tool suggests.
• Papers on the UX of AI programming assistants Austin Z. Henley · 2023-02-20 source ↗ Reader 🖥️
  Across the first wave of 2022-23 HCI/SE studies on AI programming assistants (chiefly GitHub Copilot and OpenAI Codex), the user-experience bottleneck is not the AI's ability to generate plausible code but the human's ability to discover, understand, trust, and recover from what it generates — shifting the programmer's core activity from writing code toward assessing it.
• CannotMeasureProductivity Martin Fowler · 2003-08-29 Reader 🖥️
  Software productivity cannot be measured because its true output — delivered business value — cannot be measured, so every popular proxy (lines of code, function points, feature counts, project 'success' rates) either measures the wrong thing or measures it too late to be useful.

Propositions touching this concept (47)

By publication month, oldest first (extraction month when no publication date is known).

2024-10

• explicitTransformational leadership (vision, inspirational communication, intellectual stimulation, supportive leadership, personal recognition) raises productivity (+9% per 25% increase), job satisfaction, team/product/organizational performance, and reduces burnout, but functions only as an enabler of technical and product practices, not as a standalone driver of performance — it works through delegating authority, supplying metrics/business intelligence, and aligning incentives to value delivery over feature delivery.
  2024_final_dora_report · p8

2026-02

• explicitBecause writing code was never the delivery bottleneck, faster AI code generation alone does not improve outcomes unless upstream delivery practices are already in place.
  Fragments: February 18 · p4
• explicitdevelopedChasing determinism is a category error — the right goal is value delivery with sufficient control, not deterministic LLMs.
  11) AI-spesial med Vilde Opsal og Anders Sveen · p2

2026-04

• explicitestablishedCode generation was never the real bottleneck in software development; code review, planning, and organizational readiness are the actual constraints.
  Measuring AI impact, assessing readiness, and new data trends · p1
• explicitThere is no flourishing of value delivery, new product categories, or better satisfaction of needs.
  Elizabeth Ayer on Mastodon — "The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know" · p2
• explicitdevelopedCode creation is not the bottleneck for software quality or innovation.
  Elizabeth Ayer on Mastodon — "The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know" · p4
• implicitIf code creation were the bottleneck, AI-assisted code generation would have produced visible improvements in software outcomes.
  Elizabeth Ayer on Mastodon — "The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know" · p5
• implicitcorroboratedThe real bottleneck lies in activities upstream or downstream of code creation — understanding needs, design, integration, maintenance, organizational alignment, or similar.
  Elizabeth Ayer on Mastodon — "The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know" · p6
• explicitThe best technology leaders are never far from the keyboard, and the best architects are never far from the people.
  14) Øystein Ulseth pendler mellom å lede og levere · p1
• implicitcontestedCoding is no longer the primary bottleneck in product development when AI agents are used effectively
  Henrik Kniberg's Post · p1
• explicitcorroboratedCode generation is not the bottleneck in most engineering organizations; interruptions, context switching, and meetings consume far more time
  Presentation: Leadership in AI-Assisted Engineering · p6
• explicitAgile was created to address the knowledge problem, not the speed problem.
  No, AI Did Not Kill Agile · p2
• explicitThe dominant mental model of product development treats engineering as the bottleneck, and the entire system organizes around feeding that constraint efficiently — this model is the root cause of most organizational dysfunction
  TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier · p3
• explicitIf you keep the engineering-as-bottleneck mental model, AI will accelerate all existing dysfunctions: more ideas generated, more artifacts produced, more negotiation, more overload — all faster
  TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier · p4
• explicitThe alternative mental model ends the funnel at meaningful change for customers, not at feeding a team — and in this model, AI accelerates learning rather than feeding a bottleneck
  TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier · p5
• implicitThe current excitement about AI coding speed is misleading because it focuses on the wrong metric (code production rather than value delivery).
  The Organization Is the Bottleneck · p14

2026-05

• 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.
  Reinventing team flow within AI uncertainty · p8
• 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.
  Reinventing team flow within AI uncertainty · p9
• explicitThe locus of the human bottleneck is itself moving upward as AI capability advances: autocomplete intervenes only at the code-writing layer, while sync and async agents intervene at progressively higher layers (files, commits, and — for async agents specifically — pull-request creation itself), which the authors argue could narrow the task-level-to-output gap over time rather than leave it fixed.
  Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools · p8
• explicitThe paper cannot distinguish, for the marketplace-usage result, between the marginal AI-enabled apps being genuinely lower quality versus a separate consumer-side bottleneck (discovery, attention, adoption lag) capping usage regardless of quality.
  Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools · p10
• explicitAutomation is a lie: every automated workflow generates net new human work above it (supervision, context-keeping, judgment calls, system design).
  The AI paradox: More automation, more humans, more work | Dan Shipper · p3
• implicitestablishedThe hidden ('implicit') premise underwriting Shipper's whole argument: human attention is the bottleneck on agentic productivity, and that bottleneck does not relax as models improve because each capability gain opens a new frontier requiring new attention.
  The AI paradox: More automation, more humans, more work | Dan Shipper · p18
• explicitOptimizing the non-bottleneck part of a pipeline does not increase throughput; it only grows the queue in front of the bottleneck.
  The Orchestration Tax is You · p5
• explicitThe bottleneck is structural, not motivational; effort, discipline, and grinding cannot move it.
  The Orchestration Tax is You · p16
• explicitcorroboratedIf a system is not designed around the human attention bottleneck, it will route around it by silently lowering standards.
  The Orchestration Tax is You · p20

2026-06

• explicitdevelopedThe bottleneck extends to end users: since mid-2025 new app releases spiked moderately across the Apple App Store and Google Play while total app usage stayed flat, so a growing share of AI-assisted apps attracts no meaningful audience — more software shipped does not equal more value or discovery.
  AI isn't making developers more productive – it's making them busier · p6
• explicitWhere AI does not address the bottleneck, faster code writing will not have a significant impact on delivered value.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard · p5
• explicitAI creates real value only when it accelerates the bottleneck.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard · p8
• implicitcorroboratedLegacy modernisation IS a real bottleneck for many software organisations.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard · p10
• implicitcorroboratedMost current AI coding adoption is targeted at the wrong place in the value stream — at code production, not at the actual bottleneck.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard · p11
• explicitThe human role in software engineering is evolving, not diminishing: the bottleneck and the valuable skill shift from implementation to specification, evaluation, architectural judgment, and review, so the most valuable engineers in coming years will be those who can direct agents well rather than those who write the most code.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p16

2026-07

• explicitcorroboratedBecause writing code was never the bottleneck, AI's speed at writing code turns a velocity multiplier into a debt accelerator wherever traditional software-delivery best practices are not already in place.
  The "funhouse mirror": How AI reflects the hidden truths of your software pipeline · p2
• explicitcorroboratedAI coding assistants have increased code and PR volume to the point that human review, compliance checks, and release validation — not code creation — are now the binding constraint on software delivery speed.
  AWS Expands DevOps Agent with AI-Powered Release Management to Validate Code Before Production · p2
• explicitIn some organisations the binding constraint is no longer engineering capacity but downstream absorption — slow decisions, organisational dependencies, and limited market appetite ('humanity is not ready for this much software') — so decision fatigue, not engineering throughput, is becoming the real bottleneck.
  Finding Comfort in the Uncertainty · p4
• implicitThe downstream bottleneck is framed as a defect to be engineered away with new tools, metrics, and team designs, rather than as a healthy rate-limit that protects quality and understanding.
  Five studies that are changing how I think about AI in software engineering · p15
• explicitGitLab frames the 19.2 release as a response to what it calls the AI paradox: AI-assisted coding creates a faster stream of code changes than security and review processes can absorb, moving the bottleneck downstream rather than eliminating it.
  GitLab 19.2 Puts AI Agents to Work on the Security Backlog · p1
• implicitShipping dependency remediation, logic-flaw review, terminal agents and custom YAML-defined flows together signals GitLab widening what a 'coding agent' does from generating code to running the full downstream chain of review, security and workflow orchestration — competing on the review/security bottleneck itself, not just on authoring speed.
  GitLab 19.2 Puts AI Agents to Work on the Security Backlog · p10
• explicitdevelopedAs AI got better at coding, the bottleneck in software delivery moved sequentially through the SDLC: from coding, to design and specification, to architecture, to verification.
  The Conductor Developer · p1
• explicitAI did not change what great software looks like; it changed what is scarce. Human attention is now the bottleneck, and unlike the prior stages, it does not migrate further downstream.
  The Conductor Developer · p2
• explicit⚡ disputed & corroboratedThere is a real ceiling on how many AI agents one person can orchestrate in parallel — engineers report running eight, ten, or twelve — beyond which the orchestrating human, not the agents, becomes the bottleneck.
  The Conductor Developer · p5
• explicitestablishedAI code generation roughly triples code output while producing about the same rate of defects per line, so it multiplies total issues and merely relocates the bottleneck from writing to reviewing/verifying — showing up as 'more code, not more end-to-end velocity'.
  Presentation: The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation · p2
• explicitKnowledge — especially the tacit, unwritten 'why' behind past decisions — is the real scarce bottleneck, not code.
  We've Stopped Arguing About Whether AI Changes Software · p5

2026-09

• explicitestablishedThe bottleneck in AI-assisted software delivery has shifted from code generation to verification: an agent can produce a plausible change faster than a team can decide whether to trust it.
  From AI Code to Trusted Software: Harness Engineering in Practice · p4
• explicitA sufficiently well-specified spec lets Claude execute a task close to end-to-end, but most tickets are underspecified in practice, so the real bottleneck has shifted from writing code to discovering what you actually want.
  How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar · p8
• explicitVoice interfaces are unpopular because implementations have been bad (citing Siri and Alexa), not because people dislike voice as an interaction medium; a well-engineered voice interface could become a more frequent input method than the keyboard or touchscreen.
  Generative AI in the Real World: Local Voice AI with Pete Warden · p1
• explicitGitLab's June 2026 research found review and validation are the current bottleneck in AI-assisted development, and governance typically arrives only after code creation — after the risk has already been accepted and ownership already lost.
  Own the Outer Loop · p10
• explicitThe bottleneck in AI-assisted software delivery has moved from writing code to verifying it, which reframes the central problem as governance — accountability, divergence detection, and the human/model split of oversight labor — rather than a model-capability problem.
  Article: When Spec-Driven Development Pays Off · p1

Tensions

Open gaps (77)

• illogicalThe article's own framing is internally inconsistent about scope: the intro promises 'ten metrics that are breaking down,' the SPACE section is introduced as covering 'a couple of metrics' but actually covers three, and the title promises '8' broken metrics — which does match the count of metrics explicitly presented as broken (3 DORA + 3 SPACE + 2 standalone), but only by excluding the 3 counter-example metrics from the 'ten' the intro promised. The total metrics actually discussed is 11, not 10, and 'a couple' undercounts by one. This suggests the taxonomy was fitted to a round headline number rather than derived from a principled classification.
  The 8 software engineering metrics AI broke — read next: Compare against the live leaddev.com page for possible post-publication editing (the mismatch is exactly the kind an editor introduces when trimming or adding an example late); no corpus cross-reference needed.
• incompleteThis is a 1-minute LinkedIn teaser for deeper SINTEF empirical research; no methodology, sample size, or data are given for either the specification/verification time-shift claim or the individual-to-shared-practice claim. The post only links onward to a kode24 article and gestures at a JavaZone talk.
  Nils Brede Moe's Post — read next: Read the linked kode24 article (https://lnkd.in/eKhzYCCt) covering the JavaZone talk, and cross-reference the fuller SINTEF findings already captured in this corpus at extract-heis-09-nils-brede-moe-ai-paradokset-autonomi-laringskultur.json — same researcher, same 'AI-paradokset' framing, with sourced propositions, arguments, and narratives (including the 9-of-10-vs-95% MIT figure and the car-factory study) that this short post compresses away.
• incompleteLabenz does not name the structural argument — that equity stakes, lab policy papers, and pause discourse are the same negotiation — even though his juxtaposition implies it. A senior leader reading this needs that frame surfaced.
  What OpenAI and Anthropic Think Happens Next With AI — read next: Read the actual NOTUS Jeff Stein piece, the Anthropic 'When AI Builds Itself' paper, and OpenAI's 'Democratic Governance of Frontier AI' against each other; pair with prior US precedents for government equity (TARP, Operation Warp Speed, In-Q-Tel) to characterize the proposed regime
• incompleteAnthropic's exclusion from the equity-stake discussions is mentioned but not interpreted. Why are they out? Strategic refusal? Political disfavor? Different cap-table structure (B-corp, recent S-1)?
  What OpenAI and Anthropic Think Happens Next With AI — read next: Look into Anthropic's S-1 governance terms; check whether the public-benefit structure complicates federal equity; read coverage of Amodei's White House relationships
• incompleteThe equity-vs-tax debate is presented as bedfellows-style political commentary, but the deeper question — whether state equity creates regulatory capture or breaks the incumbents' moat — is not analyzed.
  What OpenAI and Anthropic Think Happens Next With AI — read next: Read Peter Harrell's thread on taxing vs. owning AI companies (linked); compare with literature on sovereign wealth funds and state-owned enterprise governance failures
• incompleteThe Obernolte-Trahan bill is described but its preemption clause is not analyzed in light of the state-level laws it would override. What concretely changes in California, New York, Massachusetts AI law if the bill passes?
  What OpenAI and Anthropic Think Happens Next With AI — read next: Pull the bill text; compare against SB 1047 successors, NY AI bias law, MA pending bills
• incompleteLabenz brackets ChatGPT 'Dreaming' as a separate headline but does not connect it to the main story. A persistent-memory ChatGPT changes both the labor-substitution calculus (Anthropic's scenario two) and the surveillance/governance attack surface — relevant to both papers.
  What OpenAI and Anthropic Think Happens Next With AI — read next: Look at how Anthropic's paper treats persistent agents; read Mark Kreishman's thread on persistent agents linked in the headline
• uninformedThe piece does not engage with comparable governance moves in the EU AI Act, UK AISI evolution, or China's algorithm registry — all relevant to whether 'reverse federalism' is novel or imitative.
  What OpenAI and Anthropic Think Happens Next With AI — read next: Compare OpenAI's blueprint to the EU AI Act's general-purpose AI obligations and the UK AISI's recent remit changes
• 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.
  Reinventing team flow within AI uncertainty — 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.
• incompleteThe plugin-standardisation political economy is not discussed. 'The best practices of one team become the default for every team' sounds frictionless but ignores the contested-knowledge problem: whose sales process becomes the plugin, who reviews plugin updates, what happens when business units disagree, how plugin versions are deprecated. Cutler-style organisational reality is absent. The document's frame is 'institutional knowledge becomes infrastructure'; the real question is 'whose institutional knowledge'.
  Building AI Agents For The Enterprise — read next: Cutler on overload and institutional dynamics; Heis ep 11 AI-special on enterprise AI politics; anything on internal developer-platform governance (which is structurally similar — plugin marketplaces and IDP marketplaces share dynamics).
• uninformedWriting in 2003, Fowler could not have anticipated generative AI's effect on code volume: AI-assisted development now produces measurably more code per unit of human effort (with reported ~20% larger AI-generated code than human-written code for equivalent tasks), which would further inflate LOC-based studies and make his critique more urgent, not less.
  CannotMeasureProductivity — read next: Directly extended by this corpus's AI-era engineering-metrics critiques (extract-8-engineering-metrics-ai-broke, extract-tbm-437-tokens-hours-points-proxies), which independently rediscover that easily-measured, easily-inflated proxies (LOC, tokens, story points, PR counts) systematically substitute for the still-unmeasured true output.
• incompleteThe Amazon outage is presented as an outcome of the exact context gap this article diagnoses, but the article's own cited source (CNBC) attributes the outage to "changes merged without proper review" — a review-gate failure — not to a documented absence of persisted intent, behavior, or conformance records specifically. The causal attribution to the context gap, versus a more generic review-diligence lapse, is asserted rather than demonstrated from the available reporting.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture — read next: Follow further Amazon incident reporting or post-mortems, if published, to see whether investigators identified a missing intent/behavior/conformance record specifically, or a simpler story of a skipped approval step that a context store would not by itself have prevented.
• empiricalThe 10-15% throughput gain figure is stated without methodology detail. How were confounders controlled? What is the variance across organizations? The meta-longitudinal study is referenced as forthcoming but not yet available.
  Measuring AI impact, assessing readiness, and new data trends — read next: Look for DX's published meta-longitudinal study and methodology; compare with academic studies on AI-assisted development.
• conceptualThe amplification/augmentation framework measures output volume (throughput, human-equivalent hours) but does not address output quality, defect rates, or long-term maintainability of AI-generated code.
  Measuring AI impact, assessing readiness, and new data trends — read next: Investigate literature on technical debt and defect rates in AI-assisted codebases; check whether DX's framework has quality dimensions not discussed here.
• structuralThe discussion treats AI readiness as a developer-experience problem but does not address organizational incentive structures -- e.g., why documentation and CI remain chronically underinvested despite being acknowledged as important for decades.
  Measuring AI impact, assessing readiness, and new data trends — read next: Organizational economics of developer tooling investment; why 'table stakes' remain unmet.
• perspectivalThe entire conversation is from the perspective of engineering leaders at large, well-resourced companies (Twilio, Booking.com, Block). The experience of small teams, non-tech-native companies, or individual contributors is absent.
  Measuring AI impact, assessing readiness, and new data trends — read next: Seek practitioner reports from smaller organizations and IC perspectives on AI adoption.
• empirical challengeThe claim that software quality is declining is stated as self-evident but not evidenced. Quality decline in consumer software (enshittification) may coexist with genuine improvement in developer tooling, infrastructure, and specialized domains.
  Elizabeth Ayer on Mastodon — "The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know" — read next: Compare with Cory Doctorow's enshittification thesis and Ben Thompson's aggregation theory for structural explanations of why consumer-facing software quality declines even as technical capability increases.
• selection biasThe post does not address survivorship bias: AI-augmented software improvements may be happening in less visible domains (internal tools, infrastructure, niche products) while the most visible consumer software degrades for unrelated economic reasons.
  Elizabeth Ayer on Mastodon — "The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know" — read next: Look for data on AI-assisted development outcomes in enterprise/internal tooling vs. consumer products.
• incompleteThe post claims release frequency is 'the only number that matters' but doesn't argue why — and Lean's own toolkit would suggest cycle time, quality, and customer outcomes belong alongside release frequency. The reduction of 'real value' to a single metric is rhetorically clean but theoretically thin.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: DORA's four-key-metrics literature; Reinertsen on cost of delay; Steve Yegge / Gene Kim on quality-vs-speed under AI; Beck's recent newsletters on what to measure when AI changes throughput.
• incompleteTheodo's consultancy context is a selection bias engine that Bernhard doesn't address. Consultants typically work on greenfield engagements or on well-bounded modernisation projects where business needs are pre-scoped by a client brief. The very bottlenecks Bernhard names (unclear business needs, organisational dependencies) are precisely the bottlenecks consultancy contracts pre-filter for. Whether the 3x result transfers to in-house teams operating in the muck is the load-bearing open question.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Compare to Anthropic enterprise PDF findings on in-house deployments; Cutler on internal-team organisational drag; case studies of in-house legacy modernisation at scale (e.g. NAV, Entur reports already in corpus).
• incompleteLegacy modernisation is presented as 'a' bottleneck-aligned use case but Bernhard doesn't enumerate what makes it bottleneck-aligned and what other use cases would qualify. A more complete argument would name the properties (translation-heavy, human-comprehension-bound, well-specified target, measurable acceptance criteria) that make AI bottleneck-effective.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Mary Poppendieck on Lean software value-stream mapping; Theory-of-Constraints applied software literature; specific case studies of AI-driven greenfield vs migration projects.
• incompleteThe post takes the MIT/UPenn paper as authoritative but doesn't disclose the dataset, sample, or timeframe. Async agents in 2024-25 (the likely study window) are not the same product category as 2026 long-running harnesses — the 1.3x number may understate what later-generation tooling can do at the release-frequency end, OR may be optimistic if the study captured the early enthusiasm phase.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: The Demirer/Musolff/Yang paper itself; recent METR / RCT-style AI productivity studies; Pocock workshop on what changes with harness-level tooling.
• incompleteThe 'we generate better learnings' claim is asserted without describing Theodo's actual learning mechanisms — internal write-ups, retros, replication across client engagements, etc. For an audience interested in adopting the approach, the learning infrastructure is the load-bearing part.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Theodo's engineering blog (theodo.com / padok.fr); Mike Rother's Toyota Kata on learning routines; A3 thinking literature.
• uninformedThe post predates / doesn't engage with the harness-engineering thread that this corpus has been tracking (Anthropic harness paper, Pocock workshop, Cloudflare Mythos). Harness-level tooling specifically aims at the integration between code generation and release — exactly the gap Bernhard names. Whether harness engineering is a third path (between 'roll out Copilot' and 'consultancy-led bottleneck targeting') is an obvious adjacency.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Pocock workshop extraction; Anthropic harness design paper; Cloudflare Mythos extraction; the Anthropic enterprise PDF extraction.
• incomplete'Releases shipped' (~+30%) is used as the terminal proxy for delivered value, but Demirer's own chain extends to 'software consumed by users', and the article stops at releases without asking whether more releases equal more value.
  Five studies that are changing how I think about AI in software engineering — read next: Read extract-elizabeth-ayer-ai-value-delivery, which argues there is no observed flourishing of value delivery despite faster code — a direct test of whether release throughput tracks value.
• incompleteThe boundary of 'essential human work' is asserted but under-drawn. Moreira says product people can safely leave AI to build software 'when safety and big concerns' are absent, while complex concurrent systems still need technical judgment — but she gives no criteria for classifying which systems warrant formal specification versus which can be left to unspecified AI generation. Without that decision procedure, 'defining correct behaviour is essential human work' cannot be operationalised: a team cannot tell where the line falls for their system.
  Podcast: Formal Methods for Every Engineer in an AI-Powered Future — read next: Read alongside risk-tiering / not-all-software-is-equal material — the autonomy-boundary and classification gap in extract-ai-funhouse-mirror-velocity-debt#g4, and the risk-tiering concept — which frame exactly the 'which changes get which rigor' judgment this talk leaves implicit.
• incompleteNo data is given on whether Dependency Scanning Auto-Remediation or Security Review Flow actually reduce the review/security backlog at scale — only a single scripted demo (five MRs, one fixed) is shown; there is no adoption count, no false-positive rate for Security Review Flow's findings, and no before/after measurement of review or remediation throughput.
  GitLab 19.2 Puts AI Agents to Work on the Security Backlog — read next: Watch for a follow-up InfoQ piece or GitLab case study with concrete throughput/adoption numbers, and compare against independently-reported figures on AI-driven PR/review volume from other vendors (e.g. the AWS DevOps agent release coverage) to see if the pattern of 'announcement without evidence' recurs.
• incompleteThe framing of public-sector dysfunction as 'budget growth instead of value delivery' is a strong claim presented anecdotally. The implicit comparison to private sector ('we are on the same team') under-acknowledges that private-sector alignment is also engineered and partial — shareholder vs. employee interests, sales vs. engineering, short- vs. long-term.
  3) Christin Gorman leder uten tittel — read next: Read Nils Brede Moe (Heis ep 9) on the AI-paradox and learning culture; read public-sector reform literature (NAV's 'optimizing for fast flow' is on the user's list). Also read industrial-organization work on aligned vs. misaligned incentives across sectors.
• incompleteThe MIT '95% of AI projects show no return' figure is asserted as foundational but never sourced, methodologically interrogated, or compared to base rates for non-AI IT projects (where failure rates are also famously high). The framing relies heavily on this number.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — read next: Pursue the MIT study directly (likely the MIT NANDA / Sloan AI 'GenAI Divide' report from 2025) and compare against Standish CHAOS-style baselines for IT project failure to establish whether AI is failing more than other IT initiatives, or merely the same.
• incompleteThe framing is almost entirely about knowledge-work software teams in professional services / large org settings. The argument is silent on: solo developers, small startups without team infrastructure, contracting/outsourcing relationships, non-developer roles where AI is also disrupting work, and contexts where 'team' is not the unit of production.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — read next: Read Tabarrok / Acemoglu on AI and labor markets in non-team-shaped work; and Beane's Skill Code on apprenticeship in mixed expert/AI environments outside software, to test how portable Brede Moe's prescriptions are.
• incompleteThe conversation treats AI tooling as relatively homogeneous — Copilot, ChatGPT, Cursor, Claude Code are mentioned as a cluster. But the team-level practices likely differ between chat-based assistants, autonomous agents, and in-IDE pair tools. Brede Moe gestures at this with 'augmented teams' but doesn't yet differentiate.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — read next: Empirical studies of differential effects by tool class — DORA's 2025 AI findings, Microsoft / GitHub research on Copilot effects, ongoing studies of agentic coding tools.
• incompleteThe car-factory study (cited as 15-20 years old) is the central empirical anchor for the slow-down-to-speed-up claim, but it is cited without source — the listener cannot evaluate the comparison. Similarly the 9-of-10 figure.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — read next: Source the original study; even if accurate, ask whether software development resembles auto-manufacturing learning curves enough for the lesson to transfer.
• incompleteThe argument assumes that team autonomy and team learning are the right units of analysis. It does not engage with alternative views — e.g. that AI might shift the unit back to the individual contractor or fragment work into smaller, more decomposable tasks, in which case the team-level prescription is the wrong response to the wrong question.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — read next: Read agentic-work literature (Eric Ries, Naval-style 'agency leverage' arguments, Yegge's vibe-coding manifesto) for the opposing view.
• incompleteThe conversation explicitly opens but does not close the team-augmentation question — what does multi-agent + multi-human team coordination look like in practice? Vilde admits FINN/Vend has not cracked it.
  11) AI-spesial med Vilde Opsal og Anders Sveen — read next: Nils Brede Moe (Heis ep 9) on AI paradox + autonomy + learning culture; Pocock workshop on harness design for long-running agent teams; emerging literature on multi-agent code review and orchestration.
• incompleteThe list has no stated inclusion criteria, methodology, or search strategy — it is simply papers the author personally came across, including one he co-authored (the IntelliCode study), with no discussion of how representative the dozen papers are of the broader 2022-23 literature or what populations/tools are missing (longitudinal studies, non-Copilot tools, non-English-speaking programmer populations).
  Papers on the UX of AI programming assistants — read next: A later systematic review or meta-analysis of AI-coding-assistant UX studies, and the corpus's own later empirical pieces for how these early qualitative findings held up once tooling matured.
• incompleteThe claim that naming/style conventions matter less for maintainability doesn't address the scenario where a human must debug an unfamiliar, AI-written production incident under time pressure without Claude's help — arguably the exact moment readability matters most, and in some tension with the same conversation's admission that Anthropic's own incident rate has risen with velocity.
  How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar — read next: extract-boeckeler-maintainability-sensors-coding-agents and extract-code-maintainability-plummets-ai-coding-era on maintainability decay under AI-driven code velocity.
• uninformedNone of the conversation's strong quantitative-sounding claims (the autonomous-change percentage being unmeasured by design, the incident-rate increase, '100 times more testing code,' engineers 'not in the IDE for six months') are backed by cited internal eval or metrics data — they are informal, first-person estimates, despite Anthropic's own emphasis elsewhere in the corpus on evals as the standard of truth for claims about model/practice performance.
  How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar — read next: Any published Anthropic internal engineering metrics or eval results on AI-assisted development adoption and outcomes, to check these estimates against measured data.
• incompleteThe discussion of 'coding is largely solved' (failure rates for software projects dropping) sits uneasily next to the later admission that Anthropic's own incident rate has risen as a byproduct of higher velocity — the conversation doesn't reconcile whether project failure has genuinely become rarer in absolute terms, or has simply relocated from pre-launch failure to post-launch incidents.
  How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar — read next: Data on whether AI-era software failure is decreasing in aggregate or shifting in kind/timing (pre-ship vs. post-ship), e.g. incident-rate and DORA-style studies across the industry.
• illogicalThe essay argues AI 'won't give you an edge' because competitors have access to the same models trained on much of the same data (implying execution-speed parity across companies), yet elsewhere argues AI lets a team's own internal functions move in many directions 'because they can' (implying execution speed is in fact a live, consequential differentiator inside an organization — the very thing creating the coordination problem the piece is about). These two claims are never reconciled: if AI-driven execution speed doesn't differentiate companies from each other, it's unclear why its intra-organizational effects are framed as such an urgent, novel problem rather than a wash.
  Experience Mapping Matters More the Faster You Move — read next: Compare against extract-the-organization-is-the-bottleneck and Jevons-paradox material on whether AI-driven speed gains net out at the market level even as they reshape work at the organizational level.
• incompleteGeneralizability: Abundly is a small AI-native startup building an agent platform. Their incentives, team size, codebase complexity, and regulatory environment are unusual. No acknowledgment that this setup might not transfer to larger, more constrained organizations.
  Henrik Kniberg's Post — read next: Case studies of multi-agent adoption in larger organizations; enterprise AI adoption literature.
• incompleteThe presentation treats 'leadership practices' as the causal variable explaining per-company variance, but does not control for confounders like codebase quality, technical debt, team size, or domain complexity. Companies that already have good DevEx practices may simply be better at everything, including AI adoption.
  Presentation: Leadership in AI-Assisted Engineering — read next: Research on organizational readiness factors for technology adoption; look at DX's own AI Impact Report for more controlled analysis
• incompleteThe argument against AI replacing engineers relies heavily on current SWE-bench scores and a claim about algorithms not changing since the 1950s. This understates the pace of agentic and scaffolding innovations (MCP, RAG, multi-agent systems) that improve effective capability without changing underlying model architecture.
  Presentation: Leadership in AI-Assisted Engineering — read next: Anthropic, OpenAI, and DeepMind research on agent scaffolding; François Chollet's critique of benchmark-as-capability proxies
• incompleteDX is both the research organization and the vendor selling the measurement platform. The talk acknowledges DX's role but does not address how this commercial interest might shape which metrics are recommended or how 'success' is defined.
  Presentation: Leadership in AI-Assisted Engineering — read next: Independent developer productivity research (e.g., DORA team at Google, academic DevEx studies not commercially affiliated)
• uninformedThe claim that 'underlying algorithms haven't changed since the 1950s' is misleading. While perceptrons date to the 1950s, transformers (2017), RLHF, constitutional AI, chain-of-thought, and scaling laws represent genuine algorithmic innovations. The framing conflates 'neural networks exist since the 1950s' with 'nothing has changed.'
  Presentation: Leadership in AI-Assisted Engineering — read next: Vaswani et al. 'Attention Is All You Need' (2017); Kaplan et al. scaling laws papers; survey of post-transformer architectural innovations
• incompleteThe paradox is asserted but its mechanism is under-specified. Shipper offers 'every agent needs a human' (a maintenance claim), 'benchmarks miss prompting' (an attention claim), and 'models commoditize yesterday's competence' (a frontier claim). These are three different mechanisms doing different work, and Shipper conflates them. The maintenance claim is explicitly transient — he concedes personal agents return as models improve. The attention claim is partially circular — he will redesign his benchmark to zero out a saturated model. Only the frontier claim is structural, and it is the least developed. A serious version of the thesis needs to argue that the new frontier work is itself non-automatable and remunerated — neither is shown.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Acemoglu & Restrepo on task displacement and reinstatement; the 'augmentation vs. automation' literature (Brynjolfsson, Mitchell); recent econometric work on AI's effect on call-centre and software-engineering productivity (the GitHub Copilot RCT, Brynjolfsson-Li-Raymond on generative AI in customer support)
• incompleteThe 'humans-as-orchestrators' vision is unfalsifiable in this conversation. Shipper says explicitly that when models 'saturate' his senior-engineer benchmark, he will redesign it to zero out the current model. If the benchmark moves to wherever AI cannot yet go, the claim 'humans are still needed' is true by construction and tells the listener nothing about the actual trajectory of automatable knowledge work. A senior engineering leader needs a falsifiable formulation — what specifically would need to be true for Shipper to concede that the 'more humans' claim has expired? — and the conversation does not offer one.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Popper on falsifiability; Sutton's 'bitter lesson' as the counter-frame; the eval-design literature (HELM, MMLU saturations, the ARC-AGI debate); recent critiques of human-baseline benchmarks (Anthropic's METR work on long-horizon agentic tasks)
• incompleteSelection effects in the Every case are uninterrogated. Every is ~30 self-selected curious early adopters with pre-release model access, dual media-and-software business model, founder writer-CEO, no legacy systems, no regulated environment, no enterprise sales process longer than the model release cycle. Every assertion in the conversation is sourced from this one organization and projected onto knowledge work in general. For evaluating organizational impact in a Norwegian enterprise context (regulated industries, slower procurement, less English-language model access for non-English work, strong worker-council constraints), the generalization gap is large and unflagged.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Erik Brynjolfsson's recent work on cross-firm productivity dispersion in AI adoption; Wharton-led surveys on enterprise AI deployment; case studies from regulated EU firms (Klarna's published numbers and their later retraction); Norwegian-context: BI Handelshøyskolen / Sintef studies on AI adoption in Nordic enterprise (the 'forskning og digitalisering' extraction in this library)
• incompleteToken-economics assumption (SaaS users bring their own tokens via Codex) is treated as a stable equilibrium when it is more plausibly a transitional artifact. Once enterprise procurement notices that token spend is shifted to user-attached agent harnesses, three forces will push back: (a) per-call agent-tier pricing from SaaS vendors capturing the new volume, (b) enterprise consolidation of agent infrastructure (corporate-controlled Codex/Claude Code deployments), and (c) usage-based SaaS pricing emerging precisely to capture agent-driven volumes. Each of these inverts Shipper's 'buy SaaS stocks' conclusion. He does not engage any of them.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Tomasz Tunguz's recent essays on AI pricing; the cloud-pricing history (AWS's evolution from flat to consumption); Bessemer State of the Cloud reports on agent-driven pricing changes; OpenRouter / LLM-aggregator economics
• incompleteShipper's 'CEO must be personally AI-pilled' claim sits uncomfortably with his 'super-agent per company maintained by a forward-deployed engineer' claim. If the FDE is the load-bearing role and the per-company agent is the substrate, the CEO's personal model fluency is arguably the wrong variable to optimize — the firm needs FDE talent supply and an org design that protects FDE attention from the C-suite. The conversation never reconciles the personal-fluency prescription with the structural FDE prescription.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Karl Weick on 'sense-making' in organizations; recent CIO/CTO surveys on AI organizational placement (Gartner, MIT Sloan); the literature on 'two-pizza team' analogues for AI deployment
• incompleteNo engagement with worker-attention costs of the prescription. 'Ride the models' for every new release, 'try Codex in your off-hours if your employer blocks it', 'every agent needs a human gardener', 'inbox-zero for 10 straight days via Codex monologue' — collectively this is a maximally attentive lifestyle marketed as liberation. Shipper notes he 'works way more' and frames it as paradox-evidence, not as cost. For a senior engineering leader thinking about sustainable organizational design, the elision of attentional and psychological cost is significant.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: The 'AI psychological costs' extraction in this library (extract-psychological-costs-of-ai-*); Cal Newport on attention residue and deep work; recent labour-economics work on AI-driven work intensification (LSE, Stanford); union/works-council positions on AI workload
• illogicalThere is internal tension between (a) 'CLIs are over, GUIs win' and (b) 'agents using SaaS via CLI is how SaaS survives'. If the user's primary surface is Codex/Co-work GUI and the agent talks to SaaS over CLI, then CLIs are precisely what is preserved — they are the agent-readable API layer, not the user surface. Shipper conflates the user-surface CLI claim with the agent-readable-API CLI claim. The two are different and have opposite trajectories: the first dies, the second flourishes. The conversation does not separate them.
  The AI paradox: More automation, more humans, more work | Dan Shipper
• incompleteThe postscript's own rebuttal (OpenAI's expert mathematicians filtered the model's suggested discoveries) reveals a second, structurally different locus for expertise — applied downstream as institutional filtering/checking, rather than upstream as prompting skill — that the essay does not integrate into its main thesis. If organizational filtering can substitute for individual prompting expertise, the essay's individual-level framing ('the human is the bottleneck') may understate how much of the real bottleneck is organizational/institutional rather than personal.
  LLMs Reward Expertise — read next: Compare with corpus material on how organizations institutionalize AI-output verification and expert review as a substitute for (or complement to) individual user expertise.
• incompleteUnlike the source whitepaper, this video's summary omits the 'the 80% problem' (that AI generates most of a feature quickly but the remaining ~20% of edge cases and integration points still requires deep human judgment and increasingly manifests as subtle, hard-to-spot conceptual errors) — leaving out the strongest caveat against treating a reliable harness as sufficient for full delegation.
  Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) — read next: extract-new-sdlc-with-vibe-coding.json (same source, includes the 80% problem the video drops).
• incompleteThe article frames developer headcount reduction as following directly from AI reaching a raw coding-speed/autonomy threshold ('superhuman coder'), without engaging the corpus's recurring counter-finding that code generation speed was never the actual bottleneck in software delivery — so even an AI that codes 30x faster than the best human engineer might not proportionally reduce headcount if requirements-gathering, review, security, and organizational absorption capacity remain the real constraints.
  Automatisert KI-koding vil endre alt ("Automated AI coding will change everything") — read next: extract-new-sdlc-with-vibe-coding.json and other 'code was never the bottleneck' material in the corpus.
• incompleteThe rebuttal of the DeepMind 'multi-agent shows no advantage' paper is promised and then sidestepped: he reframes it into his four considerations without ever engaging the actual finding that architecture choice (centralized/decentralized/independent/hybrid) produced no advantage. Whether his adaptive quality-grounded MAS would beat a single well-prompted sequential agent is left unproven.
  Presentation: The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation — read next: Read the DeepMind MAS paper directly and the multi-agent-skeptic case (Beck's 'nobody wants agents') to judge the claim on its own evidence.
• illogicalThe paper cites both a 25-39% industry-survey productivity gain and METR's finding that experienced developers took 19% longer on certain AI-assisted tasks, in the same subsection, without reconciling when each applies — leaving the central 'does this make developers faster' question effectively answered by whichever statistic suits the surrounding argument at that point in the text.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering — read next: A study that segments AI productivity gains by task type, developer seniority, or codebase familiarity, rather than reporting a single aggregate figure.
• incompleteThe author argues that Measure and Learn remain expensive and irreducibly human, but does not explore whether AI might also transform these phases — e.g., AI-driven user behavior analysis, automated A/B testing at scale, or AI-assisted synthesis of qualitative feedback. The claim that learning is irreducibly human is asserted, not defended.
  No, AI Did Not Kill Agile — read next: Literature on AI-augmented product discovery, automated experimentation platforms (e.g., Eppo, Statsig), and whether AI can reduce the cost of the Measure/Learn phases
• incompleteThe article never engages with domains where requirements genuinely are well-understood upfront (e.g., regulatory compliance, protocol implementations, mathematical computations). The knowledge-problem framing may be less applicable in these contexts, where spec-first AI development might be entirely appropriate.
  No, AI Did Not Kill Agile — read next: Cynefin framework (Dave Snowden) for distinguishing simple/complicated/complex/chaotic domains; literature on when waterfall-like approaches are actually appropriate
• incompleteThe post's own headline statistics (McKinsey 20-40%, Gartner 40%) are cited by source organization only, with no report named or linked, and the closing '80% on progress' claim about AI-leading companies has no citation at all — the piece's rhetorical force depends on numbers it doesn't let the reader verify.
  Thomas Nys' Post — read next: Trace the actual McKinsey and Gartner reports behind these figures to check whether '20-40% of tech estate value' and '40% of infrastructure systems' are being accurately summarized or rounded into a more alarming framing than the source data supports.
• uninformedBooch dismisses Amodei's prediction partly on the basis that current models are trained only on previously-seen patterns, but doesn't engage with the trajectory argument — that model capability has been expanding beyond narrow CRUD patterns at a measurable rate — which is the actual empirical crux of near-term automation-timeline disagreements, rather than a settled historical analogy.
  The third golden age of software engineering – thanks to AI, with Grady Booch — read next: Pair with benchmark- or practitioner-report-driven pieces examining the rate of capability expansion across recent model releases, not just a snapshot of current limits.
• incompleteThe piece does not distinguish between agent types or task types when sizing the fleet. 'Background agents in the Cloud' versus 'foreground agents you steer interactively' have very different review-cost profiles; isolated refactors versus exploratory feature work have very different judgement-content. A more developed version would offer a cost function for fleet sizing rather than 'a low single digit'. The lock-thrashing claim for complex tasks is asserted but not modeled — at what point does adding one more in-flight complex task degrade ALL outputs, and how do you tell you're past it?
  The Orchestration Tax is You — read next: Queuing-theory treatments of knowledge work (e.g., Reinertsen 'The Principles of Product Development Flow'); empirical studies of attention residue (Sophie Leroy).
• incompleteOsmani assumes the developer can accurately measure their own sustainable review rate and choose to stop at it. Stolen-Focus / Bailey-style attention research suggests this self-measurement is precisely what gets degraded first when attention is depleted. The prescription 'scale fleet to your review rate' presupposes a calibrated self-monitor that the diagnosis itself implies has been compromised. The post does not address this circularity.
  The Orchestration Tax is You — read next: Chris Bailey on attention as a managed resource; Johann Hari 'Stolen Focus'; cognitive-load research on metacognitive accuracy under load.
• incompleteOsmani gestures at 'cognitive debt' via Storey but does not develop the stock-and-flow model implied by his own diagnosis. If mental model is a stock that depletes with unreviewed merges and replenishes with deep code reading, the orchestration tax is a flow-rate problem with a leverage point in the replenishment rate, not just in the merge rate. He prescribes throttling merges (backpressure) but does not prescribe deliberately re-reading old code to rebuild stale model — a complementary tactic.
  The Orchestration Tax is You — read next: Donella Meadows on stocks-and-flows and leverage points; Naur 'Programming as Theory Building' on the theory developers carry of their code; recent empirical work on mental-model decay in long-lived codebases.
• incompleteThe asymmetric-risk frame from Paul Reed's 'Ironies of A^2 I^2' (catastrophic downside when AI is misleading, modest upside when AI is correct, and operators cannot detect in real time which regime they are in) is precisely the empirical mechanism that would make 'shallow reviews' so dangerous. Osmani names shallow reviews as the failure mode but does not connect it to the Woods et al. nurses-study finding that explains WHY shallow review of AI output is uniquely catastrophic compared with shallow review of human output. The two posts are talking about the same dynamic from different angles and would strengthen each other.
  The Orchestration Tax is You — read next: Paul Reed 'The Ironies of A^2 I^2' (already extracted in this repo); Woods et al. July 2025 nurses study; the METR developer study.
• illogicalThe GIL analogy is rhetorically powerful but slightly misleading. A GIL serializes execution but does NOT serialize knowledge of state — Python threads share memory cheaply once the lock is held. The developer's situation is worse: not only is execution serial, but knowledge-of-state must be reconstructed (the 'cold reload') every time the lock is acquired. Osmani notes the cold-reload cost separately but does not see that this means the GIL analogy understates the asymmetry. A better analogy would be 'GIL plus no shared memory plus expensive page fault on every acquire' — i.e., closer to distributed-systems coordination than to threaded execution.
  The Orchestration Tax is You — read next: Distributed-systems literature on shared-nothing coordination; Hutchins on distributed cognition; the multi-agent-systems literature on shared mental models.
• incompleteThe issue diagnoses AI-era pressures (salary-scale economics, direction-less amplification, agent reliability, term-inflation) and poses them as open questions to the reader ('where does your company sit?', 'what would you do differently?') but never synthesizes them into an operating model — it stops short of what a leader should actually do.
  SWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. — read next: Will Larson's 'Revised Rules of Engineering Leadership' itself (the linked favorite), and John Cutler / engineering-strategy sources that convert principles into concrete decision rules.
• incompleteThe continuity framing (fundamentals and judgment are what matter, AI only raises their stakes) under-weights the possibility that some fundamentals themselves must change under AI — it treats 'fundamentals' as fixed rather than a live question.
  SWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. — read next: Sources debating whether the fundamentals taught today are still the right ones (e.g. Tobias Torrissen on juniors and fundamentals; 'The Future of Software Engineering' on mid-level retraining).
• incompleteThe post diagnoses the problem brilliantly but doesn't offer a transition path. How does an organization that recognizes it's running the engineering-as-bottleneck model actually shift to the learning model? What are the first moves? Who has to change their behavior first? The 8 questions at the end are diagnostic, not prescriptive.
  TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier — read next: Cutler's earlier work on mandate levels and enabling constraints; Team Topologies (Skelton & Pais) on organizational design; Marty Cagan's 'Transformed' on product operating model transitions
• incompleteThe post treats AI as a uniform amplifier, but AI tools are heterogeneous. Code generation, customer research synthesis, experiment automation, and demand analysis are different AI applications that amplify different parts of the funnel. A more specific analysis of which AI applications amplify dysfunction vs. which could help shift the model would be more actionable.
  TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier — read next: The Research-Driven Agents piece (research phase as demand shaping for agents); specific AI tooling literature on product discovery vs. delivery
• incompleteThe feature factory PM says 'I wish it was different.' There's an unexamined question: can a team that has achieved functional feature factory operation use that credibility and trust as a foundation to gradually expand its mandate toward the learning model? Or does the success of the feature factory create path dependency that makes the transition harder?
  TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier — read next: Innovation literature on the 'competency trap'; Christensen's innovator's dilemma applied to internal teams
• incompleteThe four-level taxonomy is presented as self-evident without empirical grounding, prior art references (beyond Engelbart), or criteria for distinguishing the levels in practice. It is unclear whether the levels are discrete, overlapping, or a continuum, and what determines when a system transitions from one level to another.
  The keyboard was never the bottleneck — read next: Compare with established taxonomies: Lehman's laws of software evolution, the Cynefin framework, or Conway's law literature for more rigorous level-distinction criteria.
• incompleteThe claim that AI-generated code characteristically fails at higher levels is asserted as an observed pattern but supported only by a brief characterization ('works in isolation, fails when inputs vary'). No specific examples, studies, or failure cases are cited.
  The keyboard was never the bottleneck — read next: Look for empirical studies on AI-generated code in production systems, e.g., GitHub Copilot studies, or case analyses of AI-generated code failures in integration contexts.
• incompleteThe article does not address the possibility that AI capabilities at higher levels could improve significantly. The boundary between levels 2 and 3 is treated as if it were a stable, inherent limitation rather than a current snapshot of AI capability.
  The keyboard was never the bottleneck — read next: Follow research on AI agents for multi-component system design, autonomous software engineering agents, and LLM-based architecture reasoning.
• incompleteAmundsen argues the opportunity to 'get better at getting better' exists but immediately hedges that it may not be realized. No mechanisms, incentives, or conditions for realizing it are discussed.
  The keyboard was never the bottleneck — read next: Engelbart's original 'Augmenting Human Intellect' framework, and organizational learning literature (Argyris, Senge) for conditions under which meta-improvement actually occurs.
• implicit premiseThe book promotion is structural to the argument — the entire piece is framed to show the book is newly relevant, which may bias the selection and framing of parallels toward ones that support the book's thesis.
  The Organization Is the Bottleneck
• unsupported claimThe 3x shipping speed claim is stated without citation or qualification.
  The Organization Is the Bottleneck
• misinformedThe opening hook's claim that reading the article digitally (via a browser) necessarily means 'you have just used' cURL overstates cURL's role in that specific pathway -- most mainstream web browsers use their own networking stacks rather than libcurl to fetch web pages, even though cURL genuinely is extremely widely embedded elsewhere (package managers, command-line tools, embedded devices, app backends). The framing conflates cURL's real, vast reach with a specific, likely inaccurate claim about browser page-loading.
  Who cleans up after the vibe-coding party? — read next: cURL's own documentation on where libcurl is and isn't actually used (browsers vs. tooling vs. embedded systems) for a precise picture of its footprint.