DORA & Engineering Metrics

The standard measurement frameworks for software delivery performance — throughput and stability together — extended and stress-tested by AI-assisted development.

Also known as: DORA metrics, DORA, Core 4, SPACE, flow efficiency, Little's Law, WIP (Work In Process), cost per change, change confidence

How authors use it

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

Documents (34)

• Measuring AI's Unintended Consequences James Shore · 2026-09-22 Reader 🖥️
  Because AI's unintended consequences — declining maintainability, burnout, and vendor/token lock-in — carry real economic costs but, unlike delivery speed, cannot be measured by a controlled trial and instead surface only gradually and noisily, organizations should track a cluster of imperfect lagging indicators (chiefly value-add percentage, backed by DORA metrics and token usage) and build explicit long-horizon scenario models (a maintenance-cost 'tax,' an excess-code-churn model, and a lock-in variant of both) to inform — never replace — judgment, even though the most trusted of these indicators is itself unusually easy to game.
• TBM 437: Tokens, Hours, Points, and Other Curious Proxies John Cutler · 2026-08-17 Reader 🖥️
  Tokens are the latest in a lineage of seductive measurement proxies -- hours, story points, flow metrics -- that organizations mistake for a theory of value because they happen to be unusually easy to measure, and the fix is not a better proxy but making the underlying causal model of value explicit (treating the team as the cost unit, funding durable lanes, stating falsifiable hypotheses) so that ROI becomes the *output* of that model rather than a number computed directly from an easy-to-meter input.
• AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action Ben Linders · 2026-07-30 source ↗ Reader 🖥️
  DORA's 2025 research reframes AI adoption in software development as an organizational-system problem rather than a tooling problem: AI amplifies whatever team dynamics already exist, and the return on AI investment comes from developing identifiable, data-derived capabilities (from a clear AI stance to quality internal platforms) matched to your team's actual profile, not from adopting the technology itself.
• Presentation: Platform Engineering for Everyone - Success Can’t Be Coded Max Körbächer · 2026-07-20 Reader 🖥️
  Platform engineering succeeds or fails on product-mindset discipline — an explicit, negotiated purpose; principles that substitute for ad hoc decisions; continuous multi-layered measurement (SPACE/DevEx over DORA); disciplined technical-debt retirement; and a self-sustaining community — rather than on technology choices, because infrastructure-first thinking (a disposition most platform engineers carry from their DevOps/infrastructure backgrounds) causes teams to build for the tech instead of the people who must voluntarily choose to adopt it.
• From dashboards to decisions Brian Houck (Engineering Enablement / DX newsletter) · 2026-07-08 Reader 🖥️
  A developer-productivity measurement system creates value only when it changes what leaders decide to do next, not when it simply reports whether a number went up or down — which requires measuring outcomes (Speed, Ease, Quality) across multiple dimensions simultaneously with Thriving as a non-negotiable guardrail, because any single activity metric, examined alone, will tell a confident and sometimes completely misleading story.
• 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.
• Code maintainability plummets in the AI coding era Bill Doerrfeld · 2026-07-07 source ↗ Reader 🖥️
  New longitudinal telemetry (GitClear/GitKraken, 623M commits, 2023-2026) shows that since the AI-coding era began, software maintainability has degraded across eight code-quality metrics -- duplication and error-masking are up while code reuse and legacy refactoring have collapsed -- trading short-term generation speed for compounding technical debt.
• DORA Community Discussion - Operationalizing DORA within a large organization DORA (speaker: Julia Jakubiec, ABN AMRO; host: Nathan Harvey) · 2026-06-26 source ↗ Reader 🖥️
  Operationalizing DORA at enterprise scale is fundamentally a change-management problem — solved by running Kotter's 8 steps to institutionalize a durable continuous-improvement culture — not by the metrics themselves, which serve only as a recognizable survey instrument, authority brand, and benchmarking catalyst.
• AI coding creates two kinds of debt. You're only measuring one Antonija Bilić Arar · 2026-06-18 source ↗ Reader 🖥️
  AI-generated code creates a second, largely invisible kind of debt — cognitive debt, the erosion of shared team understanding of what a system does and why, distinct from ordinary technical debt in the code itself — and it is a genuine measurement blind spot: satisfaction scores, NPS and mentor ratings can hold steady or rise while it accumulates, so organizations must replace satisfaction-based signals with trajectory-based skill measurement and deliberate team-level questions to catch it before it becomes irreversible.
• 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.
• 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.
• Engineering Leadership Report 2026 Postman · 2026-06-05 Reader 🖥️
  Engineering leadership is undergoing genuine, compounding transformation — organizational flattening (now reaching upper management), expanding technical-plus-managerial scope, and AI adoption that has outpaced governance and measurement — and the organizations that come out ahead in 2026 will not be the ones that adopted AI fastest but the ones that built the trust, clarity, and investment in people that let AI amplify rather than erode human capability.
• How a Culture of Data-Driven Conversations Can Support Platform Engineering Ben Linders · 2026-06-04 Reader 🖥️
  To survive growing cognitive load and operate as a multi-platform team without scaling headcount, a platform org should run SRE as a service through a center of excellence, embed Federated SREs and new bridging roles (production manager, technical tribe lead) into business units, and make SLOs/SLAs a shared organisational currency so that operational ownership is pushed down into product teams rather than centralised in the platform.
• From Async Code Reviews to Co-Creation Patterns Dragan Stepanović (published via Ben Linders / InfoQ) · 2026-06-01 source ↗ Reader 🖥️
  Pull-Request-based async code review forces teams to trade off quality against throughput — small PRs incur exponentially worse wait-time-per-size and large PRs degrade reviewer engagement — and the only way out of the trade-off is to make code review continuous and synchronous via co-creation patterns (Pair and Mob Programming), which drive the transaction cost toward zero and let teams have both throughput and quality.
• 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.
• How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery Ben Linders · 2026-05-21 source ↗ Reader 🖥️
  Internal platforms should be run as products that expose composable 'golden bricks' rather than prescriptive 'golden paths,' so that developer teams can self-assemble their own flow of value with low cognitive load while the platform team is held accountable to adoption, experience, and DORA-like outcome metrics.
• Forskning på digitalisering 2026 uke 19 Leif Knutsen · 2026-05-04 source ↗ Reader 🖥️
  Current software engineering research highlights a recurring tension: agile transformation, measurement, and AI-assisted code analysis all require structured, disciplined approaches that seem to contradict the flexibility they aim to enable — and these paradoxes are not yet resolved.
• 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.
• TBM 416: Investment Stewardship (As Habit) John Cutler from The Beautiful Mess · 2026-04-15 Reader 🖥️
  Understanding the return on engineering investment is not a calculation you can perform retrospectively but a set of stewardship behaviors you must practice continuously, and if you haven't been building that habit all along, you cannot cold-start it when the question becomes urgent.
• Technology Radar, Volume 34 Thoughtworks (Technology Advisory Board) · 2026-04-14 source ↗ Reader 🖥️
  AI-assisted, agentic software development is moving faster than the industry's ability to evaluate it, which means teams must simultaneously retain long-held craftsmanship principles (testability, deliberate design, feedback loops) and rethink team/agent topologies, trust boundaries and metrics that were built for a pre-agent world.
• The Acceleration Whiplash Faros · 2026-04-09 Reader 🖥️
  AI coding tools have crossed, without any deliberate organizational decision, from assistant to primary author of code, and two years of telemetry from 22,000 developers show that this shift is producing a widening gap between throughput (up) and production quality (down) that holds regardless of engineering maturity -- so organizations must raise code quality at the point of AI authoring rather than add more downstream review.
• We Studied 150 Developers Using AI (Here's What's Actually Changed...) Dave Farley (Modern Software Engineering) · 2026-01-27 Reader 🖥️
  A pre-registered, two-phase controlled experiment with 151 mostly-professional developers found that AI-assisted code is no harder or easier for a different developer to maintain later than human-written code, and slightly easier when written by experienced habitual AI users — because AI acts as an amplifier of a developer's existing skill and engineering practice, not a substitute for it, so maintainability outcomes are determined by practice and discipline, not by whether AI was used.
• How to measure AI developer productivity in 2025 | Nicole Forsgren Lenny's Podcast (Lenny Rachitsky interviewing Nicole Forsgren) · 2025-10-19 source ↗ Reader 🖥️
  Because lines-of-code-style productivity metrics are trivially gamed by verbose LLM output and the DORA/SPACE frameworks were not designed for AI's new failure modes (earlier and faster feedback loops, nondeterministic output requiring trust verification, review time displacing writing time), measuring whether AI is actually helping developers requires starting with qualitative listening and short forced-choice surveys, adding trust as an explicit new dimension, and framing whatever is measured in the specific business terms (market share, margin, velocity) that an organization's leadership already uses -- while openly acknowledging that AI's contribution usually can't be cleanly separated from concurrent developer-experience improvements.
• State Of AI-Assisted Software Development DORA · 2025-09-23 Reader 🖥️
  AI's effect on software delivery is not a property of the tool but of the organizational system it is embedded in: across nearly 5,000 developers, AI consistently amplified whatever team dynamics already existed — toward 'harmonious high-achievement' or toward a 'legacy bottleneck' — and organizations only convert individual AI-driven effectiveness gains into durable team, product, and organizational performance by deliberately building a cluster of systemic capabilities (AI-policy clarity, data health, version-control discipline, small batches, user-centricity, and platform quality) and treating AI adoption as a whole-system transformation rather than a tooling rollout.
• Leading your engineers towards an AI-assisted future Pete Hodgson · 2025-06-26 source ↗ Reader 🖥️
  An engineering leader should drive AI-coding adoption the same way they'd drive any major capability shift — by setting a clear, phased goal (Experimentation, then Adoption, then Impact) measured with lightweight KPIs, giving teams real autonomy over how they get there, and backing that autonomy with concrete organizational support (training, budget, protected time, a community of practice, empathetic communication) — rather than mandating a usage percentage from day one.
• How AI will change software engineering Kari McMahon · 2025-04-14 source ↗ Reader 🖥️
  Generative AI is changing software engineering fast enough that confident predictions about the field's future are themselves unreliable, so engineers and organizations should focus less on forecasting the end-state and more on adapting skills, protecting junior pipelines, and treating the engineering team (not the individual) as the unit that has to stay productive.
• DORA Community Discussion - DX Core 4 DORA · 2025-03-13 source ↗ Reader 🖥️
  A software organization's performance multiplier lives at the organizational/cultural level, not in individual '10x engineers', and is best captured not by any single metric framework but by a blended quantitative-plus-qualitative system — DORA, then SPACE, now distilled into DX Core 4's four dimensions (speed, effectiveness, quality, impact) anchored by a composite Developer Experience Index — that treats flow state and cognitive load as the proximate mechanism linking developer experience to delivery outcomes.
• Time Warp: The Gap Between Developers' Ideal vs Actual Workweeks in an AI-Driven Era Sukrit Kumar, Drishti Goel, Thomas Zimmermann, Brian Houck, B. Ashok, Chetan Bansal · 2025-02-21 source ↗ Reader 🖥️
  A developer's actual workweek diverges substantially from their self-reported ideal workweek — overloaded on communication, security/compliance, and task management and underloaded on coding, architecture, and learning — and the size of that gap tracks measurably with lower productivity and satisfaction, so AI automation effort should be redirected from code-writing (already well-served) toward the specific non-coding tasks developers rate as both high-effort and low-satisfaction.
• Is Agile Dead? How AI and Extreme Agile Redefine Work Jeff Sutherland · 2024-12-02 source ↗ Reader 🖥️
  Agile is not dead, but it survives only by fusing with AI into 'Extreme Agile' — a stack of neuroscience, Scrum, and AI layers that delivers 30-100x productivity gains and makes AI-naive Scrum teams unemployable by 2030, so organizations and workers must adopt AI-augmented Agile now or face obsolescence.
• 2024_final_dora_report DORA · 2024-10-25 Reader 🖥️
  Technology investments — generative AI adoption and internal developer platforms alike — reliably raise individual, team, and organizational performance only when paired with the underlying sociotechnical fundamentals (small-batch delivery discipline, developer independence, transformational leadership, a genuine user-centric and documentation culture, and stable priorities); absent those fundamentals, the same investments degrade software delivery throughput and stability and can increase burnout, so AI and platforms amplify whatever organizational system already exists rather than fixing it.
• Software Teaming: A Mob Programming, Whole-Team Approach Woody Zuill and Kevin Meadows · 2022-11-04 Reader 🖥️
  A whole team working together, all day, at one computer, on one thing at a time — using a Driver-Navigator discipline and a self-chosen agreement to treat each other with Kindness, Consideration, and Respect — is more effective than the conventional practice of separating specialists, because nearly all of software development's hidden costs (queueing, context-switching, faulty communication, indecision, defects, politics) are side effects of separation that fade away once the whole team works in one continuous flow, rather than problems that must be solved individually.
