Near-Zero-Cost Code

The collapse of the marginal cost of producing code and cognition toward zero — and the redistribution of value toward judgment, direction and verification that follows.

Also known as: marginal cost of (creating) software → zero, marginal cost of software, kode blir gratis ('code becomes free'), kode blir gratis, code becomes free, cheap code, Frozen human competence, laziness (Cantrill's sense), the descaling / industrialization of cognition

How authors use it

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

Documents (20)

• Erik van der Pluijm's Post Erik van der Pluijm · 2026-10-08 source ↗ Reader 🖥️
  When Claude Code collapses the time to build software, the 2-week sprint (and the ceremonies and metrics built around it) stops fitting, but this doesn't mean Scrum has failed — because Scrum was always about empiricism (tight feedback loops of inspect-and-adapt), not about sprint length, so the right response is to compress the cycle to 2 days, drop effort-based metrics (story points, velocity), and replace them with a recurring value judgment ('should this ship?').
• Andreessen Horowitz's Post Andreessen Horowitz (content by Anish Acharya) · 2026-09-12 Reader 🖥️
  The commoditization of raw AI intelligence is relocating competitive advantage, founder attention, and market risk away from model capability and business-side execution and toward what commodity intelligence cannot itself supply — technical depth, product packaging, and pre-existing non-AI moats — while most observers, still fixated on the bubble-or-not framing, are underestimating how far this shift still has to run.
• AI Is Changing the Rules of Entrepreneurship Victor P. Seidel, Bret Greenstein, Thomas H. Davenport · 2026-09-09 source ↗ Reader 🖥️
  AI has moved entrepreneurship from a resource-scarcity paradigm (the lean startup, optimized around scarce capital and labor) to a resource-abundance paradigm the authors call 'abundance entrepreneurship,' in which a single founder can orchestrate AI agents to generate, build, and run many ventures in parallel -- so the challenge for entrepreneurs and established firms alike is no longer gaining access to scarce resources but organizing abundant ones, which shifts the binding constraint to founder attention, judgment, and the domain expertise needed to tell which abundant option is actually worth pursuing.
• Presentation: The Future of Engineering: Mindsets That Matter When Code Isn't Enough Ben Greene · 2026-07-28 Reader 🖥️
  Software engineers remain valuable in the age of coding agents not because they can still write code, but because building working systems still requires disciplined simplicity, deliberately protected comprehension, willingness to attack hard problems first, and human empathy for customers — capacities coding agents lack and that startups have always demanded of engineers under resource pressure.
• AI Demands More Engineering Discipline, Not Less Charity Majors · 2026-07-27 source ↗ Reader 🖥️
  AI's collapse of the cost of writing code doesn't reduce the need for engineering rigor — it relocates that rigor away from the code itself and into the validation, observability, and feedback infrastructure surrounding it, which is why nondeterministic AI-generated systems demand more engineering discipline, not less.
• The case for making your own apps Casey Newton · 2026-07-22 source ↗ Reader 🖥️
  As AI collapses the cost of building software toward zero, a large and growing share of the software people use — within a few years, plausibly a third to half of it — will be hyper-personalized, disposable software they (or their friends and colleagues) make themselves, which will hollow out commercial SaaS products whose value was mainly a mediocre one-size-fits-all UI while sparing those that hold irreplaceable data or can operate headlessly.
• Why did Martin Fowler invite 60 engineers to a ski resort? Ivett Ördög · 2026-07-05 source ↗ Reader 🖥️
  The turn to AI-built software has reopened rather than resolved the foundational questions of the craft — should humans still read code, how do we know it works, does code quality still matter, and how do we manage newly-empowered citizen developers — and the author's connective throughline is an optimistic one: AI democratizes building while the disciplines that make code good for humans remain exactly the ones that make it good for AI.
• What Survived Contact Sam Ruby · 2026-07-01 source ↗ Reader 🖥️
  When agents write the code, rigor does not vanish but migrates to the objective and its evaluation; directing an agent is therefore a management act (a hire, not a tool-use) whose one non-delegable duty is owning the objective and the oracle that checks it.
• You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) Kent Beck — Still Burning Podcast · 2026-06-03 Reader 🖥️
  Cognition is becoming near-free, and per Jevons paradox that will produce more cognitive work and more engineers, not fewer — but the people best prepared for this regime are exactly the ones who already lived through writing the distributed-systems playbook, because they know two things the panicking crowd forgets: that a playbook is hard-won and not obvious until written, and that the human compulsion underneath all of this is the maker's need to create the thing rather than merely transcribe it (the 'you don't get to create anything' moment that drives Shoup out of patent law and back into engineering); accordingly the right posture is calm, perspective-keeping, deductive engagement with the new regime — bounding the genie with specs/evals, making good practices easier rather than shaming the bad, and treating this as another wave of physics-discovery rather than a hype cycle or an apocalypse.
