Writing code is free now
Writing code is no longer an expensive part of building software. Everything around it still is. And most of us are still organized as if nothing changed.
Someone can correctly say: “Writing code isn’t the real bottleneck. Reviews, testing, coordination, shared understanding are”.
That’s right, but code was expensive enough to mask all of that. Now that the mask is off, the real bottlenecks are fully exposed.
The filter is gone
In this video, Theo draws a simple diagram that captures this perfectly.
You start with 500 user problems. Maybe 100 get clearly described. You identify solutions for 50. You scope and assign 15. Engineers actually write code for 5. And since code was expensive to produce, almost everything that reached engineering eventually shipped. The cost of writing code acted as a natural filter. If something survived the funnel long enough to reach a developer’s hands, it was worth finishing.
That filter no longer exists.
Remember when non-technical colleagues asked “How long will it take to build this? / How difficult can it be to add this?” Those questions existed because execution was a real constraint. People needed to know if their idea was worth the engineering cost. Now the honest answer to most of those questions is: “Not long. Not difficult.”
The constraint isn’t whether we can build something. It’s whether we should.
The funnel doesn’t narrow at “write code” anymore. It passes straight through. And everything downstream: review, testing, QA, release… still takes the same effort it always did (or more since we have more code). The bottleneck moved, but most organizations haven’t.
The real shift: building infrastructure for agents
There’s a common framing going around that engineering is shifting from writing code to reviewing code. That’s accurate on the surface, but it misses where this is actually heading.
The shift isn’t from writing to reviewing. It’s from writing code to building systems that agents can operate in.
That feature I shipped last week didn’t work because the AI was smart. It worked because the codebase was ready. Good architectures, reusable components, clear separation of concerns… that’s what made the agent effective. If the codebase had been a mess, the agent would have produced a mess.
This is where the role is going. Our job is increasingly to build and maintain the infrastructure that makes agents productive:
- Reusable components with clear interfaces and composability (agents are great at assembling existing pieces, bad at inventing new abstractions).
- Sandbox environments (agents need a place to run, test, and fail without touching production).
- Comprehensive test suites (not for you to verify the agent’s work manually, but for the agent itself to validate its output before you see it).
- …The list will grow. We’re still figuring out what agents actually need from us.
The craft didn’t disappear. It moved up a level. We’re not writing the code anymore. We’re building the systems that write it. And the quality of those systems directly determines the quality of what agents produce.
At Golee, where I work with a small team, the goal we must aim for is to make everyone on the team capable of owning the full cycle, from understanding a user problem to shipping the solution. Not just writing code or pressing deploy, but having the judgment to decide what to build and why. The execution layer, the how, will be fully automated soon.
We don’t need more hands. We need more brains.
Close the gap with users
Theo says something bold in the video:
“If the agent knows more about your customers than you do, you don’t have a job anymore.”
He’s right. You can have the cleanest architecture, the fastest CI pipeline, the most capable AI agent, and still build the wrong thing. Systems without user understanding are just cool machines solving the wrong problems.
Another reason that feature shipped smoothly was because I knew enough about how our users interact with the product to immediately recognize the value of what my colleague described. Someone saw a friction point, communicated it, and it got resolved almost instantly. That loop is powerful. But it requires proximity to the user.
If you’re an engineer reading this: force yourself to close that gap. Join the support channels. Read the feedback. Sit with your sales team, your customer support, your designers. Not as a nice-to-have, but as a core part of your job.
The developers who understand their users deeply will always build better things.