Our job was never to write code. It was to solve people's problems.

The line I keep coming back to

"Our job was never to write code. It was to solve people's problems."

Richard Campbell said that near the end of a keynote this year. He's spent more than twenty years making podcasts for software developers, so he's watched a lot of these waves come and go. I haven't been able to put the line down since.

He said it right after the story of protein folding — the one where, for sixty years, biologists worked out how a protein folds one at a time. The first one took a decade and won a Nobel Prize. After sixty years of that, we had about a hundred and fifty of them. The number of possible folds is something like ten to the thirty-fifth. Nobody was ever going to code their way through that.

So a team at DeepMind stopped trying to write the program. They trained a model instead. By 2022 it had worked out two hundred million protein folds and published them all, for free.

His point wasn't really about proteins. It was that the code was never the job. The job was the problem underneath it.

I've spent the last four months building something, and that line is a good reminder of what the thing is actually for.

Someone twenty years ahead

The same point showed up again a few weeks later, from a very different corner. I watched a short video from Phil Smy. He's spent about twenty years building software businesses on his own — one of them, Zonmaster, he grew largely on his own past ten thousand users and into the millions in revenue. So when he talks about moats, he's talking about ones he actually built.

He took an old game called Xyphus — one he first played on a Mac 512, back in 1985. He uploaded just the binary, no source code anywhere, and asked Claude to decompile it. It did. Then he asked it to rewrite the whole game in Python. It did that too.

"Compiled code was never really protection," he said. "It was just friction." The thing that kept your code private was never a wall — it was a cost. Reading a compiled binary used to be slow and expensive, so mostly nobody bothered. AI made it cheap. "Stop assuming your binary is your moat," he says.

I wish I could say that hit me like news. But I'd written the same thing a few months earlier — a piece about what happens when anyone can clone your product in a week, and another about how the machine can appraise your code just by rebuilding it. It's a strange feeling, watching someone twenty years ahead of you land on the thing you just worked out for yourself. Reassuring, mostly. It means I wasn't making it up.

The part that let me in

Campbell's bigger point was about where this is going. A couple of years ago these tools mostly helped developers type faster — a smarter autocomplete. Now you can hand an agent a whole task, let it work, and argue with it about the result before you accept anything. That last step is the one that let someone like me in.

Because here's the thing: I have never written code in my life. For me, code isn't something I type. It's a question, a concept, an idea I hand to an agent and ask it to build. One model writes it, another tries to tear it apart, and I read what comes out. It still goes wrong plenty, and catching that is the job now. But I can build things I never could have built on my own. I work faster than I ever have. And I'm independent — I don't need a team, or a budget, or anyone's permission to make the thing I want. For me, that's a dream.

Campbell pushes it past the code, too. If these tools are good at pulling data out of wherever it lives, he asks, does the old shape of software still make sense? Do we still need the big rigid systems — the ERP, the CRM — or were those just layers we built because getting at the data used to be hard? He doesn't know. I don't either. But the question is the right one: the level we work at keeps climbing, and writing the code by hand is slowly becoming the part you don't have to do.

Building, or hiding?

Which leaves an awkward question. If the code isn't the moat, and it was never really the job, then what have I been doing for four months?

The trouble is, the easier it gets to build, the more room there is to hide inside the building.

Phil has a line for this too, and it's the one that stung. "Thoroughness is fear with a to-do list." You add the login because every product has a login. You build the dashboard because the last tool you admired had one. You wire up notifications for the user who might, someday, want them. It feels like progress. It feels responsible. And every feature is another week you don't have to show the thing to anyone and hear what they actually think.

He knows the shape of it because he's lived it. Twenty years of building, a real hit behind him, and he'll still tell you about the month he spent on a feature that, to this day, has zero visits in his analytics. It's still sitting there. He works from rural Japan, has no patience for hustle culture or looking busy — and he still fell into it.

So I made myself ask the uncomfortable version of the question. Four months in. Am I building, or am I hiding?

My honest answer

Here's my honest answer. I don't think I am — and it took me a minute to work out why.

I'm not building this to sell. I have no clue whether it's worth anything to anyone else — genuinely, none. What I know is that it's worth something to one person: me. It's a value-investing tool, and I already use it the way I mean to — I feed it real companies I might put money into, and I weigh what it tells me.

I know how that sounds. A market of one is exactly what hiding looks like from the outside: you build for yourself, so no one can ever tell you no. So I hold it to a test. When I add something, is it because I hit a wall using the thing — or because I'm putting off the moment it meets the real world? Recently I wrote about three days I spent tearing the engine apart because a report it gave me on a real company took four hours to run and I still couldn't trust what it told me. I didn't rebuild it to look busy. I rebuilt it because I was trying to use it, and it wasn't good enough yet. That's the difference: hiding adds the login nobody asked for; using it fixes what's in your way.

It's not done — far from it. It's being calibrated, and calibration is slow, patient work: real company after real company, tune, repeat. It'll earn its keep when the cycle turns and the decisions are real. But the use is real now, and that's what keeps me honest. I'm the market, and I've already bought.

And the other half of the answer: I enjoy this. Every bit of it. Four months in, nowhere near done, and I still look forward to opening it up. Maybe that sounds small next to people building companies. It doesn't feel small to me. It's the first time the tools have been good enough that I can take a question of my own and follow it all the way to an answer, by myself.

The work looks different

Campbell ended his talk somewhere near here. Every time the ground shifts like this, he said, we go back to the things that matter most. It'll pass, and we'll get back to work. The work will look different. That's okay. We'll still make a difference.

The work does look different for me. I don't type it, I ask for it. The moat I was supposed to be guarding turns out to be readable by anyone with an afternoon and the right tool. The code was never the point. A while back I wrote that we're moving into an economy that makes you prove it — where performing the work isn't the same as doing it. The proof was never going to be this essay. It's the tool I actually use, rough and unfinished, getting a little sharper every time I put a real company through it.

So here's where I've landed. The job was never to write code. It was to solve people's problems. Sometimes the person is you — and that turns out to be plenty.

Sources

• Keynote: After the AI Hype — What's Real, and What's Next — Richard Campbell, NDC, 2026. (The talk this piece opens and closes on: the "our job was never to write code" line, the protein-folding and AlphaFold story, the abstraction question about ERP and CRM, and the "the work will look different" close.)
• Compiled code was never your moat — Phil Smy, 2026. (The video this piece watches: a 1985 Xyphus binary decompiled and rewritten by Claude, and "stop assuming your binary is your moat.")
• Ship Smaller — Phil Smy. (The "thoroughness is fear with a to-do list" line, and the overbuilding-as-hiding argument.)
• About — Phil Smy — Phil Smy. (Zonmaster's ten-thousand-plus users, built mostly alone; the Shark Tank appearance; rural Japan; the feature with zero visits.)