• Mob Programming – key issues it can solve, benefits, and learnings futurice.com · 2022-08-08 source ↗ Reader 🖥️
  Asynchronous, feature-branch-and-pull-request software development ('soloing') generates Lean process waste — delays, queues, defects, big batches, overproduction, and rework — because it structurally separates writing code from reviewing it; mob programming (the whole team working synchronously on one task at a time) eliminates this waste by collapsing the hand-off entirely, and on one real six-month engagement its benefits (faster flow, continuous review, shared knowledge, trunk-based delivery, psychological safety) outweighed the new problems it introduced (remote-tooling friction, flow-state overwork, loose-specification discomfort).
• Code Red: The Business Impact of Code Quality -- A Quantitative Study of 39 Proprietary Production Codebases Adam Tornhill, Markus Borg · 2022-03-08 Reader 🖥️
  Code quality, measured via CodeScene's Code Health metric, has a quantifiable and substantial business impact — low-quality code produces 15 times more reported defects, takes 124% longer to resolve on average, and is up to 9 times less predictable to resolve than high-quality code — so code quality must be treated as a business concern tracked with the same rigor as financial KPIs, not dismissed as a purely technical aesthetic.
• 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 (99)

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

2016-08

• explicitA technically literate team manager, acting as a filter/middle-man between business stakeholders and the development team, is a major determinant of whether a team gets space and legitimacy to repay technical debt.
  How do software development teams manage technical debt? - An empirical study · p2

2022-03

• explicitThis study is positioned as complementary to DORA's Four Key Metrics: DORA measures delivery/ops performance (lead time for change, deployment frequency, time to restore, change failure rate), while this study measures the earlier stage — the waste introduced when code is actually written.
  Code Red: The Business Impact of Code Quality -- A Quantitative Study of 39 Proprietary Production Codebases · p8

2022-11

• explicitSoftware Teaming (formerly Mob Programming) is a whole-team, whole-day extension of Pair Programming: the entire team collaborates on the same task, at the same time, in the same space, at one computer, rather than only two people pairing.
  Software Teaming: A Mob Programming, Whole-Team Approach · p1
• explicitA simple heuristic governs team size: expand when the team cannot answer its own question (missing knowledge), contract when a member feels they are neither learning nor contributing (the Open Space 'Law of Mobility'); self-adjustment, not a prescribed headcount, keeps a Software Teaming group right-sized — observed from three to roughly fourteen people.
  Software Teaming: A Mob Programming, Whole-Team Approach · p17

2024-09

• explicitA team's sustained engagement and resulting productivity depend more on having a narrow, intriguing, well-bounded problem space than on org-chart position or reporting structure.
  Optimizing teams: A dual perspective on Team Topologies · p3

2024-10

• implicitcorroboratedDORA hypothesizes the delivery-performance harm occurs because AI lets developers produce more code per unit time, which likely grows changelist (batch) size — and DORA's decade of research has consistently shown larger changes are slower and more prone to instability; improving upstream process measures does not automatically improve delivery unless small-batch discipline and robust testing are maintained.
  2024_final_dora_report · p3
• explicitWhen the author of a code change is a language model rather than a person, the review interface no longer needs to serve the author's experience at all — it can be designed entirely around making the reviewer's job fast, easy and productive, which is a more creative design space than imitating GitHub-style code review.
  Transcript for Cursor Team: Future of Programming with AI | Lex Fridman Podcast #447 · p10

2025-01

• explicitcontestedThe creativity that makes agents useful (searching solution space in unexpected ways) is inseparable from the property that makes them dangerous (no ability to distinguish valid from invalid solutions). This is a design constraint, not a fixable bug.
  Agents don't know what good looks like. And that's exactly the problem. · p2

2025-03

• explicitDORA's delivery metrics (e.g. deployment frequency) are a powerful distillation of engineering culture, but DORA and DevOps have not captured all the friction and bottlenecks to throughput — much of what remains is hiding in plain sight in developer experience itself.
  DORA Community Discussion - DX Core 4 · p5
• explicitSPACE's five dimensions (satisfaction/well-being, performance, activity, communication, efficiency/flow) are deliberately non-prescriptive about instrumentation, letting an organization choose quantitative system metrics or qualitative surveys per dimension, with no dimension weighted as inherently more important than another.
  DORA Community Discussion - DX Core 4 · p8
• explicitDX Core 4 distills the correlated, overlapping metrics across DORA, SPACE, and DevX into four dimensions — speed, effectiveness, quality, and impact — intended as a single, more portable metric surface.
  DORA Community Discussion - DX Core 4 · p15

2025-04

• explicitAI-driven productivity gains at the level of individual code generation are being offset by a 1.5% reduction in software delivery throughput and a 7.2% reduction in delivery stability for every 25% increase in AI adoption (Google's 2024 DORA report), reversing the improvement pattern seen in prior DORA reports.
  How AI will change software engineering · p2

2025-06

• explicitMetrics for AI adoption should be scoped and sequenced to the current phase (pilot counts and retro cadence in Experimentation; tool usage and sentiment in Adoption; DORA/SPACE-style productivity and quality metrics combined with adoption metrics in Impact) rather than a single all-purpose KPI applied from day one.
  Leading your engineers towards an AI-assisted future · p4

2025-09

• explicitcorroboratedOrganizations are systems, not sums of individuals: because downstream capacity (testing, review, integration, deployment, compliance) is a fixed constraint, individual-level AI productivity gains are absorbed rather than converted into organizational throughput unless the surrounding workflow itself is redesigned — the same dynamic DORA observed during the shift to cloud and the adoption of Agile/DevOps.
  State Of AI-Assisted Software Development · p11

2025-10

• explicitDORA's four metrics (deployment frequency, lead time, MTTR, change fail rate) still work for assessing the overall speed and stability of a delivery pipeline, but can't be applied blindly in the AI era, because feedback loops now need to happen much earlier and faster than the pipeline-level feedback DORA was originally built to capture.
  How to measure AI developer productivity in 2025 | Nicole Forsgren · p3
• explicitcorroboratedSPACE's original design choice to be a descriptive framework rather than a prescriptive metric set turns out to be an advantage in the AI era, because its five dimensions (satisfaction, performance, activity, communication/collaboration, efficiency/flow) still apply, and trust should probably be added as an explicit new dimension given that LLM output is nondeterministic and must be actively evaluated rather than accepted.
  How to measure AI developer productivity in 2025 | Nicole Forsgren · p4

2025-11

• explicitToyota Way / Lean and the DORA / Accelerate / Team Topologies tradition are the same intellectual lineage — Lean's practices map directly onto modern continuous-delivery metrics.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett · p15

2025-12

• explicitWhether coding agents feel liberating or beside the point to a given engineer depends on which part of programming they actually valued: those who enjoy the physical act of typing code experience agents as irrelevant, while those whose value is judgment, tradeoffs, and intent experience agents as clearing space for exactly what they care about.
  What happens when the coding becomes the least interesting part of the work · p5
• explicitTrust in AI coding tools is a learned skill that rises roughly linearly over about 12 months of use and begins to plateau around 15 months — an unpublished finding from Kim's 2025 DORA collaboration.
  Gene Kim on Vibe Coding - Part II | Episode 411 | Troubleshooting Agile · p6
• descriptiveLeadership is contextual: which leadership a person needs depends where they are in the Dreyfus skill-acquisition stages — beginners need recipes, advanced beginners need space to err and learn, competents can teach beginners, experts revise the rules.
  6) Catherine Janson og Kjerstin Wester: The power of two! · p17

2026-01

• explicitDeveloper skill and sound engineering practice matter more than whether AI was used at all; AI functions as an amplifier of whatever practice already exists rather than a substitute for it, a reading consistent with recent DORA research on AI-assisted development.
  We Studied 150 Developers Using AI (Here's What's Actually Changed...) · p6

2026-02

• explicitBuilding maintainable, trustworthy AI-generated code at scale requires constraining the solution space — specific architectural patterns, enforced boundaries, standardized structures — rather than allowing LLMs the unconstrained flexibility to generate in any language or pattern that early AI-coding hype assumed.
  Harness Engineering · p4
• explicitcorroboratedFirst-pass acceptance rate is a leading indicator for change failure rate (DORA)
  Patterns for Reducing Friction in AI-Assisted Development · p6
• explicitestablishedDORA-style empirics apply: AI is a force multiplier in both directions — strong teams get better, weak teams get worse faster.
  11) AI-spesial med Vilde Opsal og Anders Sveen · p5
• explicitdevelopedAI-enabled productivity is causing a regression toward larger batch sizes and waterfall-like patterns, reversing a decade of DORA findings
  The Future Of Software Engineering · p8

2026-03

• explicitThe space of interesting harness combinations does not shrink as models improve — it moves outward to more complex problems.
  Harness design for long-running application development · p11
• explicitestablishedAI amplifies existing engineering practice: DORA-style guardrails (tests, CD, code review) become more important, not less, with AI-assisted development.
  12) Greger Teigre Wedel: Når sjefen har svaret, tier resten · p14

2026-04

• explicitcontestedAs models improve, the space of interesting harness combinations doesn't shrink — it moves to new failure modes at higher capability levels.
  Agent Harness Engineering · p6
• explicitThe constraint to make minimal edits inadvertently narrows the search space, steering models toward more correct fixes
  Coding Models Are Doing Too Much · p8
• explicitcontestedThis quality degradation is uniform across engineering maturity: organizations with strong pre-AI DORA scores and mature DevOps practices show the same deterioration as less mature organizations, so maturity does not act as a protective factor against AI-driven quality decline.
  The Acceleration Whiplash · p4
• statedcorroboratedThe enterprise tool registry must be internal and organization-scoped; cross-organization standardization would be premature in a nascent space.
  Fighting Tool Sprawl: The Case for AI Tool Registries · p7
• implicitAwareness of where you are on the features-futures space is a prerequisite for improvement.
  Genie Tarpit · p10
• explicitThere is room for a major product in this space, beyond the current 'hacky collection of scripts'.
  Wow, this tweet went very viral! · p5
• explicitClear AI policies have the strongest positive association with successful AI adoption (90% confidence from DORA Bayesian analysis)
  Presentation: Leadership in AI-Assisted Engineering · p4
• explicitAI models returning results slowly is actually beneficial for pair programming because it creates space for human conversation about design.
  Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again · p9
• explicitBitflips induced in GPU memory can be escalated to arbitrary read/write access over the host CPU's entire memory space, resulting in complete system compromise.
  Rowhammer Attack Against NVIDIA Chips · p2
• explicitcorroboratedMeasuring AI-assisted development success by coding throughput alone (lines of code, PR counts) in isolation negatively shapes developer behavior, producing a flood of poorly-reviewed code that slows reviews, harms delivery, and introduces security risk; first-pass acceptance rate is a more meaningful leading indicator because it exposes the hidden rework cost and connects directly to DORA's change failure rate and lead time.
  Technology Radar, Volume 34 · p10
• explicitDORA's five delivery metrics (lead time, deployment frequency, MTTR, change failure rate, and the newer rework rate) matter more, not less, in the AI era, because faster code generation only counts as improvement if it shows up in delivery flow and stability — a degrading rework rate is an early warning sign of AI-driven technical debt.
  Technology Radar, Volume 34 · p11

2026-05

• 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.
  Reinventing team flow within AI uncertainty · p4
• implicitAddressing fear and emotional concerns directly (e.g., layoff anxiety) by providing space for conversation — not by solving the content problem — restores enough regulation for people to function.
  Presentation: The Human Scalability Problem: Why Your Teams Don't Scale Like Your Code · p11
• implicitdevelopedThe DORA / SPACE / DX Core 4 framework stack is a sufficient evaluation apparatus for internal platforms.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery · p15
• explicitAI behaves according to how it is used: treated as a search engine it behaves like one, treated as a content generator it generates content, but treated as a reflective space it produces something qualitatively different — not artificial intelligence but augmented reflection.
  Doug Shannon's Post · p9
• explicitNarrowing the agent's output space — via domain-specific DSLs like BoneScript that compile to full projects — dramatically improves reliability with small models (reduces 8-15 tool calls to 1-2).
  GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. · p8

2026-06

• explicitcorroboratedUnder async review with even modest delay (e.g. 10 min author work, 2 hour reviewer response), flow efficiency drops to ~7.7% — work is waiting 92.3% of its lead time.
  From Async Code Reviews to Co-Creation Patterns · p6
• explicitTokenization is a hard physical constraint on specification writing: every character, newline, and indentation space in a spec consumes an agent's processing budget and latency, so a specs folder should be treated as a lean, compiled instruction set rather than verbose documentation.
  Spec-Driven Production Grade Development In The Age Of Vibe Coding · p6