• Itchy Brain (Still Burning: Michael Grinich & Kent Beck on AI adoption, enterprise developer tools) Kent Beck — Still Burning Podcast · 2026-05-20 Reader 🖥️
  We are not in another technology hype wave but in a step-function transformation: the marginal cost of producing software is collapsing toward zero, large incumbents are adopting AI faster than any prior shift, and the whole ecosystem — not just the AI labs — is accelerating; in this 'Red Queen' regime, profit and productivity may not visibly improve because every competitor is running at the new tempo, so the only sane response is to paddle straight into the wave by sustaining the maker's compulsion (the 'itchy brain'), reshaping engineering leadership toward hands-on impact, and accepting that software engineering as a profession will resemble medicine or law more than the unique 2010s template that minted six-figure undergrads.
• Vibe coding and agentic engineering are getting closer than I'd like Simon Willison · 2026-05-08 source ↗ Reader 🖥️
  As AI coding agents become more reliable, the experiential distinction between 'vibe coding' (unreviewed, low-accountability coding) and 'agentic engineering' (expert-supervised AI coding) is collapsing, which forces practitioners to find new trust signals — usage over inspection — while the entire software development lifecycle must restructure around dramatically cheaper code production.
• The Founder's Playbook: Building An AI-Native Startup Claude (Anthropic) · 2026-05-05 source ↗ Reader 🖥️
  Because AI now collapses the cost of building, researching, and operating a company, the AI-native founder's job is no longer execution but orchestration of AI across four stages (Idea, MVP, Launch, Scale), and a small (often single-founder) team that systematically routes work through Claude, Claude Cowork, and Claude Code can reach outcomes that previously required a fully-staffed organisation.
• The AI paradox: More automation, more humans, more work | Dan Shipper Lenny Rachitsky (host); Dan Shipper (guest, CEO Every) · 2026-05 Reader 🖥️
  Despite radically improving model capabilities, the agentic era will paradoxically generate more work for more humans — because every agent needs a human gardener, SaaS persists (with users bringing their own tokens via Codex/Claude Code), and progress merely commoditizes yesterday's competence and pushes humans further up the value chain to define what is worth doing next.
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) Lenny's Podcast · 2026-04-23 Reader 🖥️
  In an era of rapidly improving AI models, the PM role must shift from multi-quarter planning and cross-functional coordination toward radical speed of execution, product taste, and the ability to continuously adapt the product harness to extract maximum value from each new model generation.
• Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project Adam Wolff · 2026-04-20 source ↗ Reader 🖥️
  When AI drives implementation cost to near zero, the competitive advantage shifts from planning and coding speed to the speed of your feedback loop — how fast you can ship, learn from users, and reverse course — making experimentation, not upfront design, the right engineering strategy.
• Radar Trends to Watch: May 2026 Mike Loukides and Claude · 2026-04-20 Reader 🖥️
  The AI industry is rapidly moving from experimental models to operational infrastructure — agents, orchestration layers, and security tooling — and the central tension is between open deployment and controlled access, a tension most visible in the divergent approaches to frontier security capabilities taken by Anthropic (restrict) and OpenAI (release).
• The keyboard was never the bottleneck Mike Amundsen · 2026-04-16 source ↗ Reader 🖥️
  Generative AI commoditizes the lowest levels of programming work — producing code for known problems under fixed assumptions — but the harder, higher-level challenges of designing systems that survive change remain untouched and are now more visibly important.
• Design at the Speed of AI Stitch (Google) · 2026-04-10 source ↗ Reader 🖥️
  Stitch promises to collapse the gap between design ideation and production-ready UI code by using generative AI: describe what you want, get both editable visual designs and exportable code, instantly and for free.
• 11) AI-spesial med Vilde Opsal og Anders Sveen Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-02-16 source ↗ Reader 🖥️
  AI-assisted development is a real step up in abstraction that pays off only when teams pair it with judgment, structure and active learning — speed gains come from agentic tooling, but durable value comes from evals, information architecture and refusing to outsource learning to the model.
• Fragments: February 4 Martin Fowler · 2026-02-04 source ↗ Reader 🖥️
  AI is reshaping the developer's relationship to understanding: it can erode comprehension of the systems we build, is wisely used to navigate toward an answer but never trusted for the answer itself, and may make code cheap enough that the specification becomes the durable engineering artifact.

Tensions

Open gaps (63)

