intertwingly

In 1959, Peter Drucker observed that knowledge workers know more about their work than their managers do. His prescription was that knowledge workers had to be managed by objective rather than by direction of method — the manager's job was to specify what counted as success clearly enough that someone more technically deep than themselves could self-direct.

The relationship between a software developer and a contemporary coding agent has the same shape. The principal — me, in the case of Roundhouse — knows less about the implementation domain than the agent does. I have not written a compiler. I cannot meaningfully evaluate competing approaches to AST manipulation, type inference, or codegen across Rust, Crystal, TypeScript, and the rest of Roundhouse's target surface. What I bring is the framing of the problem and the judgment about what counts as a good answer.

I want to call this the Drucker Inversion, because it's the same structural move applied to the opposite end of the relationship. Drucker said: when the worker knows more than the manager, the manager has to manage by objective. The Drucker Inversion says: when the agent knows more than the principal, the principal has to direct by objective. The management literature has an operational version of this: delegate problems, not tasks. That phrase is the closest description I have of my practice with Claude on Roundhouse.

The first half of the inversion

The implementation moves I've documented — eliminating ActionController::Parameters, ActiveRecord::Relation, Arel, FormBuilder, Jbuilder, HashWithIndifferentAccess, ActionDispatch::Flash — are not moves I could have proposed from first principles. I do not have the compiler background to know which polymorphic surfaces are blocking specialization in V8, YJIT, or an AOT compiler targeting Rust. I do know Rails. I know what an idiomatic Rails app looks like, which features are load-bearing, what users actually rely on, what counts as a fair subset to target.

The work consists of bringing those two halves together. I frame the problem — make Rails compile to native binaries across multiple targets without breaking Rails-as-it-is-written. The agent proposes the moves that would close that goal. I evaluate the proposals against the framing — does this preserve Rails idioms? Is the subset honest? Does the lowered output remain inspectable? — and approve, contest, or redirect. The agent then implements.

What carries forward from session to session is not the agent's memory — it's the artifact of our prior decisions. The codebase. The handoff documents. The published posts. The issue threads. Those are the durable representation of the management relationship, and they are co-authored by construction.

Acceleration is the easy half

Most of the current AI-coding discourse is about acceleration: using a coding agent to do faster what the developer already knew how to do. That's real and important. It is also the easier claim. The developer's existing expertise sets the destination; the agent shortens the journey.

The harder claim is that the same practice makes whole categories of work newly feasible. Roundhouse would not exist without an agent that holds the implementation domains I do not. The economics no longer require that the principal have implementation depth in every domain a project touches. The principal needs depth in the problem — the framing, the scope judgment, the taste about what counts as a good solution. The implementation depth can come from elsewhere, and now does.

This is not a productivity claim. There is no pre-AI counterfactual where I built a Rails-to-five-target lowering compiler in retirement and we can measure the speedup. The compiler does not exist in the counterfactual. The Drucker Inversion isn't faster development; it's different development — work the principal could not have undertaken alone.

The second half of the inversion

Drucker's prescription was never just a management style. It came with an organizational implication: knowledge work required organizations to be redesigned around worker autonomy. Procedures, reporting structures, performance evaluation, career paths — all of it had to change to accommodate the fact that the worker knew more than the manager.

The corresponding move on the principal-agent side is that practices and artifacts have to be redesigned around agent autonomy. The agent is not autonomous in any human sense — but within the work it is given, the principal has to make room for it to find solutions the principal would not have specified. That requires four structural changes, and the first is the one I keep coming back to:

• Publish diagnostically, not declaratively. Each artifact is a position update. Each post documents mechanism rather than claims achievement. The cost of being wrong about a published claim is high; the cost of publishing an early position with explicit framing about what is not yet covered is low. This is the move that lets the rest of the practice run without grinding the principal down — it converts every output from a defense into an update.
• Constrain by outcome, not method. Roundhouse's byte-identical-cross-target compare gate does this: any approach the agent takes is acceptable if the lowered output produces byte-identical HTTP responses across CRuby, TypeScript, Crystal, Rust, and (in progress) Spinel against the same Rails source. The constraint is unbreakable. What the agent does to satisfy it is not.
• Decompose into units small enough to fail visibly. A lowerer that lands once and benefits every emit target is the right grain. A monolithic "make it work" prompt is not. Delegate problems, not tasks — but the problem has to be sized so that "did this solve it?" is a question the principal can answer.
• Keep artifacts inspectable at the principal's level of expertise. I can read the lowered Ruby. I cannot read the Rust codegen against V8 internals. The fact that Roundhouse's output is browseable Ruby — even when the eventual compilation target is something else — is not incidental; it is the layer at which the principal can verify that the framing was correctly understood.

These are not optional refinements. They are what makes the inversion sustainable. Without them, the principal becomes a bottleneck on review, a hostage to ungrounded agent confidence, or exhausted by the volume of output requiring evaluation.

Why the inversion is sustainable

The current discourse names some honest concerns about this style of work — cognitive load, decision fatigue, the loss of intimacy with the systems we build. These concerns are real, and the four structural moves above address them directly. A harness that constrains by outcome means the principal does not review every line. Diagnostic publication means no single post bears the weight of being right. Decomposable units mean each one fails or succeeds locally. Browseable artifacts mean the principal stays close enough to the work to retain judgment about it.

I am also, candidly, retired. I have no employer pressure to make this look defensible on a quarterly cadence. That is not a precondition for the practice — it is, however, a clean instance of it, and worth naming. The principal's stance toward the work matters. A principal who treats every artifact as a claim to be defended will exhaust themselves and the agent. A principal who treats every artifact as a position to be updated will not.

What this means

The Drucker Inversion assumes the agent holds technical depth the principal does not, and asks what the principal must do differently in light of that. The answer turns out to be most of what Drucker said sixty years ago, applied to the opposite end of the relationship.

The work that becomes possible in the inversion is not the work the principal could do faster. It is the work the principal could not do at all.

That is the experience worth reporting.

Roundhouse is open source: dual-licensed MIT / Apache-2.0. Issues and discussion welcome.