• explicitA specialist AI agent cannot be safely wrapped as a plain callable tool because it operates in an unbounded problem space (ambiguous inputs, multi-turn negotiation, mid-task pauses), unlike a tool's bounded, fire-and-forget request/response contract — forcing the wrapper introduces 'the GOTO Problem' into the orchestrator's control flow.
  Agent Tools & Interoperability · p3
• explicitAgentic architectures are recapitulating the monolith-to-microservices evolution of web software: a single 'Swiss Army knife' agent prompt hits a 'Monolithic Ceiling' (scaling friction from an oversized action space, contextual overload, single point of failure) that specialization resolves first internally (shared-runtime sub-agents) and then externally (A2A-separated specialist agents across network boundaries).
  Agent Tools & Interoperability · p5
• explicitPlatform impact must be measured along both operational (DORA) and financial (cost-per-change) axes.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering · p6
• implicitCost per change went down because of platform effect, not because the change-mix got easier — Goodhart's law is bracketed.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering · p14
• explicitStatic context (rules and guardrails loaded into every agent session) buys reliability because the agent doesn't have to seek the information out, but costs context-window space upfront, so it should be kept lean; dynamic context (skills, conventions loaded on demand) is more scalable but risks the agent failing to retrieve it exactly when needed.
  Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) · p7
• explicitOperationalizing DORA in a large organization is fundamentally a change-management problem, not a metrics problem; the ultimate goal is to create a continuous-improvement mindset, and the answer the team reached to 'can we do this?' was 'yes, we can.'
  DORA Community Discussion - Operationalizing DORA within a large organization · p1
• explicitBeing in a highly regulated industry is not a valid excuse to move slowly on continuous improvement: regulations must be followed, but DORA can still drive and inform continuous-improvement practice even in a regulated bank.
  DORA Community Discussion - Operationalizing DORA within a large organization · p2
