Software Design Fundamentals

The timeless design disciplines — deep modules, conceptual integrity, shared vocabulary, simplicity — that matter more, not less, when AI amplifies the cost of bad structure.

Also known as: deep module vs. shallow module (Ousterhout), deep module (Ousterhout), deep modules, conceptual integrity, ubiquitous language (DDD), ubiquitous language, design concept (Brooks), design concept, shared design concept (before you code), complexity (Ousterhout), software entropy, obvious, ikke clever, obvious not clever, tilført vs. essensiell kompleksitet, essential complexity, accidental complexity, information architecture (in the AI context), information architecture, Best Simple System for Now (BSSN), BSSN, gold-plating, goldplating, First Sight, straightforwardness

How authors use it

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

Documents (43)

• Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers Chintan Tank · 2026-09-23 Reader 🖥️
  At multi-tenant SaaS scale, a monolithic edge worker's deployment coupling and unbounded blast radius stop being tolerable, so the fix is to decompose it into a thin composing gateway plus independently owned, tested, and staged-release feature workers connected by Cloudflare's same-isolate service bindings — the one primitive that makes this decomposition free of the network-hop cost that normally makes splitting a backend monolith expensive — while treating multi-CDN portability, per-feature configuration, and graceful failure as first-class, non-negotiable design constraints rather than afterthoughts.
• Writing vs. Thinking Masoud Bahrami · 2026-09-21 Reader 🖥️
  Writing is not merely a record of a thought fully formed beforehand but one of the mechanisms by which thinking itself happens — a claim the author grounds in how articulation forces precision, how revision continues (rather than merely polishes) an argument, and how the same dynamic explains why naming and language do real design work in software, not just communication work.
• Article: Implementing Durable Workflows on Postgres Without an External Orchestrator Raman Varma · 2026-09-14 Reader 🖥️
  Durable workflow execution is fundamentally a database-checkpointing problem, so a team that already operates a relational database like Postgres at scale can implement production-grade durable execution — concurrent dispatch, idempotency, crash recovery, durable waits, and observability — as a handful of well-understood SQL primitives, without deploying a separate stateful orchestrator such as Temporal or AWS Step Functions.
• Beyond Autonomous Teams in Software Product Development Ben Linders · 2026-09-10 source ↗ Reader 🖥️
  Because a team's contribution in a complex organization is really a share of an ever-shifting web of value dependencies rather than a discrete 'product,' organizations should replace 'autonomous product team' thinking with 'value center' thinking, in which every unit at every level (person, team, team-of-teams, org) answers the same five recursive questions and trades off autonomy against coherence according to the shape of the value it carries, not according to ideology.
• 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.
• Worse is better: C# versus F# Mark Seemann · 2026-09-08 source ↗ Reader 🖥️
  F# is superior to C# along most axes of comparison — decisively so in F#'s built-in, compiler-enforced prevention of circular dependencies, which C# is unlikely ever to match — even though F# is, ironically, the least popular of Microsoft's three officially supported .NET languages.
• All models, no matter how smart, will eventually build systems... Steve Yegge · 2026-09-02 Reader 🖥️
  Any AI coding model, left unconstrained, will eventually build a system that outgrows its own capacity to understand or maintain it — so the durable fix is not a smarter model but an externally imposed cap on system size.
• LIVE: Uncle Bob on Software Fundamentals in the Age of AI Matt Pocock (host) with Robert C. Martin ('Uncle Bob') · 2026-08-19 source ↗ Reader 🖥️
  Software fundamentals (clean, well-partitioned, deeply-structured, well-tested code) matter just as much in the agentic era as before — not despite AI's speed but because of it — because agents hit the same complexity wall humans always have, just at a different threshold; the right response is not to impose human disciplines (like strict line-by-line TDD or heavyweight upfront specs) on agents, but to encode human values as deterministic, automated gauntlets (crap scores, mutation testing, dependency rules) that agents must pass through, while reserving strategic judgment — architecture, module boundaries, what's worth building — for humans who must now learn that judgment by experiencing the agents' own tactical gauntlet.
• 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.
• The Economic Benefit of Refactoring Giles Edwards-Alexander (published on martinfowler.com, byline Martin Fowler) · 2026-07-30 source ↗ Reader 🖥️
  Refactoring an agentic codebase according to a strict, correctness-preserving discipline can pay a measurable economic dividend — in this experiment, an 83% reduction in the input-token cost of an identical representative future change — because it lets an AI agent read a smaller, more targeted slice of the code to make the same change, even though the total code volume barely shrinks.
• 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.
• Presentation: From Copy-Paste to Composition: Building Agents Like Real Software Jake Mannix · 2026-07-27 source ↗ Reader 🖥️
  LLM-based agents that wire raw MCP tool descriptions verbatim into an agent's context window are architecturally equivalent to unstructured 1975 BASIC — one big file, no interfaces, no encapsulation — and the fix, without rewriting MCP itself, is a lightweight 'virtual tools' layer interposed between agent and tool server that gives agent teams real interfaces, encapsulation, composition, versioning, and deterministic taint-tracking security, all stored in a shared registry alongside the evals that define what each agent is for.
• DoorDash Uses Envoy and Valkey for a 1.5M RPS Proxy Cache with 99.99999% Availability Leela Kumili · 2026-07-20 Reader 🖥️
  DoorDash's Entity Cache shows that moving caching out of individual services and into a transparent, infrastructure-layer proxy (Envoy + Valkey) — with event-driven invalidation, staleness-tolerant failure handling, and stampede-avoidance techniques — can absorb very large request volume at extremely high availability without requiring any application code changes.
• 11 Tips For AI Coding With Ralph Wiggum Matt Pocock · 2026-07-11 source ↗ Reader 🖥️
  Autonomous agent loops ("Ralph") become reliably productive only when the human stops writing code and instead wraps the loop in disciplined scaffolding — an explicit end-state/stop-condition, an externalized progress file, commit-blocking feedback loops, small steps, risk-first sequencing, stated quality expectations and a sandbox — scaffolding that compensates for the agent's lack of judgment and cross-session memory and that, unguardrailed, would let the loop accelerate software entropy.
• Podcast: Formal Methods for Every Engineer in an AI-Powered Future Gabriela Moreira (guest); host Shane Hastie (InfoQ) · 2026-07-10 Reader 🖥️
  Formal methods are a practical tool for reasoning about the edge cases of complex distributed and concurrent systems, and because AI in 2026 collapses the historic barriers to writing specifications and the glue code that binds them to real implementations, the profession's enduring human work shifts to defining which system behaviours are correct — the judgment AI cannot take over.
