Changeability & Optionality

Software's capacity to absorb future change — the second axis of value that AI-generated code systematically underdelivers on.

Also known as: endringsdyktig, futures / flexibility / optionality, optionality, flexibility, sustainable software (Charity Majors), sustainable software, anticipation, scaling design, dimensions of change

How authors use it

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

Documents (21)

• Meta Open-Sources Astryx, Its Agent-Ready React Design System Bruno Couriol · 2026-09-14 source ↗ Reader 🖥️
  Meta's open-sourcing of Astryx exemplifies an emerging design-system architecture that treats AI agents as first-class consumers alongside human engineers — pairing a token-driven, framework-agnostic styling layer with dedicated CLI/MCP interfaces and an explicit code-ejection escape hatch — while leaving unresolved whether a single corporate sponsor's governance can be trusted for infrastructure this foundational.
• Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase Lily Mara · 2026-09-10 source ↗ Reader 🖥️
  Rewriting an existing system for performance is safer and more tractable at the individual-function level — via a C FFI boundary connecting a fast language (Rust) to the existing slow one (Python, via PyO3) — than at the whole-system or even microservice level, because the smaller unit of change lets teams keep the old implementation, tests, and process contracts intact while swapping only the internals that are actually the aggregate cost driver.
• Reject Change, Sometimes Kent Beck · 2026-09-02 Reader 🖥️
  Because a growing product's payoff structure differs by 3X phase — roughly symmetric win/loss during Extract, sharply upside-skewed during Explore, and ruin-inclusive (win/die/switch) during Expand — the correct exposure to volatility differs sharply too: Extract calls for the disciplined, rebalancing 'Shannon's Demon' strategy of protecting revenue and keeping changes reversible even at some cost to upside (i.e., deliberately rejecting some change), Explore calls for going all in on volatility despite that same strategy's mathematical dominance in symmetric bets, and Expand calls for a third move — investing directly to reduce the probability of catastrophic failure — so 'embrace change' is not a universal software-development virtue but a phase-specific one.
• JEP 540 Proposed to Target JDK 28 with a Simple JSON API A N M Bazlur Rahman · 2026-08-17 source ↗ Reader 🖥️
  JEP 540 proposes a deliberately narrow, strict, immutable, dependency-free JSON API for the JDK standard library — trading the completeness of libraries like Jackson and Gson for interface simplicity — and ships it as an incubating module so the community can pressure-test its navigation, exception, conversion and construction ergonomics before the design is finalized.
• 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.
• Software Design in the Agentic Age: Place Your Bets Mathias Verraes · 2026-07-07 source ↗ Reader 🖥️
  In the agentic age, code-level quality becomes automatable but high-level software design and rigorous (ideally executable) specifications remain decisive human-led work, so under deep uncertainty about AI's payoffs and externalities teams should bet on design rigour, executable specifications, and the ability to revert from agent generation back to human engineering.
• Fragments: July 6 Martin Fowler · 2026-07-06 source ↗ Reader 🖥️
  Agentic software development has crossed from aspiration into established practice — the debate is no longer whether it changes software engineering but how — and the central live question is whether classic design and architecture fundamentals still matter, with Fowler's emerging answer being that they do, both because agents use the same constructs humans do and because good design hedges against escalating token costs and the risk of losing affordable access to AI.
• Worse is better: JSON versus XML Mark Seemann · 2026-07-06 source ↗ Reader 🖥️
  Despite JSON's popularity, XML is the superior data-interchange format in most respects — because its mature ecosystem of standards (schemas, versioning, querying, streaming, even sum types) delivers real capability that JSON only reinvents piecemeal, while JSON's supposed advantages (informality, size, readability) are illusory, marginal, or equally achievable in XML — making JSON another case of 'worse is better'.
