Stocks and Flows: Systems Thinking in Software Design

Jun 21 2026

Stocks and flows offer a systems-thinking lens for software design: instead of modeling only the visible entities — accounts, balances, queues, inventories, credits — they ask what is accumulating, what is changing it, and what evidence explains the current state. A balance is not just a number; it is the consequence of charges, payments, refunds, delays, corrections, and reconciliation. A queue is not just a list; it is shaped by arrivals, completions, retries, and backpressure. The piece argues that many stateful systems become confusing when they preserve snapshots but lose the movements that produced them, and that better models make those movements explicit enough to reason about correctness, freshness, boundaries, and change over time.

Design Design Thinking Essay

 The Cybernetics of Missing Variety

Jun 21 2026

Cybernetics, especially Ashby’s Law of Requisite Variety, to look at what happens when software models are too small for the world they regulate. Starting from a deceptively simple paid / unpaid payment status, it follows the complexity that appears when reality adds captures, settlements, refunds, disputes, chargebacks, provider webhooks, reconciliation, and human workarounds. The argument is not that every distinction deserves a first-class model, or that systems should copy vendor state machines wholesale. It is that meaningful variety has to be absorbed somewhere: in owned domain facts, feedback loops, operational processes, or people. A simple model can be useful, but it does not make complexity disappear. It only decides where that complexity will surface.

Cybernetics Design Essay

 You Can Get Some Satisfaction From Model Theory

Jun 21 2026

This essay uses the model-theory idea of satisfaction as a lens for thinking about software invariants: the difference between the rules a system claims to have and the states it actually permits. Starting from the familiar pain of “impossible” production bugs, it argues that domain models are not defined by architecture docs, class names, or happy-path code, but by the states the system can really enter. If an invoice without a customer can exist, then that state is part of the effective model, whether anyone intended it or not. The essay connects this to databases, type systems, state machines, service-layer validation, and AI coding assistants, making the case that important invariants should be structural where possible, while still leaving room for temporary states, policy rules, and the messy judgment production systems require.

Design Essay

 It's All About Communication

Mar 25 2026

Software is fundamentally communication, but the introduction of AI systems complicates the old human–machine model. Instead of a simple grid of interactions, it’s more useful to think in terms of three participants: humans, machines, and AI; each communicating differently. Working with AI highlights gaps in clarity, exposes hidden assumptions in code, and adds flexible translation layers between intent and execution. Rather than replacing existing interactions, AI reshapes them, shifting the focus from precise instructions to clearer expression of intent, and making communication itself more central and more visible in how we build software.

AI Essay

 Black Boxes, White Boxes, and the Visibility Spectrum

Feb 28 2026

This essay examines the spectrum of transparency in software systems, from fully open-source code to the deep opacity of LLMs and managed cloud services. Black boxes are powerful cognitive compression tools—hiding complexity behind clean interfaces—but create real challenges when things break and debugging requires visibility you don't have. As developers increasingly depend on AI APIs and serverless platforms, it might help using hybrid architectures that strategically combine opaque and transparent components, keeping core business logic visible while delegating well-bounded problems to black boxes.

AI Design Essay

 Excellence Is a Path, Not a Place

Feb 26 2026

On the last day of a music theory course, the teacher says "you can do anything, anytime" — and it lands like a revelation, but only because years of learning the rules gave that freedom its meaning. This piece argues that the same dynamic governs software excellence, and that AI has compressed but not eliminated the journey. The bell curve of a developer's career — naïve simplicity through sophisticated complexity back to informed simplicity — still holds, but tools like code assistants let you reach the complexity phase in weeks rather than years, which is exhilarating right up until something breaks and you're debugging abstractions you never earned an understanding of. The traditional schools of thought (clean code purists, pragmatist hackers, performance craftsmen) still disagree on plenty, but they converge on one thing AI hasn't changed: understanding your system matters, and no tool can substitute for the intuition built through deliberate struggle. The practical north star is trust — can others rely on what you build? — and the working heuristic is simple: if you can't explain why the AI's approach makes sense for your specific problem, you probably shouldn't ship it. Excellence in the AI era isn't refusing the tools or surrendering to them; it's caring enough to walk the path that gives you the right to break the rules. The speed limit got lifted, but the road is the same.

AI Essay

 The Human in the Loop

Feb 25 2026

AI can write code — that's no longer the interesting question. The interesting question is what happens to us when it does. This piece explores the tension between generation and understanding in AI-assisted development: the tools let you prototype five approaches in an afternoon, which is a genuine superpower, but they also create a seductive dopamine loop where effortless output bypasses the struggle that builds real competence. The core problem is trust calibration — AI-generated code passes structural smell tests while subtly failing semantic ones, and catching that gap requires exactly the kind of embodied intuition you only develop by wrestling with problems yourself. The highest-leverage meta-skill turns out to be decomposition: breaking complex problems into pieces you can reason about, which can't be delegated because it is the understanding. The practical sweet spot isn't avoiding AI or surrendering to it — it's using it for breadth (exploring patterns, drafting alternatives, generating boilerplate) while reserving depth for yourself, especially in the genuinely hard parts where judgment, taste, and debugging intuition matter most. What remains irreducibly human isn't the code — it's the walk that builds the navigator.

AI Essay

 Designing for the Unknown

Feb 24 2026

Most software systems aspire to robustness — surviving stress unchanged — but that's just a holding pattern in a world that won't stop moving. Drawing on Taleb's concept of antifragility and Barry O'Reilly's Residuality Theory, this piece argues that we can deliberately engineer systems that improve under stress by combining two ideas from complexity science: Kauffman's Random Boolean Networks (which show that real system topologies are far more manageable than their theoretical state spaces suggest) and Monte Carlo-style thought experiments (tracing hypothetical scenarios through your architecture to find structural brittleness before the world finds it for you). The multiplier effect is key — fixing a structural weakness uncovered by one imagined scenario tends to cover dozens you never thought of. AI coding assistants make this exploration dramatically faster, letting you prototype multiple architectural alternatives in hours instead of weeks, but they don't replace the judgment calls about which scenarios matter and what the results mean. The takeaway: thinking is still the cheapest, highest-leverage activity in software design, and now we have even less excuse not to do more of it.

AI Design Essay

 Layers, Levels, and the Cognitive Maze

Feb 22 2026

This essay explores the difference between meaningful architectural layers and mere levels of indirection in software design. I argue that splitting code into smaller pieces often creates navigational mazes rather than genuine separation of concerns, using the bloated business-logic layer and the repository pattern as key examples. AI coding assistants highlight the problem: they can follow complex call chains perfectly but still struggle when the underlying organization doesn't reflect coherent business concepts. The piece advocates for indirection that earns its existence through a distinct purpose, not just a smaller file size.

AI Design

 It's All About Interfaces

Feb 21 2026

The most important thing in software design isn't the logic or the algorithms — it's the interfaces. Coding assistants are making this truth visceral: when a machine consumes your API, every implicit assumption and ambiguous contract is exposed. This piece explores how hexagonal architecture, basic principles, and the DRY rule all take on new significance when AI agents stress-test your designs, and why getting interfaces right is becoming the most human skill in software engineering.

AI Design Essay