• AI Is Changing Software Engineering. The Fundamentals Still Matter. Abby Bangser · 2026-07-07 source ↗ Reader 🖥️
  AI is transforming who produces, consumes, and maintains software, but the organisations moving fastest succeed by doubling down on engineering fundamentals — right-sized boundaries, modular abstractions, clear interfaces, and operational discipline — as the foundation that lets humans and AI build together safely and sustainably.
• 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.
• Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat Jimmy Nilsson · 2026-07-07 source ↗ Reader 🖥️
  Reflecting on Thoughtworks' 'Future of Software Development' retreat, the author reports that leading practitioners have moved past the hype-versus-doom polarisation about agentic coding toward nuanced 'when, where and how' thinking, converging on the view that enduring engineering fundamentals (DDD, XP, TOC, TDD, BDD, CD) plus a renewed 'Extreme Humanism' matter more than ever in the agentic age — which is why he is optimistic.
• Notes from FOSE Europe Giles Edwards-Alexander · 2026-07-07 source ↗ Reader 🖥️
  Five months into the agentic era the value of agentic engineering is now settled ('the evidence is in'), so the live frontier of the debate has moved from the tools themselves to the socio-organisational questions they raise — how to design your organisation (Optimiser vs Learner), where engineering rigour and human judgement now live, and how to coordinate agentic work across teams and enterprises — none of which is yet resolved.
• 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.
• 5 Things World-Class Engineers Do That You Don't Steve Huynh · 2026-07-01 source ↗ Reader 🖥️
  Elite engineers are distinguished not by raw intelligence or effort but by five deliberate practices the author claims to have observed repeatedly across podcast conversations with principal/distinguished engineers: measuring growth monthly rather than waiting for reviews, amplifying colleagues instead of maximizing solo output, absorbing complexity so customers experience simplicity, deliberately avoiding the crowded competitive path, and converting personal failures into institutional lessons.
• Maintainability sensors for coding agents Birgitta Böckeler · 2026-05-19 source ↗ Reader 🖥️
  Static analysis tools like ESLint, now cheap to customize because AI can write the rules and messages, are an immediately high-value sensor for keeping an AI coding agent's output maintainable — provided their warnings are rewritten as explicit self-correction guidance for the agent rather than left as generic human-facing messages — but this same newfound ease risks producing feedback overload and a false sense of quality assurance.
• SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. Oren Ellenbogen · 2026-05-18 Reader 🖥️
  In the agentic era, software leaders win by raising their ceiling — investing in fundamentals, original thinking, and emotionally-attuned leadership — rather than letting AI flatten everyone to the same elevated floor.
• 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.
• [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero AI Engineer (channel); speaker: Matt Pocock (AI Hero) · 2026-04-24 source ↗ Reader 🖥️
  AI is not a new paradigm for software engineering — the fundamentals that make working with humans effective (small tasks, vertical slices, deep modules, fast feedback loops, alignment through dialogue, TDD) are exactly what make working with AI agents effective; the path from idea to shipped feature is therefore a deliberately planned, human-driven pipeline (align → PRD → vertical-slice Kanban → AFK implementation → QA) in which the codebase itself is treated as the battleground, not the spec.
• It Ain't Broke: Why Software Fundamentals Matter More Than Ever Matt Pocock (AI Hero conference talk, AI Engineer) · 2026-04-23 Reader 🖥️
  Because AI amplifies the cost of bad code through software entropy, investing in software design fundamentals — shared understanding, ubiquitous language, deep modules, TDD, and deliberate architecture — matters more in the AI era than it ever did before.
• 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.
• 13) Tobias K. Torrissen om kodekvalitet, konferanser og AI Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-03-16 source ↗ Reader 🖥️
  In the age of LLM-generated code, the durable value of an engineering leader is not in writing code but in cultivating the engineering practices, explicit design discipline, and craft community that determine whether a long-lived system can be understood, maintained, and adapted — and code quality, understood as 'obvious over clever,' matters more in this era, not less.
• 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.
• Bliki: Mythical Man Month Martin Fowler · 2026-01-01 source ↗ Reader 🖥️
  Fred Brooks's 'The Mythical Man-Month' remains essential reading because its core lessons — that communication overhead defeats brute-force staffing and that conceptual integrity is the highest design priority — are as true in 2026 as in 1975.
• Why Rust is different, with Alice Ryhl The Pragmatic Engineer (Gergely Orosz, host) · 2026 Reader 🖥️
  Rust earns its growing adoption not by adding features but by systematically engineering away whole classes of programmer mistakes — null, uninitialized memory, unhandled errors, stale documentation, memory-unsafety, non-exhaustive matches — through a type system, ownership/borrow checker, and a governance and tooling culture (RFCs, editions, Cargo, doc-tests) that treats reliability as a composite property rather than a single feature.
• How AI will change software engineering – with Martin Fowler The Pragmatic Engineer · 2025-11-19 source ↗ Reader 🖥️
  AI's defining change to software engineering is not primarily a jump in abstraction level but a shift from deterministic to non-deterministic systems — and the disciplines that make software durable and legible to teams over time (small reviewable steps, tests, refactoring, shared vocabulary, mentorship) matter more, not less, as a result, even as the field has not yet worked out how teams — as opposed to individuals — should operate with AI.
• Eight years of wanting, three months of building with AI Lalit Maganti · 2025-03-01 source ↗ Reader 🖥️
  AI coding agents are a genuine force multiplier for implementation and last-mile polish, and can unlock projects that would otherwise die from the intersection of difficulty and tedium, but they are a dangerous substitute for design, architecture, and taste -- the developer must retain ownership of the soul of the software or risk building a codebase they cannot reason about.
• How Coders Can Survive—and Thrive—in a ChatGPT World IEEE Spectrum · 2023-07-03 source ↗ Reader 🖥️
  Programmers remain relevant in an LLM-centered coding world not by out-generating AI at writing code, but by doubling down on what AI does not supply — problem-solving, software-engineering fundamentals, structural judgment, precise communication of intent, and critical scrutiny of AI output — while treating AI tools themselves as a fast-moving, interchangeable part of the workflow rather than a fixed skill to master once.
• 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.
• 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.
• How to write with style Kurt Vonnegut · 1982 Reader 🖥️
  Good writing style is not verbal ornament but the honest self-revelation of a writer who genuinely cares about a worthwhile subject and respects the reader — and it is achieved not through games with language but through caring about content, sounding like the actual person you are, keeping language simple, and cutting anything that does not illuminate the subject.