• Software Design in the Agentic Age: Placing Your Bets aardling.eu · 2026-07-03 Reader 🖥️
  Even though no one yet has evidence that classic code-design and domain-modeling discipline is necessary for agentic development, the author bets on maintaining it anyway — high test coverage, sound domain models and Ubiquitous Language, disciplined Bounded Contexts, and code quality — because doing so is the dominant strategy under uncertainty (cheap to unwind if unnecessary, expensive to retrofit if not) and because it preserves the option to revert an organization from agentic code generation back to human engineering if AI's economics or reliability falter.
• Your Company Needs an Energy Strategy for AI's Next Phase Eric Yanfei Zhao · 2026-06 Reader 🖥️
  Because the AI value stack's scarce control point is migrating from models and GPUs down to electricity itself, every enterprise — not just hyperscalers — must now treat energy access as a board-level strategic variable and build distinctive capability to measure, reduce, contract for, and geographically place its AI compute before scarcity becomes an operating emergency.
• KI, utvikling og følelser Vidar Moe · 2026-05-21 source ↗ Reader 🖥️
  Generative AI is reshaping software development less as a productivity story and more as an emotional one — moving developers from building to specifying systems, and the central professional question is no longer how to ship faster but how to keep developers from becoming alienated, dulled, and burnt out, which requires deliberately keeping humans inside the loop through code-the-foundation workshops, explicit TDD with the agent, and a psychological reframe from programming to problem-solving.
• Applying Best Simple System for Now for Software Design Ben Linders · 2026-05-09 source ↗ Reader 🖥️
  The trade-off between technical debt and missed deadlines is a false dichotomy; by building the simplest system that meets only current requirements to a high standard (Best Simple System for Now), teams can ship continuously while keeping future change cheap — because simplicity, not speculative flexibility, is the real source of adaptability.
• Genie Tarpit Kent Beck from Software Design: Tidy First? · 2026-04-29 source ↗ Reader 🖥️
  AI code generators ('genies') naturally produce code that is both less functional and less flexible than what even mediocre human teams produce, and nobody yet knows how to fix this.
• 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.
• 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.
• 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.
• Gene Kim on Vibe Coding - Part II | Episode 411 | Troubleshooting Agile Douglas Squirrel · 2025-12-18 source ↗ Reader 🖥️
  Vibe coding changes software teams' organizational unit of work — toward smaller, option-rich teams and even individual business-stakeholder-plus-developer pairs rather than net headcount reduction — and because trust in these tools is a learned skill that takes about a year to build, leaders should start adopting now rather than wait for the technology to mature further.
• 5) Vidar Moe: Det eneste Vidar vil er å ha det lett Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-11-17 source ↗ Reader 🖥️
  Vidar Moe's core engineering-leadership philosophy is 'gjøre det lett og rett' (make it easy and right) — a Toyota-Way-inflected craft and leadership stance in which you lead an organization most powerfully not by exhortation but by patiently building the tooling, frameworks, fagtid, hiring filters, fixed-term leadership rotation, and shared decision arenas that make the right thing the path of least resistance; the episode's ironic title ('the only thing Vidar wants is to have it easy') inverts this — Moe wants the work to be easy precisely because he is willing to do the very hard, decade-long, mostly invisible work of removing friction from doing the right thing, and his current concern with AI agents is the natural next chapter of the same project.
• What good software looks like at REA Alison Rosewarne · 2018-06-12 Reader 🖥️
  What makes software 'good' at REA is not a single abstract ideal but three concrete, criteria-based lenses — dev (changeability), ops (operability), and arch (bounded responsibility) — that the teams who own each system rate themselves against on a recurring basis, so architectural quality becomes an organizationally-supported habit rather than a one-time design decision.
• Technical Debt Quadrant Martin Fowler · 2009-10-14 source ↗ Reader 🖥️
  Whether a design flaw counts as 'technical debt' is the wrong question; the useful question is whether the debt metaphor helps you think about and communicate design trade-offs, and answering it well requires distinguishing reckless from prudent debt and deliberate from inadvertent debt — including a fourth, inevitable category (prudent-inadvertent debt) that even excellent teams cannot avoid.
• 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 (7)

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

2018-06

