I Don't Write Code Anymore -- I Build the Systems That Do

I started coding when I was 14. Back then it was raw C++, manually managing memory, writing every line by hand, debugging with print statements and prayer. You typed everything. You understood every instruction. The computer did exactly what you told it to, and when it didn’t, it was your fault.

I’m 39 now. I still write code most days. But what I actually do has fundamentally changed. And I think most people — even people in tech — haven’t fully grasped the shift.

The old model: human as the typist

For decades, the job of a programmer was to translate intent into instructions. You had an idea, you figured out the algorithm, you typed the implementation, you tested it, you shipped it. The bottleneck was always human throughput — how fast you could think and type.

Tools got better. IDEs, linters, autocomplete, frameworks. But the core loop was the same: human writes code, computer executes code.

We optimized this loop relentlessly. Better languages. Better editors. Better abstractions. But it was always a human typing instructions into a machine.

The shift: human as the system designer

Something changed in the last couple of years, and it wasn’t just “AI helps you code faster.” That’s the surface-level take. The real shift is deeper.

The job isn’t typing anymore. The job is designing the system within which code gets written.

Think about what happens now when you’re building something with AI assistance:

1. You describe the intent. Not the implementation — the intent. “I need a service that processes incoming webhooks, validates the payload against this schema, writes to this queue, and retries on failure.”
2. The system generates the implementation. The code, the tests, the error handling, the logging.
3. You evaluate, adjust, and constrain. Does this actually do what I want? Is it secure? Does it fit the existing architecture?

Steps 1 and 3 are the real work now. Step 2 is what the machine does. And the skill that matters most isn’t typing speed or memorizing APIs — it’s systems thinking.

What this means in practice

At Meshi, I spend most of my time building infrastructure, not writing application code. The infrastructure defines the boundaries within which agents operate — what they can do, what they can’t, how they communicate, what happens when they fail.

The agents write the code. I build the world they write it in.

This is a fundamentally different skill than traditional programming. You’re not implementing a feature. You’re defining a space in which features emerge. You’re setting constraints, guardrails, and feedback loops. You’re designing the rules of the game, not playing it.

The uncomfortable truth

Here’s what nobody wants to say out loud: most of what we spent decades learning to do manually can now be done by a machine in seconds. Writing CRUD endpoints. Implementing standard algorithms. Building boilerplate infrastructure. Generating test cases. Writing documentation.

The stuff that can’t be automated yet — and won’t be for a while — is the deep systems work. Understanding why a particular architecture is right for this specific problem. Knowing which trade-offs matter and which don’t. Designing for failure modes you’ve seen before and can anticipate. Making judgment calls that require experience, not just data.

This is why I’m not worried about AI replacing engineers. I’m worried about engineers who don’t make the shift. If your value is “I can write code fast,” that’s a losing game. If your value is “I can design systems that solve real problems,” you’re more valuable than ever.

The new craft

There’s a new kind of craftsmanship emerging. It’s not about writing elegant code — it’s about designing elegant systems. Systems where the right behavior is the easy behavior. Systems where AI agents can be productive without being dangerous. Systems that are robust not because every line was carefully written, but because the architecture itself prevents failure.

This is harder than traditional programming in some ways. You’re working at a higher level of abstraction. You need to think about emergent behavior, not just individual instructions. You need to anticipate how a system will behave when you’re not controlling every line of code.

But it’s also more creative. More impactful. And honestly, more interesting.

The full circle

I started by building game engines — systems where the rules of the world were explicitly defined, and interesting behavior emerged from those rules. Now I build agent runtimes — systems where the rules of execution are explicitly defined, and useful behavior emerges from those rules.

The more things change, the more they stay the same. The craft was never really about the typing. It was always about the systems. We just spent a few decades pretending otherwise because the machines weren’t ready yet.

Now they are. And the people who thrive will be the ones who embrace the shift — not as a threat to their skills, but as the thing they were actually training for all along.