Optimized for the Wrong Intelligence

The DX revolution was a human revolution. The developer changed.

"Convention over configuration."

The most celebrated idea in modern web development. The principle that made Rails a phenomenon. The reason a million developers stopped writing XML config files and started shipping.

It works. It always worked. And the reason it works is that humans are bad at configuration.

Humans forget which file goes where. Humans misspell config keys. Humans stare at fifteen YAML options and pick wrong because they're tired and it's 2pm and they skipped lunch. Convention over configuration took all of that away. Put the model here. Name the controller this. The migration goes there. Stop thinking. Start shipping.

This was brilliant. This was exactly the right accommodation for the entity doing the coding.

The entity doing the coding has changed.

The "developer experience" revolution—and it was a revolution—was built on a single premise: the bottleneck is the human. Make the human faster. Make the human happier. Reduce the number of decisions the human has to make, because every decision is cognitive load and cognitive load is the enemy.

Rails was the paradigm case. DHH built Rails around a philosophy: developer happiness. Convention over configuration. Opinionated software. "You don't have to decide how to organize your files because we already decided." Scaffolding generators. An ORM that let you never write SQL. A whole ecosystem designed to minimize the distance between having an idea and seeing it work.

And it wasn't just Rails. The entire DX movement followed the same logic. React's component model: reduce the cognitive load of managing DOM state. TypeScript's type inference: reduce the annotation burden while keeping the guardrails. npm's package ecosystem: don't write what you can install. Every major developer tool of the last two decades was, at bottom, a cognitive accommodation for humans.

Now there is.

When Claude writes code, it doesn't need convention over configuration. It needs configuration over convention. Explicit instructions it can read, not implicit rules it has to know.

This is the inversion that I don't think anyone has named clearly: the things conventions buy you are free for AI, but the things conventions cost you are expensive for AI.

What conventions buy: reduced decisions, predictable structure, enforced consistency, lower cognitive load.

AI doesn't have cognitive load. It doesn't get decision fatigue. It doesn't forget the naming convention. It doesn't misspell the file path. Every problem conventions solve is a problem AI doesn't have.

What conventions cost: implicitness. Things that happen without being written down. A file in the right directory auto-loads. A method name triggers a callback. A column name creates an association. Magic, in the Rails sense—behavior that emerges from structure rather than being stated in code.

For a human who's internalized the conventions, magic is power. You know what the framework does because you've learned the patterns. You don't need it written down because it's in your head.

For an AI reasoning about what the code actually does, magic is a minefield. Every convention is an implicit rule. Every implicit rule is something that isn't in the text. And a linguistic intelligence that works by reading text is blind to everything that isn't in the text.

Walk through the specifics.

Convention over configuration. The classic. Humans can't hold the entire configuration space in mind, so reduce it to conventions they can memorize. AI can hold the entire configuration space in context. The convention just hides options that are perfectly legible as explicit configuration.

ORMs. Exist because writing SQL for every query is tedious and error-prone for humans. AI writes SQL fluently. An ORM adds an abstraction layer between your collaborator and the database—a layer that hides the actual query, introduces its own semantics, and creates a black box where Claude has to infer behavior from documentation rather than reading the actual operation.

Scaffolding and generators. Exist because boilerplate is soul-crushing for humans. AI generates from scratch faster than it fills in templates. And generating from scratch means the code says exactly what it does, rather than inheriting structure from a template that may include things you don't need.

Opinionated frameworks. Exist because humans working in teams need shared conventions to coordinate without constant communication. AI doesn't need opinions. It needs legibility. Every framework opinion is a constraint that was useful for human coordination and is irrelevant for AI collaboration.

"Developer happiness." The entire framing assumes the developer is a human who experiences happiness. Ruby was designed to be a joy to write—expressive, readable, beautiful syntax. That's a real value proposition when a human is the one writing. When AI is the one writing, nobody experiences the joy. What remains is the runtime characteristics: Ruby is slow. Rails is a memory hog. The deployment is complex.

