Allocate Architects by Irreversibility, Not Difficulty

In the early 1980s, the engineers standardizing the protocol that would become the internet made a decision that seemed entirely reasonable at the time. Addresses would be 32 bits wide: room for about 4.3 billion of them. In a world with a few hundred networked machines, 4.3 billion was a number so large it rounded to infinity, and the choice took almost no deliberation. It was the obvious, easy call. It is now one of the most expensive commitments in the history of computing. We ran out of addresses, and the fix (IPv6, standardized in 1998 with a vastly larger space) has been rolling out for more than a quarter century and is still not finished. Google first measured native IPv6 reaching about half of its traffic only in early 2026, because you cannot quietly swap the addressing scheme of a network the entire planet runs on.

The point is not that the engineers were wrong; given what they knew, 32 bits was defensible. The point is that the decision was trivial to make and nearly impossible to unmake, and those are two completely different properties that we habitually confuse. The address width was not a hard problem; a junior engineer could have picked the number. It was an irreversible one, and its difficulty told you nothing about the attention it deserved. In an AI-heavy organization, seniority should track irreversibility, not difficulty, because the hard problems are now cheap to retry and the cheap-looking decisions are the ones you can’t take back.

What follows: why difficulty and irreversibility are orthogonal, why AI collapses the cost of the hard-but-reversible while leaving the easy-but-irreversible exactly as expensive as it always was, and how to re-route senior attention onto the quadrant that actually compounds.

The strongest version of “put your best people on the hardest problems”

The conventional rule is not stupid; it earned its place. Hard problems are where projects die: the gnarly concurrency bug, the algorithm nobody can get right, the integration that defeats three teams. Putting your most capable people on the hardest problems is how you keep the whole thing from foundering on the one part that resists. For most of software history this was correct, because difficulty and cost were tightly coupled: a hard problem was expensive to attempt, expensive to get wrong, and expensive to redo, so difficulty was a decent proxy for “where senior judgment pays off.” Concede all of that. As a heuristic in a pre-AI shop, “hardest problems, best people” was close to right.

The coupling is what breaks. When a design→test loop can attempt a hard-but-closable problem cheaply, generate ten approaches, and grind the wrong ones into the ground for tokens, difficulty stops being expensive. You can try the hard thing, throw it away, and try again by dinnertime. The moment the hard-but-reversible problem became cheap to retry, difficulty stopped being a reason to spend your scarcest attention, and the only property that still reliably predicts cost is whether the decision comes back.

The category error

Lay the two axes on a grid and the mis-allocation becomes obvious. Difficulty on one axis, irreversibility on the other, and four quadrants.

Hard and irreversible: yes, senior attention, a consistency model you’ll build a decade of code on top of, a security architecture, a data-partitioning scheme. Hard and reversible: delegate it to the loop. A tricky algorithm behind a stable interface, a complex-but-swappable component; if it’s wrong, you regenerate it, and the difficulty no longer justifies your best people’s hours. Easy and reversible: pure tokens, the entire disposable middle of the codebase; hand it over and don’t look. And then the quadrant everyone neglects: easy and irreversible. The field you typed as a 32-bit integer. The table two services both quietly took ownership of. The event whose ordering you never guaranteed because it “obviously” arrived in order. The public API shape you shipped in a hurry that ten thousand customers now depend on. None of these is hard. Every one of them is a commitment you will pay to unwind for years, if you can unwind it at all.

Code is disposable and regenerable; the next model rewrites it better next quarter. What compounds silently are the decisions that outlive the code: data models, ordering and causality and consistency guarantees, ownership boundaries, the contracts you’ve published to other people. Those persist across every rewrite, and they get harder to change precisely because more and more depends on them; the compounding runs the wrong way. Yet most organizations route senior attention by difficulty, or by dollar size, or by whichever decision has the most executives watching. The easy-but-irreversible decisions get made quickly, by whoever is nearest, precisely because they don’t look hard, which is how the most expensive commitments in a system get made with the least deliberation, exactly as the internet’s address width was.

What this means in practice

This repository’s own engineering history is an unusually clean demonstration, because it contains five full rewrites: a LibreChat fork, a Python version, a Rails version, a Go backend, a Flutter client. Five times, essentially all the code was thrown away. That was affordable precisely because code is disposable: the implementation was hard-but-reversible, and AI-assisted development made trying, discarding, and retrying cheap enough to do repeatedly. What did not get thrown away five times were the data models, the boundaries between services, and the contracts the product exposed. Those were the commitments that had to be right, because they were the ones that couldn’t be casually undone, and they are exactly where the human judgment concentrated.

The reason this needs saying is that the loop offers no resistance at the boundary. As that engineering series put it bluntly, DevFlow “will faithfully implement a bad architecture as efficiently as a good one.” The machine does not flinch when you point it at an irreversible mistake; it builds the mistake at full speed and with excellent test coverage, and hands it back to you green. The loop has no sense of what will be expensive to unwind, because reversibility is a property of your business and your dependents, not of the code. So the human’s job at the boundary is not to work harder than the machine. It is to be the only entity in the system that even knows the boundary is there.

The practical instrument is a single question, asked before you spend any senior attention: if this is wrong, what does it cost to undo? Cheap to undo, however hard, delegate to the loop and move on. Expensive or impossible to undo, however easy it looks, stop and put your most experienced person on it, even if, especially if, it looks like a five-minute decision.

What this requires architecturally

Allocating by irreversibility only works if hard-but-reversible really is cheap to redo, and that is an infrastructure property you have to earn. This is the underrated value of a harness like DevFlow: work is structured into discrete units, each landing as an atomic, individually reversible commit, so a wrong-but-reversible decision can be bisected to, reverted, and regenerated without collateral damage. The atomic-commit discipline is what makes “try it, and if it’s wrong throw it away” a real option rather than a brave-sounding lie. And that, in turn, is what frees senior attention to sit where it belongs: on the boundaries that no revert will save you from. Cheap reversibility for the disposable work is precisely what buys you the room to guard the irreversible work. The tooling that makes the code disposable is the tooling that lets you finally spend your architects on the things that aren’t.

What to do

Re-map your org chart against the right axis. Take your most experienced people off the merely hard problems that a governed loop can now grind (they are expensive babysitters there) and move them onto the easy-but-irreversible decisions that are currently being made in five minutes by whoever’s closest: the schema, the ID scheme, the ownership boundary, the public contract, the ordering guarantee, the data you’re about to share and can’t recall. Make “what does it cost to undo?” a required question in design review, and treat a low answer as permission to delegate and a high answer as a demand for senior time, independent of how hard the thing looks.

The instinct to put your best people on the hardest problems was right for a world where hard meant expensive. That world is closing. Code is disposable now; the schema, the boundary, the promise still cost what they always did. Spend your architects where the decisions don’t come back.