• explicitGood software cannot be captured by a single universal quality; REA uses three distinct lenses — dev, ops, arch — because different stakeholders need different guarantees (changeability, operability, well-bounded responsibility) from a system.
  What good software looks like at REA · p1
• explicitA low barrier to making changes is valuable only if it doesn't compromise quality — changeability and quality are companions to be jointly optimized, not traded off against each other.
  What good software looks like at REA · p3

2026-02

• explicitThere is a software-type spectrum that determines whether AI uplift dominates: throwaway scripts (LLM-generated Python for one-off Excel filtering) at one end, Charity Majors' 'sustainable software' at the other; failing to make this distinction is the most common adoption mistake.
  11) AI-spesial med Vilde Opsal og Anders Sveen · p19

2026-04

• explicitThe flexibility axis has a wider operating range — you can neglect it for a while without immediately feeling the consequences.
  Genie Tarpit · p4
• explicitFeatures and futures are not truly orthogonal — fewer defect interruptions free time for flexibility, and flexibility makes it easier to create working features.
  Genie Tarpit · p5

2026-05

• explicitAI assistants naturally produce code that sits below the quality threshold needed for sustainable software — complexity accumulates until even the AI cannot pretend to make progress.
  Fragments: May 5 · p7

2026-07

• implicitDeferring commitment to build 'optionality' (e.g., years in consulting or banking before eventually starting a company) is a disguised form of risk-aversion, not genuine strategic flexibility, because lifestyle inflation and social conformity make the deferred commitment progressively less likely.
  Introducing The Founder Mindset: Tim Ferriss on Experiments, Risk, and Freedom · p9

Tensions

Open gaps (45)

• incompleteOm Mishra's experiment — the document's only quantitative-feeling evidence — is explicitly caveated as a single developer's single-task run, not a benchmark: no repetition, no variance, no independent or blinded review of the resulting code, and it measures only speed and validation-pass count, not downstream code quality, maintainability, or defect rate. It says nothing about whether agent-skills' faster completion trades off against the changeability/comprehension concerns this corpus raises elsewhere about AI-generated code.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub — read next: extract-osmani-loop-engineering#p12 (comprehension debt grows as a loop ships more code the human didn't write) and the corpus's technical-debt/changeability concepts — neither is engaged by this comparison's speed-and-validation-pass framing.
• incompleteNo discussion of how BSSN handles genuinely uncertain or conflicting current requirements. The framework assumes 'current requirements' are knowable and stable, but in many contexts they are ambiguous or in flux.
  Applying Best Simple System for Now for Software Design
• incompleteNo treatment of team or organizational dynamics. BSSN is presented as an individual design discipline. How does it interact with architectural governance, platform teams, or mandated standards that may require speculative infrastructure?
  Applying Best Simple System for Now for Software Design
• illogicalMinor tension: the 'Best' characteristic requires telemetry, automated tests, API docs, and automated deployment paths. These are themselves forward-looking investments that go beyond 'current requirements'. The boundary between 'necessary quality infrastructure' and 'speculative code' is not clearly drawn.
  Applying Best Simple System for Now for Software Design
• illogicalThe 'pets to cattle' analogy assumes code can be treated like infrastructure — interchangeable, statelessly regenerable, verifiable via automated health checks — but code, unlike a server, typically encodes unique business logic and meaning. 'Verifiably correct' for a server means 'responds to health checks'; 'verifiably correct' for a business function is a much harder, domain-specific correctness problem that the piece never distinguishes from the infrastructure case it borrows its confidence from.
  Stop being skeptical about AI for development with Charity Majors — read next: This corpus's changeability/optionality material on what AI-generated code systematically underdelivers on.
• incompleteBeck states the two axes are 'not truly orthogonal' but continues to use them as if they were, without modeling the interaction. The coupling between features and futures is acknowledged but unexplored.
  Genie Tarpit — read next: Explore how feature reliability and flexibility co-evolve — possibly in Beck's earlier 'Features Versus Futures' post.
