From Tiny to Deletion Safety

In 2014, I gave a talk called Tiny. The argument was simple: keep things small enough that a human can understand them.

In 2026, that idea has evolved.

Small is no longer primarily about cognitive load. Small is about deletion safety.

When generation is abundant, the scarce resource is no longer typing. It is verification. It is traceability. It is knowing what must remain true when implementations change.

Regeneration only works at the right grain.

From Cognitive Load to Deletion Safety

"Small" used to mean easier to reason about, faster to ship, less likely to explode. Now "small" means safe to delete, cheap to regenerate, and verifiable at a clean boundary.

If deleting a component feels terrifying, the problem isn't courage. It's architecture. If you can't kill it, you don't own it.

It owns you.

This builds directly on earlier arguments in this series. The Deletion Test asked whether you could delete your entire codebase and regenerate it from specification. That was a diagnostic for the system as a whole. The regenerative grain applies the same logic at a finer resolution: individual components, services, and modules. Where the Deletion Test reveals whether your evaluations are strong enough to survive regeneration, the grain question reveals whether your boundaries are drawn in the right place.

Tinyness isn't aesthetic minimalism. It is structural. It determines whether regeneration is safe or reckless.

Finding the Grain

Before you settle on a component boundary, imagine deleting it and recreating it from its specification. Not refactoring it. Not patching it. Deleting it.

If that thought makes you sweat, the grain is wrong.

This diagnostic isn't a law of physics. It's a heuristic. But it's a reliable one. And unlike a one-time design exercise, it's something you run repeatedly when requirements shift, when a service accretes new responsibilities, when a team changes. Boundaries aren't set at the whiteboard. They're discovered iteratively, the way you discover the natural grain of wood by working with it. Force a cut against the grain and it splinters. Find the grain and the material cooperates.

Here's how to test it.

Comprehension. Can a human (or an LLM) understand the invariants, edge cases, and data transformations of this unit in roughly ten minutes? If understanding requires a historical tour of the repository or a walkthrough of hidden behaviors, you're not holding a component. You're holding accumulated sediment. Layers deposited over time that no one can safely excavate.

Isolation. Can you verify this unit's correctness at its boundary without booting half the system? Not necessarily with boundary tests alone (property-based tests and simulations may still matter) but the core behavior should be mechanically assertable without orchestrating the world around it. If your "unit" requires shared infrastructure just to run, you haven't found a seam.

Mutation ownership. Does this unit have exclusive logical write authority over its data? Physical replication doesn't matter. Read models don't matter. What matters is whether more than one place in the system can change the same logical state. Shared writes create hidden coupling. You cannot safely regenerate what you do not exclusively control.

Contracts. Does the unit communicate through a versioned, schema-enforced interface — typed APIs, explicit behavioral contracts? If so, you can replace it without destabilizing neighbors. If it relies on shared libraries or informal knowledge of how the other side works, regeneration becomes a coordination event instead of a replacement. This is the difference between pruning a branch and performing surgery on a root system.

Your gut. Rate your emotional response to deleting this component. If it feels trivial, the grain may be too fine or fragmented to the point of meaninglessness. If it feels like mild inconvenience, you are in the right zone. If it feels like existential dread, you've discovered a taproot.

That last one sounds soft. It isn't. Deletion terror is a technical signal. It usually means hidden invariants, implicit contracts, or shared mutation, which are precisely the conditions that make regeneration unsafe.

A Concrete Example

Consider a feature-flag evaluation service. Its job is simple: accept a user context and a flag key, return a deterministic decision, and log the evaluation.

The correct grain is not the entire user-profile subsystem or the entire logging pipeline. It is the evaluation engine itself.

If the rules are declarative, the invariants (determinism, no hidden side effects) are verified at the boundary, and the service has exclusive authority over flag definitions, then you can delete the implementation, regenerate it from its specification, run the evaluations, and ship.

If, instead, it reaches directly into user databases, embeds logging side effects across the codebase, or allows multiple services to mutate flag rules, deletion becomes terrifying.

The grain was wrong.

Finding the Sweet Spot

Not everything should be tiny.

When the grain is too coarse, the verification surface explodes. Regeneration becomes opaque. Fear accumulates like deadwood. When the grain is too fine, you drown in orchestration and coordination overhead. Meaning fragments across too many seams. Decision fatigue replaces clarity.

The right grain is large enough to contain coherent invariants and small enough to isolate mutation. A unit that fits in working memory, owns its mutations, exposes a versioned contract, and can be verified at its boundary without booting the entire system.

The goal is not maximal fragmentation. It is disposability.

What this doesn't yet address is how grain decisions compose. Five well-grained components don't automatically produce a well-grained system. System-level regeneration requires something beyond individual component boundaries — orchestration contracts, integration specifications, the connective tissue between seams. That's a question this series will return to.

Where This Doesn't Apply Cleanly

There are domains where regeneration must be handled with extreme care: cryptographic primitives, protocol parsers, performance-critical hot paths, regulated or safety-critical components.

In those contexts, deletion safety coexists with formal verification, audits, and traceability requirements. The grain question still applies — you still want to know whether boundaries are drawn well — but the cost of regeneration is higher and must be deliberate.

Regeneration presupposes deterministic specifications and boundary evaluations. Without them, you are not regenerating. You are improvising.

What This Changes on Monday

This is not about adopting a new framework. It is about shifting from writing code that lasts to designing systems whose components can be replaced.

That shift forces you to care about deterministic specifications, boundary evaluations, mutation ownership, and versioned contracts. The same things The Gradient of Trust argues are more durable than prompts, and that Immutable Infrastructure, Immutable Code argues should never be patched in place.

In a world where generation is abundant, the most expensive thing you can own is code you are afraid to change.

Tinyness is no longer about elegance. It is about safe forgetting.