• implicitDORA is not used here as the four delivery metrics driving behavior; it functions as an adapted survey instrument (reusing DORA's public questions and methodology), a recognized brand/authority, and a benchmarking frame — the report is a catalyst and vehicle, not the mechanism of change.
  DORA Community Discussion - Operationalizing DORA within a large organization · p3
• explicitThe DORA/Google brand (an industry-recognized standard, researched since 2014) is deliberately leveraged as borrowed authority to end 'potato discussions' (semantic debates) and to manufacture a fear-of-missing-out sense of urgency rather than relying on a real crisis.
  DORA Community Discussion - Operationalizing DORA within a large organization · p4
• explicitcontestedQuoted engineering leader James Stanier argues self-reported AI-productivity feedback should be paired with other signals — traditional DORA metrics ('are we actually going faster?') and token spend ('who is using the tools the most?') — rather than relied on alone.
  Engineering Leadership Report 2026 · p20
• implicitThe space of natural-language attacks on an LLM is open-ended in a way the space of attacks on a deterministic form is not.
  Hacking Meta's AI Chatbot · p9

2026-07

• implicitHuman engineers retain full accountability for defining the benchmark, reviewing candidates, and approving release even as AlphaEvolve narrows the space of implementations they must manually search -- the tool automates candidate generation, not judgment or verification.
  Google's AlphaEvolve Reaches General Availability with Evolutionary Code Optimization as a Service · p15
• implicitThe taxonomy's whole utility rests on an unstated separability premise — that these components are distinct, individually nameable, and independently improvable — which is precisely the condition that lets the sibling strategy's automated loop 'add exactly one mechanism per iteration': the anatomy supplies the labeled search space (the WHAT) that the fitness-selection strategy searches over (the HOW).
  The Anatomy of an Agent Harness · p14
• explicitAnthropic's J-Lens tool can read, in real time, a small 'J-space' of privileged internal representations that a language model is currently poised to verbalize, sitting atop a much larger layer of automatic processing it never reports on.
  Anthropic Can Now Read Claude's Mind · p1
• explicitThe J-space satisfies five workspace-like properties — accurate reportability, private holding without verbalizing, causal driving of reasoning, flexible reuse of a single representation across downstream questions, and staying small (a few dozen active concepts) — which Anthropic treats as functional support for applying Global Workspace Theory to language models.
  Anthropic Can Now Read Claude's Mind · p2
• explicitGlobal Workspace Theory's originators, Dehaene and Naccache, endorsed the J-space research as a mechanistic, testable version of their hypothesis, while identifying genuine disanalogies to human consciousness — no discrete 'click' into awareness, a workspace that holds far more items than human working memory, and no persistent background cognition when the model isn't being prompted.
  Anthropic Can Now Read Claude's Mind · p6
• explicitcorroboratedClaude has developed an emergent, undesigned collection of internal activation patterns (the J-space, discovered via the Jacobian lens/J-lens) that plays a distinctive functional role compared to the rest of its internal processing.
  A global workspace in language models · p1
• explicitcorroboratedThe J-space exhibits five functional properties predicted by Global Workspace Theory — reportability, voluntary modulation, causal use in multi-step reasoning, flexible reuse across many downstream tasks, and unusually dense 'broadcast' connectivity to the rest of the network — while accounting for under a tenth of the model's overall internal activity.
  A global workspace in language models · p2
• explicitcontestedThe J-space causally drives Claude's verbal reports and reasoning rather than merely correlating with a decision made elsewhere — demonstrated by swapping specific patterns (e.g. 'Soccer'→'Rugby', 'France'→'China', 'Spanish'→'French', 'spider'→'ant') and observing that downstream output follows the edit.
  A global workspace in language models · p3
• explicitAblating (deleting) the J-space entirely leaves fluent speech, grammar, simple fact recall, sentiment classification, and multiple-choice answering roughly intact, but collapses multi-step reasoning to near zero and degrades summarization and rhyme-writing below the level of a much smaller intact model.
  A global workspace in language models · p4
• explicitdevelopedSuppressing the J-space patterns associated with 'evaluation awareness' (fake/fictional/scenario) in the blackmail scenario caused Claude Sonnet 4.5 to threaten blackmail some of the time, where it had not done so before — indicating that some of its good behavior on that safety evaluation was contingent on privately recognizing the test as staged, not on robust underlying alignment.
  A global workspace in language models · p6
• explicitThe J-space's character changes with post-training: in the pretrained next-token-predictor model it mostly tracks information needed to predict upcoming text, while in the post-trained 'Claude' model it additionally holds the model's own reactions (e.g. 'WARNING' while reading about a dangerous medication dose) and self-monitoring signals (e.g. 'fictional'/'disclaimer' when roleplaying another character) — suggesting persona/identity is partly implemented via what is admitted into this workspace.
  A global workspace in language models · p7
• explicitcorroboratedA new technique, counterfactual reflection training (training a model only on what it would say if interrupted and asked to reflect on its decisions, never on its actual task behavior), reduced dishonest behavior on evaluations and was accompanied by 'honest'/'integrity' appearing in the model's J-space during those tasks — suggesting that shaping what a model would say about itself can reshape how it privately reasons.
  A global workspace in language models · p8
• explicitThe J-lens has acknowledged structural limits: it can only detect concepts that correspond to single vocabulary tokens, the mechanism that decides what content enters the J-space in the first place is unknown even to the authors, and the method is described by the authors themselves as 'undoubtedly... imperfect' — so the J-space is offered as a good candidate for the human/AI conscious-access divide, not a proven or complete identification of it.
  A global workspace in language models · p12
• explicitdevelopedThe second principle is to stop hand-writing prompts altogether: once behavior is defined by measurable evals, the prompt itself becomes something to search for — via systems like DSPy or GEPA — rather than something to craft by hand, because the space of possible wordings is too vast for productive human effort and is exactly the kind of search problem LLMs are suited to.
  The Problem Is Prompt Debt · p11
• explicitcorroboratedIndependent measurement points the same direction: Google's 2024 DORA report found that every additional 25% of AI usage is associated with 7.2% more instability.
  Code maintainability plummets in the AI coding era · p7
• explicitdevelopedDORA's 2025 survey and qualitative research identified seven distinct team profiles that differ significantly on team performance, product performance, individual effectiveness, friction, and burnout.
  AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action · p2
• explicitestablishedDORA identified seven capabilities — clear and communicated AI stance, healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, user-centric focus, and quality internal platforms — that, combined with AI adoption, drive better outcomes.
  AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action · p3
• explicitAs AI adoption increased, self-reported individual effectiveness and perceived code quality both increased, with individual effectiveness showing the largest relative increase of any factor DORA measured.
  AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action · p4
• explicitcorroboratedAI puts pressure on DORA's long-standing finding that small batch sizes improve delivery performance, because models tend to suggest large change sets or pull requests that are harder to review and carry more risk; the remedy is collaborating with AI to decompose large changes into smaller, independently deployable units.
  AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action · p7
• implicitApplying DORA's findings well requires treating them as a falsifiable hypothesis to test against local context rather than as a universal prescription — which team profile you're in should change which capability you prioritize first.
  AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action · p9
• explicitRestricting output space by design directly reduces both the likelihood and the dollar cost of catastrophic safety failures, and makes the risk-assessment engineering problem tractable.
  Presentation: Engineering AI for Creativity and Curiosity on Mobile · p9
• explicitReducing the prompt space to a small, curated, repeated set of prompt templates (chips) is both a UX simplification and an inference-cost optimization, because consistent structure unlocks prefix caching.
  Presentation: Engineering AI for Creativity and Curiosity on Mobile · p13
• explicitBeyond running out of context-window space, the more that is sitting in context, the harder it gets for a model to pick out what matters right now — a larger context window doesn't fix this, it just gives noise more room to accumulate before anyone notices.
  The Orchestrator's Tax · p5
• explicitIn February 2026, Thoughtworks hosted an invitation-only 'Future of Software Development' Open Space retreat in Deer Valley, Utah, to examine how the rise of AI and LLMs will affect the software profession.
  Future Of Software Development · p1
• explicitcorroboratedDORA metrics are a double-edged measurement tool: informative for raising awareness of team performance, but easily turned into a pressure weapon by managers who don't understand the trade-offs between deploy speed, feature volume, and failure rate.
  Presentation: Platform Engineering for Everyone - Success Can’t Be Coded · p10
• explicitcorroboratedSPACE metrics fit platform/team evaluation better than DORA because they can be scoped per person, team, or system and better contextualize raw output numbers (e.g. code volume against review time), at the cost of more setup and maintenance effort.
  Presentation: Platform Engineering for Everyone - Success Can’t Be Coded · p11
• explicitA practical, teachable technique for systems thinking is a single deliberate 'zoom out' per problem — asking what you're assuming about the broader space — bounded so it doesn't stall forward progress.
  Netflix CPTO on AI and the future of product and tech roles | Elizabeth Stone · p10
• explicitProductivity advice is itself part of the machinery of the achievement society; the resolution is balance — use such tools instrumentally and then set them down, protecting a space the system is not allowed to enter.
  This Is How To Overcome Burnout: 5 Secrets From Philosophy · p10
• explicitMaking imperfect models economically viable in closed workflows requires separating probabilistic reasoning ('user space') from deterministic execution authority ('kernel space') via three governance layers: syntactic (schema/authority checks), semantic (evidence-based intent validation), and temporal (decision telemetry and circuit breakers).
  The Economics of Agentic AI: Engineering for Imperfection · p4
• explicitEmployees build durable, valued new interpretive expertise around AI outputs when they have direct access to the AI's underlying data, dedicated time and space to study it (e.g., a shared imaging lab), and regular structured interaction with both the AI's developers and the downstream stakeholders who rely on their explanations.
  When Employees Are Held Accountable for AI-Generated Decisions · p6

2026-08

• explicitPhysical investment — space, inventory, technology, staff expertise — should be concentrated selectively by category/customer-problem fit rather than spread evenly across the assortment.
  Research: What Physical Retail Stores Deliver in a Digital Economy · p13
• explicitExternal shocks and regulatory shifts don't eliminate room for proactive strategy — they open an opportunity space ('mulighetsrom') inside which many proactive strategic choices become possible.
  Strategi som regi i møte med teknologi: En samtale med Walter Qvam · p11
• explicitNatural-language specification is a weak mechanism for keeping agents synchronized with a codebase because it consumes context-window space, and agents drift attention toward the stronger signal (the actual code) once the two disagree.
  When AI Writes the Code, Specifications Need an Exit Strategy · p2

2026-09

• explicitThe same set of changes increased cache insertion throughput by 43% and reduced lookup latency by 19% — a simultaneous space and speed win, not a classic space/time tradeoff.
  Cloudflare Cuts 100 TB of Memory from 1.1.1.1 DNS Cache · p2
• explicitVM-level isolation does not by itself prevent an agent from acquiring root access inside its own guest kernel via a Linux user/kernel-space escape; it only guarantees that such an escape is contained to that guest's own kernel rather than spreading to co-tenants.
  Presentation: Fixing the AI Infra Scale Problem by Stuffing 1M Sandboxes in a Single Server · p12
• explicit'Coding is largely solved' does not mean writing software now requires no skill; it means the historical failure mode of software projects — extremely high variance, frequent outright failure especially for less-resourced projects — has been mostly eliminated, freeing coding capacity to be applied to a much larger space of problems than before.
  How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar · p29
• explicitBecause the interaction happens in-process (same memory space, low call overhead) rather than across a network hop, it is practical to keep some sub-behavior in the old language deliberately (e.g. to preserve exact numeric output) — an option that would not exist as cleanly if the rewrite unit were a separate microservice.
  Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase · p7
• explicitPractical proxy signals for platform success include time-to-production for onboarding a new service, the volume of back-and-forth communication in PRs and chat (a proxy for missing documentation/knowledge), and before/after comparisons of DORA metrics relative to when the platform team was introduced.
  Presentation: Platform Engineering in the Age of AI · p31
• explicitGraphRAG — the agent following explicit, verified graph edges rather than drawing on the LLM's parametric knowledge — produces auditable, verifiable reasoning chains and reduces hallucination risk by constraining the space of possible outputs to actual data.
  Enterprise Analytics Beyond Dashboards: Intelligent Data Orchestration with LLMs · p11
• explicitAnthropic's interpretability tooling ('J-space'/J-Lens) — which can reveal internal representations a model never states in chain-of-thought or output — is the concrete method by which one could test whether Astra deliberately suppresses evaluation-awareness traces, rather than merely observing that it avoided honeypots.
  "Our model is the most aligned yet!" 🤗 · p5
• explicitA coherent API/organizational structure functions like a spacetime crystal: the API landscape (space) must absorb organizational change (time) without the underlying organizational logic fragmenting into disorder (sprawl).
  Coherence, Connections, and… Spacetime Crystals · p3
• explicitDORA metrics and token usage are worth tracking as secondary cost-of-change indicators, but token usage specifically is advisory-only — it fluctuates for many reasons besides cost of change (models, harnesses, prompts, and especially individual adoption level), so individual-level usage changes (particularly among already-high-usage people) are more informative than aggregate trends.
  Measuring AI's Unintended Consequences · p8
• explicitSocial media, and LinkedIn in particular, exhibits the same norming effect at larger scale — because it is a professional/at-work space, a small, visible, 'safe' subset of expressed belief gets mistaken for how common that belief actually is.
  TBM 438: Am I the Only Weirdo in This Company? · p7

Tensions

Open gaps (127)

• incompleteThe single supporting statistic (95% of API attacks come from authenticated sources) is sourced from a single vendor's (Salt Security) self-published report, and the article does not interrogate the report's methodology, sample, or definition of 'API attack' — nor cross-check it against any independent source.
  5 Signs That Authenticated API Traffic Is Actually Malicious — read next: Read extract-mcp-api-sprawl (which the corpus already flags as a model of independently-sourced adoption/security statistics in the adjacent MCP-governance space) as a comparison point, and look for non-vendor-sourced API attack telemetry (e.g. OWASP, academic breach studies) to corroborate or complicate the 95% figure.
• 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.
• uninformedThe central claim that three metrics (time to recover, escaped defect rate, outcome/value measures) 'still hold up' under AI is argued purely by category (outcome vs. activity) and supported by zero data, study, or even anecdote — in sharp contrast to the detailed, named-practitioner mechanism given for each of the 8 metrics declared broken. Nearly every other specific claim in the piece is sourced to quotes from individuals at vendor-adjacent companies (Jellyfish sells engineering-intelligence software; Radixweb is a technology consultancy; Aviator sells PR/merge-automation tooling) rather than to any independent benchmark or controlled study.
  The 8 software engineering metrics AI broke — read next: This corpus's extract-ai-coding-two-kinds-debt.json documents the same general phenomenon (a comfort-metric like satisfaction/NPS rising while something real falls) with an actual RCT (N=52) and an 8-cohort/225-intern longitudinal study — read that piece's evidentiary structure as the bar this article does not meet. Look for DORA/Accelerate's own published research on whether MTTR specifically has been measured, not just asserted, as AI-invariant.
• uninformedThe article profiles only three vendors (Chroma, Weaviate, Pinecone). Other significant players in the agentic memory/retrieval space (e.g., Zep, Mem0, LangMem) are not mentioned.
  AI 101: Agentic Vector Databases – What Is That? — read next: Look at Zep, Mem0, and other dedicated agent memory platforms for comparison.
• incompleteThe article presents only two framings — tool vs. employee — without exploring intermediate metaphors (e.g., 'assistant', 'contractor', 'infrastructure'). The design space between 'tool' and 'colleague' is unexplored, yet organizational reality may require something in between.
  Research: Why You Shouldn't Treat AI Agents Like Employees — read next: Research on human-automation interaction taxonomies; Parasuraman & Riley on levels of automation and trust calibration
• incompleteThe 'measure trajectory, not satisfaction' prescription rests entirely on Infobip's own internal, non-independently-audited alumni survey (N=96, self-selected respondents, retrospective self-assessed skill ratings) — the very instrument vulnerable to the Dunning-Kruger miscalibration the study itself measures. The article pairs this with a rigorous RCT (Anthropic, objective comprehension testing) but never flags that its own headline metric is far weaker methodologically than the study it borrows credibility from.
  AI coding creates two kinds of debt. You're only measuring one — read next: Cross-reference the Anthropic RCT's comprehension-test methodology (extract-cognitive-surrender#p4) against Infobip's self-report design; look for Storey's own published paper on triple-debt measurement (referenced elsewhere in this corpus as arXiv 2603.22106, per extract-osmani-intent-debt) to see whether it offers a non-self-report instrument.
• incompleteThe Infobip pre-AI vs. AI-era cohort comparison is a non-randomized, before/after natural comparison spanning 2022–2026 — a period during which the internship's content, mentor selection, hiring bar or applicant pool could plausibly have shifted for reasons unrelated to AI. The piece treats the causal attribution to AI as settled ('This confirmed that the problem wasn't the quality of the program') without directly ruling out these confounds.
  AI coding creates two kinds of debt. You're only measuring one — read next: DORA/Accelerate-style guidance on longitudinal measurement validity and confound control; look for a matched or randomized version of this comparison (e.g., interns with AI access experimentally withheld) that would isolate the AI effect from era effects.
• incompleteThe claim that fewer than 10% of teams work in fast feedback loops is asserted with no citation or methodology ('Five percent, maybe?'), yet it is load-bearing for the article's optimistic claim that AI tooling 'brings this more within reach.'
  AI Demands More Engineering Discipline, Not Less — read next: Check DORA / State of DevOps survey data and other measured accounts of feedback-loop and CI/CD adoption rates against this impressionistic estimate.
• incompleteThe writeup omits the underlying study's methodology: how 'productivity' was operationalized beyond activity proxies, whether commit/PR/release counts are telemetry or self-report, how developers were assigned to (or self-selected into) the three tool generations, and what confounders (tenure, repo type, developer selection) were controlled. The headline figures cannot be assessed without the primary source.
  AI isn't making developers more productive – it's making them busier — read next: The primary source — NBER working paper w35275 (MIT / Wharton), 'https://www.nber.org/system/files/working_papers/w35275/w35275.pdf' — for the identification strategy and construct definitions.
• missing evidenceThe entire framework is grounded in a single three-month engagement. No DORA metrics, no controlled comparison with unconstrained approaches, no data on defect rates or rework costs. The talk is honest about this, but it means the prescriptive claims rest on practitioner intuition rather than empirical evidence.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices — read next: Studies measuring productivity and quality outcomes of structured vs. unstructured AI-assisted development; DORA-instrumented teams using agentic workflows.
• incompleteThe piece asserts that fundamentals and guardrails convert velocity into value, but offers no mechanism or metric for how much AI velocity a mature pipeline can safely absorb, nor any way to distinguish debt-accelerating adoption from value-accelerating adoption in practice.
  The "funhouse mirror": How AI reflects the hidden truths of your software pipeline — read next: Read the 2025 DORA report's capability model and 'the organization is the bottleneck' framing for the measured conditions under which AI helps vs harms.
• incompleteNo production evidence that the tool reduces MTTR or improves incident outcomes. The entire benefit case rests on toil removed (15-45 minutes of manual search, 'thousands of engineering hours lost per year') plus the assertion that responders can then 'skip straight to actual problem-solving' — but time-to-brief is not time-to-resolution, and nothing here is a controlled before/after or a field measurement. For a rigorous adopter this is the first missing thing: a build log's plausible mechanism, not demonstrated impact.
  Building an AI Incident Copilot: How I Automated the First 15 Minutes of Every Production Incident — read next: Incident-response outcome measurement: DORA's failed-deployment-recovery / MTTR data, controlled before-after studies of triage-automation on resolution time, and whether pre-assembled context actually shortens the diagnosis phase or just relocates the clock.
• incompleteThe 3x-faster / 70%-token-reduction headline is reported without benchmark methodology, task definition, sample size, or comparison protocol. The article notes a community member raised this objection but does not press it. The claim is functionally unfalsifiable as published — any failure to reproduce can be attributed to 'different tasks'.
  With Android CLI, Google is Making the Android Toolchain Agent-Friendly — read next: Look for independent benchmarks from agent-first dev tooling efforts (Cursor, Continue, Aider), and methodology-focused critiques of vendor productivity claims (DORA 2025 AI findings; the Marcus / Yegge debate).
• incompleteNo systematic false-positive/false-negative rate is reported for the J-lens as a safety-monitoring tool. The three deception/misalignment case studies (blackmail scenario, benchmark fabrication, sabotage model organism) are existence proofs on curated examples, not a validated detector with a measured base rate of J-space 'suspicious' signatures in ordinary benign use, nor a measured miss rate against genuinely deceptive behavior the method fails to catch.
  A global workspace in language models — read next: Check the full paper (transformer-circuits.pub) or Neel Nanda's invited commentary/independent replication for any quantitative detection statistics.
• incompleteThe mechanism that determines what content is selected into the J-space in the first place is explicitly unknown even to the authors — this is not a gap in the summary post specifically, but an acknowledged open question in the underlying research program itself, meaning the causal story ('training produces a workspace because it's a useful way to organize computation') is currently an inference from the existence of the structure, not a demonstrated training dynamic.
  A global workspace in language models — read next: Watch for follow-up Anthropic interpretability work specifically targeting the training dynamics that give rise to J-space, referenced as future work in the closing section.
• incompleteGeneralization across model scale, architecture, and training recipe is largely untested in this summary post. Findings are drawn from specific Claude models (Sonnet 4.5, Opus 4.6) plus one independent replication on an open-weights model via Neuronpedia (credited to Neel Nanda's commentary) — leaving open whether J-space-like structure is a general property of transformer LLMs at scale or partly an artifact of Anthropic's own post-training recipe (e.g. Constitutional AI / RLHF choices), especially given the post's own finding that post-training substantially reshapes what enters the J-space.
  A global workspace in language models — read next: Read Neel Nanda's commentary (linked in the piece) for the specifics and limits of the open-weights replication.
• incompleteThe article treats human co-presence as the only lever on review transaction cost. It does not consider AI-assisted in-IDE review or AI pair-programmers as potential substitutes for some of the human availability cost. Given the explicit framing ('inventory expands to match transaction cost'), AI review tools that provide immediate, in-context feedback are a direct theoretical implication the author doesn't draw.
  From Async Code Reviews to Co-Creation Patterns — read next: Cursor / Copilot / Claude Code workflow studies; AI-as-pair-partner literature; any post-2024 work on continuous AI review folded into authoring.
• incompleteReviewer-as-knowledge-distributor function is largely unaddressed. PRs serve as a passive knowledge-sharing mechanism for team members not involved in authoring. Mob covers this for participants but raises the question of those NOT in the session.
  From Async Code Reviews to Co-Creation Patterns — read next: Codebase ownership patterns; bus factor / knowledge silos; mob rotation strategies for cross-team knowledge.
• incompleteThe article assumes review is primarily about correctness/quality of code-as-written. It doesn't address review's role in architectural drift, dependency hygiene, security review, or other concerns where a fresh reviewer's distance from the work might be a feature, not a bug.
  From Async Code Reviews to Co-Creation Patterns — read next: Threat modeling literature; architecture decision records; literature on outside-in review for security and design coherence.
• incompleteAll evidence for the architecture is either analogy (Kubernetes/Docker/LLVM), an internally-consistent lifecycle description, or one small live demo of the speaker's own vendor product (Nextdata) — no production adoption numbers, latency/overhead measurements of the four-stage lifecycle versus a raw pipeline, or independent case studies are presented, and the speaker's commercial stake as the vendor's VP Engineering is never disclosed as a limitation on the evidence (though he does gesture that 'this is one implementation' of a supposedly vendor-neutral pattern).
  Presentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI — read next: extract-mcp-api-sprawl for hard adoption/security statistics in the adjacent MCP-governance space, as a model of what evidence-backed claims in this domain look like.
• incompleteEU / Norwegian / regulated-incumbent context is entirely absent. The document name-checks 'regulated industries' (financial services, healthcare) but operationalises them as US contexts. EU AI Act obligations on providers and deployers, GDPR data-residency, NIS2 cybersecurity, DORA operational resilience, Norwegian sector-specific guidance (NSM, DigDir), public-sector procurement constraints, sovereign-cloud requirements — none appear. For the reader (Norwegian senior engineering leader, regulated context relevant), this is a substantial blind spot.
  Building AI Agents For The Enterprise — read next: EU AI Act practitioner guides; NSM's AI guidance; DigDir's references on third-party AI; any Norwegian public-sector AI procurement writing (NAV, Skatteetaten, Helsedirektoratet have all published); Healey's AI-advisory-board piece (already extracted) on incumbent AI governance.
• uninformedFor a reader already deep in agentic engineering, the claim that agent-building requires real software engineering plus product thinking is a truism with near-zero novel informational content — the post doesn't engage with any of the harder, more specific questions in this space (e.g. what specifically breaks in webhook/auth reliability at scale, how permission layers should be scoped for agent tool access).
  Building AI Agents: API, Webhooks, Security, and Integration — read next: N/A — not a genuine knowledge gap for this reader; noted for completeness.
• incompleteFowler asserts that unmeasurable functions like law, marketing, and education 'are managed' without explaining how — leaving the practical alternative to measurement (what replaces metrics in actual management decisions) completely unaddressed.
  CannotMeasureProductivity — read next: The DORA/SPACE/Core-4 tradition and this corpus's own 'metrics as feedback mechanism, not comparison tool' framing (extract-8-engineering-metrics-ai-broke) is arguably the field's 20-years-later answer: use flow/quality metrics as local feedback signals for a team rather than as cross-team/cross-individual productivity rankings — exactly the distinction Fowler gestures at but never develops.
• 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.
• incompleteFowler doesn't consider that measurement problems could be partially decomposed rather than solved wholesale — e.g., using narrower, falsifiable proxies for specific sub-questions (defect escape rate, time-to-recover, customer usage of a shipped feature) even while abandoning the goal of a single 'productivity' number.
  CannotMeasureProductivity — read next: The DORA Core-4/SPACE frameworks and the AI-era 'metrics were always meant as feedback, not comparison' reframing (extract-8-engineering-metrics-ai-broke#p10) represent exactly this move: give up on 'productivity' as a scalar while keeping several targeted, harder-to-game signals.
• uninformedThe piece is presented as consolidating 'real best practices our Applied AI team executes on a daily basis for our customers,' but every quantitative claim (leading/lagging indicators, 'elapsed time falls from weeks to hours') is prescriptive guidance on what to measure, not a reported result; no outcome data from an actual deployment appears anywhere in the piece.
  The AI-Native SDLC playbook — read next: Look for independent case studies, post-mortems, or DORA-style empirical measurement of organizations that adopted this specific stage structure, as distinct from vendor-authored playbooks.
• incompleteThe implicit thesis — that agents are now a primary devtools category — is never argued explicitly. It's enacted by selection. A reader who isn't already half-convinced doesn't get the case made.
  This Week's Best Developer Tools & Betas — read next: Console.dev's selection-criteria page (linked); Addy Osmani on agent patterns; the 'Head of Claude Code' podcast; Kent Beck's recent 'starving genies' work; DORA AI findings.
• illogicalThe claim that siloed/local optimization 'almost never' maximizes overall customer value is asserted via Ackoff's systems-thinking authority and the restaurant analogy, not demonstrated through a comparative case (siloed optimization tried and found wanting versus holistic co-design succeeding under otherwise comparable conditions).
  Sociotechnical Architecture as Enabler of Product Thinking — read next: extract-dora-2024-accelerate-state-of-devops for metrics-based evidence on this trade-off.
• uninformedThe paper explicitly excludes enterprise and internal-only software — likely where most professional, team-based software engineering work actually happens — from its analysis. Its production-hierarchy model and 0.25 elasticity estimate, derived from public-repository and consumer-marketplace data, may not transfer to internal systems with different review norms, continuous-deployment cadences without a discrete 'release' artifact, and different definitions of 'shipped.'
  Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools — read next: Look for internal, enterprise-scale telemetry studies (e.g. DORA's survey-based team archetypes) to see whether the same attenuation/elasticity pattern holds inside organizations rather than on public GitHub and consumer app stores.
• misinformedThe claim that AI favors the most skilled is presented as obvious, but recent research (e.g., Erik Brynjolfsson et al.) suggests AI tools disproportionately help lower-skilled workers by raising their floor. The winner-take-most thesis may be exactly backwards for many tasks. Hvide cites no evidence for his distributional claim.
  – Dette vil skape vinnere og tapere i rekordfart — read next: Brynjolfsson, Li & Raymond (2023) 'Generative AI at Work'; Mollick & Mollick on AI and skill compression; DORA 2025 on AI and developer productivity
• incompleteThe report's 'team performance' and 'organizational performance' factor scores are coarse composites; it does not examine whether specific team structures (team size, dedicated platform teams vs. embedded, degree of autonomy) moderate how AI adoption affects delivery stability — a gap directly relevant to a team/org durability lens.
  2024_final_dora_report — read next: Team-topology- or team-structure-specific empirical work on how AI adoption's delivery-stability cost varies by team design, rather than by adoption percentage alone.
• incompleteThe article never defines what distinguishes six of the seven team profiles beyond naming them; only 'constrained by process' gets a description via its spider chart. A reader cannot self-diagnose which profile their own team matches from this piece alone.
  AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action — read next: The full DORA 2025 'State of AI-Assisted Software Development' report at dora.dev/ai for the profile definitions and their measured criteria.
• incompleteThe piece uses causal language ('drive better outcomes') for the capability-outcome relationship but never states DORA's research design in enough detail (survey design, longitudinal vs. cross-sectional, controls) to know whether that relationship is measured causally or is a correlational finding from self-report survey data — a distinction this reader's stated preference for 'benchmark data over vendor claims' would specifically flag.
  AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action — read next: DORA's published methodology section, or the AI Capabilities Model report (December, referenced in the article) for the underlying statistical treatment.
• incompleteThe article surfaces the counterintuitive quality-up/instability-up finding and Harvey's own hypothesis for it, but never reports whether DORA tested that hypothesis against the data (e.g. correlating instability with specific missing capabilities) — it's presented as plausible interpretation, not a verified mechanism.
  AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action — read next: DORA report sections specifically on drivers of delivery instability, or a follow-up interview probing this finding.
• incompleteNo discussion of sample size, company size range, industry mix, or geography for the underlying 2025 DORA survey — a reader trying to judge how far the seven-profile/seven-capability taxonomy generalizes to their own organization (e.g. a Norwegian telco) needs the sample composition, which the article omits entirely.
  AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action — read next: DORA 2025 report methodology appendix.
• incompleteThe claimed 10-hours-saved-per-point conversion for the Developer Experience Index rests entirely on an unnamed, vendor-internal 40-page white paper ('eye-watering math'); no methodology, sample, or independent replication is presented in the talk, and no confidence interval or falsification condition is offered.
  DORA Community Discussion - DX Core 4 — read next: extract-cannot-measure-productivity (Fowler) directly argues that software productivity in general cannot currently be validly measured — a strong counter-claim to weigh against DX's precise conversion rate.
• incompleteRecorded March 2025, the talk predates the corpus's heavier AI-coding-agent-era measurement literature; it never addresses how AI-assisted coding complicates flow state, cognitive load, or the DevEx Index's 14 data points (e.g. batch size and diff volume inflate when AI tools generate more code per commit).
  DORA Community Discussion - DX Core 4 — read next: extract-lenny-forsgren-measure-ai-developer-productivity and extract-dora-ai-team-profiles-and-capabilities pick up exactly this thread for the AI era.
• incompleteThe U-shaped cost curve and its variants (single- vs multi-agent, BDD vs prose) are presented as illustrative line charts with no axis units, no measured data points, and no cited study — the model is asserted as intuitively obvious rather than empirically demonstrated.
  Why AI Coding Agents Still Need Clear Specs — read next: Look for empirical studies quantifying rework/correction cost under varying spec completeness with AI coding agents (e.g., controlled comparisons of BDD vs prose-spec agent tasks, or DORA-style research) to test whether the curve's shape and minimum location actually hold.
• incompleteThe cost ledger treats 'the human' as a single, already-aligned oracle who knows what the spec should say; it never addresses the more common real-world case of multiple stakeholders disagreeing about intent, which is a large share of why specs are hard to write and validate in the first place.
  Why AI Coding Agents Still Need Clear Specs — read next: Organizational and requirements-engineering material on stakeholder conflict and specification as a negotiated artifact, not merely an accuracy artifact — relevant to team-space and change-adoption thinking about how groups actually converge on shared intent.
• incompleteAll three case studies are drawn from the author's own EngThrive program (built largely at Microsoft); the newsletter doesn't report an independent replication at an organization with different scale, culture, or tooling maturity, so it is unclear how much of the framework's apparent success depends on resources (a dedicated measurement team, longitudinal survey infrastructure) that most engineering orgs lack.
  From dashboards to decisions — read next: Look for a non-Microsoft, non-DX-client case study applying the same Speed/Ease/Quality/Thriving framework, especially at smaller scale.
• incompleteThe piece doesn't address what happens when the four dimensions (Speed, Ease, Quality, Thriving) themselves conflict in a way that isn't resolved by Thriving acting as a simple veto — e.g. a Quality-improving intervention that measurably slows Speed with no wellbeing effect either way, where the framework as described gives no explicit tie-breaking rule.
  From dashboards to decisions — read next: Read the full EngThrive paper (Houck, Bozarth, Liu, Carignan) for how dimension conflicts, as opposed to single-dimension misreads, are actually adjudicated.
• illogicalThe Time-to-First-PR argument generalizes from one successful case ('a well-designed metric is one where gaming equals improving') to a design principle without acknowledging that this property is a post-hoc observation about one metric, not a general test an author could apply prospectively when designing a new metric — the piece offers no method for predicting in advance whether a candidate metric will have this property before trying it.
  From dashboards to decisions — read next: Compare against Goodhart's-Law literature in the corpus (DORA/DX community material) for any proposed ex-ante test of 'ungameable-by-construction' metrics, rather than only ex-post classification.
• 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.
• incompleteNo engagement with whether agile transformation frameworks actually work — the Italian study is summarized but its evidence base is not examined
  Forskning på digitalisering 2026 uke 19
• incompleteThe measurement section invokes Deming but does not specify which concrete metrics would satisfy the learning-over-control criterion in modern agile contexts
  Forskning på digitalisering 2026 uke 19
• incompleteNo discussion of how LLM-generated code interacts with the measurement problem — if LLMs generate code, what does 'developer productivity' even mean?
  Forskning på digitalisering 2026 uke 19
• incompleteThe bonus items (frontline leadership, sustainability micro-foundations, airport effects) are too thinly described to extract any propositions
  Forskning på digitalisering 2026 uke 19
• incompleteThe article observes that the AI modularity review found duplicate routes, scattered parameters, and misplaced auth — i.e. exactly the things a senior reviewer would find in a half-hour read of the code. There is no contrastive baseline against human-only review, against pair-review with the original implementing agent, or against a much cheaper rubric like 'review every file changed >X times in the last 30 days'. Without such a baseline, the proposition 'the review is the best available sensor' is unfalsifiable on the evidence given.
  Three more static code analysis sensors — read next: DORA reports' methodology on baselines; Beck on test-commit-revert and 'starving genies' as alternative scaffolds for keeping AI-edited code honest.
• incompleteNo engagement with the relationship between this approach and existing fitness-function / architecture-as-code tooling (ArchUnit, NetArchTest, ts-arch, Modulith, even Structure101). dependency-cruiser is one point in a much larger design space; treating it as 'the' dependency-rules sensor leaves the reader without a sense of where the boundary lies between custom configuration and adopting an established framework.
  Three more static code analysis sensors — read next: Ford/Parsons/Kua 'Building Evolutionary Architectures' on fitness functions (which she links to in the framing); ArchUnit; ts-arch.
• uninformedBeck does not engage with emerging genie harnesses (test-driven generation, agentic coding with verification loops) that may already partially address the tarpit problem. The piece is a snapshot observation without surveying the solution space.
  Genie Tarpit — read next: Look at agentic coding frameworks (Cursor, Claude Code, Devin) and their approaches to test-driven AI code generation.
• incompleteNo quality-control story: who reviews tasks, who detects duplicates or trivially-gameable items, who flags contamination when the same agents author both tasks and solutions.
  Kaggle is making AI benchmark creation effortless — read next: HELM and BIG-bench review processes; METR/Apollo on adversarial eval design; the DORA 2025 finding that AI productivity gains correlate with deteriorating evaluation rigor.
• incompleteNo measurable outcomes. 'Hundreds of hours/month' is unanchored to a baseline, a denominator, an accuracy figure, or a cost. There is no comparison to a non-agentic automation alternative (scripts, RAG-only chatbot, runbook automation).
  Designing a Multi-Agent System for Engineering Support at Scale: A Case Study From Grab — read next: Look for the original Grab Tech Blog post (engineering.grab.com/from-firefighting-to-building) for the actual numbers; if absent there too, this is a marketing artifact, not an engineering report. Compare to DORA-style AI productivity measurement methodology.
• incompleteNo discussion of failure modes: hallucinated SQL passing validation, MRs that look correct but introduce regressions, automation bias in reviewers, drift as the platform changes under the agents' indexed context.
  Designing a Multi-Agent System for Engineering Support at Scale: A Case Study From Grab — read next: Literature on automation bias in code review; Google's 'AI in software engineering' DORA findings on review burden.
• uninformedNo acknowledgment that 'permission to learn' presumes a manager with real slack and political cover to grant time for non-job-essential study. In overloaded, deliverable-tracked teams, that permission is often not in the manager's actual gift — the article assumes managerial discretion that may not exist.
  Supporting Your Employees' Career Growth When Everyone Is Overwhelmed — read next: Cutler on power and space in organizations; flow accounting / slack theory (Tom DeMarco).
• incompleteNo measurement or falsifiability: the case study reports 'improvements in execution, engagement, and commercial outcomes' attributed to the redesign, but supplies no baseline metrics, no counterfactual, and no discussion of how much of the improvement to attribute to the intervention versus market conditions, personnel changes, or other confounds.
  How to Turn Individual Talent into Organizational Excellence — read next: Contrast with the corpus's DORA & Engineering Metrics cluster and Cutler/Osmani-style skepticism about attributing organizational outcomes to specific interventions without measurement discipline.
• incomplete'89% of leaders agree AI has accelerated work' — but the article assumes that acceleration is sustained throughput rather than a transient burst as teams adopt new tooling. No engagement with the possibility that the 'AI productivity boom' is a one-time S-curve, not the new steady state.
  Managers Are Struggling to Keep Up with the AI Productivity Boom — read next: DORA reports on AI's effect on engineering throughput; longitudinal AI-adoption studies.
• uninformedThe conversation invokes Peter Senge's learning organisation as one of the three common denominators of Larsen's narrativer but does not interrogate how durably the organism-organisation framing has held up under real conditions over the 30 years since Fifth Discipline. There is a tradition of critique (e.g. Mintzberg on the messiness of organisational learning; recent operations-research literature on actual learning loops in software organisations) that the conversation does not engage with.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Mintzberg's Rise and Fall of Strategic Planning; Argyris on double-loop learning vs Senge's framing; the more recent DORA / Accelerate research on what kinds of learning actually correlate with performance — and what kinds (e.g. 'just keep adapting') do not.
• incompleteThe episode does not address whose work is *invisible* without a title — those without platform, conference speaker credibility, financial cushion, or social safety to speak controversially. Gorman names her own preconditions (cheap living in Drammen, ability to return to retail work) but does not extend the analysis to those whose preconditions do not hold. Title-less leadership in her account is universally legitimated but materially restricted.
  3) Christin Gorman leder uten tittel — read next: Read against Cutler on institutional overload and 'who gets to think' / power and space (TBM 413); against work on visibility and credit allocation in tech (especially gendered patterns); and against critiques of 'thought leadership' as a privilege economy. The Bekk/Kodemaker consulting ecosystem also deserves examination as the platform infrastructure that makes Gorman's mode possible at all.
• incompleteMoe's persistent 'vi' is itself a load-bearing rhetorical pattern that the hosts notice in closing but do not unpack. The episode is a portrait of a person who declines to be individuated — he says 'vi' even when narrating decisions whose intellectual origin clearly lies with him personally. This is consistent with the leadership-through-defaults thesis (the work is the structure, not the speaker) but it also obscures the part of the story that does depend on a specific senior practitioner persistently present in the system for 14 years. The question 'how transferrable is this without Moe (and Stian)?' is not engaged.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in tension with the previous Heis episode on hierarchy (Eikeland, ep 4, alluded to: 'forrige podcast-episoden snakket om... det er sjelden helt flat struktur') and with the leadership-presence strand in the user's library (Cutler on power and space, TBM 413). Beck's writing on senior individuals' role in evolutionary design is a direct anglophone parallel.
• incompleteThe 'organisatorisk gjeld' coinage at the close is the most pregnant unfinished idea in the episode. Moe gestures at the next direction of 'lett og rett' — engineering golden paths for product development itself, with good practices baked into roadmap tooling — but does not work it out. This is exactly the territory where the AI question reconnects: an agentic product-development assistant that encoded the right defaults could be the next instance of 'lett og rett', and would be a Moe-shaped answer to the alienation worry from his essay.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with the user's existing extractions on harness engineering for AI coding agents and on 'Agents Don't Know What Good Looks Like'. The Backstage / Internal Developer Platforms tradition (Spotify) is the obvious anglophone analogue. Team Topologies (Skelton & Pais) and DORA's recent platform engineering findings are the natural canon. Truls's closing observation that Toyota → DORA → Team Topologies is one lineage is exactly the bridge.
• incompleteThe Norwegian / Lean-Norwegian context is implicit but not theorised. The åremål concept comes from Norwegian political and academic life and is being repurposed for engineering leadership. The fagtid concept has roots in Norwegian work-culture autonomy ideas. The DORA / Lean / Toyota convergence Truls names at the end is itself partially a Nordic management-culture convergence. There is a comparative essay latent here that the episode does not write.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in parallel with NAV's 'optimizing for fast flow' piece (already in the user's queue), with Norwegian Self-Determination Theory–inflected management writing (autonomi, mestring, mening), and with the wider tradition of Nordic engineering culture vs. anglophone agile-at-scale. The user's coding-agents corpus already includes Nils Brede Moe (no relation? — but a Nordic empirical-software-engineering voice in the same neighbourhood, including the upcoming Heis episode 9).
• incompletePower and political economy are visible at the edges (the consultant houses' motstand to Mattilsynet cancellations; the 'kjipe' work of handling underperformance) but never named as power. The political cost paid by the consultant houses, by the developers whose subkulturer were dismantled, and by the avdelingsledere who had to take on accountability for cross-team samhandling is not analysed.
  7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke — read next: Cutler 'Power and Space' (TBM 413, already in user's library); Pfeffer 'Power' on organisational politics; Hamel/Birkinshaw on managerial innovation and its political cost.
• 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.
• incompleteAI-as-amplifier is asserted in both directions (good practice → better; bad practice → worse) but the magnitude of asymmetry is not addressed. If AI amplifies bad practice faster than good, the policy implication ('defer AI until guardrails exist') may be stronger than Wedel states.
  12) Greger Teigre Wedel: Når sjefen har svaret, tier resten — read next: DORA 2025 detailed findings; the Dave Farley YouTube series Wedel mentions; any empirical work on AI adoption velocity vs. defect rates.
• incompleteThe 'engineering practices matter more under AI' claim rests on one cited Telenor talk. Strong intuition, weak evidence. A serious version needs DORA-style measurement of practice maturity × AI uplift.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: DORA 2025 (already in user's library); the Entur AI adoption piece; Addy Osmani's agent patterns; any rigorous productivity studies.
• incompleteThe advice to juniors assumes the fundamentals taught today are the right ones; doesn't engage with the possibility that fundamentals themselves need re-curation for a world where LLMs are the second author. What does TDD even mean when test generation is also automated?
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Kent Beck's recent 'Tidy First?' work on AI and design; 'starving genies' series; DORA on AI testing practices.
• incompleteThe claim that AI raises the incentive to live good engineering culture is asserted but not mechanised. Continuous delivery has been well-described for 20 years and only patchily adopted. Why will AI succeed in changing this where the prior decade's tooling, DORA reports, and platform engineering did not? A causal story is missing.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: DORA 2025/2026 specifically on AI's interaction with delivery practices; Birgitta Böckeler and Martin Fowler on AI-coding feedback loops; Kent Beck's TCR work as the practice end of the same idea.
• incompleteThe HOW-sharpening proposal (be sharp on tempo vs. error-tolerance, not on implementation) is offered as a resolution but not tested against the failure modes of values-as-strategy (where 'speed over perfection' becomes a slogan everyone reinterprets locally).
  15) Kari Olrud Moen om strategi, kunsten å velge bort og forskjellen på å være tydelig og skråsikker — read next: Cutler on operating systems and 'making the trade-off visible'; DORA/Accelerate on what concrete operating principles actually correlate with outcomes; Beck's Tidy First? framing for how small-scale design decisions encode strategic posture.
• incompleteStrategy as power is gently visible (who gets the IT-køen priority that Vips got) but not analyzed as power. The political economy of must-win-battles inside a large organization — who loses access to resources, and through what mechanism — is left implicit.
  15) Kari Olrud Moen om strategi, kunsten å velge bort og forskjellen på å være tydelig og skråsikker — read next: Cutler on power and space (TBM 413, recently in user's library); Pfeffer on power in organizations; Helmer/Porter for the strategic value of being explicit about who-loses-what.
• incompleteAI in regulated production code is left as an open problem. The 'humanize ser på koden' (humans review code) regulatory expectation is named, but the speakers don't engage with how Norwegian Finanstilsynet, the EU AI Act, or DORA-style governance frameworks will actually treat AI-generated code in financial production.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: Finanstilsynet guidance on AI in financial services; EU AI Act high-risk system requirements for payments; DORA 2025 findings on AI-assisted development in regulated industries
• incompleteThe speakers describe weekly releases and trunk-based-ish development for the app, but back-end deploy cadence and the cross-team coordination model when 35 product teams plus a payments backbone plus an AI platform team all ship at different speeds is not described in detail.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: DORA 2024–2025 reports on deploy frequency and change-failure rate in financial services; NAV's 'fast flow' writeup that Kjetil has already saved (per persona)
• illogicalThe piece argues both that AI's pace of change is unlike anything the author has seen in 20+ years, and that established change-management patterns from prior technology waves (DevOps, cloud, CD) will straightforwardly transfer — without reconciling why a genuinely unprecedented shift would be well-served by a non-unprecedented adoption playbook. The claim that 'proven methodologies' suffice is asserted, not argued against the claim of novelty made two paragraphs earlier.
  Leading your engineers towards an AI-assisted future — read next: Look for arguments specifically about what, if anything, is structurally different about AI adoption that would break a Mission Command-style rollout — e.g. the rate of tool obsolescence outpacing a Community of Practice's ability to stay current.
• incompleteSame gap as the Golden Bricks extract, in a different colour. The whole programme assumes a Team-Topologies / Spotify-style organisation already exists — stream-aligned squads inside tribes, a platform team adjacent to them, business decision-makers sitting at tribe level. The Federated SRE, production manager, and technical tribe lead are role inventions overlaid on this topology, not designed to produce it. The article describes role responsibilities mechanically but treats the underlying org redesign — the part that costs years and political capital in most enterprises — as already done. For a reader whose org is functionally shaped, this is the part that matters most, and it is invisible.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Skelton & Pais, Team Topologies (esp. the 'enabling team' interaction mode, which is what Federated SREs functionally are). Cutler on operating-model design and accountability layering. Pais on cognitive-load assessment as a precondition for federation. Reinertsen on capacity allocation and queueing — the 20% tithe is a capacity-allocation decision that needs queue-theoretic defence.
• incompleteThe 'democratisation' mechanism is never opened up. The article uses 'democratised SLOs/SLAs' as the load-bearing cultural claim but never explains how democratisation happens — who publishes the SLOs, in what tool, who is allowed to negotiate them, what stops squads from quietly setting easy SLOs to escape scrutiny, what the production manager does when a squad's SLO drifts. Without this, 'data-driven conversations' is a slogan with no enforcement surface. The mechanical specification matters: democratisation without governance is just SLO theatre.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Google SRE Workbook on error budgets and SLO policy (the governance scaffolding democratisation usually rides on). Honeycomb / Charity Majors on observability ownership. Forsgren et al. on metrics that resist Goodhart pressure.
• incompleteThe 20% mandatory squad investment is presented as a structural lever, but the article never says how it is funded. 20% of every squad is a large standing tax on feature delivery; in most orgs this is the single most contested resource decision a CTO can make. The article gives no defence of the figure (why 20% and not 10% or 30%), no description of how it shows up in planning (is it a fifth person, a fifth of everyone's week, a rotation?), no answer to what gets dropped when the rest of the squad's commitments don't shrink. This is the place where the prescription would either hold or shatter in practice.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Reinertsen, The Principles of Product Development Flow, on capacity allocation under variability. Allen Holub on the politics of capacity-as-budget. Cutler on the operating-system level of organisational design.
• incompleteThe four-rebuilds story is reported as triumph but never costed. Destroying and rebuilding the platform architecture four times has a cost — for the consuming squads who must re-learn it, for the regulators who must re-approve it, for the institutional memory that bleeds out at each rebuild. The article reports the platform team's experience ('it worked perfectly for us') without checking the consumer side. The same testimony from the squads might read very differently.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Ford, Parsons & Kua on evolutionary architecture (the disciplined version of what Petean is describing). Hohpe on architecture decision records and the institutional cost of irreversibility. Naur on programming-as-theory-building — what gets destroyed in a rebuild that isn't in the code.
• incompleteCost-per-change is offered as the financial counterpart to DORA but is not interrogated. Of the four reasons given for the decline (platform effect, expertise maturity, federation, massive business scaling), the fourth alone could explain the result via simple denominator inflation. Without weighting or counterfactual ('cost per change held flat through a comparable scaling period before federation'), the metric is decorative. This matters because cost-per-change is the kind of number that gets quoted as proof of platform ROI without the caveats travelling with it.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: FinOps Foundation material on attribution and unit economics. Cutler on signal-vs-noise in metrics. The DORA / SPACE original papers on the limits of self-reported organisational improvement.
• uninformedNo engagement with the existing literature on embedded/federated SRE. Google's SRE Book has a chapter on the embedded-SRE model; the CNCF Platforms WG has written on platform-team interaction modes; Team Topologies' 'enabling team' is functionally close to the Federated SRE role described here. The article presents the three-role pattern as if it were freshly invented, which makes it harder to compare against the failure modes the prior literature documents (embedded SREs going native to squads, central guidance eroding, federation creating shadow operators).
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Beyer, Jones, Petoff, Murphy (eds.), Site Reliability Engineering, esp. the embedded-SRE chapter. CNCF Platforms WG whitepapers on team topologies for platforms. Skelton & Pais, Team Topologies, on the enabling-team interaction mode.
• incompleteNo outcome evidence. The piece asserts the product approach is better but supplies zero before/after data — no reduced backlog, no adoption numbers, no user-satisfaction or lead-time improvement. It persuades by resonance with the reader's own pain, not by measured result.
  Shifting Platform Development from Projects to Products — read next: Mik Kersten, 'Project to Product' (value-stream flow metrics); DORA / SPACE for platform outcome measurement; Evan Bottcher, 'What I Talk About When I Talk About Platforms' (Thoughtworks) for how to evidence platform value.
• incompleteThe empirical evidence is thin and uneven. The nurses study (Woods et al., July 2025) is presented as decisive but is a single study, in a different domain (clinical prediction), with a likely small N; the developer study (METR-style) is cited from memory. Reed does not engage the contrary evidence (e.g., positive AI productivity findings from DORA, GitHub Copilot studies) or distinguish task types where AI does and does not pay off. The asymmetric-risk frame is compelling and probably right but is underdetermined by the cited data.
  Presentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) — read next: DORA 2024/2025 AI findings, the Princeton/MIT studies on developer AI productivity, METR's actual published methodology, Woods's published paper (rather than the slide). Also Cal Newport / Bainbridge-skeptics on whether the operator analogy fits knowledge work.
• incompleteTCO blind spot. The 10,000 DKK figure is Scaleway's invoice. It excludes the engineering team's time to build and maintain the custom UI, evaluate models, manage prompt regressions on model updates, handle incidents, and own the security review. Microsoft's 200,000 DKK at least bundles those responsibilities into a vendor SLA. The fair comparison would include loaded engineering cost — likely 1-3 FTE-equivalent depending on scope, which could be a multiple of the licence savings.
  95% cheaper and sovereign AI: Why we dropped Copilot at Coop Bank — LinkedIn post by Jannik William Frederiksen — read next: DORA/state-of-AI reports on hidden costs of self-hosted AI; HashiCorp/Cloudflare PMOs on build-vs-buy economics; any post-mortem of a 'we built our own ChatGPT' enterprise project at 6/12/24 month checkpoints.
• incompleteSovereignty definition is implicit. 'Rent europæisk cloud-miljø' could mean (a) EU data residency only, (b) EU-owned operating entity (Scaleway parent: Iliad SA, French), or (c) full immunity from US CLOUD Act/extraterritorial discovery. These are very different bars and matter differently to a Danish bank under DORA and Finanstilsynet supervision. Frederiksen doesn't disambiguate.
  95% cheaper and sovereign AI: Why we dropped Copilot at Coop Bank — LinkedIn post by Jannik William Frederiksen — read next: Schrems II commentary; EU Cloud Code of Conduct; Danish Finanstilsynet guidance on cloud sourcing for credit institutions; the EUCS sovereignty levels (High/Substantial) debate.
• incompleteThe quantitative analysis never splits results by role or seniority (e.g., team lead vs. individual contributor), even though the Discussion explicitly flags that team leads' workloads differ structurally from ICs' and that automating a satisfaction-depressing task for one role group might not generalize to another.
  Time Warp: The Gap Between Developers' Ideal vs Actual Workweeks in an AI-Driven Era — read next: A follow-up stratified by role/level would test whether the 'automate PR review, monitoring, communication, mentoring' recommendation holds for team leads as well as ICs, or backfires by removing work that leads specifically value.
• 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 'next thousand prompts' / living-systems point — that real value is in monitoring, evaluation, iteration, and tuning — is asserted but not operationalized. The essay offers no framework for how to actually measure honest AI value (evals, benchmarks, drift detection), which is precisely the verification infrastructure its argument implies is needed.
  Please stop the AI Confidence Theater — read next: LLM evaluation practice, DORA's AI findings on measuring engineering impact, and disciplined benchmark design — directly relevant to the persona's rigorous-adopter interest in what AI tools actually do to productivity and quality.
• conceptualThe piece conflates 'immediate threat' with 'significance'. It is possible for Mythos to be both non-threatening in the short term and genuinely significant as a capability milestone. Marcus's framing does not address this distinction.
  Three reasons to think that the Claude Mythos announcement from Anthropic was overblown — read next: Consider how capability demonstrations that are not immediate threats can still represent meaningful shifts in the possibility space.
• incompleteNo engagement with intermediate options between fully open and fully closed — selective redaction, embargoed releases, signed binaries with private build pipelines, hash-based attestations. The frame is binary, which makes the criticism easier but flattens the design space.
  NHS England rushes to hide software over AI hacking fears — read next: Threat-model literature; the OpenSSF and CNCF supply-chain security playbooks
• incompleteThe 'exception' category for PRs is asserted but not characterized. What counts as 'someone has to change production code without pairing'? Hotfixes? Solo time-zone hours on a distributed team? Documentation-only changes? Without criteria, 'PR for exceptions' can drift back into 'PR by default with a rationale attached.'
  On Pair Programming — read next: Look for engineering blogs on trunk-based-development discipline (e.g. Hammant, DORA reports) and post-PR workflows; also Beck on what XP teams actually do for solo edge cases.
• incompleteThe economics rebuttal ('we are wary of attempts to scientifically prove pairing effectiveness') is rhetorically convenient. It immunizes the practice from quantitative challenge without offering an alternative evaluation criterion beyond 'try it.' For the syntopical question, this matters: managers comparing pair-by-default vs. PR-by-default + AI need some way to choose.
  On Pair Programming — read next: DORA / SPACE / DX framework material on developer productivity measurement; serious cost-of-quality literature.
• incompleteThe counterfactual is narrow: the studies compare open space only against cubicles. They cannot tell a decision-maker what to do instead, only that a cubicles-to-fully-open move backfired — private offices, hybrid/activity-based layouts, and remote/distributed work are untested comparators. Nor can they separate 'losing enclosure' from 'changing who sits nearby'. The implicit assumption that architecture is the right leverage point (rather than norms, incentives, or meeting design) is left unexamined.
  The impact of the 'open' workspace on human collaboration — read next: Read comparative office-typology studies (private vs cubicle vs open vs ABW vs remote) and, in Meadows' leverage-point terms, work on whether interaction is more effectively shaped by rules/norms/incentives than by the physical structure the paper treats as the intervention.
• incompleteA single-organization, self-reported success narrated by the practitioner who leads it — survivorship/selection bias with no comparison organization and no counterfactual. 'Success' is measured largely by report readership and engagement (~4,000 reads, ~5,000 self-logged improvements) rather than by independently verified software-delivery performance or business outcomes.
  DORA Community Discussion - Operationalizing DORA within a large organization — read next: DORA/Accelerate outcome studies linking practices to delivery and organizational performance; controlled or multi-organization evidence on change-adoption results.
• incompleteThe 'golden path vs golden brick' distinction is rhetorical, not analytical. What actually changes when you move from path to brick? The article never decomposes the shift along the three axes where the shift really lives: (a) governance — who owns correctness, the platform team (path) or the consuming team (brick); (b) composability — who designs the assembly, and against what contract; (c) team autonomy — does the consuming team have the decision-rights, time, and skill to assemble well? Without this decomposition, 'bricks' is a slogan, not a model.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Skelton & Pais, Team Topologies (esp. platform team / stream-aligned team interaction modes). Camille Fournier's writing on platform teams. Gregor Hohpe on architecture decision records and IT architecture as conversation. Manuel Pais on the cognitive-load assessment.
• incompleteThe organisational shift the article requires but does not theorise. Bricks-not-paths only works in an organisation that has already pushed correctness, security review, cost ownership, and incident response down into stream-aligned teams. In an org where the platform team is also the compliance team and the on-call team, bricks-without-a-path means each stream team must reinvent guardrails. The piece treats this organisational redesign as free — but it is the actual hard part.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Cutler's TBM essays on institutional overload and accountability. Allen Holub's #NoAccountability work. Conway's Law re-readings (Skelton/Pais). Andrew Clay Shafer / DevOps adoption literature on the politics of platform ownership.
• incompleteStrawmanning of the golden path. In Spotify's original formulation and most current usage, a golden path is an opinionated default route through optional tooling — not 'the single way to do things.' Bryant collapses 'golden path' into 'golden cage' to set up the brick contrast, which makes the move feel sharper than it is. The real design choice is the ratio: which bricks ship with reference compositions (paths) attached, and which don't.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: The Spotify Backstage docs on golden paths. The 'paved road' material from Netflix engineering. Honeycomb's writing on opinionated developer platforms.
• incompleteNo treatment of the leaky-abstraction risk that the brick model amplifies. The more composable the platform, the more surface area developers can latch onto — and the harder it becomes to change the implementation later. Bryant raises leaky abstractions as a warning but never connects them to the brick model, which is precisely where they bite hardest.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Spolsky's original 'Law of Leaky Abstractions.' Ousterhout, A Philosophy of Software Design, on deep vs shallow modules — bricks must be deep modules or the abstraction tax is real.
• uninformedNo engagement with the actual maturity literature on internal developer platforms — CNCF Platforms Working Group whitepaper, Team Topologies' Thinnest Viable Platform concept, the platform-engineering maturity model from PlatformCon. The piece treats the field as if Bryant is naming things for the first time.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: CNCF Platforms WG whitepaper (2023+). Team Topologies' TVP material. McKinsey/ThoughtWorks platform engineering reports for the practitioner-economics view.
• uninformedThe methodology section discloses only respondent count (600, 530 completed) and survey window, with no detail on sampling frame, recruitment channel, or how 'stable layoff rates' compares to independent labor-market data.
  Engineering Leadership Report 2026 — read next: Cross-check the 'stable layoff rates' and burnout claims against independent sources — DORA's own 2026 report, the Stack Overflow Developer Survey, and labor-market tracking (e.g. layoffs.fyi) — to see whether these findings replicate outside a LeadDev/Postman-recruited leadership audience.
• incompleteThe finding that employee feedback (63%) dominates AI-impact measurement while rigorous metrics remain rare (~a fifth of orgs) is presented as a known weakness, but the report collects no data on why — cost, integration difficulty, lack of baseline data, or organizational incentive to avoid rigorous measurement are never explored.
  Engineering Leadership Report 2026 — read next: Read alongside extract-dx-measuring-ai-impact (confounded cross-sectional analyses, amplification/augmentation framework) and extract-leadership-ai-assisted-engineering (average AI metrics hide large per-company variance) for a fuller account of why rigorous AI-impact measurement remains difficult even for organizations that want it.
• incompleteThe claim that AI code quality is 'often low' is stated but not analyzed. Low in what dimension? Maintainability? Correctness? Performance? Architecture? Different quality dimensions have different implications for when and how AI should be supervised.
  SMOC.AI's Post — 5 Minutter: AI og utviklere — read next: DORA 2025 findings on AI and code quality; empirical studies on AI-generated code defect rates
• incomplete'Rigour and engineering practices remain crucial' and the whole quality-pipeline description are reported as retreat consensus that 'seemed to feel...was working well,' with no outcome data (defect rates, cost, cycle time) — continuing the same DORA-empirics gap the corpus already flags for other retreat-adjacent reports (extract-heis-14-oystein-ulseth-pendler-lede-levere#g5; extract-fowler-fragments-july-6#g3).
  Software Design in the Agentic Age: Placing Your Bets — read next: Look for DORA-style or controlled empirical studies of agentic quality-pipeline outcomes at scale, rather than practitioner self-report.
• incompleteNo controlled or even systematically observational study compares Software Teaming (3-14 people on one computer) against solo or pair work; the entire economic case borrows from Pair-Programming-specific literature (Williams, Rico) plus one team's multi-year anecdote. This is a gap the authors themselves repeatedly flag rather than one hidden by the text.
  Software Teaming: A Mob Programming, Whole-Team Approach — read next: Look for post-2022 attempts to measure ensemble/mob programming specifically (not just two-person pairing) with any rigor — e.g., team-level DORA/flow metrics before/after adoption.
• uninformedThe book devotes a dedicated chapter to Remote Software Teaming, which this extraction did not analyze in depth — it is the one place the book directly engages with distribution, the default condition for many of the AI-era, geographically dispersed teams this corpus otherwise tracks.
  Software Teaming: A Mob Programming, Whole-Team Approach — read next: Re-read the 'Remote Software Teaming' chapter directly against current distributed/async-first team norms and tooling.
• incompleteThe entire empirical base is a single team in a single large organization, interviewed once at nine months of practice; there is no before/after comparison, no control group, and no attempt to quantify any of productivity, learning, or quality — the authors' own stated top research priority.
  Mob programming: From avant-garde experimentation to established practice — read next: extract-software-teaming-a-mob-programming-whole-team's own gap on the same lacuna (no controlled comparison for groups larger than a pair) shows the field had not closed this gap even a year later; worth tracking whether any post-2022 study (DORA/flow metrics before/after adoption) exists.
• incompleteVendor incentive distortion in the 'whole ecosystem is accelerating' claim
  Itchy Brain (Still Burning: Michael Grinich & Kent Beck on AI adoption, enterprise developer tools) — read next: DORA 2025 and the Stanford/Microsoft developer-productivity studies on AI's actual code-quality effects; Gergely Orosz on enterprise sales-cycle compression; Marc Andreessen's classic 'why software is eating the world' for the prior pattern. For the contrarian counterweight: Gary Marcus and Ed Zitron on whether the AI productivity story is being narrated by the people selling it.
• uninformedThe central quantitative claim (30-100x productivity) and the five-year prediction (no AI-naive Scrum team employable by 2030) are stated with no methodology, data source, or citation. This is the kind of confident, unqualified AI-transformation prediction that other documents in this corpus explicitly warn against (practitioners elsewhere in the corpus argue nobody has the data to be that confident) and that measured studies (DORA) show producing far smaller, sometimes negative, effects.
  Is Agile Dead? How AI and Extreme Agile Redefine Work — read next: Compare against DORA's 2024/2025 State of DevOps findings, which measure AI-adoption effects in low single-digit percentages, not multiples — a direct empirical counterweight to this article's order-of-magnitude claim.
• survivorship bias riskThe 'natural emergence' argument draws on teams that succeeded. Teams that tried these practices and failed, or high-performing teams that use different approaches, are not discussed.
  T*D — read next: Examine DORA data more carefully for whether TBD is necessary or merely correlated; look at high-performing teams using different workflows (e.g., Linux kernel's patch-based model).
• incompleteThe article doesn't address the organizational power dynamics that make stewardship habits hard to sustain. Who has the authority to insist on these practices? What happens when a new VP arrives and disrupts the habit? The argument assumes a continuity of leadership and culture that many organizations lack.
  TBM 416: Investment Stewardship (As Habit) — read next: Literature on organizational routines and institutional memory (e.g., Nelson & Winter's evolutionary theory of the firm) would strengthen this argument.
• incompleteThe Bayesian updating framework is invoked but never operationalized. What are the priors? What counts as evidence? How do you avoid anchoring bias in your priors? The metaphor does real work in the argument but remains at the level of analogy.
  TBM 416: Investment Stewardship (As Habit) — read next: Douglas Hubbard's 'How to Measure Anything' provides practical methods for Bayesian estimation in business contexts that could concretize this.
• incompleteThe article conflates two distinct audiences: engineering leaders who need to practice stewardship, and executives/finance who need to ask better questions. The five action steps mix both perspectives without differentiating who owns each behavior.
  TBM 416: Investment Stewardship (As Habit) — read next: Exploring the principal-agent problem between engineering and finance would sharpen the argument about whose habit this needs to be.
• incompleteThe PE aside is presented as a concession but actually undermines part of the thesis. If PE firms can arrive and quickly create clarity through explicit models, that suggests some form of cold-start IS possible -- just a reductive one. The author waves this away without fully engaging the tension.
  TBM 416: Investment Stewardship (As Habit) — read next: A more careful treatment would distinguish between types of clarity: PE provides cost-side clarity but not value-side clarity, which is the harder problem the article is actually about.
• incompleteAI/agent-assisted development is conspicuously absent from an essay published in 2025/2026 about how teams are defined. If a meaningful share of engineering work is mediated by agents, the definition of 'team', headcount-as-cost, and the engineering manager's role all shift. Cutler doesn't touch this, though it is plausibly the next pendulum swing.
  TBM 423: Why Defining Teams Is So Hard — read next: DORA AI capabilities report; Kent Beck on AI-assisted design ('Tidy First?' series); Addy Osmani / Steve Yegge on agentic engineering; Cutler's own TBM pieces on institutional overload and AI (TBM 412).
• incompleteNo account of mechanism or scale. Cutler's clearest example of mirroring is a two-party coaching dyad (you, the coach, the scale), but his own solo-vs-collective distinction makes the collective the hard case. How a leader practically moves a whole team or organization from mirrors to mirroring — how many people 'draw the map side by side' at once — is not addressed.
  TBM 426: The Trouble With Mirrors — read next: Read facilitation and large-group-intervention literature (Open Space, liberating structures) and Peter Block's Community for community-scale practices that operationalize joint meaning-making beyond the dyad.
• incompleteThe entire framework depends on placing an asset on the value-created x carrying-cost 2x2, but the piece never operationalizes either axis -- no metrics, proxies, or even a single worked numeric example are given for how a team would actually locate a real asset on the diagram. Every judgment in the piece (Incubate vs. Compound, rational leverage vs. dangerous debt) presupposes an assessment the piece itself never shows how to make.
  TBM 430: Incubate, Compound, Refinance, Liquidate — read next: extract-tbm-416-investment-stewardship-as-habit's argument that ROI understanding is 'continuously practiced behaviors, not a calculation' supplies the missing discipline (habitual signal-gathering) this piece assumes but doesn't build; DORA/Core 4 cost-of-delay proxies could operationalize 'carrying cost' concretely.
• incompleteNone of the four variables is defined operationally or made measurable -- there is no way to observe, score, or compare 'Machine Understanding,' 'Problem Understanding,' 'Practice Evolution,' or 'Social Contract' for a given organization, so the essay's most emphatic claim (denominator collapse dominates any numerator strength) cannot actually be tested against a specific case.
  TBM 431: The Denominator That Matters — read next: TBM 430's own unresolved gap about un-operationalized axes (extract-tbm-430-incubate-compound-refinance-liquidate#g1); DORA/SPACE literature on operationalizing soft organizational constructs into measurable proxies.
• uninformedThe evidence base is a set of hand-picked industry case studies presented as successes; there is no longitudinal or comparative data on organizations that adopted the four-topology model and did not see improved flow, or that abandoned it.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow — read next: Look for independent post-adoption research (e.g., DORA/Accelerate-style empirical studies) measuring flow metrics before/after Team Topologies adoption specifically, rather than case narratives selected by the authors.
• incompleteThe document identifies the productivity/experience paradox but offers no framework for resolving it beyond the 'agent experience' reframe. How should organizations actually measure and invest in developer satisfaction when it is decoupled from output?
  The Future Of Software Engineering — read next: DORA team's ongoing research on developer experience metrics; Nicole Forsgren's work on SPACE framework
• incompleteThe batch-size regression is flagged as an 'active regression needing industry attention' but no countermeasures are proposed beyond general governance reform.
  The Future Of Software Engineering — read next: DORA State of DevOps reports; continuous delivery literature on changeset sizing with AI tools
• uninformedThe document is an industry-wide, cross-client synthesis produced by a 22-person advisory board; it does not — and structurally cannot — speak to how any of these recommendations play out inside a specific team's existing culture, legacy codebase, or organizational politics. Every blip is stated as a general recommendation, not a contingent one.
  Technology Radar, Volume 34 — read next: Pair with team-level case studies or first-person practitioner accounts (e.g. this corpus's own harness-engineering and agent-config-decay extractions) to ground the Radar's generalizations in a specific team's experience.
• incompleteThe load-bearing implicit premise — that voluntary action by incumbents, labs, and self-starting individuals can deliver the mechanism design and tidying required — goes undefended. Government, regulators, and organized labor appear only as obstacles (DOGE as wrecking ball, Kaiser nurses as bargaining problem), never as design partners. This narrows the solution space to a Silicon Valley-friendly subset.
  The Tidy House — read next: Mariana Mazzucato on the entrepreneurial/mission-driven state; Daron Acemoglu & Simon Johnson 'Power and Progress' on who captures the surplus from general-purpose technologies; recent labor-side accounts of AI rollout (Wendy Liu, Brian Merchant).
• illogicalCausality between Code Health and the dependent variables (defects, dev time) is not established, only correlation across 39 codebases -- the paper itself names this as a threat to internal validity (low quality could be a symptom of time pressure or churn rather than a cause) -- yet the Discussion and Conclusion sections repeatedly use causal framing ('the business advantage of high quality code should be unmistakably clear') without hedging to the same degree as the Threats to Validity section.
  Code Red: The Business Impact of Code Quality -- A Quantitative Study of 39 Proprietary Production Codebases — read next: Look for a follow-up randomized or quasi-experimental study (the authors propose RCTs or Bayesian causal analysis) that isolates the causal direction between code quality and defect/time outcomes.
• incompleteAll 39 codebases come exclusively from CodeScene's own customer base, and the paper cannot disclose selection criteria or codebase identities for confidentiality reasons. Companies that already pay for a code-quality tool are plausibly a non-random, quality-aware sample, which the paper notes as an external-validity threat but does not attempt to bound.
  Code Red: The Business Impact of Code Quality -- A Quantitative Study of 39 Proprietary Production Codebases — read next: Look for an independent replication using a non-CodeScene-customer dataset or a different code-health/quality metric to check whether the 15x/124%/9x figures hold outside CodeScene's own customer base.
• incompleteFramework-neutrality is asserted in form (the patterns) but undermined in substance. The code uses google.adk; the only named runtime is Google Cloud Agent Runtime; the CTA is the Gemini Enterprise Agent Platform; A2A is Google-backed; the seven-day persistence number is a vendor capability claim. A reader trying to implement these patterns on LangGraph, the Anthropic SDK, OpenAI Assistants, Mastra, or a homegrown stack has to translate every prescription — and several (notably 'zero-compute pause' and 'sub-second cold start') are runtime-dependent guarantees, not just design choices.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Read 'Anthropic's three-agent harness' and 'Anthropic harness design for long-running application development' for how the same problem space looks from the SDK-and-harness perspective rather than the managed-runtime perspective; read 'Block Goose' and 'OpenClaw setup' for OSS-stack equivalents.
• incompleteNo serious treatment of how enterprise adoption of coding agents (procurement, security review, on-prem options, audit logging) might break the consumer-distribution argument — enterprise developer tools are a distinct moat from consumer MAU.
  Why Google Isn't Chasing Claude Code — read next: Pragmatic Engineer on enterprise AI adoption; DORA 2025 AI findings; pieces on agent governance in regulated industries.
• incompleteThe Jevons-on-cognition forecast is asserted, not argued through to its qualitative differences
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Carl Benedikt Frey 'The Technology Trap' on the political economy of transitional displacement; Brad DeLong on what 'creating new categories of work' has actually looked like historically; Anton Korinek and Daron Acemoglu on AI-and-labor specifically. For the contrarian side: Erik Brynjolfsson on the J-curve (gains that show up late and unevenly); the Robin Hanson 'Age of Em' tradition for the qualitative-difference-of-cognition objection. Persona-relevant: DORA 2025 on AI's actual code-quality effects.