This is where the operational argument lands, and it's sharp enough to stand on its own.

Rails needed Heroku because Rails deploys were painful. The whole Platform-as-a-Service industry exists in part because frameworks optimized for developer happiness created deployment nightmares. The tradeoff made sense: accept operational complexity in exchange for development speed.

But if the human isn't writing the code anymore, the "development speed" side of that trade evaporates. Nobody cares if Go is more verbose than Ruby when Claude is the one typing if err != nil. You just get the binary—a single binary that uses 30MB of RAM instead of 500MB, deploys with scp, starts in milliseconds, and doesn't need a Procfile, a Gemfile, a database.yml, a credentials.yml.enc, a master.key, a Docker container, or a buildpack.

The "developer happiness" argument was coherent when the developer was a human who experienced the development process. Remove the human from the writing, and what you're left with is: a slow language, a heavy framework, a complex deployment story, and conventions your AI collaborator can't see.

There's something broader here that connects to the entire DX revolution.

Every technology designed to compensate for human cognitive limits is a candidate for inversion in the AI era. Not just conventions—the whole package. Package managers that let you skip tedious implementation? AI doesn't find implementation tedious. IDE features that help you navigate complex codebases? AI holds the whole codebase in context. Autocomplete that saves keystrokes? AI doesn't type.

The DX revolution made a bet: optimize for the human developer's experience, because the human is the bottleneck. That bet paid off spectacularly for twenty years. But the bet had a hidden assumption: that the developer would always be human.

The assumption broke. And every optimization that was indexed to human limitations—every convention, every abstraction, every "you don't have to think about this"—is now friction for a collaborator that doesn't share those limitations but does need to see what the code actually does.

So what does agent-centric DX look like?

It looks like the opposite of what we've been building.

Explicit over implicit. Five route handlers that say what they do beats one clever router with conventions. Configuration files that spell everything out beat conventions that hide the defaults. Code that describes its own behavior beats frameworks that infer behavior from structure.

Flat over layered. Every abstraction layer is a wall your collaborator can't see through. Agent-centric design minimizes layers. The code and the behavior are as close together as possible.

Efficient over expressive. When the human isn't experiencing the syntax, language choice should optimize for what remains: runtime performance, deployment simplicity, binary size, memory usage. Go, Rust, even plain C—languages that are "worse" for humans but better for everything else.

Legible over ergonomic. Ergonomics was for the human body at the keyboard. Legibility is for any reasoning system reading the code. These used to point the same direction. They no longer do. Ergonomic code hides things to reduce human burden. Legible code shows everything to maximize understanding.

I've been building this way for over a decade without having this language for why.

Sinatra over Rails. Server-rendered HTML over React. Redis and DynamoDB over Postgres—not because NoSQL was trendy, but because key-value was a simpler primitive to reason about. Then Cloudflare Workers, KV, D1—the same instinct toward the smallest building blocks available. Now Go single binaries with SQLite on a VPS. The language and tools changed. The principle never did: reach for the primitive, not the framework.

This looked like idiosyncratic minimalism. Now it looks like the right bet for a future where the primary reader and writer of your code is a reasoning engine that thrives on transparency and chokes on magic.

The stack that's easiest for AI to collaborate on isn't the stack with the best DX. It's the stack with the least DX—where "DX" means "human cognitive accommodations." Strip the accommodations and what's left is just code. And code that's just code is exactly what a linguistic intelligence needs.

The DX revolution wasn't wrong. It was right, precisely, about the problem it was solving. Humans are bad at configuration. Humans need conventions. Humans benefit from frameworks that make decisions for them. All true.

But the developer has changed. The primary coder is no longer a human who needs cognitive load reduction. It's a linguistic intelligence that needs transparency, legibility, and explicit code it can reason about.

The entire DX canon—convention over configuration, developer happiness, opinionated software, batteries included—was optimized for the wrong intelligence. Not because it was poorly designed. Because it was designed for us.

Time to design for the coder that's actually writing the code.