• incompleteThe 'tarpit' metaphor is in the title but never formally defined or analyzed in the text. The mechanism by which complexity self-reinforces is asserted rather than demonstrated.
  Genie Tarpit — read next: The Turing tarpit concept and complexity theory literature; also empirical studies of AI-generated code maintainability.
• 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.
• incompleteThe piece defers the question of why teams choose to stay in the muddling zone ('we can talk later') — but this is directly relevant to whether genies merely accelerate existing tendencies.
  Genie Tarpit — read next: Beck's broader 'Tidy First?' series likely addresses the incentive structures that keep teams muddling.
• incompleteTreats energy as a procurement-and-deployment problem (route smaller models, sign PPAs, pick Nordic regions) rather than as a strategic constraint that should reshape AI architecture decisions — e.g., whether to deploy agentic loops at all, whether to build retrieval-heavy systems vs. cached responses, whether to build AI features whose value-per-watt is negative.
  Your Company Needs an Energy Strategy for AI's Next Phase — read next: Sasha Luccioni and Hugging Face on AI energy accounting; Andy Masley and effective-altruist energy debates; Kate Crawford 'Atlas of AI' on AI's material substrate.
• incompleteThe proposed governance body (CIO + CFO + procurement + sustainability) reproduces the assumption that AI is something the IT/procurement axis manages. It does not engage with the possibility that energy-bounded AI is a board-level capital-allocation question on par with major capex, nor that engineering leadership (CTO, head of AI) should own intelligence-per-watt as a product KPI.
  Your Company Needs an Energy Strategy for AI's Next Phase — read next: Recent CTO-track writing on AI infra strategy; capital-allocation literature on industrial transitions.
• incompleteJevons is invoked rhetorically but the article doesn't engage with the implication: if demand will always grow to consume available efficiency gains, then efficiency-focused recommendations (Action 1, Action 2) only delay the bottleneck for the individual firm without changing the aggregate trajectory. The piece offers no view on whether firms should care about aggregate trajectory.
  Your Company Needs an Energy Strategy for AI's Next Phase — read next: Climate-economics literature on rebound effects; Vaclav Smil on energy transitions.
• incompleteNo discussion of grid externalities — what happens to non-AI users and communities when hyperscalers and incumbents lock up 20-year nuclear PPAs and Nordic colocation. The framing is purely firm-strategic; the political economy is mentioned ('politically contested') but not analyzed.
  Your Company Needs an Energy Strategy for AI's Next Phase — read next: Reporting on data-center power disputes in Virginia, Ireland, and the U.S. Midwest; energy-justice literature.
• incompleteThe Great Value Loop framework is presented as a recurring pattern but the article does not interrogate whether the energy era differs structurally — physical infrastructure has 20+ year build timelines, hard geographic constraints, and political sovereignty implications that the previous three layers (connectivity, attention, compute) did not.
  Your Company Needs an Energy Strategy for AI's Next Phase — read next: History of electrification (Hughes 'Networks of Power'); literature on infrastructure lock-in and path dependence.
• uninformedDoes not engage with on-device / edge inference as an alternative architectural lever for reducing data-center electricity demand. The five actions all assume cloud-resident inference.
  Your Company Needs an Energy Strategy for AI's Next Phase — read next: Apple Intelligence and on-device LLM literature; small-language-model research from Mistral, Microsoft Phi, etc.