• incompleteNo evidence or data backs any of the seven claims — no churn rates behind the 'fair-weather developer' claim, no benchmark numbers behind the two-to-three-lab shift, no GPU price figures, no revenue or margin data behind 'value is in packaging.' Every claim rests on the authority of a single VC firm (and its general partner, Ben Horowitz) with a direct financial interest in several of the claims being true (e.g. that founders don't need business sophistication, that packaging companies — the kind a16z funds — capture the value labs leave behind).
  Andreessen Horowitz's Post — read next: Cross-check specific claims against the corpus's evidence-heavier sources: the H100-pricing claim against extract-baseten-ceo-inference-crunch (which independently gives the same H100 aging/price-rising fact with a number attached), and the margin/value-capture claim against extract-hbr-ai-looming-competition-for-margin (which argues the opposite — that applications built on broadly accessible models are hard to defend, i.e. margin erosion, not packaging-layer capture).
• uninformedPoint 2's founder-profile claim (less business sophistication, more technical/research depth) is presumably drawn from a16z's own portfolio-founder population — a strongly selection-biased sample, since a16z disproportionately funds deep-tech/AI-infrastructure founders — with no comparison to founder profiles in less technical-AI-adjacent startup categories.
  Andreessen Horowitz's Post
• misinformedThe LinkedIn teaser text promises '8 signals worth paying attention to,' but the graphic contains exactly 7 numbered points — a small, concrete internal inconsistency in the post's own production, worth flagging even though it doesn't affect the substance of the 7 signals themselves.
  Andreessen Horowitz's Post
• incompleteThe piece does not address the token, compute, or latency cost of continuously regenerating code from specs or architecture rather than editing it in place — a cost this corpus's own extraction of 'Software Design in the Agentic Age' explicitly flags as unresolved industry-wide.
  AI Demands More Engineering Discipline, Not Less — read next: Read cost-of-regeneration analyses (token economics, verification overhead) before assuming continuous regeneration is economically superior to durable, maintained code.
• uninformedNo mention of legal or IP questions raised by AI-generated business assets -- copyright status of AI-generated code, branding, and marketing copy, or liability when an autonomous agent like Felix independently spends capital and enters payment transactions.
  AI Is Changing the Rules of Entrepreneurship — read next: Legal scholarship on AI agent liability and the IP status of generative output; regulatory commentary on autonomous agents holding and spending capital.
• incompleteSycophancy and the 'illusion of progress' are named as core challenges, but the only prescribed mitigation is a general exhortation to 'leave their computers for the real world of commerce' -- no concrete practice (adversarial-critic prompting, real customer-validation gates, third-party audits) is offered, even though this is the crux of the 'expertise still matters' argument.
  AI Is Changing the Rules of Entrepreneurship — read next: Corpus material on adversarial-critic prompting patterns explicitly names the same unresolved failure mode -- see extract-eating-my-own-dog-food-ai-autonomy-framework#g5 ('model sycophancy despite hostile persona, critique that is adversarial in tone but generic in substance').
• incompleteThe conversation is entirely from Anthropic's perspective. No competing viewpoints from OpenAI, Google, or independent practitioners are represented. The interview format means Lenny largely agrees with and amplifies Cat Wu's positions rather than stress-testing them.
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Read critical analyses of Anthropic's approach from outside observers; compare with product practices at other frontier labs.
• incompleteThe 'just do things' philosophy and extreme speed of shipping are presented as unqualified goods. The costs (product consistency, user confusion, bugs shipped) are acknowledged but treated as acceptable trade-offs without exploring when they become unacceptable — particularly for enterprise customers who need stability.
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Look at enterprise SaaS literature on release management and the cost of change fatigue for large organizations.
• uninformedThe discussion of Co-work replacing tedious PM tasks (decks, meeting prep, email triage) lacks any engagement with the quality ceiling problem: are these AI-generated outputs actually good enough for high-stakes contexts, or do they create a mediocrity trap?
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Seek empirical studies on AI-generated content quality in professional settings; read critiques of 'good enough' AI output.
• incompleteThe Open Claude decision is framed purely as a resource allocation choice. The community trust cost and the broader ecosystem implications of an AI company restricting how its model can be accessed through third-party tools are not explored.
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Read platform economics literature on ecosystem lock-in; review community responses and long-term effects of similar decisions by other platform companies.
• scopeThe page targets 'founders and PMs' — people who are not designers. It is silent on whether professional designers would find value in the tool or whether it threatens to deskill the profession.
  Design at the Speed of AI — read next: Look for professional designer reactions and analyses of how AI design tools affect the design labor market
• argumentativeThe implicit equation 'faster = better' is never interrogated. The page assumes that the bottleneck in product development is design speed, but the actual bottleneck may be understanding what to build, not how fast you can produce a UI for it.
  Design at the Speed of AI — read next: Read Marty Cagan (Inspired/Empowered) on discovery vs. delivery; the argument that shipping faster only helps if you're shipping the right thing
• technicalNo information on what models power the generation, what training data was used, what design patterns are baked in, or how customizable the outputs are beyond 'editing'.
  Design at the Speed of AI — read next: Look for Google's technical documentation or API docs for Stitch
• incompleteAll three case studies come from a single team (Claude Code at Anthropic) building a CLI tool with unusually tight dogfooding loops. The argument that experimentation should replace upfront design is not tested against contexts with higher costs of failure (healthcare, infrastructure, finance), longer feedback cycles, or larger teams where coordination costs dominate.
  Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project — read next: Literature on high-reliability organizations (e.g., Normal Accidents by Perrow); experiences of AI adoption in safety-critical domains
• incompleteThe talk assumes a small, highly skilled team that can make and evaluate architectural decisions rapidly. No discussion of how these practices scale to larger organizations where most engineers are not senior architects.
  Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project — read next: Team Topologies (Skelton & Pais); research on scaling agile and continuous deployment in large organizations
• uninformedThe SQLite analysis conflates SQLite's limitations with the specific way it was deployed (npm native dependency distribution, Better-SQLite3 binding). SQLite-via-WASM (e.g., sql.js) would have avoided the native dependency problem entirely. The multiprocess locking concern is real but standard WAL mode mitigates it significantly.
  Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project — read next: SQLite documentation on WAL mode; sql.js and other WASM-based SQLite distributions
• incompleteVendor risk is structurally absent. The playbook never names that 'AI-native' as defined here means 'Anthropic-native'. Customers building this way inherit Anthropic's pricing, capability, rate-limit, and product-strategy decisions as critical-path dependencies — exactly the workflow lock-in pattern the Scale chapter prescribes against competitors.
  The Founder's Playbook: Building An AI-Native Startup — read next: Contrast with Cloudflare 'Mythos' retro (already extracted) on what depending on a single AI vendor's pricing and capability surface looks like under stress; read multi-model / model-portability discussions and 'OpenRouter-style' abstraction-layer arguments.
• incompleteNo unit economics. The playbook celebrates leanness in headcount but is silent on token cost at company scale. A 5-person AI-native startup serving 100k users may have COGS that look nothing like the 200-person SaaS company they're imitating. Margin structure, model-price exposure, and gross-margin scenarios are absent.
  The Founder's Playbook: Building An AI-Native Startup — read next: Read recent inference-cost analyses (Baseten, public AI-startup tear-downs); compare to a SaaS gross-margin baseline. Useful: any first-hand founder writing on token-economics post-PMF.
• incompleteExisting-organisation applicability is zero. The reader (a senior engineering leader at an incumbent) gets no help translating this. Almost every prescription assumes a greenfield codebase, no legacy team, no existing change-management constraints, no negotiated CTO/CISO relationship, and full founder authority — none of which holds inside an established organisation.
  The Founder's Playbook: Building An AI-Native Startup — read next: Read incumbent-transformation pieces (Entur AI adoption, NAV fast-flow); Cutler's organisational-operating-system writing; any 'AI in regulated incumbent' case study (Norwegian or otherwise).
• incompleteRegulatory and data-sovereignty depth is absent. Compliance is treated as a Launch-stage to-do (SOC 2, GDPR, HIPAA) rather than a structural constraint. The EU AI Act, Norwegian public-sector procurement, data residency obligations, on-prem requirements, and sector-specific (finance, health, defence) constraints are not discussed and would invalidate or substantially reshape parts of the playbook.
  The Founder's Playbook: Building An AI-Native Startup — read next: EU AI Act practitioner guides; Norwegian DigDir / NSM guidance on third-party AI; Healey's AI-advisory-board piece (already extracted) on AI governance inside organisations.
• incompleteThe model-capability-curve assumption is unnamed but everywhere. The whole playbook implicitly assumes models keep getting better, cheaper, and more available at current rates. If that curve plateaus or regresses, the orchestrator-without-team model becomes much weaker, but the playbook gives no scenarios for that.
  The Founder's Playbook: Building An AI-Native Startup — read next: Gary Marcus and other capability-skeptic writing; cost-curve and scaling-limit discussions; Anthropic's own harness-engineering paper (already extracted) which is more candid about current limits.
• incompleteArchitectural-coherence prescription (CLAUDE.md, specs before code) is good advice but is reintroducing classical software-engineering discipline (formal specs, ADRs, design docs) without acknowledging the lineage. The implicit message — 'this is new' — undersells how much of the prescription is rediscovery.
  The Founder's Playbook: Building An AI-Native Startup — read next: Re-read Kent Beck (Tidy First?), structured-design literature (Yourdon & Constantine), and ADR/design-doc practice writeups against the playbook's reframing.
• illogicalThe non-technical-founder claim and the architectural-discipline claim are in tension. If the prescribed engineering practice (CLAUDE.md, security review, debt remediation, observability) requires architectural judgement, then 'non-technical founder' is doing a narrower kind of work than the document suggests — likely 'prototype and validate', not 'run a Scale-stage company solo'. The playbook never reconciles this.
  The Founder's Playbook: Building An AI-Native Startup — read next: Non-technical-founder case study autopsies; the 'who survives the MVP-to-Launch transition without an engineer' empirical question.
• incompleteSectoral / geographic narrowness. Every example is US, SaaS-shaped, English-language, B2B-leaning. Norwegian / Nordic / public-sector / non-SaaS / B2C / hardware startups are entirely absent.
  The Founder's Playbook: Building An AI-Native Startup — read next: NAV's fast-flow piece; Entur AI adoption; any Nordic-context AI-startup writing.
• incompleteAttention and institutional memory of the founder herself is unaddressed. The playbook moves the founder from execution to orchestration but never asks what kind of attention infrastructure the orchestrator needs, what cognitive failure modes emerge when one person owns judgement across all domains, or how a solo orchestrator builds organisational memory beyond their own head. This is precisely the hidden-layer concern (Bailey, Stolen Focus, Cutler on overload) the reader cares about.
  The Founder's Playbook: Building An AI-Native Startup — read next: Cutler TBM 412 (institutionalised overload + AI), Bailey on attention infrastructure, anything on cognitive load of high-context orchestration roles.
• incompleteThe argumentative framing — 'AI-native is the right framing' — is never set against its alternative ('AI-augmented' as integration into existing patterns; 'AI-using' as a feature choice). The playbook treats 'AI-native' as the default future rather than as one strategic posture among several.
  The Founder's Playbook: Building An AI-Native Startup — read next: Read alternative framings: AI-augmented engineering writeups, smallcode-style minimalism (already extracted), and the broader 'is AI-native a category or a marketing label?' debate.
• incompleteThe spec-only library is demonstrated on a trivial, cleanly specifiable domain (timestamp-to-phrase formatting); the piece does not address whether spec-plus-tests scale to domains with emergent, under-specifiable, or performance-critical behavior, where the spec may grow as complex as the code it replaces.
  Fragments: February 4 — read next: Read on the limits of spec-driven development and where specifications stop being cheaper than implementations.
• incompleteGreene's evidence throughout is drawn almost entirely from his own two startups (InsightSquared, Outcomes4Me) plus one recent personal side project (the Android RAG proof-of-concept); no comparative case is offered of a startup or team that ignored these mindsets and what happened as a result, nor of a larger, less resource-constrained organization successfully applying the same lessons. It is left open whether 'the lessons startups have always taught us' generalize past small, high-autonomy, high-trust teams.
  Presentation: The Future of Engineering: Mindsets That Matter When Code Isn't Enough — read next: Seek accounts of these same mindsets (start simple, protect comprehension, attack hard bits first) applied — or failing to apply — inside larger, less autonomous engineering organizations.
• incompleteThe conversation explicitly opens but does not close the team-augmentation question — what does multi-agent + multi-human team coordination look like in practice? Vilde admits FINN/Vend has not cracked it.
  11) AI-spesial med Vilde Opsal og Anders Sveen — read next: Nils Brede Moe (Heis ep 9) on AI paradox + autonomy + learning culture; Pocock workshop on harness design for long-running agent teams; emerging literature on multi-agent code review and orchestration.