• How to write clearly Edward T. Thompson · 1979 Reader 🖥️
  Writing clearly is a learnable discipline rather than a gift, and it rests on first thinking clearly: because muddy prose is really muddy thinking, the writer who does the hard work of settling and ordering what to say before writing — then prunes, simplifies, and calibrates everything in the reader's service — can make almost any idea understood with the least possible effort from the reader.

Propositions touching this concept (23)

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

2025-11

• explicitdevelopedBuilding a rigorous, shared, DSL-like vocabulary to communicate with the LLM — ideally co-built with the LLM itself — is a more promising line of attack than either unchecked vibe coding or large upfront specifications, echoing domain-driven design's 'ubiquitous language.'
  How AI will change software engineering – with Martin Fowler · p9

2026-01

• explicitConceptual integrity is the most important consideration in system design.
  Bliki: Mythical Man Month · p3
• explicitConceptual integrity requires both simplicity and straightforwardness (composability).
  Bliki: Mythical Man Month · p5
• implicitThe pursuit of conceptual integrity is a career-level organizing principle for a software practitioner.
  Bliki: Mythical Man Month · p8

2026-02

• explicitestablishedInformation architecture (clear naming, structure, patterns, minimization, bounded changes) becomes *more* important — not less — under code agents, because the agents themselves respond better to structured codebases.
  11) AI-spesial med Vilde Opsal og Anders Sveen · p4
• implicitImplicit/assumed: the unit of valuable change is the *judgment + evals + information architecture* stack, not the individual prompt — i.e., the durable engineering output is now organizational rather than per-developer.
  11) AI-spesial med Vilde Opsal og Anders Sveen · p21

2026-04

• explicitDeep modules (Ousterhout) make codebases easy for agents to navigate AND let humans retain a mental model of the codebase while delegating implementation behind module interfaces.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p10
• explicitThe PRD itself does not need to be reviewed by the developer once alignment was reached during grilling, because LLMs are reliable summarizers of an already-shared design concept.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p18
• explicitWorking with AI in 2026 means working harder than before, AND losing your mental model of the codebase faster than before; the architectural prescription (deep modules with interfaces you design yourself) is the proposed defence.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p22
• explicitOperations in complex product domains is fundamentally an information architecture and ontology design problem, not a manufacturing-style process optimization problem.
  Introduction · p5
• explicit⚡ disputed & corroboratedThe specs-to-code approach produces progressively worse code with each iteration due to software entropy.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever · p2
• explicitA ubiquitous language reduces AI verbosity and improves implementation alignment with plans.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever · p7
• explicitestablishedDeep modules with simple interfaces make a codebase both testable and AI-friendly.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever · p11
• explicitDevelopers can safely delegate implementation of non-critical deep modules to AI while retaining control of the interface design.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever · p12

2026-05

• explicitBSSN is a practice discipline that must be learned through repeated experience, not through intellectual persuasion.
  Applying Best Simple System for Now for Software Design · p7
• explicitcorroboratedBefore coding (or prompting), teams should reach a shared design concept — agents amplify whatever direction you give them
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. · p7

2026-07

• explicitAn agent treats the existing codebase as evidence that outweighs a few lines of instruction, so it imitates whatever patterns it sees ('agents amplify what they see; poor code leads to poorer code'); an autonomous loop therefore ACCELERATES software entropy — piling dozens of commits per hour where a human commits once or twice a day — unless the codebase is kept clean, quality expectations are made explicit, and feedback loops enforce standards.
  11 Tips For AI Coding With Ralph Wiggum · p9
• explicitHigh-level software design — a clear domain model expressed across code, tests, documentation, UI and stakeholder conversation; a well-defined shared Ubiquitous Language; pragmatically-scoped Bounded Contexts; and continuous evolution of all three — remains essential and largely human territory even where low-level code generation is automated. Bounded Contexts additionally help agentic development directly by capping context-window size and token cost.
  Software Design in the Agentic Age: Placing Your Bets · p4
• explicitThe author is unconvinced that code can be safely discarded and regenerated at will from specifications, because regeneration carries its own cost and could increase the cost of re-verifying functional and non-functional requirements (security, performance) on every regeneration; he is also unsure whether low-level code quality matters much beyond its effect on token cost — yet he still bets on high test coverage, sound domain models/Ubiquitous Language/Bounded Contexts and code quality, primarily as a hedge that preserves the option to revert an organization from agentic generation back to human engineering if AI's economics or reliability don't hold up.
  Software Design in the Agentic Age: Placing Your Bets · p7
• explicitdevelopedHuman-legible naming and Ubiquitous Language likely still matter functionally in agentic development, not merely for human comfort, because language must be shared across code, specifications, diagrams, UIs, APIs and MCPs and across human/agent conversation — and because LLMs are trained on massive amounts of human language, not on hypothetical non-human-readable agent-only languages, which lack sufficient training data to be viable.
  Software Design in the Agentic Age: Placing Your Bets · p11

2026-08

• explicitWell-partitioned, deep modules with disciplined interfaces help AI agents the same way they help humans — by letting the agent (or reader) focus on one module without needing to hold the whole system in mind at once — though the complexity threshold at which this stops working may differ for agents versus humans.
  LIVE: Uncle Bob on Software Fundamentals in the Age of AI · p9

2026-09

• explicitSome dependencies among value-delivering units are essential to the value itself (cannot be removed without destroying it), while others are accidental artifacts of organizational history — mirroring Brooks' essential/accidental complexity distinction from software design.
  Beyond Autonomous Teams in Software Product Development · p5
• explicitThe 'how do we fit together' question extends beyond backlog/sprint-goal coordination to a system's conceptual integrity (Fred Brooks) — i.e., whether resourcing and focus choices serve a coherent whole rather than a series of disconnected tickets.
  Beyond Autonomous Teams in Software Product Development · p11

Tensions

Open gaps (86)

• incompleteNo discussion of which quality signals resist deterministic proxying altogether. Mutation testing and unit tests can catch correctness regressions but not architectural coherence, elegance, or long-term comprehensibility — the very qualities ('clean', 'thoughtful') the post's own opening paragraph names as markers of good code.
  Addy Osmani's Post — read next: extract-garg-reducing-friction-ai-development.json (g2: Polanyi's paradox — the most important quality signals may be exactly the ones hardest to articulate as explicit constraints) and the software-design-fundamentals corpus (Ousterhout on deep modules, complexity) for what judgment stays irreducibly human.
• incomplete'Right-sizing' is presented as clearly beneficial, but the author concedes many are 'still figuring out which primitives they are and how best to invest in them' — the piece provides no heuristic for finding the right boundary or context size.
  AI Is Changing Software Engineering. The Fundamentals Still Matter. — read next: Read on modularity heuristics such as Ousterhout's deep modules, and on context-window budgeting for LLMs.
