Ikea Code - embracing utility over craft in the age of agents
January 2026
Pulling tangled requirements from a backlog and shipping them to customers used to take weeks. Now it can take hours. The tools changed; the question is whether our approach to building software has caught up.
This is something I have been thinking about a lot lately, and I want to commit some of it to writing.
Fast cycles demand small domains
To enable fast product cycles — idea to customer — without completely sacrificing security or maintainability, it is more important than ever to follow small domains, distributed systems, and separation of cross-cutting concerns.
Small contexts benefit both developers and agents. They limit the blast radius of any given change, which adds confidence in the system and lowers the bar a PR has to clear before it rolls out to production. More changes, faster, everything easy to revert. The same good old practices that enable a well-performing team to do trunk-based development.
A good CI/CD pipeline is paramount here. Automated gates are what let you move fast without fear.
Is the craft of code compromised?
In short: I believe it is. And I am beginning to think that is acceptable.
You can have artisanal furniture — love and a lot of value in it. But you also have utility furniture that is highly scalable. Think IKEA.
It is time to embrace Ikea code. 🪑
What does Ikea code look like?
It has strong coverage of what it needs to do. Key BDD tests convert business requirements into prompts, and prompts into repeatable snapshots of what is supposed to happen. The test suite is the spec. If the tests pass, the feature is done.
It has a single purpose. Its domain is small, making it manageable and optimized for what it does. Failure is also limited — if one product item does not pan out, no big deal. There are others.
It is highly composable. It fits into a larger system. The system itself provides cross-cutting concerns. Do not worry about authentication. Do not worry about scalability. Those are resolved as first-class citizens by the platform, not by every individual service.
Do people care how the implementation looks?
Yes, but actually no.
There are cheap tables that do their job effectively and are literally built out of cardboard. And that is okay. In fact, that is desirable — even if it is painful to admit.
How does this affect PR reviews?
I do not care how the implementation looks. I know security is checked at the edges. I know scalability is resolved by the architecture itself.
So by the time you are in the weeds, it simply does not matter whether you — or the autogenerated code — is using a for loop or a functional stream, declarative or imperative. What matters is:
- Does it do what the business requirements say?
- Does it fit cleanly into the larger system?
- Can it be reverted or replaced without drama?
Where does developer value lie?
This is a spicy take and I have not fully committed to it yet. But viewing agents as the big enablers, maybe it is not as scary as it seems. The developers’ value shifts from writing implementation to:
- Defining clear, small domains
- Writing the BDD tests that encode business intent
- Designing the system that provides security and scalability as a first-class concern
- Knowing when to throw a service away and start fresh
Ikea code is not a regression. It might be the natural evolution of how software gets built at scale.