• incompleteThe episode systematically tells the success-side of the story. Crisis → response → improvement is the recurring arc, but failed experiments, dead-end framework choices, or instances where 'gjøre det lett og rett' produced unintended organisational uniformity are absent. Moe's stated regret is only directional (could have done more, faster, in more places), not structural (e.g. 'this particular default we engineered was wrong'). The hosts twice surface the hierarchy-is-inevitable point but do not press on whether the framework-team's 'easy and right' becomes a hidden orthodoxy.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with Allen Holub's #NoAccountability strand (already in the user's persona) and with anything on the costs of platform-engineering paved roads (e.g. Charity Majors / Honeycomb on the limits of golden paths). The user's existing extraction on Cutler's institutionalised overload is a strong complement here — Cutler's frame would ask what the second-order costs of the SpareBank 1 system look like.
• 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.
• incompletePair programming is named as the most effective form of knowledge sharing and as the substrate that the rest of the infrastructure exists to support, but the cost question (developer preference, time investment, neurodiversity, hybrid/remote context) is not engaged. Moe acknowledges that change in this direction is 'ordentlig seig' — really tough/slow — but does not ask why even at SpareBank 1, with all the structure in place, pair programming is not yet universal. The same gap exists in his essay's TDD-with-the-agent prescription.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read Birgitta Böckeler's recent work on remote pair programming, and the user's already-extracted Beck material on TCR (which functions as a half-step toward pair-discipline). The 'AI Joy Gap Developers' extraction the user already has — which treats reconnection-of-developers as needing organisational structure — is a direct complement.
• 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).
• 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.
• illogicalThe talk asserts the bug-introduction risk is lower at function scale than for a full rewrite (proposition p5) but never actually demonstrates this — no comparative data, incident rates, or even an anecdote of a bug this technique introduced. The claim rests entirely on 'smaller scope, therefore safer' intuition, which the talk does not test against the possibility that FFI boundaries introduce their own novel bug class (memory/lifetime mismatches, GIL misuse, silent numeric divergence as actually shown) that a same-language refactor would not.
  Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase — read next: Read practitioner postmortems specifically about FFI-boundary bugs (use-after-free across a Python/Rust boundary, GIL deadlocks, ABI mismatches) to test whether 'smaller unit of change' actually implies 'lower risk' once the risk profile of the boundary itself is counted.
• uninformedDeployment and dev-environment complexity are named as costs but never quantified or walked through concretely (e.g. what a CI pipeline that cross-compiles Rust wheels for every supported OS/architecture actually looks like, how long that adds to build times, what happens when a contributor's machine can't match a required target triple).
  Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase — read next: Read maturin/PyO3's own packaging documentation and case studies (e.g. cryptography, polars, pydantic-core) on multi-platform wheel-building pain, to fill in the concrete operational cost this talk only names in the abstract.
• incompleteThe article notes JEP 198 (2014) was a broader, never-delivered predecessor but does not explain why it stalled, leaving the reader unable to judge whether JEP 540's narrower scope specifically fixes the reason the earlier attempt failed, or whether it risks repeating that failure for different reasons.
  JEP 540 Proposed to Target JDK 28 with a Simple JSON API — read next: JEP 198 itself and any OpenJDK retrospective or mailing-list history on why a JDK-native JSON API was proposed in 2014 and never delivered.
• incompleteDuplicate-member-name rejection is framed purely as a general interoperability inconvenience, but the article never connects it to the security literature on parser-differential attacks (where two parsers in a pipeline disagree on which duplicate key wins, enabling validation bypass or smuggling) — an angle where a strict, spec-first standard-library parser is unusually well positioned, but the piece doesn't make that case.
  JEP 540 Proposed to Target JDK 28 with a Simple JSON API — read next: Security research and write-ups on JSON/HTTP parser-differential and duplicate-key smuggling vulnerabilities.
• incompleteTeam-level and organizational dynamics are almost absent. The piece is written from the individual developer's interior, with the team as a setting but not an object of analysis. Yet many of the named harms (large PRs defeating review, knowledge transmission to new developers, burnout) are fundamentally social phenomena. What happens to pair-programming culture? To mentorship? To code-review-as-teaching? To the social production of shared mental models when an agent is the third participant? The essay names the symptoms but stays at the level of the individual practitioner.
  KI, utvikling og følelser — read next: Pair with John Cutler on team operating systems (the 'institutionalized overload' arc) and with Beck/Cutler on how design discussion functions socially. Also read Pamela Hieronymi or similar on what attention/understanding requires of a community, not just an individual. The user's existing extraction on 'AI Joy Gap Developers' — which treats the polarization as needing organizational structures (AI platform teams, cultural practices reconnecting developers) — is a direct complement to Moe and worth reading together.