• incompleteTeam adoption is treated as an exercise for the reader. Pocock's answer to 'how does this work in a team?' is essentially: 'the upstream becomes team-shared, the downstream is one or two devs managing the pipeline.' He gives no story for: review queue scaling, distribution of PRD-authoring authority, who owns skills/coding-standards as a shared asset, code-review burden as a team-wide labour question, or how juniors learn craft in a workflow where most code is agent-written.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Cutler on overload and accountability culture; Beck on socio-technical change; Fearless Change for the adoption-of-practices angle in the user's hidden-layer interests.
• incompleteThe 'pre-AI books' recommendation is the closing thesis but is left underspecified. Pocock cites Pragmatic Programmer (tracer bullets), Ousterhout's Philosophy of Software Design (deep modules), Brooks's Design of Design (design concept), Fowler's Refactoring (small steps) — but does not give a reading list, nor a mapping of which insight from which book deploys at which point in the workflow. This is the load-bearing connection to the user's craft tradition and is left as a 'go buy them on Amazon.'
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: The user's library already covers Beck (small steps, TCR, simple design), Hickey (Simple Made Easy), Yourdon & Constantine (Structured Design), Meadows (Thinking in Systems). The mapping work is for the orchestrator to do: e.g., Pocock's 'don't bite off more than you can chew' is Fowler-on-refactoring; deep modules is Ousterhout; tracer bullets is Hunt & Thomas; design concept is Brooks. The honest gap is that Pocock does not even mention Beck — surprising given Beck's TCR is operationally close to red-green-refactor as Pocock practices it.
• incompletePocock's workflow structurally mirrors Anthropic's harness paper (planner / generator / evaluator) and Böckeler's adaptive-control framing, but he does not name them or compare. The grill-me skill is alignment; the PRD-to-Kanban is planning; the AFK Ralph loop is generation; TDD + manual QA + reviewer-Opus is evaluation. Surfacing this overlap is essential to placing his workshop in the broader 2026 AI-coding discourse.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Anthropic harness paper, Böckeler on adaptive control, Addy Osmani on agent patterns (in the user's saves) — all map onto Pocock's lifecycle with different vocabulary.
• incompletePocock conflates two definitions of 'done': (a) feature shipped with QA-imposed taste, and (b) commit produced by the Ralph loop with passing tests. The transitions between (a) and (b) — especially the merge-and-conflict-resolution at the end of multiple parallel sandbox branches — are sketched (the Sandcastle merger agent) but not interrogated for what happens when the merger itself produces semantically broken code. This is exactly where small-PR discipline matters and where he admits he doesn't have the answer.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Beck on incremental design and TCR; trunk-based development literature; the smallcode failure-mode catalog if it covers merge-stage failures.
• incompleteThe implicit premise that the developer can read agent output well enough to QA, code-review, and impose taste is enormous. Pocock states 'understanding code deeply is going to make you a much, much better developer and get more out of AI' and 'bad codebases make bad agents' — but does not address the developer who is themselves junior, distracted, or not the original architect. The workflow may be most valuable to seniors and least usable by the engineers who most need leverage.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Marcus on code quality (in user's recent saves), Beck on apprenticeship/teaching contexts, Cutler on directly-responsible-individuals and skill distribution.
• uninformedPocock specifically defers the question on conforming to security, architectural, and API-contract constraints ('I'm going to answer that in a bit') and never returns to it. For the user's organizational context (Norwegian senior leader watching governance signals), this is the highest-value question and is left unaddressed.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Security-review skill, Schneier on Security, explainable-AI requirements paper in the user's library, organisational adoption studies on AI tooling in regulated industries.
• 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
• incompleteThe claim that the five questions apply unchanged 'at all levels: team, team-of-teams, department, whole organisation' is asserted but only ever demonstrated with a single team-level worked example (Scrum backlog, sprint goal); no worked example is given at the team-of-teams, department, or whole-organization level, so the universality/recursiveness claim is untested within the piece itself.
  Beyond Autonomous Teams in Software Product Development
• illogicalThe article's central optimistic thesis — that the cost-benefit balance for static analysis has shifted decisively in AI's favor — sits uneasily next to its own unresolved counter-example: the max-lines rules produced good refactoring in isolation but also seemed to drive a 'worrying trend' of React components with growing prop lists, a different maintainability problem the author admits she can't yet detect or judge. The piece doesn't reconcile these two observations, nor consider whether the sensor setup itself (optimizing per-rule, per-file) structurally can't see this kind of cross-component tradeoff regressing even as every individual rule stays green.
  Maintainability sensors for coding agents — read next: The next installment already in this corpus (extract-fowler-bockeler-static-sensors-iii) is a partial answer — it addresses cross-file/module concerns with dependency-cruiser rules and an inferential modularity review, though it doesn't specifically revisit the prop-drilling example raised here.
• incompleteThe "degrade to origin" rule is presented as unconditionally safe, but the article never considers cases where the unoptimized origin response is itself unacceptable — a client device that genuinely cannot render the origin format, or a tenant whose cost/bandwidth contract depends on the optimization having actually run. The fallback's own failure mode is left unexamined.
  Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers — read next: Would benefit from engaging with graceful-degradation literature that treats the fallback path itself as a design surface with its own failure modes, not an automatically safe default.
• incompleteThe article names the observability loss caused by decomposition (diagnostics captured inside a downstream feature worker are not propagated back through the gateway) but never describes how the team actually debugs a failing request in production once it crosses a service-binding boundary — the fix for the gap it identifies is left unstated.
  Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers — read next: Distributed-tracing / observability practice for chained service-to-service calls (e.g., correlation IDs threaded through headers, structured logging aggregation) would close this.
• unstated assumptionThe author assumes that the inability to externalize institutional knowledge and design context is a fundamental limitation of AI, not merely a tooling limitation. This conflates current AI capabilities with inherent constraints. Future models with persistent memory, codebase-scale context, and temporal reasoning could potentially bridge this gap.
  Eight years of wanting, three months of building with AI — read next: Read work on long-context models, AI memory architectures, and research on whether design taste can be formalized or learned (e.g., Christopher Alexander's pattern language as a possible bridge).
• omissionThe article does not discuss the economics of AI-assisted development beyond the $200/month Claude Max subscription. The 250 hours of personal time invested is mentioned but not analyzed in terms of opportunity cost or compared to hiring/contracting alternatives.
  Eight years of wanting, three months of building with AI — read next: Compare with analyses of AI coding tool ROI; consider the total cost including cognitive overhead and the discarded vibe-coding month.
• unexamined tensionThe author claims 'AI didn't just make the same project faster -- it changed what the project was' (adding editor extensions, docs, WASM playground). But he also claims the core value comes from the parser architecture, which AI was harmful for. This raises the question: did AI expand the project's scope in the right direction, or did the cheap last-mile features dilute focus on the hard core?
  Eight years of wanting, three months of building with AI — read next: Consider the 80/20 principle in open source: does breadth of features or depth of core reliability drive adoption?
• implicit premiseThe expertise-x-verifiability framework assumes that 'taste' and design judgment are inherently human and non-formalizable. This is stated as obvious but is actually a deep philosophical claim about the nature of aesthetic and design knowledge. If taste could be partially formalized (as design systems and API design guidelines attempt), the framework's boundaries would shift.
  Eight years of wanting, three months of building with AI — read next: Joshua Bloch's 'How to Design a Good API and Why It Matters'; API design guideline literature; whether LLMs can learn design heuristics from large corpora of well-designed APIs.
• incompleteFowler claims the lessons are 'still relevant today' but provides no modern examples or evidence. The piece is purely retrospective endorsement. What does violating conceptual integrity look like in 2026 — in microservices, AI-generated code, or platform teams? How does Brooks's Law manifest with remote/async teams, AI pair programmers, or open-source contribution models?
  Bliki: Mythical Man Month — read next: Brooks's own 'No Silver Bullet' essay (included in the anniversary edition); Conway's 1968 paper on organizational structure mirroring system design; Team Topologies (Skelton & Pais) for a modern treatment of communication paths as architectural constraints; Fred Brooks's later reflections in 'The Design of Design' (2010).
• 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.
• incompleteTorrissen's frame is largely Norwegian consultancy and public-sector. The 30-year-lifespan argument is anchored in NAV/Skatt/politi; he gestures at differential quality bars for low-stakes consumer apps but does not engage with product-company contexts (startup, scaleup, SaaS) where the relevant time horizon is 3-5 years and the relevant readers are 5-10 engineers, not 70 forvaltere.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Read this against the Pocock workshop extraction (product-company AI workflow) and Vidar Moe (Heis), to see how product-company engineers calibrate quality differently.
• 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 'obvious over clever' principle is presented as inheritance from NAV's tekniske retning but the tradeoff against domain-modelling power, type-system expressiveness, and idiomatic language use is not explored. A 'maximally obvious' codebase in a functional language with strong types may look obscure to a Java-trained 70-forvalter pool.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Greg Young / Vlad Khononov on domain modelling; Ousterhout's 'A Philosophy of Software Design'; Rich Hickey's 'Simple Made Easy' (vs. 'easy ≠ obvious').
• incompleteTorrissen acknowledges he's about to participate in a recursive case (reviewing code that was itself generated agentically) and only jokes. The methodology gap — how does code review change when the developer's intent is partially encoded in prompts, ADRs, and context files rather than commit history — is left for next time.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Anthropic 'harness design' talk and the Pocock workshop already in this corpus.
• 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.
• uninformedTorrissen disclaims familiarity with the formal 'distribution law' he invokes (Parnas/Helland-style). He gets the spirit right but doesn't engage with the literature on when distribution is forced (latency, regulatory, fault isolation).
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Pat Helland's papers; Parnas on module boundaries; Vlad Khononov directly.
• incompleteCode quality discussion is silent on data and persistence design — arguably the longest-lived and hardest-to-change layer in 30-year systems. The whole conversation is about behavioural code.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Stripe-style schema evolution practice; Martin Kleppmann's data engineering work; event-sourcing reflections from CQRS practitioners.
• illogicalJonas argues both that we are early on the AI S-curve (so 10% gains are not the story) and that complexity will push back on productivity gains as they accumulate. These are compatible but in tension: if the curve climbs steeply because of intent-level abstraction, the complexity ceiling should appear later; if complexity bites soon, the curve is shallower than claimed. The argument is not adjudicated.
  17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis — read next: The Brooks / Mythical Man Month tradition on accidental vs essential complexity; Ousterhout on system design; recent measurements on long-running agent harnesses (Anthropic harness design work) which directly test the complexity-ceiling claim.
• incompleteThe method assumes a single, fixed message that already exists, whole, before writing begins -- 'you know where you will stop before you start.' It has no place for exploratory or discovery writing, in which the point emerges only through the act of drafting. This is in tension with Thompson's own implicit 'clear writing = clear thinking': he treats thinking as prior to and separable from writing (think via the cards, then transcribe), whereas the writing-as-thinking tradition holds that writing IS the thinking, and that outlining-first can only help once the hard cognitive work is already done.
  How to write clearly — read next: Read Peter Elbow 'Writing With Power' and Sonke Ahrens 'How to Take Smart Notes' (Zettelkasten) on writing as thinking-to-discover, and Franco 'What we lose when AI writes for us' on writing as constituting (not merely reporting) a view -- against Thompson's think-first-then-write separation.
• incomplete'Clarity' is treated as always achievable by simplification, but some subjects are irreducibly complex, uncertain, or essentially ambiguous, and faithful writing must preserve that -- flattening them into one clean surface reading can falsify. Every Thompson exemplar (all the fish died; the cherry tree) is a subject where nothing complex is lost; none tests the claim against genuinely conceptual or contested material.
  How to write clearly — read next: Read Ousterhout on essential vs. accidental complexity and deep-simple vs. simplistic, and technical-writing / explanation-theory work on rendering irreducible complexity without falsifying it -- to see where 'be clear' shades into 'oversimplify.'
• incompleteThe essay is pre-digital and pre-collaborative: it prescribes clarity as a solo writer's individual discipline, yet its own proof texts ('Notice how WE edited this', 'Condensing, as Reader's Digest does it') reveal that the exemplary clear prose is the product of a collective editorial apparatus. It says nothing about writing with editors, collaborators, revision tooling, or (now) AI drafting assistants -- the very machinery that actually produces the 'condensed' Digest style it holds up as the model.
  How to write clearly — read next: Read on editorial process and collaborative revision (how Reader's Digest condensing actually worked as a pipeline), and current work on AI-assisted drafting where the outline-first and condense steps are negotiated with a machine rather than performed alone.
• incomplete'Start where your readers are -- how much do they know?' assumes a single, knowable audience with an identifiable common level of knowledge (natural for a mass magazine with an imagined 'average reader'). It gives no guidance for heterogeneous or unknown audiences -- the default condition of digital publishing -- where readers span wildly different priors and there is no one level to start from.
  How to write clearly — read next: Read on writing for mixed audiences and layered/progressive-disclosure documents (letting expert and novice readers each take the path suited to them) rather than a single pitched level.
• incompleteThe essay is entirely of the print-essay era: it says nothing about digital, collaborative, or AI-assisted writing. Its whole model — a single author revealing a single self to a reader — does not touch what 'sounding like yourself' or 'style as self-revelation' mean when text can be machine-generated, co-written, or stylistically homogenized at scale.
  How to write with style — read next: Read against Franco 'What we lose when AI writes for us' (style/voice as the Self, and its convergence under AI), Acunzo 'The best response to AI slop' (distinctive firsthand voice as the non-commoditizable signal), and the taste article (correctness vs. quality when a machine produces the prose).
• incomplete'Sound like yourself' is under-specified to the point of circularity for a novice: it presupposes an already-articulate, trustworthy voice worth sounding like, and locates that voice in one's origin and childhood speech rather than in any developable skill. It offers no method for a beginner whose natural voice is inarticulate or undeveloped to find or grow one.
  How to write with style — read next: Read a pedagogy-of-voice source (Zinsser 'On Writing Well', Peter Elbow's 'Writing With Power') and the deliberate-practice literature on how voice is cultivated rather than inherited.
• incompleteThe simplicity argument generalizes from emotional profundity to all profundity. Every exemplar (Hamlet's soliloquy, Joyce's 'She was tired', Genesis) is emotional or narrative depth rendered plainly; none is a technically or conceptually irreducible subject. The claim that childlike simplicity fits 'the most profound subjects' may not survive contact with domains whose complexity is essential, not incidental.
  How to write with style — read next: Read Ousterhout on essential vs. accidental complexity and the difference between deep-simple and simplistic; explanation theory / technical-writing craft on rendering irreducible complexity without falsifying it.
• incompleteThe claim that non-standard voice is 'delightful' assumes a reader who is charmed by it ('like a very pretty girl with one eye green and one blue'), with no account of the many contexts where non-standard or regional voice is penalized rather than trusted. 'Sound like yourself' is treated as costless, which may reflect the privilege of a canonical author rather than the situation of a writer whose authentic voice carries real reputational cost.
  How to write with style — read next: Read sociolinguistics on prestige dialects and linguistic discrimination, and the literature on code-switching, to see where authentic voice is a liability rather than a delight.
• 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.
• incompleteConstruction ergonomics (wrapping every Java primitive in a factory call before it can enter a JSON object or array) is flagged as 'one likely area for feedback,' but the article never explores what alternative designs — builder APIs, varargs helpers, or implicit boxing conveniences used by other JSON libraries — might resolve it, or why the JEP authors chose explicit factories over those alternatives in the first place.
  JEP 540 Proposed to Target JDK 28 with a Simple JSON API — read next: The JEP 540 specification's own 'Alternatives' section, and any core-libs-dev / amber-dev mailing-list discussion from the incubation period proposing alternative construction APIs.
• 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.
• incompleteThe domain-modeling skepticism ('why would DDD work now when it never became standard before?') is raised sharply but never answered, leaving the proposed core mechanism for steering agents and scaling teams unresolved.
  Notes from FOSE Europe — read next: Read on domain-driven design applied to agent steering and on enterprise context/knowledge layers to see what, if anything, is different this time.
• 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.
• incompleteThe talk claims AI performs well in good codebases and poorly in bad ones, but provides no data or examples to substantiate this — it relies entirely on the audience's intuitive agreement.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Look for empirical studies measuring AI coding tool performance as a function of codebase quality metrics (coupling, cohesion, test coverage).
• incompleteThe talk does not address who is responsible for the initial codebase quality when starting a greenfield AI-assisted project. If the AI generates the initial code, the entropy problem exists from day one.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Investigate AI-assisted bootstrapping practices and whether initial architecture prompting can produce deep-module structures from the start.
• incompleteThe 'Improve Codebase Architecture' skill is mentioned but described only as 'quite complicated' — the talk does not explain how to refactor a shallow-module codebase into deep modules, which is the hardest step.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Read Ousterhout's A Philosophy of Software Design chapters on deep modules; explore the mattpocock/skills GitHub repo for the actual skill implementation.
• incompleteThe talk assumes TDD is applicable to all AI-generated code, but does not address domains where TDD is hard to apply (UI, data pipelines, exploratory prototyping) or where the cost of test-writing may exceed the cost of debugging.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Look for frameworks on when TDD is cost-effective vs. when other feedback mechanisms (type checking, property testing, visual review) are better suited.
• incompleteThe talk's five tips are presented as independent failure modes, but the dependencies between them are not explored. For example, does ubiquitous language require deep modules to be effective? Does Grill Me only work if the developer already has architectural knowledge?
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Consider whether these practices form a prerequisite chain or can be adopted independently.
• incompleteThe claim that design-pattern/architecture vocabulary declined in the 2010s because cloud-managed building blocks absorbed architectural decisions is offered tentatively (relayed from Grady Booch, with Fowler admitting 'I haven't had the opportunity to focus on that') and is not reconciled with the fact that distributed-systems pattern books (Unmesh Joshi's, which Fowler himself worked on) exist and are, by Fowler's own account, valuable — leaving unclear whether patterns declined in substance or just in public discourse/branding.
  How AI will change software engineering – with Martin Fowler — read next: Look for a more rigorous account of whether architectural decision-making genuinely migrated into managed cloud services, versus patterns persisting informally as company-specific jargon (the Uber service-naming example Fowler and Orosz discuss in the same segment).
• uninformedFowler attributes the current software-industry downturn and job losses primarily to the end of zero-interest-rate financing rather than AI, but does not engage with the counter-evidence elsewhere in the discourse that some of the layoff wave is genuine AI-driven restructuring (not merely macroeconomic or a cover story) — he states his view confidently without weighing the split causation other commentators report.
  How AI will change software engineering – with Martin Fowler — read next: Compare against corpus accounts that split the layoff wave into AI-washing/cover-story and genuinely AI-driven restructuring components.
• incompleteThe category of bug Rust does NOT prevent is left implicit. Logic bugs, mis-modeled domains, distributed-systems race conditions across services, mis-handled business invariants — these are arguably the dominant cost in modern backends, and Rust's compile-time machinery does not touch them. Yet the conversation rhetorically positions Rust as 'reliable' full stop.
  Why Rust is different, with Alice Ryhl — read next: Read Hillel Wayne on formal methods and where types stop helping; Rich Hickey 'Simple Made Easy' on complexity that types don't catch; recent work on property-based testing (Hegel/Hypothesis — sponsor of this very episode, interestingly).
• incompleteThe organizational shift Rust demands is gestured at ('change the struct, not the code') but never made explicit. Adopting Rust seriously means moving design effort upstream — into types and ownership topology — which has real implications for who designs, when, and how PRs are reviewed. The conversation treats this as a personal learning curve when it is plausibly a team-process redesign.
  Why Rust is different, with Alice Ryhl — read next: Read Kent Beck on where in the design timeline to invest effort (Tidy First?), Yourdon & Constantine on coupling/cohesion as the unit of design, and Ousterhout's 'A Philosophy of Software Design' on deep modules — then ask: in a Rust shop, who owns ownership decisions, and when?
• incompleteThe cost-of-incidents argument is anchored to a Western, large-company threat model ('don't get woken up at night,' 'don't ship a CVE,' 'don't lose root'). It would be much stronger framed against actual cost-curve data: how much do memory-safety CVEs cost on average, what fraction of Google/Microsoft/AWS incident postmortems involve memory bugs, what's the marginal Rust dev-hour cost per prevented incident? Alice alludes to '~70% of Microsoft/Google bugs are memory bugs' folklore without citing.
  Why Rust is different, with Alice Ryhl — read next: Read the Microsoft Security Response Center memory-safety report (the source of the 70% figure), Google's Android memory-safety post-Rust adoption data, the CISA secure-by-design memo, and the US DoD/NSA memory-safety guidance Alice alludes to.
• incompleteThe Cargo/npm risk parallel is acknowledged and immediately dropped. Given the kernel's explicit rejection of fetch-and-run package management (Linus's anecdote), Rust's strategy for supply-chain integrity is load-bearing for any organization considering it for security-sensitive code — yet the episode offers nothing beyond 'it's a hard problem.'
  Why Rust is different, with Alice Ryhl — read next: Read crates.io's threat model docs, the Cargo audit/cargo-vet tooling, Linux distributions' approaches to vendoring Rust crates, and recent academic work on the npm/PyPI/crates supply-chain attack surface.
• incompleteThe Rust-and-AI thesis ('compiler-as-leash for agents') is asserted but not pressure-tested. Crucially absent: what happens when the agent reaches for `unsafe` to satisfy the compiler? What happens when the agent's chosen data structure is the wrong one and the compiler keeps approving — but at the cost of forcing Arc<Mutex<...>> everywhere? The compiler can't catch 'this struct shape was a bad idea.'
  Why Rust is different, with Alice Ryhl — read next: Look for empirical evaluations of AI coding agents in Rust vs in Go/TypeScript (recent benchmarks from Anthropic/OpenAI/SWE-bench-Rust), and pair with vibe-coding critiques like Steve Yegge / Gene Kim — exactly what Kjetil is already reading.
• uninformedGergely floats 'is Rust uniquely good for agents because of compiler feedback?' and neither speaker has data; Alice has 'tried to use them' but is 'still learning.' This is a place where the conversation would have benefited from a third voice with measured agent-on-Rust experience.
  Why Rust is different, with Alice Ryhl — read next: Recent reports/benchmarks on agentic coding by language (e.g. METR/Anthropic, Cursor postmortems, the Aider language-success-rate leaderboard) would directly fill this.
• illogicalThe phrase 'when it compiles, it works' is acknowledged-in-quotes but then deployed as if it were literally true (Alice's refactoring anecdote, Gergely's monologue). This conflates 'no bugs in the bug-classes Rust catches' with 'no bugs at all.' For an audience of senior engineers, the difference matters and the slippage is rhetorically convenient.
  Why Rust is different, with Alice Ryhl — read next: Read any survey on bug-class distributions in production systems; pair with Brian Goetz / Bjarne Stroustrup commentary on the limits of static typing.
• illogicalThe central 'F# has a larger unique-feature set, therefore it's superior' argument rests on a Venn diagram the author himself calls 'not to scale' and describing something that 'can't even be measured' — the same unweighed-capability move flagged as a central weakness in the predecessor JSON-vs-XML article, and in direct tension with the Best Simple System for Now view that more speculative capability and optionality make systems harder, not easier, to reason about and change.
  Worse is better: C# versus F# — read next: Re-read 'Applying Best Simple System for Now' (extract-applying-best-simple-system-for-now) alongside this piece to test whether 'F# has more features' is evidence of superiority or simply of more surface area, by the same standard BSSN uses against speculative extensibility.
• incompleteThe 'what C# does better' section lists real, current C# advantages (Razor/GUI support, IDE tooling, cyclomatic-complexity/coverage/mutation-testing tool support, programmer availability) but never weighs them against F#'s advantages in any explicit cost-benefit — each point is granted and then set aside ('I do occasionally find cyclomatic complexity useful, so it'd be nice to have tool support for that') rather than integrated into the overall superiority verdict, mirroring the same aggregation-without-weighing pattern flagged in the JSON-vs-XML predecessor article.
  Worse is better: C# versus F# — read next: Look for a practitioner cost-benefit account of migrating a real C# codebase to F#, weighing tooling gaps (mutation testing, coverage, IDE refactoring support) against the architectural and expressivity gains claimed here.
• incompleteThe article names 'declarative programming is harder to learn than imperative programming' as a likely driver of C#'s greater popularity, but explicitly declines to investigate whether this is inherent to human cognition or an artifact of how most programmers first encounter programming — leaving the actual mechanism behind F#'s unpopularity, and thus the practical case for or against teaching F# (or FP) first, unresolved.
  Worse is better: C# versus F# — read next: Read CS-education or cognitive-science literature on whether imperative-first instruction creates a lasting bias against declarative/functional thinking, versus functional programming being intrinsically harder to learn regardless of instruction order.
• incompleteThe claimed F# tooling deficit for mutation testing rests on information the author flags as possibly outdated ('last time I worked with mutation testing in .NET I found no F# support, but it looks as though Stryker has at least rudimentary F# support... I should look into that in the future') — the article's own concession that C# has a testing-tooling advantage is not verified as current at time of writing.
  Worse is better: C# versus F# — read next: Check Stryker.NET's current F# support maturity directly rather than relying on this now-superseded claim, especially since this extraction may itself now be dated.
• incompleteThe payoff-matrix argument for betting on code-quality investment never assigns probabilities, timeframes, or a magnitude to the cost of maintaining quality infrastructure — it establishes only a qualitative asymmetry (cheap to remove vs. expensive to add later) without showing that asymmetry outweighs the opportunity cost of near-term velocity foregone if camp 1 (agents don't need design principles) turns out substantially right in the near-to-medium term.
  Software Design in the Agentic Age: Placing Your Bets — read next: Look for a quantified real-options or cost-of-delay analysis applied to engineering-practice investment decisions under this kind of technological uncertainty.
• incompleteThe 'raise the floor but not the ceiling' claim is repeated approvingly but never operationalized. How does a leader, in practice, recognize ceiling-extending original work as opposed to confidently-presented model-mediated work? Without a heuristic, the framing becomes a flattering self-description rather than a usable filter.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Read Cedric Chin on tacit knowledge or Tyler Cowen on 'what counts as taste in an AI era' for concrete diagnostics; also Karpathy's full talk for his hiring criteria as a partial answer
• incompleteTwo of the curator's headline framings — 'AI raises the floor' and 'AI eats closed loops first' — are pulled toward each other but not reconciled. If AI raises the floor on closed-loop work, the implication is that closed-loop expertise becomes commodity labor while open-loop / relational / ethical work becomes the new premium. The newsletter implies this but does not state it, leaving leaders without an explicit instruction.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Elad Gil's full 'Misty AI Frontier' piece + a careful read of Yue Zhao's leadership argument against Christensen's disruption framing — the synthesis is more useful than either alone
• incompleteThe newsletter implicitly equates 'agentic engineering' (a craft skill) with 'agentic leadership' (a hiring/strategy task) but never separates them. Whether the same person should both code with agents and lead teams that code with agents — and whether the screening criteria are the same — is left ambiguous.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Bruno Fernandez-Ruiz's 'Engineering in the Compiler Age' slides (referenced here, worth a focused extraction) and Karpathy's actual hiring section to see how he separates IC craft from leadership selection
• incompleteThe 'Anthropic AI-resistant evaluation' story is treated as a positive exemplar, but the newsletter does not engage with the obvious tension: a long-horizon take-home where AI is permitted requires significant unpaid candidate time, which is a known equity problem. The curator endorses the design pattern without acknowledging its cost.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: The original Anthropic write-up, plus any of the recent compensated-interview / pair-programming-screen literature, for a more honest cost-benefit picture
• illogicalThe endorsement of 'gut over head' (SahilBloom tweet) sits uneasily next to the endorsement of 'shared design concept before you code' (Pocock). The first valorizes unjustified judgment; the second valorizes explicit-and-shared rationalization before action. The newsletter treats both as obviously correct without noting that they pull in opposite directions for a leader deciding which to lean on in a given situation.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Daniel Kahneman on when intuition is trustworthy (closed environments with rapid feedback — i.e., precisely the closed loops AI is eating); Gary Klein's recognition-primed decision research for the conditions under which gut beats analysis
• incompleteThe claim that 'randomly cutting the file into smaller files is unlikely to help as much' as the duplication-first sequence used here is asserted, not tested — no control condition (e.g. mechanically splitting the original file into N same-sized chunks without deduplication first) isolates the effect of duplication-removal from the effect of file-count/size on the agent's read behavior.
  The Economic Benefit of Refactoring — read next: Read extract-fowler-fragments-july-6#g1 and #g2, which flag the identical unresolved confound-isolation problem in the broader 'token cost as architecture proxy' claim this article partially, but not fully, answers.
• 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.
• incompleteMartin's central distinction — impose values, not disciplines — is given exactly one worked example (TDD's line-by-line interleaving versus full test coverage). He never generalizes it into a method for deciding, for an arbitrary classic discipline, which part is the 'value' and which part is the human-limitation-compensating 'discipline'. Without that method, the distinction risks becoming post-hoc rationalization for whatever an agent happens to do naturally, rather than a principled design tool.
  LIVE: Uncle Bob on Software Fundamentals in the Age of AI — read next: extract-pocock-software-fundamentals#p9 claims flatly that 'TDD forces LLMs to take small, disciplined steps that prevent entropy' — directly comparable material from the same host's own conference talk, worth reading against this conversation's more nuanced 'impose values not disciplines' position to see whether they are reconcilable or in genuine tension.
• illogicalThe article states that SKIP LOCKED gives "exactly-once processing guarantees," but the mechanism it actually describes only guarantees exactly-once *claim* — a row is assigned to exactly one worker at a time. Exactly-once *effect* (the property practitioners usually mean by that phrase) depends on the separate idempotent-checkpoint mechanism introduced two sections later. Stating the stronger claim in the SKIP LOCKED section conflates dispatch-level and effect-level guarantees.
  Article: Implementing Durable Workflows on Postgres Without an External Orchestrator — read next: Kleppmann's 'Designing Data-Intensive Applications' on effectively-once/exactly-once semantics, or Temporal's own documentation explaining why it separates at-least-once activity delivery from exactly-once effects via idempotency keys — the same distinction this article's own idempotency section implicitly relies on but doesn't name when making the SKIP LOCKED claim.
• uninformedThe article credits MySQL 8.0+, MariaDB 10.6+, Oracle, Db2, and SQL Server with SKIP LOCKED-equivalent mechanisms in a single aside, implying the pattern ports cleanly across databases, but does not note that these engines differ meaningfully in isolation-level defaults and MVCC/locking implementation (e.g., MySQL's gap-locking behavior under REPEATABLE READ) — real portability risk for a reader who lifts the exact SQL onto a different database.
  Article: Implementing Durable Workflows on Postgres Without an External Orchestrator — read next: Each database's own locking-read documentation, cross-compared for isolation-level defaults, before assuming this pattern is a drop-in replacement across engines.
• 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.
• incompleteThe claim that code is "another form of writing" — and therefore does the same thinking work as prose — is asserted by declaration rather than independently argued. The essay never explains why writing code should activate the same cognitive process as writing prose, rather than being a related but distinct discipline (e.g., naming partly constrained by compiler/type-system rules and existing conventions, not by the same open-ended "what do I actually mean" question prose poses).
  Writing vs. Thinking — read next: Compare with extract-software-design-agentic-age-placing-bets#p11 on why human-legible naming and Ubiquitous Language matter functionally — that argument grounds the claim in shared-language requirements across code/docs/conversation rather than in a cognitive-process equivalence with prose writing.
• incompleteHe confines 'you can't unit test for taste' to messy data and treats code as the safely 'verifiable domain,' but never turns the lens onto AI-generated code itself, where tests pass yet design taste — simplicity, deep modules, restraint — has no red/green check. As agents generate more test-passing code, the untestable-taste problem migrates into the codebase, not away from it.
  You can't unit test for taste — read next: Read Ousterhout 'A Philosophy of Software Design,' Beck 'Tidy First?,' and Hickey 'Simple Made Easy' on design quality as unassertable; cross with corpus docs agents-dont-know-what-good-looks-like (behavioral vs capability verification) and cognitive-surrender (surface-correctness signals). Test the claim: is a green build ever evidence of good design?