• incompleteNorwegian/Nordic constraints (persondata, public-sector compliance, sovereignty, DPA-with-Anthropic) are mentioned repeatedly but never developed into a coherent picture of how the Norwegian stack will diverge from the US default agent stack.
  11) AI-spesial med Vilde Opsal og Anders Sveen — read next: Smidigposten / Norwegian agile community pieces on public-sector AI; sovereign-AI / data residency discussions; Vipps/DNB/NAV-specific writeups.
• uninformed (in a time-stamped sense)The episode is explicitly dated end of January 2026 and pre-DeepSick announcement; the participants flag this themselves.
  11) AI-spesial med Vilde Opsal og Anders Sveen — read next: Re-listen after major model releases; compare against follow-up Heis special when produced.
• incompleteThe paradox is asserted but its mechanism is under-specified. Shipper offers 'every agent needs a human' (a maintenance claim), 'benchmarks miss prompting' (an attention claim), and 'models commoditize yesterday's competence' (a frontier claim). These are three different mechanisms doing different work, and Shipper conflates them. The maintenance claim is explicitly transient — he concedes personal agents return as models improve. The attention claim is partially circular — he will redesign his benchmark to zero out a saturated model. Only the frontier claim is structural, and it is the least developed. A serious version of the thesis needs to argue that the new frontier work is itself non-automatable and remunerated — neither is shown.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Acemoglu & Restrepo on task displacement and reinstatement; the 'augmentation vs. automation' literature (Brynjolfsson, Mitchell); recent econometric work on AI's effect on call-centre and software-engineering productivity (the GitHub Copilot RCT, Brynjolfsson-Li-Raymond on generative AI in customer support)
• incompleteThe 'humans-as-orchestrators' vision is unfalsifiable in this conversation. Shipper says explicitly that when models 'saturate' his senior-engineer benchmark, he will redesign it to zero out the current model. If the benchmark moves to wherever AI cannot yet go, the claim 'humans are still needed' is true by construction and tells the listener nothing about the actual trajectory of automatable knowledge work. A senior engineering leader needs a falsifiable formulation — what specifically would need to be true for Shipper to concede that the 'more humans' claim has expired? — and the conversation does not offer one.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Popper on falsifiability; Sutton's 'bitter lesson' as the counter-frame; the eval-design literature (HELM, MMLU saturations, the ARC-AGI debate); recent critiques of human-baseline benchmarks (Anthropic's METR work on long-horizon agentic tasks)
• incompleteSelection effects in the Every case are uninterrogated. Every is ~30 self-selected curious early adopters with pre-release model access, dual media-and-software business model, founder writer-CEO, no legacy systems, no regulated environment, no enterprise sales process longer than the model release cycle. Every assertion in the conversation is sourced from this one organization and projected onto knowledge work in general. For evaluating organizational impact in a Norwegian enterprise context (regulated industries, slower procurement, less English-language model access for non-English work, strong worker-council constraints), the generalization gap is large and unflagged.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Erik Brynjolfsson's recent work on cross-firm productivity dispersion in AI adoption; Wharton-led surveys on enterprise AI deployment; case studies from regulated EU firms (Klarna's published numbers and their later retraction); Norwegian-context: BI Handelshøyskolen / Sintef studies on AI adoption in Nordic enterprise (the 'forskning og digitalisering' extraction in this library)
• incompleteToken-economics assumption (SaaS users bring their own tokens via Codex) is treated as a stable equilibrium when it is more plausibly a transitional artifact. Once enterprise procurement notices that token spend is shifted to user-attached agent harnesses, three forces will push back: (a) per-call agent-tier pricing from SaaS vendors capturing the new volume, (b) enterprise consolidation of agent infrastructure (corporate-controlled Codex/Claude Code deployments), and (c) usage-based SaaS pricing emerging precisely to capture agent-driven volumes. Each of these inverts Shipper's 'buy SaaS stocks' conclusion. He does not engage any of them.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Tomasz Tunguz's recent essays on AI pricing; the cloud-pricing history (AWS's evolution from flat to consumption); Bessemer State of the Cloud reports on agent-driven pricing changes; OpenRouter / LLM-aggregator economics
• incompleteShipper's 'CEO must be personally AI-pilled' claim sits uncomfortably with his 'super-agent per company maintained by a forward-deployed engineer' claim. If the FDE is the load-bearing role and the per-company agent is the substrate, the CEO's personal model fluency is arguably the wrong variable to optimize — the firm needs FDE talent supply and an org design that protects FDE attention from the C-suite. The conversation never reconciles the personal-fluency prescription with the structural FDE prescription.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Karl Weick on 'sense-making' in organizations; recent CIO/CTO surveys on AI organizational placement (Gartner, MIT Sloan); the literature on 'two-pizza team' analogues for AI deployment
• incompleteNo engagement with worker-attention costs of the prescription. 'Ride the models' for every new release, 'try Codex in your off-hours if your employer blocks it', 'every agent needs a human gardener', 'inbox-zero for 10 straight days via Codex monologue' — collectively this is a maximally attentive lifestyle marketed as liberation. Shipper notes he 'works way more' and frames it as paradox-evidence, not as cost. For a senior engineering leader thinking about sustainable organizational design, the elision of attentional and psychological cost is significant.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: The 'AI psychological costs' extraction in this library (extract-psychological-costs-of-ai-*); Cal Newport on attention residue and deep work; recent labour-economics work on AI-driven work intensification (LSE, Stanford); union/works-council positions on AI workload
• illogicalThere is internal tension between (a) 'CLIs are over, GUIs win' and (b) 'agents using SaaS via CLI is how SaaS survives'. If the user's primary surface is Codex/Co-work GUI and the agent talks to SaaS over CLI, then CLIs are precisely what is preserved — they are the agent-readable API layer, not the user surface. Shipper conflates the user-surface CLI claim with the agent-readable-API CLI claim. The two are different and have opposite trajectories: the first dies, the second flourishes. The conversation does not separate them.
  The AI paradox: More automation, more humans, more work | Dan Shipper
• incompleteThe article presents the three-layer agentic stack (orchestration, execution, review) as an emerging standard but provides no analysis of whether this architecture is actually sound or just the first thing that crystallized. There is no discussion of failure modes, debugging, or accountability within this architecture.
  Radar Trends to Watch: May 2026 — read next: Bryan Cantrill's laziness essay; 'Hidden Technical Debt of Agentic Engineering'; distributed systems architecture literature
• incompleteThe tension between 'reimagining' (rebuilding software from scratch with AI) and 'laziness' (the virtue of designing for future maintainability) is present in the article but never connected. If AI makes building cheap but maintaining thoughtful, these two trends are on a collision course.
  Radar Trends to Watch: May 2026 — read next: Cantrill's full essay on laziness; the original 'Hidden Technical Debt in Machine Learning Systems' paper
• uninformedThe article does not address the labor market implications of AI becoming operational at the team level. If agents replace team-level workflows, the impact on employment is qualitatively different from individual productivity gains.
  Radar Trends to Watch: May 2026 — read next: Daron Acemoglu's work on AI and labor; the Stanford AI Index's labor market sections
• incompleteThe co-authorship attribution ('Mike Loukides and Claude') is noted without comment. The article does not discuss what it means for a trends roundup to be co-authored by an AI model — raising questions about editorial judgment, selection bias, and the epistemic status of the analysis.
  Radar Trends to Watch: May 2026 — read next: Discussions of AI co-authorship norms; editorial standards for AI-assisted journalism
• 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.
• incompleteThe marginal-cost claim is accounting-incomplete (Beck flags it; Grinich doesn't return)
  Itchy Brain (Still Burning: Michael Grinich & Kent Beck on AI adoption, enterprise developer tools) — read next: Anything in your Kent Beck file on TCR and scope-of-done (this is exactly the conversation about plausible deniability and shrinking scope); Lorin Hochstein on operational complexity; the Böckeler harness-engineering extraction in this repo (the 'gap between running system and trusted system' is the harness-engineering surface). The Adam Tooze / Brad DeLong line on 'productivity gains that don't show up in the statistics' is the macroeconomic complement.
• incompleteThe 'descaling of software' counter-trend is named by Beck and left hanging
  Itchy Brain (Still Burning: Michael Grinich & Kent Beck on AI adoption, enterprise developer tools) — read next: Steve Yegge on vibe coding; Gene Kim's vibe coding series; Simon Willison on the 'no-coder using LLMs to build real software' phenomenon; the Schoening agency-over-skills extraction in this repo (the agency thesis is the descaling-friendly side of this tug of war). Honest framing: Beck's craft instincts and Grinich's institutional instincts pull in opposite directions; you may have to choose.
• incompleteGrinich's 'industrialization phase' analogy launders externalities
  Itchy Brain (Still Burning: Michael Grinich & Kent Beck on AI adoption, enterprise developer tools) — read next: Tooze on energy transitions; the IEA's compute-electricity projections; the literature on whether the late-19th-century industrialization actually 'cleaned up' or just exported externalities. For Kjetil specifically: this is the systems-thinking lens — feedback loops, stocks/flows, who absorbs what — applied to the rhetoric of inevitability.
• incompleteWhat changes about Beck specifically — the craft thinker in this regime
  Itchy Brain (Still Burning: Michael Grinich & Kent Beck on AI adoption, enterprise developer tools) — read next: Beck's own recent Substack posts (Tidy First, the 'starving genies' piece, 'forest thinning'); your highlights on Beck for where he reframes craft for the agentic era; Hickey's 'Simple Made Easy' as the substrate craft argument; Ousterhout's complexity work. The persona-relevant cross-thread: this is where Kjetil's 'fragility of ideas' hidden layer touches the AI transition — if the craft of attentive code-reading is the protected attention surface, what protects it now?
• incompleteWhat does the 'itchy brain' protect against, exactly?
  Itchy Brain (Still Burning: Michael Grinich & Kent Beck on AI adoption, enterprise developer tools) — read next: Pressfield on Resistance; Cal Newport on deep work degradation under tool proliferation; the David Whyte/Maria Popova line on the difference between making and consuming; the persona's Bailey/Hyperfocus annotations on what attention needs in order to do anything. This is where the persona's hidden layer (fragility of ideas) and the episode's title concept (itchy brain) collide — and it is the most productive question the episode opens.
• incompleteThe four-level taxonomy is presented as self-evident without empirical grounding, prior art references (beyond Engelbart), or criteria for distinguishing the levels in practice. It is unclear whether the levels are discrete, overlapping, or a continuum, and what determines when a system transitions from one level to another.
  The keyboard was never the bottleneck — read next: Compare with established taxonomies: Lehman's laws of software evolution, the Cynefin framework, or Conway's law literature for more rigorous level-distinction criteria.
• incompleteThe claim that AI-generated code characteristically fails at higher levels is asserted as an observed pattern but supported only by a brief characterization ('works in isolation, fails when inputs vary'). No specific examples, studies, or failure cases are cited.
  The keyboard was never the bottleneck — read next: Look for empirical studies on AI-generated code in production systems, e.g., GitHub Copilot studies, or case analyses of AI-generated code failures in integration contexts.
• incompleteThe article does not address the possibility that AI capabilities at higher levels could improve significantly. The boundary between levels 2 and 3 is treated as if it were a stable, inherent limitation rather than a current snapshot of AI capability.
  The keyboard was never the bottleneck — read next: Follow research on AI agents for multi-component system design, autonomous software engineering agents, and LLM-based architecture reasoning.
• incompleteAmundsen argues the opportunity to 'get better at getting better' exists but immediately hedges that it may not be realized. No mechanisms, incentives, or conditions for realizing it are discussed.
  The keyboard was never the bottleneck — read next: Engelbart's original 'Augmenting Human Intellect' framework, and organizational learning literature (Argyris, Senge) for conditions under which meta-improvement actually occurs.
• incompleteThe 2-day cycle is presented from the inside of a single, apparently small team ('we've been trying'); the post doesn't address whether a 3-day cadence (plan/build/demo) scales to multiple interdependent teams, where cross-team dependencies, shared architecture decisions, and release coordination historically required longer sprint boundaries to synchronize.
  Erik van der Pluijm's Post — read next: Cross-read against the corpus's coordination-cost and multi-team scaling material to test whether compressed cycles survive beyond a single small team.
• incompleteThe whole cross-retreat comparison rests on an acknowledged seam: the author read only the public summary of the earlier retreat, so he cannot separate 'the conversation genuinely grew' from 'the earlier summary simply compressed this out.' The central 'what changed' claim is offered on face value with that limitation showing.
  What Survived Contact — read next: Obtain the fuller record (not just the public key-takeaways summary) of the earlier Thoughtworks retreat and re-run the comparison against like-for-like source material.
• incompleteThe 'usage as trust signal' argument assumes that usage reveals bugs, but many serious defects (security vulnerabilities, data races, subtle data corruption) can lurk for months or years without being triggered by normal usage. Usage is a better signal than artifact appearance, but it is not a sufficient signal for safety-critical properties.
  Vibe coding and agentic engineering are getting closer than I'd like — read next: Literature on latent defects in software; Nancy Leveson's work on system safety; the Therac-25 case.
• incompleteThe essay treats the accountability gap between human teams and AI agents as an acknowledged discomfort but does not explore solutions — contractual liability, organizational accountability structures, or the possibility that AI vendors could offer guarantees or insurance for agent-produced code.
  Vibe coding and agentic engineering are getting closer than I'd like — read next: Legal scholarship on AI liability; Anthropic's own responsible scaling policy; discussions of AI insurance markets.
• incompleteThe 'you don't get to create anything' extension to AI is never made explicit
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Beck's own Substack on 'starving genies' and the human's relationship to the genie's outputs; Cal Newport's deep-work tradition on how the substitution of tool-mediated production changes the nature of the work; Pressfield on Resistance; and — the persona-relevant cross-thread — the 'fragility of ideas' hidden layer in Kjetil's reading: if the maker-compulsion is the durable substrate, what does it look like when the agent satisfies it without you having moved? This is the productive question the episode leaves on the table.
• 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.
• incompleteThe playbook claim under-specifies the AI playbook's structure
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Hamel Husain on evals; Simon Willison on the working LLM-augmented practitioner's actual playbook; Addy Osmani and the Claude Code patterns crowd; the Bernhard / Bockeler / Thoughtworks harness-engineering thread already in this repo; the Heis ep 11 AI-special with Vilde Opsal and Anders Sveen for the Norwegian practitioner cut; the Heis ep 13 Torrissen for code-quality-under-AI. This is exactly where 'craft transmission for the next era' lives — and where the conversation is most incomplete.
• incompleteThe 'apprenticeship channel under 50:1 manager ratios' problem from the prior Still Burning episode is not picked up
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: John Cutler on overload and DRI dynamics; Will Larson and Tanya Reilly on engineering-org structure; the Heis ep 13 Torrissen extraction for the Norwegian practitioner take on code-quality and craft transmission under AI. Persona-relevant: the 'fragility of ideas' layer — ideas die at the institutional adoption point if the apprenticeship channel is gone.
• incompleteShoup's 'make it easy, don't shame' principle is stated as climate policy and not applied to software craft
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Cutler on operating-system design and waste; Thaler and Sunstein on choice architecture for the foundational behavioral-economics text; Kniberg on Spotify's model as an example of friction-reduction at scale. Persona-relevant: this is exactly where Kjetil's leadership-vs-management orientation and his Cutler-deep reading already live.
• incompleteThe 'distributed-systems-playbook-writers as exemplars' framing implicitly leaves out the playbook that didn't get written
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Schneier on security (in Kjetil's RSS); the Ruined by Design / Mike Monteiro line on what professionals fail to write playbooks for; the Norwegian intelligence reports (NSM, PST) for the security-and-resilience perspective; recent regulatory writing on AI-and-governance for what is being written by non-engineers because engineers didn't write it.
• incompleteThe Beck-as-inductive vs. Shoup-as-deductive split is named but not connected to the playbook-writing claim
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Anything on creative-cognitive partnerships at scale: Brian Eno's 'scenius' concept, Anne Lamott on the writer-editor pairing, the literature on the pair-programming and mob-programming traditions in software. For the temperament-and-craft thread specifically: Beck's own writing on the craft of seeing simple design where others see complexity.