• incompleteWhat happens when the agent fails you, or when its behavior shifts under you (a model upgrade, a vendor policy change, an outage)? Moe writes from a moment of arrival ('Opus 4.5 is good enough'), but his entire psychological framework presupposes that the agent is a stable enough partner that you can build a working rhythm with it. The risk of dependency on a non-stationary, vendor-controlled colleague is not addressed.
  KI, utvikling og følelser — read next: Read alongside the user's existing extractions on 'AI Inference Unit Economics' and 'AI Companies Reckless Not Evil' — those address the supply side of the same dependency. Also worth pairing with anything on platform risk and lock-in in developer tooling.
• incompleteNo engagement with the counter-thesis that agentic specification is itself a learnable new craft with its own first principles, rather than a hollow shell around an absent practice. Moe treats 'specifying' as essentially less than 'building' — the alienation premise depends on this. But it is at least defensible to argue that designing the specification surface, the test contract, the architectural guardrails, and the review protocol for an agent is a real engineering act that has its own depth. The essay would be stronger if it engaged this counter-position rather than implicitly dismissing it.
  KI, utvikling og følelser — read next: Steve Yegge's vibe coding manifesto (which the user is tracking) and Gene Kim's vibe coding series are explicit attempts to defend specification as craft. Read Moe in tension with them, not just alongside. Beck's evolutionary design tradition is also relevant: is the agent a new kind of pair-programmer that requires a new design discipline, or is it the thing that hollowed out the discipline?
• incompleteGenerational and career-stage differences are absent. Moe writes as a senior developer at an established Norwegian banking organization. The piece's emotional grammar — feeling alienated, missing the satisfaction of having built something, worrying about transmission — is the emotional grammar of an experienced practitioner. For a developer who entered the profession in 2024, agent-coding is not a loss but a baseline; the very experience of 'fremmedgjøring' may not arise. Moe's essay is implicitly written from one career stage and would be more powerful if it acknowledged this.
  KI, utvikling og følelser — read next: Anything serious on generational cohorts in tech adoption. Look for empirical work on new-developer experience in AI-assisted environments — this is a real research gap right now. The user's interest in the 'Stolen Focus' tradition suggests this is also a place where the digital-native vs digital-immigrant frame might be productively applied to AI-native vs AI-immigrant developers.
• incompleteThe Norwegian / Nordic context of the essay is implicit but not theorized. SpareBank 1 Utvikling, the T-bane, Norwegian engineering culture's relative emphasis on 'flyt', autonomi and mestring (drawing on Self-Determination Theory in a way that pervades Nordic management discourse) — all of this shapes Moe's framing. An anglophone reader might miss that 'venting på autocomplete' as a moral category is partly a Norwegian work-culture artifact. There is a comparative essay latent here that the piece does not write.
  KI, utvikling og følelser — read next: Read in parallel with anglophone AI-coding voices (Beck's recent essays, Cutler's TBM 412 on institutionalized overload + AI) to see what gets emphasized differently. The NAV 'optimizing for fast flow' piece already in the user's queue is a useful Nordic-context anchor.
• incompleteThe article reports Reddit users' concerns about Astryx's long-term maintenance and governance as a Meta-sponsored framework, but never investigates Astryx's actual governance model — whether it has an independent steering process, a contribution/RFC process, or any structural safeguard against Meta simply losing interest (as has happened with other corporate-sponsored OSS).
  Meta Open-Sources Astryx, Its Agent-Ready React Design System — read next: Look for Astryx's own governance/contribution documentation, and compare against how Meta has historically governed React itself (which now has a broader community governance model) versus tools it has open-sourced and later deprioritized.
• incompleteThe article never quantifies where token/prop-level customization stops and forced `swizzle` ejection begins, nor how often teams in practice need to eject components versus staying within the supported customization surface — leaving the real cost of the ejection escape hatch unclear.
  Meta Open-Sources Astryx, Its Agent-Ready React Design System — read next: Look for practitioner reports or Astryx's own documentation on customization limits and swizzle-frequency in production use.
