Back

Essay

Knowing How to Code Is Not the Valuable Part Anymore

September 7, 20266 min read

Short answer: AI has made writing code fast and nearly free, so knowing how to build software stopped being the scarce skill. What's still scarce — and still valuable — is knowing what to build. If a software business has none of the three structural moats left (network effects, proprietary data, or IP and licenses), the code itself won't save it.

I am a so-called professional vibe coder. I run an agency selling AI implementations to businesses, including publicly listed ones, and I vibe code all of it. I used to know how to code. Frankly, I have completely forgotten.

A while back I saw a post from someone with a lot of experience as a software engineer, looking for the best courses on how to vibe code — beyond just prompting — so he could finally feel ready to start working on his own idea.

That really annoyed me, and it took me a while to work out why.

Vibe coding is not the hard part

It is not hard because it is not scarce. Anyone can do it. Anyone can build software, anyone can build an app, and right now a lot of people are doing exactly that.

What makes me useful to a client is not that I am the best at setting up the routines, the skills, the config files. It is that I know what software to build, not how to build software.

That is the whole thing:

Knowing how to build software is not valuable. Knowing what software to build is.

Two groups need to hear that, and they are going to hear it differently.

If you sell your ability to code — developer, IT consultancy, AI agency — this is about what you are charging for.

If you sell software — SaaS, apps, anything with a price tag on a codebase — this is about what you think your product is. If you are still under the impression that you can sell lines of code and people will pay for it, you are mistaken. It might work for a little while. It will not work for long.

The tab next to the chat

Here is the part I think people are not looking at closely enough.

Almost everyone I know interacts with an AI chat professionally, most of them for most of their tasks. Open the Claude desktop app and the tab literally right next to Chat and Cowork is Code.

Do you not think people will eventually realize how easy that tab is to use? Do you not think the labs building these tools will eventually set the whole thing up for you, so that it is as simple as telling the tab next to your chat what to build — and it builds it, launches it, connects the database, connects the hosting, and hands you back your own app?

I am fairly certain that is a reality in a few months. Maybe weeks. It is always sooner than we expect.

Now run the numbers as a consumer. I want an app. It is just code — nothing but software. Which is the better path?

  1. Accidentally come across your app, which is probably small and not widely known. Research it. Find it. Download it. And, for all your effort to have been worth anything, pay for it.
  2. Ask an AI to build it, and make it a PWA I can put on my phone.

The second one is so much better and easier that it is not close. And I am not speculating — I already have three of them. Tailored to my routines, my habits, the things I want to get done in a day, everything I want to automate. Mobile app? PWA, done. Just software? Add it to whatever tool I am already in.

That is the point. Software has no value.

So what still has value? Three things.

If the value cannot come from the software, it has to come from somewhere else. I have been saying this for months, people keep trying to correct me, and so far nobody has managed it. Every reason a software product survives the era where software is free comes down to one of three buckets. (If you can name a fourth, I want this list to be right, not to be mine.)

1. Network effects

The value of your offer increases with every new user who joins. You cannot vibe code other people's presence.

2. Data

You have data nobody else can access. That comes in two shapes.

  • Access. An integration to a platform that gives you data others cannot get. If you can pull more out of a source than anyone else, that is a moat.
  • Depth. Data, expertise, or skill about something so specific that nobody else has it — which means the AI you build on top of it is better than anyone else's. Nobody can compete with it and nobody can steal it.

The extreme version is the search history Google sits on. You get the idea.

3. IP and licenses

Stripe is my favorite example.

Can you vibe code a Stripe? Technically — yes, probably.

Can you vibe code the licenses to actually store, hold, and move money? No. You cannot. That sits behind a wall of millions of dollars in legal fees you simply have to walk through, which Stripe already has. That is their moat. They have raised the cost of entry, and they are safe precisely because no amount of vibe coding gets you past it.

I go through each of these three in more depth — with the danger-zone list of large companies that don't obviously have any of them — in this piece on startup moats in the AI era. This one is about what the three-moat framework means for the people who get paid to build, not just the people who own what gets built.

If you are a consultant or a freelancer, this still applies

The obvious objection: fine, but I am not building a SaaS, I build things for clients. How does a moat apply to me?

If you build internal automations, the value is data — the company paying for it is the only company that will ever buy it, and it sits on data about itself that nobody else can reach. That falls squarely in the data bucket.

But remember what is coming: soon those businesses will not need to pay you to build it, because they can prompt an AI themselves.

So build something market-facing instead. Tap into their network effects. Find somewhere to leverage more data. Look at whether they have IP or licenses that let them build software very few others could — and leverage that.

You have to become a design thinker. An inventor. A designer, much more than a coder.

What to actually do on Monday

  • If you sell software: make sure you have one of the three — network effects, data, IP and licenses. If you cannot name yours, you do not have one.
  • If you sell dev work: stop selling the building. Sell what to build. Sell the outcome. You are the one designing and inventing the best software to build, and that is where the money is — not in knowing how to code.

Here is the test I would put to any consultant right now. Is there a way for you to earn from this deal through a revenue share, or on outcomes, instead of per hour? Can you get paid without boiling it down to an hourly rate or a project-based fixed fee?

If yes, you are probably on the right track, because it means you are using what you know to unlock revenue the client could not see. That is value.

But if you want to go back to "I charge 100 bucks an hour because I know how to code and I will build the automations you need" — I think you will struggle. Maybe you already are. You definitely will.

This is exactly the shift Ordana is built around: structuring a real revenue share collaboration — contract, split, automated payout through Stripe Connect — instead of an invoice for hours. If you already have a client relationship where the value you add is judgment, not typing speed, that is the deal worth writing down.

One thing I genuinely do not know

I help plan the curriculum at a vocational school in Sweden that trains people to become programmers. The biggest question on the table right now is how we keep that education relevant, and how we make sure the students graduating will actually get jobs as programmers.

It is a hard question and it is giving me a lot of headaches. If you have any ideas, I would genuinely like to hear them.

Related reading: