Idea as a Code

Three weeks ago Antirez - the creator of Redis - published a post titled “Control the ideas, not the code”. It got loud, fast. His argument, simplified: if you own the ideas behind your software, staring at the code line by line is often a waste of time. Reviewing 5,000 LLM-generated lines a day isn’t engineering. It’s a bottleneck dressed up as craftsmanship.

He’s right. And it opens a question the industry has been avoiding.

What was code for, exactly?

Clean code. Design patterns. Readable naming. The whole apparatus of software craftsmanship was built for one reason: so humans could understand what the machine was doing. Machines never needed high-level languages. We invented them for ourselves - as a translation layer between how we think and how silicon executes.

Now the translation layer is being handled by something else.

When agents write most of the code, “readable to humans” stops being the primary constraint. The code still has to be correct, secure, performant - but those are properties you validate, not properties you read into being. The craftsmanship doesn’t disappear. It moves.

Where the weight goes

If you’re not spending your day reading code, what are you doing?

You’re describing the idea precisely enough that an agent can build it. You’re defining architectural decisions, user stories, acceptance criteria, the behavior you actually want. You’re picking the tools that will validate the output - the tests, the linters, the security scans, the performance benchmarks. You’re designing the workflows that catch what the model gets wrong.

This is exactly the loop I wrote about in The Day Your AI Forgets How to Think:

What reduces risk isn’t a better model. It’s better tooling, clearer processes, and an environment built to absorb the imperfections rather than pretend they don’t exist.

Same principle, different scale. There it was about protecting yourself from a model getting worse. Here it’s about building software that’s correct in the first place.

The center of gravity in software engineering is moving. From writing code to describing ideas - and building the environment that turns those ideas into working systems.

The idea, made precise

I’ve been building forge-md around this premise for a few months now. And with the team we’ve been testing a lighter, more portable version of the same thinking - sdd-starter, a scaffold for spec-driven development. One Markdown file describing the intent, a set of workflows that turn it into a specification, and a build process that traces every line back to a decision you already made.

The “idea” isn’t a paragraph. It’s a compact but complete artifact: what you’re building, for whom, under what constraints, with which architectural choices, which quality tools, which definition of done. Done well, it produces code that meets the bar we used to call clean code - not because a human wrote it beautifully, but because the process couldn’t produce anything else.

That’s what I mean by “Idea as a code”. Not “prompt something and hope”. The idea, made precise, is the source. The code is the compilation artifact.

Where this could go

Recently Elon Musk pushed the idea to its logical extreme, replying to a similar thread:

Source code is on the verge of becoming like assembly, and the next step is skipping source code entirely - generating efficient binaries directly with AI.

Musk has a habit of naming directions the industry ends up walking in years later. Worth taking seriously when he calls the next one.

Grady Booch the man who literally co-created UML - pushed back in the same thread:

A language with sufficient expressiveness, precision, and repeatability to build executable artifacts is, by definition, a programming language.

He’s not wrong either.

The honest answer probably lives between them. Whether the intermediate representation stays as human-readable code, collapses into something more compact, or eventually disappears into binaries - the direction is the same. The source of truth moves up the stack, from characters in a file to intent in a specification. And the more the final artifact becomes unreadable to humans, the more the idea has to be precise, because reading the output is no longer a fallback. That’s not an argument against this direction. It’s an argument for taking the specification seriously now, before the safety net of readable code disappears.

This doesn’t make software easier

I want to be careful here. The narrative that AI makes building software easy is wrong, and it’s going to hurt the people who believe it.

Doing this well demands more, not less. You need architecture. You need to understand security, performance, testing, deployment. You need judgment about which tools to compose and which processes to enforce. Generalists - people who can connect the dots across the stack - gain leverage in this model. Narrow specialists whose job was writing a specific kind of code lose some of it.

The skill shifts from implementation to specification and orchestration. That’s harder in some ways, easier in others. It is not less.

Why this matters beyond software

A friend once told me about a recruiter at a FAANG company who blew him away with the depth of their knowledge. Then he found out what that person actually spent their days building: cute little ears and filters you can slap onto a video in a social app.

I don’t mean this as criticism of the person or the product. The point is what the industry has been doing with its best minds. Enormous energy - years of study, real intellectual firepower - has gone into problems that, in the grand scheme, don’t matter very much.

The human brain works best at high levels of abstraction. Natural language is our primary tool for reasoning. If most of the mechanical translation from intent to executable code can be handled by agents, the interesting question isn’t whether we lose the craft. It’s what we do with the energy we get back.

There are more urgent problems in the world than the next filter. If describing ideas replaces writing code as the core skill, we might finally get to some of them.

That’s the part I find genuinely exciting.