• uninformedBeck imports the volatility/rebalancing framing directly from Kunal Bhalla ('pointed out the exception... introduced me to... Shannon's Demon') but gives no independent check that the coin-flipper model captures the actual statistical structure of real product changes, versus being an elegant trading analogy that happens to sound applicable.
  Reject Change, Sometimes — read next: Look into the empirical distribution of 'did this change help or hurt' outcomes for real product changes (e.g. from experimentation/A-B-testing literature) to see whether they're closer to symmetric, skewed, or something else entirely — and whether that distribution actually differs by company stage the way Beck assumes.
• uninformedThe central bet on design quality depends on long-term maintainability and evolvability, yet the author concedes there 'isn't much data on long term evolvability with agentic development' because the space is young. The most load-bearing timescale of the argument is therefore supported largely by analogy to human software engineering rather than by evidence from agentic development itself.
  Software Design in the Agentic Age: Place Your Bets — read next: Watch for longitudinal studies of agent-maintained codebases as they mature, and for evidence on whether agentic assumptions about cost-of-change transfer from the human case.
• 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 article asserts that ecosystem maturity/standardization makes XML 'superior' but never defines the criteria of superiority or weighs them against JSON's decisive real-world advantages — network effects, JavaScript-ecosystem gravity, and cognitive simplicity — which are the actual reasons formats win adoption. 'Superiority' is treated as a property of the format in isolation rather than of the format-in-its-ecosystem.
  Worse is better: JSON versus XML — read next: Read Richard Gabriel's original 'The Rise of Worse Is Better' — it argues that the 'worse' option's simplicity of interface is itself the deeper virtue, directly challenging the 'why reinvent the wheel' framing — alongside the network-effects and standards-adoption literature.
• illogicalThe recurring 'why reinvent the wheel?' treats JSON's re-implementation of XML capabilities as pure waste, but the very fact that the ecosystem chose to reinvent a SIMPLER wheel is evidence that XML's richer wheel was mis-sized for the common case. The argument thus assumes what it needs to prove — that XML's heavier standards are worth their cost — and this directly contradicts the Gabriel 'worse is better' thesis Seemann himself invokes as his framing device (a tension the article never acknowledges).
  Worse is better: JSON versus XML — read next: Engage Gabriel's actual claim that simplicity of the common case can rightly dominate completeness, and read the design-fundamentals argument that unused capability is a cost, not a latent asset.
• incompleteThe size argument is dismissed too quickly — 'when performance really is a consideration, JSON may be too big, too' waves away rather than engages the large middle band of high-throughput text APIs (aggregate bandwidth, parse cost, streaming) and the schema-driven binary formats that are actually chosen when neither text format fits.
  Worse is better: JSON versus XML — read next: Read the schema-driven binary serialization literature — Protocol Buffers, Apache Avro, Cap'n Proto, MessagePack — to see where the real interchange-format frontier lies beyond the XML-vs-JSON text axis.
• incompleteThe Hyrum's-law/implicit-contract point is used only against JSON, but it cuts both ways: XML with an XSD still couples consumers to undocumented behaviors, and a schema is not a free lunch — XSD complexity, schema evolution, and versioning cost are never weighed against the benefit claimed.
  Worse is better: JSON versus XML — read next: Read on schema evolution and compatibility (e.g. Avro/Protobuf compatibility rules, and API-versioning practice) to see the ongoing cost side of the schema ledger the article omits.
• incompleteThe configuration-file case rests almost entirely on JSON's lack of standard comments, yet never mentions YAML, TOML, or HCL — the formats that actually displaced both XML and JSON for configuration — which makes the 'XML for config' recommendation weaker and more dated than presented.
  Worse is better: JSON versus XML — read next: Compare TOML and YAML directly on the same criteria (comments, readability, schema tooling) to see why the config-format question was largely settled without either XML or JSON winning.