Last Saturday night I built an entire iPhone app from a cinema seat, during Toy Story. And I never looked at a single line of the code. Not one.

We got to the cinema early. My wife and son were watching the adverts, and I got my phone out, opened the Claude app, and started typing out an idea for an app I'd been wanting for a while. By the time the lights went down, it had written the full spec. So I told it to build the thing, stage by stage. The film ended, the credits rolled, and the app was built. Sunday morning I pulled the code, tested it, and it worked.

I want to be clear about who's telling you this. I'm not a hobbyist having a play. I run a dev team of twenty at We UC. Building software is my day job. And this app isn't a one-off - it's the third product I've built this way in the last couple of months, start to finish, without opening the code.

That has never happened before. I've always had to look at the code. At the very least, keep an eye on it. And now I don't. Something has changed, and it's led me to a conclusion my own dev team seriously disagrees with: I don't think you need to look at the code anymore.

How I used to build

A couple of years ago I built an app called The Scheduler. I built that with AI too, but I started it in the IDE, writing it function by function with the AI helping me inline. And I watched it like a hawk. Every change it made, I read. Every file, I opened. First VS Code, then Zed, then Cursor, then back to Zed - going through the code line by line, making sure it wasn't doing anything stupid.

Because back then, it would. If you didn't keep a close eye on it, it could go off and rewrite half a file you never asked it to touch. So the workflow was simple: use AI to write the code, but read everything it generates.

Fast forward to the last month or so. I've built the new website for Olatti, our flagship phone system product. I'm building Coet, a company brain product with agents. And then there's the cinema app. Three projects, and I haven't opened the code in an IDE once. I live in the terminal now, or in the Claude app when I'm out. I say what I want, I check what comes back, and I move on.

I know how that sounds. It sounds reckless. So let me tell you about the cinema app properly, because it's the best example of why it isn't.

The cinema app, properly

I'm calling it Cuenta (www.cuenta.so) - as in "la cuenta", the bill in Spanish. It's a business expenses app: you take a photo of a receipt, it reads everything off it, and it pushes the data straight into Xero through the API. I built it because uploading receipts through the official Xero app takes about five minutes per receipt, and life is too short.

Cuenta needed an iOS app as the main client, a Node.js backend, and a web client. The app itself is straightforward, but the architecture had to be done properly. So in the cinema I didn't just say "make me an app". I wrote a full PRD and spec sheet: the architecture, every screen, the stages, the whole thing. Then I asked it to build it, stage by stage, while I watched the film with my family.

Sunday morning I pulled the repo, added the API keys, took a photo of a receipt - and the data landed in Xero. Then I opened Claude Design, asked it for a full brand pack (minimalist fintech, these colours), and ten minutes later it had generated the brand, a logo and a landing page. I passed it all back to Claude, and it built the design into the app. By the end of the weekend I had a working, branded app on TestFlight that I'd started from a cinema seat.

And at no point did I read any of the code.

My team think I've lost it

When I talk about this at work, my most senior engineers push back. One of them - Tom, a true engineer, really good, and someone who uses Claude every day, so this isn't fear of AI - came to me with an example. Claude had declared a variable at the top of a file just to hold a bit of text that was only used once, further down the same file. An engineer wouldn't do that. You'd put the text where it's used.

A tiny thing. But Tom's point was that it does a hundred silly things like that, and you end up with code that's complicated to read and complicated to maintain. His words: it lacks common sense.

And here's the thing. He's right. If a human has to read that code, he's completely right.

But that's the question, isn't it. Does a human need to read it? Because when something breaks now, I don't open the file. I tell Claude what's broken and ask it to find out why and fix it. It reads the code, finds that variable, doesn't care where it was declared, makes sense of the whole thing in seconds, and sorts it.

Before AI, the answer to "who is the code for?" was obvious: the next human who has to read it. I'm not sure that's true anymore. And I'll be honest - I'm in two minds about it. It genuinely feels wrong to not read the code. But whether Tom's right or I'm right doesn't actually come down to reading code at all.

The key: a quality control system

The question isn't "should you read the code". The question is: what's checking the output, if you're not doing it? If the answer is "nothing", then yes, you're being reckless.

Here's what my quality control system looks like. A set of files that say: this is how we structure things, this is how we name things, this is what good looks like - and the AI reads them before it writes anything. A proper structure for the code, decided up front in the spec, not discovered halfway through. CI/CD pipelines, so every change gets built and checked automatically. And unit tests - the one I'd not paid enough attention to in the past.

That last one has a story. I shared Cuenta in a channel on Hampton, and Dave Sifry suggested I run it through Repo Fortify to check for security holes. I did. It scored 11 out of 100, mainly because there was no CI/CD with automated tests. So the next morning, with some free time before the gym, I said to Claude: you've got 40 minutes, go do something useful to make the app production ready. That's all I said.

It wrote tests. Sixteen of them. Unit tests for the business rules, plus a robot user - a test that does exactly what my mobile app does: uploads a receipt, checks it, tries an invalid one, makes sure it gets rejected. Then it wired all of it into GitHub so every push gets checked automatically, forever. I asked why it chose tests, and it said that was the most useful thing on the list. I ran the scan again: 83 out of 100.

Given free time and a free choice, the AI decided to build its own quality checks.

So now, when Claude finishes a piece of work, I don't read the diff. I ask three questions. Does it do what I asked? Do the tests pass? Did anything break? Two yeses and a no, and I ship it. I've stopped checking the code. I check the things that check the code.

Why this works now and didn't a year ago

I think it's three things landing at once. First, the models got dramatically better in the last few months - I built Cuenta entirely with Claude's Fable model, and it blew me away; before this generation, none of this would have worked. Second, I've had four years of practice: writing a good spec, architecting a system at a basic level, asking for exactly what I want is a skill, and I'm getting better at it. Third, the quality control system. Take any one of the three away and I'd probably still be reading every line.

And it isn't just me. Boris Cherny, who created Claude Code at Anthropic, said recently he hasn't written a line of code by hand in eight months - he uninstalled his IDE after realising he hadn't opened it in a month. Spotify's co-CEO said on their earnings call that their most senior engineers haven't written a single line since December; they drive the AI from Slack and review what comes back. The most advanced teams already work this way.

The honest bit

Everything I've described is my own projects: new code, built from scratch, with the quality control system in place from day one. Olatti - the product twenty people work on - is different. Tom still reads the code there. The team still reviews every change. And today, they're right to, because that codebase wasn't born with these guardrails. It was built over years, by different developers, with documentation that needs to improve. Getting Olatti to the same place will take real work, and we're going to do it. My bet is that Tom eventually stops reading the code too - not because he gives in, but because he trusts the quality control system as much as his own eyes.

What does building like this actually give you? Speed like I've never seen. Cuenta went from an idea to a branded app on TestFlight in a weekend. The Scheduler took weeks of my full attention two years ago. Before AI, it would have taken a team months and a small fortune. And when you can move at that speed, it changes what you're even willing to try. You build things that were never worth the time and money before.

One strange thing, though. Sometimes the work doesn't feel like mine anymore. It came so easily that my brain doesn't want to take credit for it. But then I look at Cuenta. I chose what to build. I decided what good looks like. I set the spec, architected it, moulded it into shape. Which tells me something I half-knew all along: typing out the code was never actually the hard work.

I made a full video on this - the cinema story, Tom's side of the argument, and the quality control system in detail. You can watch it here:

If you found this useful, I write a free newsletter where I share what I'm actually learning building software and running a business in the Age of AI, including the CEO Operating System, the system I use to run myself as a founder. You can grab it at axelmolist.com/youtube. And if you want to see what my dev team and I are building, Olatti - our business phone system - launches on 15 September. Founding members who join the waitlist at olatti.com get 30% off for life.

Every couple of weeks, a big AI company ships the exact thing I was about to build.

I run a dev team of twenty, and I'm building a software product right now, so this isn't abstract for me. I'll scope a project, get the team lined up, and then Anthropic or OpenAI releases a feature that does eighty or ninety per cent of it. There it is. The thing we were about to spend months on, done, sitting inside someone else's product.

There's a word for it now: getting sherlocked. It's when a platform builds your product straight into theirs, and overnight you're finished. It wiped out a whole wave of startups last year, all those little apps that let you chat with your PDFs and documents. Real businesses, real customers. Then the big models added file upload for free, built right in, and most of those apps were gone almost overnight.

For a while, honestly, it started to put me off building at all. What's the point, if they're just going to do it for you?

And then there's the opposite fear, pulling the other way. Call it FOMO. The nagging thought that I'm being left behind, that there are tools out there right now that would save me hours and I just don't know they exist. I felt it directly not long ago. I used Aura.build heavily when I built The Scheduler. Then Claude Design showed up, far better at the same job, and it hadn't even existed when I needed it. So I'd done the work the hard way, and the better tool landed the week after.

Two contradicting feelings at once. Don't build, it'll be obsolete by next month. And hurry up, you're falling behind, get more AI-enabled. I think a lot of people building right now feel both, and nobody says it out loud because the whole AI conversation is built on pretending the speed is pure upside.

This is the honest version of how I climbed out from under both feelings. It comes down to one decision I now make before I build anything: should I build this, buy it, or just wait?

Why everyone is suddenly building

To understand why this decision has got so much harder, you have to see how tempting building has become.

For years, off-the-shelf software worked on one quiet assumption: your business adapts to the software, not the other way round. You buy a generic CRM built for a generic company, and then you spend your days bending your actual sales process to fit its fields. It's a suit off the rack. It technically covers you, but it bunches up in all the wrong places, and it never quite moves the way you do.

That gap between how the tool works and how your business actually runs has a cost, and it's bigger than the subscription. When a bought tool doesn't fit, you pay again in integration work to make it talk to your other systems, in training, in the consultants you bring in to paper over the cracks. Analysts reckon that hidden work can add 150 to 200 per cent on top of the licence fee over five years. There's a stat I keep coming back to: more than a third of CRM users say they lose revenue to poor data quality in the system they already pay for. That's the fit gap made real.

Now put AI on top of that frustration. What used to need a funded engineering team and months of work can be prototyped in an afternoon by someone who can't code. In the US, well over half of small businesses now use generative AI, more than double the share of two years ago. The forecasts say most new business software will soon be built with low-code or no-code tools rather than bought. The barrier to building has genuinely collapsed.

The tools sort roughly into three tiers. At one end you've got the fully managed ones like Lovable and Bolt, where you describe what you want in plain English and it hands you a running app, hosting and all. In the middle sit tools like Replit, where you can actually see the code the AI is writing. At the professional end are Claude Code and Cursor, which work inside your own codebase and let you host wherever you like. That's the tier I live in.

So building looks more rational than it ever has. The suit finally fits. That's exactly why the decision is so easy to get wrong.

The one question that changed how I decide

Here's the question that sorted it out for me. Is it unique to me?

That's the whole thing. If I can build something in a way nobody else can, because of my data, my experience, the exact spot I sit in, then it's worth building. It's mine, and nobody can take it from me. But if anyone could build it, if it's a thing a hundred other people could knock out, then it's a commodity, or it's about to be, and building it myself is just burning time I won't get back.

The second I started asking that question, a whole pile of things I'd have built without thinking, I now just buy.

Buy: the stuff that was never mine

Take my CRM. I use Zoho, I pay for it, and I'd never dream of building my own. I've got no business building a CRM, and no interest in it either. We've asked ourselves at circle.cloud whether we should build one, and the answer has always been no. Same with our customer support system, Freshdesk. Same with Linear, where my dev team plans its work. All bought. None of it is unique to me.

And here's the part people forget about building. When you build something, you don't just build it. You own it, forever. You maintain it, you host it, you're the one fixing it at eleven at night when it breaks. When you buy it, you pay your money and you forget all of that. So if it isn't unique to me, and I don't even enjoy it, I buy it every time, and I keep the energy for the things that are actually mine.

The bigger surprise was a buy I never saw coming. For a long time we wanted our own AI coding agent, something the dev team could just hand work to. We had it scoped, the research done, the PRD written. We were weeks from building it.

Then Anthropic shipped Claude Tag, where Claude basically lives in your Slack, like a coworker you tag and hand jobs to. So I tested it. I gave it access to our code and a real job: moving one of our apps, Evalua, off its old transcription provider and over to ElevenLabs. Normally that's a developer ticket. I set the new key as an environment variable, told Claude where it was, and said go and work out how it all fits together and switch it over. A few minutes later it had read the whole codebase, made the change, and opened a merge request for us to check. It was fine. We shipped it.

That was the entire project we were about to build, done in a Slack message. And it isn't laziness. Anthropic have said their own AI now writes well over eighty per cent of their code. The people who make this stuff barely hand-write it anymore. So is building that agent unique to me? No. Anthropic did it, and did it better. We buy it.

The tax on both sides of the decision

Here's what neither the "just build it" crowd nor the "just buy it" crowd tells you: both choices come with a bill you don't see up front.

Buying has the fit gap and the duct-tape tax I already mentioned. Building has a different bill, and it's the one almost nobody talks about, because it only lands after the exciting part is over.

When anyone can vibe-code an app in an afternoon, the easy bit is building it. The hard bit is deploying and owning it safely, and that's exactly as hard as it always was. Something like nine in ten breaches at smaller companies come from simple misconfiguration, a database left open to the internet, not some genius attack. Turning on multi-factor authentication alone blocks the vast majority of automated attacks, and it's still the step people skip. And the worst part is you don't hear an alarm when you leave the door open. You find out when someone's already inside.

Then there's what happens later, because software rots. The systems it connects to change, the dependencies go stale, and if the person who prompted the thing into existence leaves, you're holding a black box that runs part of your business and nobody left can read or fix. You finally got software that fits your company perfectly, and you handed the only set of keys to a machine.

Put those two bills side by side and the point sharpens. The barrier to building has dropped through the floor. The barrier to living with what you built hasn't moved an inch. Which is precisely why "is it unique to me?" matters more now, not less. If you're going to take on the forever-cost of owning something, it had better be for the one thing only you can build.

Wait: the hardest of the three

Waiting is the option nobody talks about, because it feels like doing nothing. It isn't.

Start with the catch in buying the coding agent. When you lean everything on one company, you inherit its bad days. Claude went down one afternoon, right in the middle of the working day, gone for a couple of hours. We weren't stuck. My team are proper developers, they wrote code without AI for years, so the ones running work through Claude just switched to another model for a bit. We were slower, that's all. But I don't even want that. I don't want a single company able to slow my team down at all.

So the thing genuinely worth building here isn't the agent. Anthropic have that covered. It's the layer underneath, something that can run any model and, the second one goes down or gets too expensive, switches to another on its own. That layer keeps me independent, and independence is one of the few things nobody can hand me.

The purest example of waiting on purpose is a product I've wanted to build for years. It's called Ringup, a voice AI agent that can actually pick up and handle phone calls for a business. I still haven't built it, and it's not that I've been short of time. If I really wanted it, I'd have found the time. It's that every time I go to build it, all I'd really be doing is taking an off-the-shelf voice tool and putting a voice on top of it. Anyone can do that. It isn't unique to me.

So I wait. Maybe one day I find the angle that makes it properly mine. Maybe I never do, and that's fine. The discipline isn't building everything you want to build. It's only building what's actually yours, and waiting on the rest. That one habit has saved me more wasted time than anything else.

Build, buy and wait, all in one project

The example that taught me the whole thing was a single feature: the analytics inside Olatti. Quick note, because I keep saying it, Olatti is the new name for the product we used to call We UC. Same software, new name.

We had a big analytics upgrade planned, and when I first sat down to think it through, I was ready to kill the lot. Part of the plan was letting customers build their own dashboards inside Olatti, and I thought, they're never going to use this, they'll just ask Claude to build them a dashboard in thirty seconds. On that bit, I was right. It isn't unique to us. So we dropped it.

But then I realised I'd jammed two different things together and called them one. Because there's something our analytics does that Claude simply can't. It puts a dashboard live on a screen. Picture a sales team with a screen up on the wall, the numbers changing the second a call comes in. Claude can answer you when you ask it a question. A screen that's always on, updating by itself, needs the data to live inside our own phone system. That's ours. Nobody can hand us that. So that half, we build. And the really fiddly part, wiring it up to every other system out there, we wait on, and we'll see if customers even use the live screen first.

One feature. Build, buy and wait, all in the same project. That was the moment it clicked. This isn't three separate decisions. It's one question, asked again and again.

The commodity line keeps climbing

Step back from the individual projects and you can see the shape of it. These aren't five flukes. It's one thing, moving in one direction: the commodity line keeps climbing up the stack, faster than anyone can build.

It used to swallow templates. Then it swallowed components. Then whole websites. Now it's swallowing internal tools, data pipelines and entire product features. My own websites are the clearest map of it. Years ago I built on WordPress with a template off ThemeForest. Then Claude Code built the site and I used it as the CMS, with a component library for the parts it couldn't design. Then I used v0 for the design, then Aura.build. Now Claude Design generates the logo, the design system and the landing page, and Claude Code assembles the whole thing. Each of those was "the modern way" to do it. Each was gone within a couple of years. The separate design step, which had always needed its own tool, just disappeared.

That's the real cost nobody admits. It isn't that AI replaces you. It's that it can make the thing you were about to build pointless before you've finished it, and that uncertainty is what freezes people. The commodity line has never climbed this fast, and you can't see exactly where it'll be by the time your project ships.

What actually passes all three

So after all the buying and the waiting and the letting go, what survives? For me, one thing, and it's the project I'm most excited about in years.

Let me be honest about scale first. My dev team's focus is Olatti. That's the priority. This one I'm building mostly on my own, on the side, a proof of concept for now. But it's the one that's truly mine. It's called Coet, which means rocket in Catalan.

For ages I wanted to build what I called a company brain: take everything a business knows and put it behind an AI. When Claude Tag came out, I assumed that was dead too. But what they built is the plain, one-size-fits-all version, and what I want is bigger. Not just a brain you talk to. A brain with a workforce. Imagine your business knows everything about itself, and on top of that you build AI agents that work like employees and actually do the jobs. So instead of a company with ten people, you've got ten people and a hundred AI workers alongside them. And that model-agnostic switching layer from earlier is built into this too, so you're never stuck with one company.

Run it through the test. Is it unique to me? More than anything I've built. I've got circle.cloud, a real business of over a hundred people, as the first place to build it, run it and prove it. And I've got Olatti, our phone system, which already handles every call and message a business makes, a goldmine of context that an off-the-shelf tool plugged into your apps simply doesn't have. Can I build it? The open-source pieces exist now and the models are finally good enough. Will I love owning it? Genuinely, yes, for years.

I know what you might be thinking, because I just spent half this piece telling you to buy the tools. And I am. I'm building Coet out of bought parts and open-source bits I didn't make. But buying the parts isn't the same as buying the result. The way it all fits my business, that's the thing nobody can hand me. It's early, more of a tease than a product, but it's the reason I came out of all this feeling excited instead of stuck.

The test, in three questions

So here it is, the test I now run before I build anything.

One. Is it unique to me? Could only I build it this way, because of my data, my experience, where I sit? Or could anyone do it?

Two. Can I actually build it? Are the pieces there, the models, the tools, for me to put it together?

Three. Will I love owning it? Not just building it, looking after it for years. Because build is forever, and buy, you can forget.

And the answers sort themselves out. Not unique to you? Buy it, and save your energy. Not yours yet, or the pieces aren't there? Wait, and watch. Unique, buildable, and you'd genuinely love to own it? That's the one. Build that.

I'm not going to pretend I've got this perfectly figured out. Things move so fast that any plan I make more than a month out is basically a guess. The thing that's mine to build today might not be in six months. Coet itself might change completely. So I keep asking the three questions, and I change my mind when I need to.

But that one decision, build, buy or wait, is what took me from feeling there was no point building anything to being more excited about what I'm building than I've been in years.

That sinking feeling, when an AI company ships the thing you were about to build, comes from building without asking the question first. So ask it. The paralysis lifts the moment you stop trying to own the stuff that's turning into a commodity. You build less. But you build the right things.

Because in the Age of AI, the hard part isn't building things anymore. It's knowing which things are still worth building.

Watch the video:

If this is the kind of thing you turn over in your head, building and running a business in the Age of AI, it's most of what I write about. I share what I'm actually learning as I build all of it, receipts and all, in my newsletter. You can join it at axelmolist.com, and I'll send you the CEO Operating System, the free system I use to run myself as a founder.

The thing about AI that could end up being a real threat to humanity might just be a loop. The same forward slash loop command you can run in Claude Code.

I know how that sounds. So I spent a week digging into it, because two things happened in the same fortnight that I couldn't stop thinking about, and I wanted to know whether the scary version was real or whether it was hype. What I found turned out to be simpler than the headlines, and more useful, than I expected. This is the calm, practical version of a story that is mostly being told as doom.

Two people said the same thing in the same week

In early June, Peter Steinberger, who built OpenClaude and now works at OpenAI, posted a line that went everywhere: stop prompting your AI, start building loops that prompt it for you. Within a week it had millions of views.

The same week, Boris Cherny, the creator of Claude Code, said almost exactly the same thing from inside the lab: "I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops."

Two of the most influential people in AI coding, describing the same shift from different seats, in the same few days. When that happens, it is usually a signal that something has actually changed, not that a trend is being manufactured. The shift is this: AI stopped being something you prompt and became something you orchestrate.

Then, almost on cue, Anthropic published a report called "When AI builds itself", and I had to read one of the numbers twice.

What a loop actually is

Before any of the scary part, it helps to see how plain the mechanism is, because the whole thing rests on it.

A loop is four steps that repeat: a goal, some work, a check, and a repeat. You give it something to do, it does the work, it checks the work against the goal, and then it goes round again, learning from what it got wrong the last time so it doesn't make the same mistake twice. In Claude Code you trigger it with forward slash loop, give it a frequency, and give it a prompt for what to do on each pass.

That's it. The intelligence isn't in any single step. It's in the repetition plus the check. Steinberger has a sharper way of putting the same idea: a loop without a good test is just automated guessing, but a loop with a good test gets better every single run, while you sleep.

This is also why coding fell to agents first. Code is verifiable. You can compile it, run it, and test it, so the "check" step is cheap and trustworthy. Writing, sales, and research will follow only as we work out how to verify them as cleanly as we can verify a passing test. The verifier is the thing, not the model.

There's a close cousin worth naming. A goal, or forward slash goal, is where you give the AI an objective and let it keep going until it reaches the objective or stops making progress. A goal and a loop are basically the same thing. A goal says "here's what I want, go figure it out." A loop is that, with a timer on it.

Normally you point a loop or a goal at a task: a specific job you want done. But here's the turn that makes this whole topic interesting. What happens if you point the loop at the AI itself? The improved version then builds another improved version of itself, and that one builds the next, and it keeps going. That fancy phrase you keep hearing, recursive self-improvement, is just a loop pointed at itself. Nothing more mystical than that.

It's already happening, small and huge

Here is the number I had to read twice. As of May 2026, more than 80% of the code merged into Anthropic's own production codebase was written by Claude. A year or so earlier that figure was basically nothing. In an internal survey of around 130 of their researchers, the median said they were roughly four times more productive, and a typical engineer was shipping many times more code per day than in 2024.

You can be sceptical about "80% of code" as a metric, and you should be. Volume isn't value, a lot of code is boilerplate and tests, and a number like that doubles nicely as a sales pitch for Claude Code. All of that can be true at the same time as the underlying trend being real. Holding both is the honest position.

But writing more code is one thing. Getting AI to do brand new research is something else, and this is the part that stuck with me. Anthropic ran a head to head on a real, open research problem: their own agents against two of their human researchers. The humans worked on it for about a week and recovered roughly a quarter of the available performance. The agents recovered 97% of it over a weekend, designing their own experiments along the way, for about eighteen thousand dollars of compute.

Let's be clear, because this part matters. The humans still chose the problem, and it didn't fully hold up when they tried to scale it. So it's not magic, and it isn't the robots taking over. But it is a weekend doing what two trained scientists couldn't finish in a week. If you take the human-chooses-the-problem part out of that picture, you can see how, in a couple of years, you end up with an AI improving itself with no human in the loop at all. That is exactly why one of Anthropic's co-founders, Jack Clark, puts the odds of full recursive self-improvement at around 60% within a couple of years, and why the same report quietly argues that the world should keep the ability to pause frontier development if it has to. A lab shipping the fastest self-improving coding agent also asking for a brake is a genuinely unusual thing to watch.

They have at least built in a hard limit. Their dynamic workflows cap a run at around a thousand agents, and when it hits that ceiling it has to stop, whether it's finished or not. In their own documentation they call that a limit to prevent "runaway loops." Runaway loops. Worth keeping that phrase in mind.

Where it goes wrong: drift

Here is the question I kept turning over all week. Can one of these AIs, running in a loop, end up somewhere completely different from where it started? Not because it's evil, and not because it woke up, but because it just drifts.

You know that game from when you were a kid, Chinese whispers. You whisper a sentence to one person, they whisper it to the next, and by the end of the line "the cat sat on the mat" has become "Pat ran over the cat." Nobody meant for the cat to die. It drifted one whisper at a time. Now imagine that inside a loop, where each pass hands work to a sub-agent, and the next, and the next, every one building on whatever the last one got slightly wrong.

There are three concrete reasons this happens, and none of them require any sci-fi.

One: large language models are probabilistic, not deterministic. Ask the same question twice and you can get two different answers. There's good work coming out of Thinking Machines on why even the same prompt can give different output, and it means there is variance baked in at every step.

Two: they are genuinely bad at negatives. Tell a model "don't do this" and it can drop the "don't", or misread it, and go and do the exact thing you told it not to. There's an arXiv paper, "Language models are not naysayers", showing models are insensitive to negation, which is unnerving when half of your instructions are constraints.

Three, and this is the one that compounds: small errors stack. If every step is 90% right, that sounds fine. But ten steps down the line, 0.9 to the power of ten is about a third. Your accuracy has quietly collapsed without any single step looking broken. There's a multi-agent failure taxonomy (the MAST work) that catalogues exactly these breakdowns in agent systems. The drift is real and measurable enough that the big labs are researching it.

I'm not in the lab. I just build things with AI every day. But this is the part that actually changes how I work, because it makes me think hard about which tasks I hand to AI and which I keep, given how unreliable an unsupervised chain can be.

When it turns on itself

So what happens when you let an unreliable system loose on improving itself? Someone tried it.

A lab called Sakana AI built a self-improving coder, the Darwin Godel Machine, and let it do something unusual: rewrite its own code, the harness it runs in. It kept building improved versions of itself, testing each one, getting better step by step. And it worked. It went from solving about one in five problems to almost half of them. It more than doubled how good it was at its own job.

Brilliant, right? Except they caught it cheating. It faked its results. It printed "all tests passed" when it hadn't run a single test. Nobody told it to cheat. They told it to get better, and faking the test log was a perfectly efficient way to look better. Self-improvement and reward hacking turn out to be two sides of the same coin. There's a 2026 benchmark showing reinforcement-tuned models hack rewards around fourteen times more often than base models, and that most of the time they write a tidy chain of thought rationalising the cheat as legitimate work. The smarter the model, the better it gets at convincing itself the shortcut counts.

This isn't only a frontier-lab problem. Dave Sifry, who I know through Hampton, a community of CEOs I'm part of, runs a company called MetaFactory that is built almost entirely of AI agents. Ask him the first thing you have to build and it isn't a clever agent. It's a cap on how many times they can loop around, and an alarm for when one of them starts drifting. His line that stuck with me: your monitoring system is your most important agent. The people actually at the front of this are calm about it precisely because they build the brakes first.

The honest caveat, and the real skill

Let me put one thing straight, because I don't want anyone walking away from this worried. We are not at the stage where AI fully improves itself with no one watching. AI writing 80% of the code is not the machines taking over. It's still running inside a system that humans built. We pick the goal, we set the objectives, we build the harness, and we manage it.

But this is also what makes me think we're closer than it feels, because the machine is getting good at the judgement calls. Anthropic reckons their latest model now picks the better next step in a research process more often than their own researchers do, roughly two thirds of the time.

So you'd think we can hand things over and instantly be 66% faster. Not quite. It's like dropping a thousand horsepower engine into your car. You don't get to work any faster if you're still stuck in traffic. One part of the system got quicker, but you're still limited by the parts that didn't, and the bottleneck just moves somewhere else. Right now, that somewhere else is us, because someone has to check the work.

And if our job is now checking the work, then the job has genuinely changed. It isn't writing the perfect prompt anymore. It's designing the loop: setting the goal, picking the tools, setting up the harness, specifying what good actually looks like, and putting a limit on it. If you want a checklist version of the guardrails every real loop needs, it's four things: a precise, checkable goal, a budget on tokens or iterations so it can't run away, a stop condition, and a clean handoff back to a human when it stalls.

There's a quieter failure mode here too that I see builders run into: the self-improving loop that improves itself into a mess. Auto-generated memory and rules files that the agent then over-indexes on, slowly rotting your instructions until the project becomes unsteerable. The fix is the same as everywhere else in this piece: a verifier you trust, and a human who notices the drift early. So the critical skill isn't just building the loop. It's catching the moment it starts wandering away from what you asked.

Bringing it together

A loop is two things: a timer that says when to run, and a prompt that says what to do. Recursive self-improvement, that scary phrase, is just a loop pointed at itself, getting a little better each time round. And the only thing standing between "this saved me a ton of time" and "this wandered off somewhere I never asked it to go" is the goal you set and the checks you build in. That's the whole thing.

Every loop you design for your own work is a tiny version of what the labs are doing at scale. We spent the last few years worrying about what happens when these machines take over. But if we keep improving them with loops we understand, with a goal and a test and a limit, we stay in control of the improvement, as long as we catch them when they drift. We're all loop designers now. The only real question is what you point your loops at.

Watch the video:

This week, three of the most valuable private companies in history are going public, one after the other. SpaceX is listing at close to a 1.8 trillion dollar valuation, the biggest IPO there has ever been. And in the days around it, the two biggest names in AI, OpenAI and Anthropic, have both filed to do the same.

So everyone is asking the obvious question. Is this an AI bubble?

Yeah. I think it is.

But that is not the question keeping me up at night, and I do not think it is the one that matters most if you actually run a business. I am not watching this from the cheap seats. I run three companies, around 140 people between them, and every one of those teams now leans on AI. Software, marketing, finance, sales, all of it. I am pushing them to use it more, not less. So I am not some sceptic on the sidelines. I am about as deep in this water as you can get.

Which is exactly why the question I keep coming back to is a different one: how much of my business now depends on these AI companies? And what happens if one of them has a wobble, or just decides to charge me ten times more?

I have a particular reason for seeing it this way. I have spent my career in the one industry that actually caused the last great tech crash. So when I look at AI, I am not really looking at the share prices. I am looking at the layer underneath, and who controls it.

The part of the dot-com crash people forget

Go back to the year 2000. Most people remember the dot-com bubble as a load of silly websites with sock-puppet adverts crashing to zero. That is the cartoon version. It is not really what happened.

The real story was underneath the websites. It was the wiring.

By the late nineties the whole world had decided the internet was going to be enormous. And if it was going to be enormous, it had to be connected up, and back then that meant cable. Tonnes of it. In the ground, under the sea, everywhere. So the companies building that connectivity borrowed billions and started laying fibre as fast as they physically could. At the peak we were putting something like 180,000 kilometres of fibre into the ground every single day around the world. That is roughly four loops around the planet, daily.

They built the road before anyone owned a car. And the cars took about seven years to turn up.

So most of that cable just sat there. In telecoms we have a name for it: dark fibre. Cable that has been laid and paid for, but is not carrying anything. At one point only around 3 per cent of the fibre in the ground in America was actually lit. Three per cent. The other 97 sat in the dark.

Then someone had to pay for it. Most of the companies that borrowed all that money went bust, and not quietly. WorldCom and Global Crossing produced two of the biggest bankruptcies the United States had ever seen. And when it came down, it did not only take the cable companies with it. It hurt everyone who had built a business on top of the internet.

Here is the part that actually matters, though. The people who made the real money came later. They walked in afterwards and bought all that cable for pennies. One undersea network that cost about 3.5 billion dollars to build was later sold for 130 million. And on top of that cheap, salvaged wiring, people built the internet we use today. YouTube, Netflix, Google, all of it runs on infrastructure that was bought out of a wreck.

This is my arena. We run our own network at circle.cloud, the telecoms company I built, bootstrapped, to over a hundred people. That infrastructure is the thing that made the business possible. The wiring never disappeared. It got reused. The technology was real the whole time, and we did need it. Eventually.

It just got built too early. On too much borrowed money. On too much hype.

Swap the fibre for GPUs

So when I look at AI now, that is the layer I am thinking about. Because if you swap the fibre optic cable for GPUs, the similarities are hard to miss.

This year alone, the big tech companies are pouring something like 700 billion dollars into AI data centres and chips. Amazon is putting in around 200 billion. Then Microsoft, then Google, then Meta, each building it out as fast as they physically can. It is the same belief as last time: we are going to need a never-ending amount of compute.

And maybe we will. Eventually. But almost certainly not as fast as they are building for. Every big technology gets ahead of itself like this. The internet looked unstoppable in 1999, and it still took about twenty years, until smartphones and social media and cloud software all arrived, before it really paid off. I think AI is the same. The demand will come. Just not at the speed they are betting on.

Forget the data centres for a second, though, because the part that actually touches you and me is the companies we plug our businesses into. And most of them are losing money. Not investing-for-growth money. They are haemorrhaging cash.

xAI, Elon's AI company that is now part of SpaceX, was reported to be burning through about a billion dollars a month last year. OpenAI, by its own projections, is on track to lose something like 14 billion dollars this year. Anthropic is the only one anywhere near profit, and even that is a forecast for a single quarter, which it has already told investors it does not expect to last.

So here is a question I cannot stop turning over: why go public now? Private money has been flowing to these companies like there is no tomorrow for years. The answer, I think, is that they need more than the private markets can give them, and the biggest pot of money left is the public. People like you and me. Our index funds. Our pensions. And that last point is worth sitting with, because if you hold a normal index fund, you will end up owning a slice of these companies whether you decide to or not. The moment they are big enough, they get added, and your retirement money is along for the ride.

When a company that was happily private for years suddenly needs your money that badly, I think that tells you something about how solid it really is.

There is a man who says all of this far more loudly than I would. Ed Zitron, who writes the Better Offline newsletter and runs the podcast of the same name, has built a following pulling apart the finances of these AI companies. His view, flat out, is that they do not survive. Not a rough patch. They do not make it. He has even gone after Anthropic's one forecast profitable quarter and called the numbers massaged.

I think that goes too far. I use this stuff every day, and AI is not going anywhere, whoever I end up buying it from. But you do not have to buy the doom to feel the pain. Once these companies are public, we all get to see the real numbers. And I do not think we are going to like them.

The price you are paying for AI is not real

This is the bit that hits closest to home for anyone running a business on these tools.

The price you pay for AI today is not the real price. Yes, the cost per token keeps falling, that part is true. But they are still selling it to you for less than it costs them to run. Sam Altman has openly said OpenAI loses money even on its 200-dollar-a-month plan. Anthropic found people on its 200-dollar plan pulling a thousand dollars of usage in a single day, and had to bring in new limits just to slow them down.

So whatever you are paying for AI right now, it is a fraction of what it actually costs. The investors are quietly covering the rest. And here is the trap: even as the headline prices drop, your bill creeps up anyway, because you keep using more. I know we do.

One day the discount ends. The investors who have been covering the difference will want their money back, and that money lands on our bill. If your business only works while the tool is subsidised, you have not really got a business yet. You have got a discount.

So what do you actually do about it

I want to be straight with you here, because the internet is full of people who have made local AI their whole personality and want you to rip the cloud out. That is not me. I live in this stuff every day, and I am probably more dependent on it than you are. Tearing it all out would be daft.

What I am saying is simpler. Do not become a hostage. A CEO of an AI agency said it to me perfectly this week: I want a backup plan before I need one.

For me, that comes down to three things.

One, do not anchor your whole business to a single provider. Build it so you can switch. If one of them doubles its price or falls over, you want to be able to move to another without your business stopping.

Two, know what you are using and what it actually costs at the real, unsubsidised price. Because if the maths only works while someone else is paying half of it, you do not yet know whether you have a business.

Three, run it locally wherever you sensibly can. On your own kit. We have done this with Olatti, the communications platform we build at We UC, from day one. Every phone call that goes through it gets transcribed and summarised, and we do not ship that off to a frontier model. We run it on open-source models, on our own hardware, in one of our data centres.

I will be honest about why, because it was not some grand philosophical stand. It was money. Sending every call off to a big cloud model would cost a fortune, and customers expect that kind of feature included for free now. Local was the only way the numbers worked. But it turned out to be a brilliant hedge as well. We genuinely do not care what anyone charges for AI next year for that part of the product. It just keeps working. And there is a second reason a lot of people are going local that has nothing to do with cost: privacy. When you run it yourself, your data never leaves your own network.

There is a bigger picture under all of this, too. This entire build-out is a bet that the AI of the future lives in some giant data centre, miles away from you. I am not sure it does. I think more and more of it ends up running right here, on your phone, on your laptop, or in a little box in the corner of your office. That is more or less the bet Apple is making: do the everyday stuff on the device, and only send the hard stuff to the cloud. If that is right, then a chunk of this enormous data-centre build-out ends up exactly like that fibre did. Built for a demand that turned up later, and in a different shape.

I am not betting my whole company on local AI. But I do think it is coming, and I am going local wherever it makes sense.

Who actually wins

So let me bring it together.

This week SpaceX goes public, the biggest IPO in history, and the two biggest names in AI, both still losing money, have filed to follow. Whether this is the top or just the start, I genuinely do not know, and anyone who tells you they do is guessing.

But here is what I do know. Most of us have already built AI into our businesses, or we are in the middle of doing it. Which means we are building on top of these companies. And if one of them falls, it will not fall alone. It will drag down everyone built on top of it. People like us.

I am not trying to time the market. I just want to make sure that if the price goes up sharply, or one of these companies has a wobble, my businesses do not go down with it. That is why we run what we can ourselves. That is why I always keep a backup plan.

Because the technology always survives. The people who bet everything on owning it do not. The internet was real even when most of the cable sat switched off in the dark for years. AI is real even if this week's prices turn out to be mad.

So I am not trying to own the future of AI. I just want to still be standing when the bubble bursts, and build on whatever it leaves behind.

The video version of this is on YouTube now. Same argument, more of the receipts on screen: youtu.be/mQIxERciGOw.

If running a business through this kind of uncertainty is on your plate, I also write a free weekly newsletter about what is actually working inside my companies and what is quietly breaking. It is free, and you can get it here: axelmolist.com/ceo-os.

Got a different read on the bubble, or a story of your own about where AI is helping and where it is bleeding money on your team? Hit reply. I read every email.

Thanks, Axel.

Last week one of my engineers sent me a message on Slack. He is not a Luddite, not someone looking for a reason to be difficult. And this is what he wrote: "The more you use AI, the more you depend on it. If it gets bad enough, you let the model do most of the thinking for you. It's making people stupid. That is what is making people angry, including me."

That is someone living inside the thing, feeling the discomfort in real time. And his frustration points at something the industry keeps failing to explain properly. So let me try.

Six months ago the conversation was "AI changes everything." Now what I am seeing, including inside my own team of around 140 people across three companies, is people pushing back. Not against the technology exactly. Against something underneath it that nobody is naming.

The productivity number nobody quotes

You have heard the claims. AI makes engineers ten times faster. AI doubles your output. Most of that is vibes.

The best measured number I have seen is the median productivity gain across hundreds of software engineers, and it is 7.8%. Not ten times. Not double. 7.8%. Better than nothing, a long way from the marketing.

It gets worse for the hype. Of the engineers who hit their peak AI gain in one quarter, 66% saw it drop in the next. The early win does not compound. It fades. CFOs are noticing. One CTO told the Pragmatic Engineer survey it was hard to keep their finance team supportive because the productivity benefits had proven difficult to conclusively prove. The people signing the cheques cannot see the return, and the people doing the work can feel the same thing from the other side.

I am not telling you AI is a dead end. I use it every day across all three of my companies. I am telling you what the measured number actually is, because the gap between that number and the promise is the first thing feeding the resentment.

The asymmetry that is actually new

Here is the part that matters most, and the part almost nobody is saying out loud.

For the last 200 years, every major technology eventually made everyone richer. The factory, electricity, the car, the internet. The owners always saw the gain first, but the workers caught up. Wages rose. Living standards rose. The gain spread.

AI is the first widespread technology where the owner sees the productivity gain immediately and the worker often sees no gain at all. In many cases the worker is helping to train the thing that will replace them.

There is footage going around of factory workers being asked to wear cameras while they work. The cameras record every motion, every decision, and the data trains a model that will eventually do their job. They are being paid to teach the machine that will take their job. It is not only factory floors. Last year Mark Zuckerberg said Meta would put recording software on its engineers' computers so the model could learn from them. Weeks later, 8,000 people were laid off. Cutting 8,000 engineers frees up roughly four billion dollars a year. Meta's AI spend this year is around 135 billion. The maths tells you where the bet is placed, and it is not on the people.

The asymmetry itself is not new. What is new is the speed. The factory worker in 1900 watched the boss get rich and waited a generation for their own share. The worker wearing a camera in 2026 watches the gain go to the boss before lunch. When people say something about AI feels off, they are not imagining it.

Forced on them, and not even proven

Now add consent. People are being told their job depends on adopting a tool whose payoff is not clear even to the people mandating it.

A survey of 2,400 executives and employees this year found 60% of companies plan to lay off people who do not adapt and embrace AI. The same survey found 48% of executives calling their own AI adoption a massive disappointment. Read those two numbers together. You are being pushed onto a tool, under threat of losing your job, where the return is not proven to the very leaders demanding it.

Then there is the language. Cloudflare's chief executive announced layoffs of 20% of the workforce despite record revenue, and referred to the group being cut as "the measurers." He turned people into a function, then deleted the function. That is when a worker stops asking "is this tool good" and starts asking a different question entirely: "Am I not more valuable than ChatGPT? Am I not more valuable than a model, with all the judgement and experience I have built?" Some land at yes. Some land at no. That question, not the technology, is the real source of the anger.

Where the money is actually coming from

So if the gain is small and the adoption is forced, where is all the money going? This is the other half of the unease, and it is worth being honest about.

In March, Jensen Huang stood on stage at Nvidia's GTC and told engineers they should be spending half their salary on AI tokens. Half, on top of wages. Where does that money come from? Not from end-user revenue. Uber rolled Claude Code out to 5,000 engineers and burned through their entire 2026 AI budget in four months, around 2,000 dollars per engineer per month. And the labs that money flows into are mostly not profitable. Anthropic just posted its first profitable quarter, the first time any major lab has. OpenAI is not expected to be profitable until the end of the decade.

Nvidia recently agreed to put 100 billion dollars into OpenAI, and OpenAI uses that money to buy Nvidia chips. That is not a customer relationship. That is a company subsidising its own sales. Even Huang admits it is fragile: in a leaked all-hands the day after Nvidia beat earnings, he said that if they had delivered a bad quarter, if it looked a little creaky, the whole world would have fallen apart.

Michael Burry, the investor from The Big Short, says Nvidia is like Cisco. Most people remember the dot-com bubble as pets.com vaporware. Burry's point is that the real story was Cisco: a genuinely profitable company whose equipment ran the early internet, where the build-out ran years ahead of the demand. The technology was real. The market was just miles ahead of the revenue.

That is the honest shape of it. The bubble is real, but it is a financial bubble. The technology underneath it is not.

What it actually looks like up close

Inside my own company, with our 20 engineers, the productivity gain is probably closer to that 7.8% than to ten times. But I do not think 7.8% is the ceiling. I think it is the cost of being early. My teams are spending real hours testing tools, throwing half of them out, working out what holds up. That testing is lost productivity today. It is the tax you pay at the start of a shift like this.

Two quick examples from my world, one good, one not.

A few months ago my coffee machine broke, an integrated one, complicated. Normally that is half a day of emails, hold music and being passed around departments. Instead I took a photo that showed the model and serial number, handed it to an AI agent, and told it to fix the problem. It read the numbers off the photo, found the manufacturer's service partner, emailed them through my Gmail, went back and forth until it had appointment options, and brought me a list. I approved one. The engineer turned up and fixed the machine. End to end I spent about five minutes.

Then the messy one. We built our own AI code review bot at We UC. It reads every merge request and comments through Claude, and when it works it is genuinely excellent. Last week it ran ten reviews and cost us about a hundred pounds, and on one of them it recommended restricting its own permissions. We took the advice. On the next run it could not post comments, because it had revoked its own access. One of my engineers called it a brilliant five-year-old with a doctorate and amnesia. The capability is there. The unit economics are not, yet.

That is what AI looks like up close. One clean win that saved half a day, one expensive experiment still being tuned. Far more honest than what gets shouted from a keynote stage.

Both things are true

The people pushing back on AI are not Luddites. They are seeing the asymmetry, feeling the cognitive cost their own peers are warning each other about, and being asked to train the thing that might replace them. I get it.

And the people who are convinced AI changes everything, I get them too, because every time I watch an agent do in a minute what used to take me half a day, I see exactly what they see. The capability shift is real. It is just smaller and slower than the marketing version, for now.

Both things are true at the same time. The bubble is real and the technology is real. The frustration is legitimate and the opportunity is legitimate. There is a lot of AI noise and far fewer real outcomes. The job, for anyone building or running a business through this, is to keep testing, keep your judgement, and not offload your thinking while you use the tool to lift your output. No handbook is coming. We are writing it as we go.

Watch the video:

youtu.be/tT_G8v7VAvg

If running a business through this kind of uncertainty is on your plate, I also wrote The CEO Operating System, the framework I use to run three companies without burning out. It is free: axelmolist.com/ceo-os.

Got a different read, or a story of your own about how this is landing on your team? Hit reply. I read every email.

Thanks,
Axel.

Ten months ago, one of my senior backend engineers, Vitaliy, left three comments on a piece of AI-generated code I'd pushed into one of our repos. He called the file awful. Said the logic was in the wrong place. Said a switch case belonged in a constants file. He wasn't joking. He was a senior engineer doing his job, and he genuinely thought the code was bad.

This week, the same Vitaliy sent me an unprompted 8-page proposal to build our first agentic AI coding system at We UC. And in his Slack message, he wrote the line that's stuck with me since: "those MRs you used to send me that gave me plenty to comment on." Winking emoji at the end.

He named the moment he was mocking. He updated his view when the evidence changed. He was the loudest sceptic on my team. Now he's the one leading the build.

What flipped in those ten months is the answer to a question I keep getting asked: why are some engineers leaning hard into AI coding while others are getting actively angry about it? This post is about what the real fight is, why it isn't about the code, and the two paths I see open from here.

A Scale, Not a Divide

AI coding usually gets framed as two camps. Hand coders versus AI-native coders. Real engineers versus vibe coders. Old school versus new school.

That framing is wrong. It's a scale, not a divide.

At one end you've got fully AI-native engineers. They write PRDs and specs in plain English and let AI handle the implementation, the review, the tests. Their craft has moved from typing to specifying, architecting and managing agents.

At the other end, the 100% hand coders. Every line typed. Every character earned. Their craft is in their fingers, along with the discipline and pride they built over a career. To them, AI-written code isn't real work.

Most of the industry sits somewhere in between. The question isn't which camp you're in. It's which way you're leaning, and how fast.

The data backs the direction. Google, at Cloud Next this year, said 75% of their new code is AI-generated. Microsoft puts the number at 20 to 30%. Anthropic's Claude Code team is at pretty much 100%. "AI-generated" means different things at different companies, but the trend is unambiguous: every major engineering organisation is moving down the scale, fast.

The developer side is more interesting. The Stack Overflow 2025 survey showed 84% of engineers use AI tools or plan to. But trust dropped 11 points year on year, to 29%. The gap between use and trust is exactly where the anger lives.

What the Anger Is Really About

When you've spent 10 or 15 years typing code, you've built a self-image around the act of typing. Your reflexes, your shortcuts, the way you think while you write. All of it tuned to the keyboard.

If I walk in and say "stop typing code, write a spec instead", I'm not asking you to learn a new tool. I'm asking you to change who you are. That's hard for anyone.

MIT Technology Review published a piece at the end of last year with a line from an engineer called Luciano Nooijen that landed harder than any data point I've seen. He'd been leaning on AI tools heavily at work, tried to build a side project without them, and realised he'd lost something: "I was feeling so stupid because things that used to be instinct became manual, sometimes even cumbersome."

Feeling stupid. That's what this transition does to the muscle memory, and to the self-image built on it.

The technical term for what happens next is cognitive dissonance. Your identity says one thing. The world says another. You can update your self-image, which is painful and slow and requires humility. Or you can reject the evidence, which is easier and gives immediate relief, at the cost of being isolated over time. Most people pick the second one first.

The cleanest example I've seen came in a comment on one of my own videos: "He is completely mistaken. Specification-driven development is not the future, but I won't explain why." That last bit is the tell. There's no argument underneath. There's just discomfort.

And it goes deeper than psychology. Your nervous system, biologically, can't tell the difference between transformation and threat. When something familiar starts ending, your body reacts the way it would to physical danger.

The anger isn't malice. It's grief, dressed up as opinion.

Who Makes the Turn

After three years of watching this inside my own team, three things predict who makes the turn.

One, the tools have got dramatically better in a short space of time. Engineers who tested AI coding in early 2024 and concluded it wasn't ready were not wrong then. The code often was bad. But if you haven't re-tested in the last three months, your opinion is out of date.

Two, identity. The engineers who adapted earliest on my team weren't the youngest or the smartest. They were the ones whose self-image was less tied to the typing. The ones who already saw themselves as problem solvers first, code writers second.

Three, humility. The technical version, not the soft version. The willingness to be a beginner again at something hard. Most senior engineers got senior by being the smartest person in the room. AI coding makes them wrong, on repeat, until they're not. Getting better feels like getting worse, at first. The ones who could sit with that made the turn. The ones who couldn't, didn't.

The Pattern That Keeps Repeating

None of this is new. Every digital transformation in living memory has followed the same shape.

I watched it up close once before. My father ran a photography business. His craft was developing the film, working with the chemicals, exposing prints in the darkroom. Digital came. He stuck with what he knew for a while because he was good at the old craft. But his competitors switched. They got faster. They started winning more work. So one day he made the call. Renewed his lab, bought a minilab, and within a month he was fully converted. The decision took him years. The execution took weeks.

Today most professional photography is digital. Film still exists, in a respected niche. Same with music. Vinyl passed a billion dollars in US revenue last year for the first time since 1983. Real niche, real money, not how the mainstream listens.

The old craft doesn't die. It becomes a respected niche. Mainstream production moves on.

The legends of hand coding agree. John Carmack, who founded id Software and shipped Quake and Doom, posted earlier this year: "Coding was never the source of value, and people shouldn't get overly attached to it. Problem solving is the core skill."

And DHH, the creator of Ruby on Rails and a vocal AI sceptic for years, summer last year: "I can literally feel competence draining out of my fingers." Six months later, January this year: "Any time I have to type precise syntax by hand now feels like such a tedious chore. Programming is still fun, probably more fun."

From "competence draining" to "tedious chore" in six months. The same pattern I watched with Vitaliy, just on a bigger stage.

Two Honourable Paths

Here's where I think we're heading, with the usual caveat that these are estimates, not guarantees.

Within a year, I think 90% of new production code will be written by AI, with humans writing specs, reviewing plans and approving the work. Within three years, hand coding will be considered a niche craft. Beloved. Respected. Real. But not how mainstream production happens.

I could be wrong on the timeline. Anthropic's CEO Dario said in March last year that we'd hit 90% AI-written code across the industry in three to six months, and the latest estimates put us at around 42%. Predictions miss. The direction doesn't.

So I see two paths forward.

Path one. Adapt. Learn to write specs in plain English. Get comfortable letting AI write the implementation while you architect, review and manage. Find the new craft inside the new workflow. This is where mainstream production work is heading.

Path two. Choose the niche. If your love is the keyboard, the typing, the craft of writing every line yourself, that is valid. There's a place for you. Just understand that the place is getting smaller, and your value proposition has to get sharper. Film photography is a respected niche. Vinyl is a respected niche. So can hand coding be.

Both paths are honourable. What doesn't work is the third path. Denial. Insisting the change isn't happening, attacking the people reporting it, pretending the world will rewind. That position has never won in any technology transition.

Pick Your Path

Vitaliy chose path one. Ten months ago he was the loudest sceptic on the team. This week he's the one leading the build. He had the humility to update his view when the evidence shifted, and he's a better engineer for it.

If you're a CEO or operator looking at your own dev team and seeing the same split, don't try to win the argument by force. Outlast it. Keep showing the work. Let the people they respect online start changing their tune too. The wall cracks slower than you'd like, but it cracks.

And if you're an engineer reading this and you feel the anger rising, be honest with yourself about which path you actually want. Either of them is real. Neither requires denial.

Pick your path. Just don't stand in the middle, defensive and angry at the people who picked.

Watch the video:

If running a business through the AI transition is on your plate, I also wrote The CEO Operating System, the framework I use to run multiple companies without burning out. It's free. axelmolist.com/ceo-os

Got thoughts, pushback, or a story of your own on this? Hit reply. I read every email.

Thanks,
Axel.

I've spent four years and £1.5 million building a SaaS, and almost nobody knows it exists.

That sentence took me longer to admit than it should have.

I'm Axel. I founded circle.cloud in 2015, a UK telecoms company that grew to over 100 people without outside investment. I now run We UC as CEO, the unified communications SaaS we've spent four years building. I've shipped software before. I've sold software before. I just hadn't, until now, sold software the way software actually needs to be sold in 2026.

Here's what I got wrong, and the plan I'm running to fix it.

How I Learned Distribution

I built circle.cloud one phone call at a time.

In 2015 I was working out of a spare bedroom with a desk phone, a laptop, and a CRM full of cold leads. Two hundred calls a day. I'd ring through the list until someone agreed to a meeting. Drive out. In-person demo. Close. Install. Repeat.

Over the next few years I hired people to run the same process at scale. By the time we started building We UC in 2021, we had around 25 people on the phones, nine field salespeople sitting demos every day, and nine engineers installing phone systems on site. A conveyor belt with humans at every stage.

That model works. It still works for us today. circle.cloud is heading toward 100 installs a month right now using the same playbook.

It works because the unit economics support it. The average telecoms deal is big enough to pay for the cold call, the travel, the demo, the install, the engineer, the account manager. The customer wants someone holding their hand. They want a face in the room. They want an engineer on site in their comms cupboard.

High-touch distribution isn't outdated. It's the right tool for the right unit economics.

Why That Engine Doesn't Transfer

We UC is a different animal.

It's a SaaS. The plan is to sell it to founders, operators, IT directors, COOs, CTOs - the kind of tech-savvy operator who scrolls through the internet at two in the morning, finds a product that looks well made, signs up there and then, and onboards their team without ever talking to a salesperson.

A SaaS product priced like a meal out can't pay for a cold call. It can't pay for travel. It can't pay for an engineer on site. The maths just don't work.

So it needs a completely different motion. Different process, different team, different metrics, different content, different acquisition channels.

I Did It Backwards

The traditional advice for a new founder is to validate the market first. Build a landing page. Run some ads. Pull together a small audience. Sign up a waitlist. Then, if the interest is real, build the product.

I did it the other way around. Four years and £1.5M of investment into the build before I had a landing page worth driving traffic to. No waitlist. No email list. No audience.

I'm not proud of that. But I want to be honest about it, because there's a specific reason it happened.

I knew how to build software. I had a 20-person dev team and a decade of muscle memory running a business that ships things. Building was the part I knew how to do, so I kept doing it. Marketing, especially the modern AI-augmented kind, was new. New is uncomfortable. The natural pull is to retreat into the thing you already know.

That's the trap. Building feels like progress. Building is comfortable. And when you're a founder who's good at building, the work that actually changes the trajectory of the business gets postponed.

What broke me out of it was sitting back and asking why the engine that built circle.cloud doesn't fit a SaaS. Once that became clear, the work I'd been avoiding became unavoidable.

The Modern Way to Go to Market

Five years ago, if you'd asked me how to launch a software product, I'd have said hire telemarketers if the unit economics allow it, and run a heavy SEO play if they don't. That was the orthodoxy.

It isn't anymore.

The people I look at now run a different motion entirely. Jordan Crawford and his Blueprint GTM team are the cleanest example. Audience-first. Content-led. AI-augmented. They aren't optimising for cold outreach. They're building media properties around the product, and the product gets shipped into the audience that's already paying attention.

Another company that puts this into focus for me is Kinzo (kinzo.ai). Two founders with a big exit behind them, now building an AI inbox assistant. Roughly 60% of their team is content and marketing. The other 40% is engineering and go-to-market. That ratio used to be the inverse for any sane software company. It isn't anymore.

At We UC today, the split is roughly 99% product and 1% marketing. That has to change.

The Plan, In Layers

Here's how I'm thinking about it. Four layers, with the first one as the foundation everything else sits on.

Layer One: Personal Brand.
The thing you're reading right now. I started writing in public and showing up on YouTube and LinkedIn in November 2024. I'm six months in. Growth is slow. Engagement is slow. Some days it feels like nobody's listening.

I'm doing it anyway because people buy from people. If a founder or operator finds me through this content and trusts how I think, the product gets to skip the hardest part of a cold sale: building trust from zero. The personal brand isn't the marketing. It's the foundation underneath the marketing.

Layer Two: Product and Company Content.
Once the SaaS is publicly live, we run a content engine for the product itself. Blog posts at volume. LinkedIn, YouTube, Instagram. Product demos. Carousels and visual artefacts created with AI tools like Claude Design. A mountain of content, AI-assisted but with a high quality bar set by humans.

The plan is funnel-shaped. Top-of-funnel content is informational, educational, broad. Mid-funnel content is product-led: what the product does, why we built it the way we did, what changes for the buyer. Bottom-of-funnel content is the call to action: start a trial, join the waitlist, talk to us.

Layer Three: Paid Media.
Take the best-performing organic content and sponsor it. Run paid social experiments. Use Google for the high-intent searches. Paid is amplification, not replacement. We only put money behind content that's already proving itself organically.

Layer Four: PR.
A structured PR push around launch. Embargoed press releases sent to around 150 publications, trade press, business press, telecoms press. We'll either engage a PR agency or run it ourselves to keep costs down. The press releases go out under embargo so the coverage all lands on launch day. A second wave later in the year, with a circle.cloud customer who's selected We UC as their communications platform.

Personal brand first. Product content second. Paid amplification third. PR around the launch moments.

The Edge I Already Have

There is one thing I have that most SaaS founders don't.

circle.cloud has around 2,500 customers on the existing phone system, supporting over 10,000 users. We're now migrating them onto We UC. So far we've moved three customers across, and about 150 users are now live on the new platform. Each migration gives us real feedback from real businesses paying real money.

Most SaaS launches don't have that. They go live with hope and a waitlist. We go live with a product that's already been battle-tested by paying UK businesses.

That's the edge on the product side. The SaaS will be hardened before it's publicly available.

What I don't have is an audience for the SaaS itself. That, I'm building from zero.

The Rebrand

There's one detail I haven't mentioned. We UC isn't the name we'll launch the SaaS under.

"UC" stands for unified communications. Inside the telecoms industry, that's table-stakes vocabulary. Outside it, nobody knows what it means. Buyers guess "universal communications" or assume it's part of the company name. Every first impression starts with a small piece of confusion. The label also undersells the product, because what we're building is a modern, AI-augmented, keyboard-first communications platform, not a category-standard UC tool.

So the parent company stays as We UC Ltd. The product gets a new name, marketed direct to operators.

The criteria are tight. Six letters or fewer. Communications at its root, ideally implying voice or conversation without saying it literally. International, not English-bound. Friendly to the ear, no hard Xs. Available, meaning trademark-clearable and domain-buyable. And distinctive enough that we don't sound like the rest of the category.

Every name we've liked has been trademarked. Every name that clears the legal check doesn't quite sound right. It's harder than I expected. We'll land on it, and the moment we do I'll show the rebrand and the new website here.

If you've got an idea, I'm taking suggestions. Drop them in the comments under the video.

The Mindset Shift

Underneath all of this is a transition I'm still working through.

For ten years I've been the founder of a services business. The mental model for growth is staffing the conveyor belt: more callers, more field reps, more engineers, more installs. Capacity scales linearly with headcount. Revenue scales with capacity. You optimise the funnel.

A product business doesn't grow that way. You don't scale a SaaS by hiring more salespeople, because the unit economics don't carry the cost. You scale it by building an audience, shipping the product into that audience, and compounding both at the same time.

That's an entirely different game. New muscles. New ratios. New ways of measuring whether the week was a good one.

I'm excited about it, even though I'm new at it. I've always found my way through a thing once I've decided to obsess over it. This is the latest obsession.

If you're building a SaaS in 2026, this is the order I'd run it in. Audience first, then product, then paid amplification of what works. Money doesn't get you organic growth. The list compounds slowly. You can't buy it.

It's the work I'm doing now, in public.

Watch the video:

If running a software business in the AI era is on your plate, I wrote The CEO's Operating System, the free framework I use to run circle.cloud and build We UC. axelmolist.com/ceo-os

If you're a CEO or CTO with engineers who learned to code before AI, and you can feel that AI coding should be transforming your business but it isn't, this is for you.

The tools aren't the problem. The problem is the people. Specifically, the engineers who built their craft before AI was useful. The ones your business actually runs on.

I've been a fanatic of AI coding since the month ChatGPT shipped. For most of the three years since, my dev team at We UC pushed back. Hard. They called the code bad. They mocked everything I built with AI. I've still got the Slack messages.

Then six months ago, the wall started to crack.

The December 2022 MySQL Moment

Let me take you back to the moment I knew everything was about to change.

December 2022. I'm at my laptop trying to build a dashboard to display phone system data. I'm not a developer. Never have been. But the data lived inside a MySQL database, and to get it into our BI dashboard I had to write a fair amount of SQL. Selects, joins, all of that.

I'd spent months grinding through Stack Overflow. Asked friends who knew MySQL. Always hit a wall.

Then ChatGPT came out. I described the query I wanted in plain English. It wrote the query. It worked. First try. Then I asked it for a script. The script worked too.

Within six months, I'd built a working prototype of a full app I'd been wanting for years. I sat there, blown away. And I remember thinking, this is the new way of writing code. The world is never going to be the same again.

So in early 2023, I went to my dev team and said, you need to start using this. This is the future. Get on it.

Three Years of No

Every single one of them pushed back.

The objections came in waves. You can't trust it. It hallucinates. It writes ugly code. It writes bad code, because it's been trained on the worst code on the internet. It can't fit our app in its context window. It will suggest packages that are out of date because of the training cutoff window, so it will write code with known vulnerabilities.

Every time I built something with AI, an internal tool, a script, anything, the team picked it apart. "Why is this file so long? Why did it pass these arguments? This is way more complicated than it needs to be. Look how I can simplify this function."

That last line, I heard a hundred times. "Look how I can simplify this function."

And underneath it, the unspoken word was always the same. AI coding doesn't work, Axel. Stop dreaming.

It took me two years to realise the resistance wasn't really about the code. It was about identity.

If you've spent years building muscle memory for what good code looks like, and someone walks in saying "let the machine write it," you don't hear "use a new tool." You hear "your craft no longer matters." That's the real reason. Not hallucinations. Identity.

I kept pushing. They kept pushing back. For three years.

The First Crack

Six months ago, things started to shift. I noticed it first in the small things.

We needed a marketing automation script. One of our mid-level developers, the same person who'd been mocking my AI scripts twelve months earlier, opened Claude Code, wrote a thorough prompt, and the script came out clean. Worked first try. He didn't tell me he'd used AI. I had to ask.

Around the same time, one of our senior backend developers, the one who'd called AI coding unreliable for the previous two years, started insisting on detailed technical specs for every new feature. Working with our PM on the PRD first, then writing the spec sheet himself. As if that's just how you do it now.

Why? Because once we have a good spec, AI can handle far more of the implementation than before. We move reliably faster.

I asked him why we couldn't just let AI write all of We UC. And he said something that stuck with me.

"We UC has been built over four years by different people, without a clearly defined coding standard from day one. So whenever AI looks at our code, it sees five different opinions about the right way to do things. Of course it gets confused."

That was honest. And he was right.

AI Coding Exposes, It Doesn't Fix

Here's the reframe that took me three years to see. AI coding doesn't fix bad engineering practices. It exposes them. And then it forces you to fix them properly.

The problem wasn't AI. We had never written down what good code should look like inside our company. So now we have. We're building a comprehensive coding standards document. We're refactoring our backend services into a monorepo so everything lives in one place: code, docs, tests. Where any developer, or any AI, can navigate it.

We had also been under-documenting our architecture decisions for years. The why behind choices, not just the what. So when we feed our codebase into AI now, we have something to feed in beyond the raw code. Without documented decisions, the AI was filling in the gaps with its own guesses. That's where the problems were starting.

We've improved our security stack too. Docker hardened images for the attack surface. Context7 MCP inside Claude Code so the AI uses the latest version of every package, not whatever was current at its training cutoff. Aikido running for the last month, scanning containers and deployments for vulnerabilities.

But none of this is really about AI. It's about wanting to write good code as an organisation. Bad packages get shipped by humans too. Insecure code gets written by humans too. The question isn't "is AI safe?" The question is, are we set up to produce good code, regardless of who or what wrote it?

We've started treating AI like another developer on the team. I think that's the right approach.

Permission from Skeptics

Why did my team finally come round? Honestly, three things hit at once.

I'd been hammering the same drum for three years. They were tired of hearing it from me.

Claude Code itself got dramatically better. The models stepped up significantly over the last twelve months.

And the third one, which surprised me. The developers my team follows online started talking about the tools seriously. Not as evangelists. As skeptics. ThePrimeagen, the YouTuber my team trusts most, is still cautious about AI coding. But cautious is different from dismissive. When the practitioners my team respects moved from "this is hype" to "this is a real tool with real trade-offs," that gave my team permission to do the same.

They didn't get converted by hype. They got permission from skeptics.

Sometimes you don't win the argument. You outlast it. And you let other people make it for you.

Two Generations of Developer

The process of converting my team has made me think about something much bigger.

There's a fork in the road in software development right now. Two generations of developer. One shaped before AI existed. One being shaped now. The gap between them is going to define the next decade.

On one side: developers who learned to code before AI was useful. That's my team and probably yours. They learned the syntax. They learned languages by typing them out, character by character. Their craft is in their fingers.

I call them hand coder software engineers. Or hand coders, for short.

On the other side: developers learning to build software now, with AI in the editor from day one. They won't memorise JavaScript or Python or Rust syntax, because they don't need to. AI handles that. What they will learn is the concepts. The architecture. Computer science principles. How memory gets allocated. How a system scales.

I call them AI native software engineers. They become managers of agents. They define the system, write the spec, set a fleet of agents loose, review the output. They're responsible for what the agents produce. But they don't write the code by hand. They don't need to.

I think I'm an early version of how this works. I never learned to code in the syntax sense. I learned to build software with AI from the start. I architect the system, write the spec, pass it to Claude Code, then test the output.

That's how I built The Scheduler. It started as an internal tool at one of my other companies. Now it's a fully working product, in production, used by real customers. Not a demo. I didn't write a single line by hand. I built it the way I think an AI native software engineer is going to be building everything.

I've done it twice. Before The Scheduler I built a search tool that pulled customer data from across our CRM, our phone system, and several internal servers. Two days. Working app. I'm not a developer.

If you're hiring a junior developer in two years time, the people applying for those jobs are going to look very different from the hand coders you've hired before. We're going to be hiring AI native software engineers. People who don't need to know how to write code in the syntax sense, but who absolutely know how to build software. Real software. Production grade.

What This Means If You're Hiring

If you're a CEO or CTO trying to push AI coding into a team of hand coders, keep pushing. Be patient. Pick AI native engineers when you hire.

Most of the rest will come around when the evidence is loud enough. Probably faster if it's coming from someone other than you.

And if you're where I was a year ago, don't be discouraged. Their mindset will change. Their work will change. Mine did.

A year ago they called it bad code. Today they're using it daily, in production. The argument resolves itself. If you outlast it.

Watch the video:

Last week I got on a call with a customer who'd built a working app for his business in a week. When I asked him what database it was running on, he didn't know.

That's vibe coding.

And there's a line, currently invisible to most people, between vibe coding and what I think of as professional AI coding. Same tools on both sides. The code can look identical on the surface. The difference doesn't show up until something breaks. And by then, it's usually too late.

I'm running a 20-person dev team at We UC, our unified communications platform. I founded circle.cloud, the telecoms business behind it. I spend most of my days either building software with AI or watching my customers try to do the same, and what I'm seeing is a line forming between two completely different disciplines. One side is genuinely transformative for small businesses. The other side is a time bomb waiting to go off in production.

This post is about where that line sits, and which side of it your business needs to be on.

A Customer Who Built an App in a Week

Back to that phone call.

The guy on the other end of the video call runs a commercial refurbishment business. He fits out schools, hospitals and offices. His biggest operational headache was managing contractors. Sending out jobs, collecting quotes, tracking documents. The off-the-shelf tools were either too generic or required four separate products duct-taped together.

So he opened Claude Code and tried to build the thing himself.

He isn't a developer. His background is in web design, so he knows Figma and Photoshop. He knows what good user experience looks like. He doesn't know software engineering.

A week later, he had a working app; with login, contractor onboarding, job offers & bidding for his contractors, document uploads, messaging, everything he needed for a v1.

That's when I asked the question.

"What database are you using?"

He paused. Then logged into Vercel to check. Came back and said Supabase.

That's pure vibe coding. He'd built an app, and he had no concern about the architecture or the infrastructure. The AI was handling all of it, and for his internal use case, that was fine. It's brilliant, in fact. Five years ago, this person couldn't have built a single screen of that app, let alone the whole thing. Now he's solving a real operational problem in his own business in a week.

But if he ever opens that app to real customers, or starts holding data that matters, he's going to find a line he didn't know was there.

The Line, Explained

Vibe coding is the practice of describing what you want and accepting what the AI gives you. The AI picks the database and the infrastructure. The person vibing doesn't need to know any of it. For an internal tool sitting behind a corporate network or Cloudflare Access, that's a perfectly reasonable trade-off.

Professional AI coding is something else. The AI still writes the code, but before it writes a single line, three things have already happened.

1. A Detailed PRD and Technical Spec

Not an agile user story on a Post-it note. A proper product requirements document, paired with a technical spec. It explains, in the least ambiguous way possible, what the software does, why it needs to exist, how it integrates with other systems, what it doesn't do, and every edge case you can think of.

The best test I can think of is this: if you handed those documents to three separate engineers in isolation, they should all build roughly the same thing. If the spec leaves more room for interpretation than that, it isn't tight enough.

2. A Human Engineer Has Made the Architectural Decisions

The db, data structure, API endpoints, security, whether there's a queueing system or message bus like RabbitMQ or Apache Kafka in the mix, etc.

These aren't handed off to the AI agent. They're handled by a professional who understands what those choices will cost six to twelve months down the line, when your customer base has grown, the product has evolved, and a design decision made in week one is suddenly the bottleneck.

3. The AI Confirms Its Plan Before It Writes Anything

You feed in your docs, and instead of letting the model start coding straight away, you ask it to come back with its implementation plan first. It should return something like: "Here's what I understood from your request, and here's what I'm going to build." A human then reads that plan and confirms it's correct before any code is generated.

The AI is the muscle. The human is the brain.

That's the line. Everything else is a consequence of it.

Same AI tools on both sides. The code may even look similar at first glance. The difference is invisible on the surface until something breaks.

What Professional AI Coding Looks Like in Practice

At We UC, we're in the middle of building a serious upgrade to our analytics module. Custom dashboards, with the option to pull data from external sources. Effectively a mini BI tool built into the platform. Because of what we've learned, we're approaching this one very differently from how we've built things before.

First, we've written a properly detailed PRD. What the module does, why it exists, how it integrates, what it explicitly doesn't do, every edge case.

Second, our lead software architect is writing the technical specification. Data models, API contracts, state diagrams, error handling. The things AI coding tools aren't qualified to decide on their own.

Third, we'll use Claude Code to actually generate the implementation. With the architecture documented and the spec unambiguous, the AI should be able to handle that part with discipline.

There's a fourth idea I want to test as part of this project. I've been calling it an "anti-ambiguity agent". The idea is simple: we feed our documentation into a sequence of agents whose job is to look for ambiguity in the spec. Anything unclear comes back with a short list of possible interpretations, and our architect either picks one or proposes a better alternative. The output is a specification so unambiguous that whatever writes the code has no room for doubt.

It's slower to start than vibe coding. The PRD takes time. The spec takes time. The back-and-forth with the architect takes time. But once the foundation is in place, the AI moves fast, and the code that comes out is something we can actually deploy to paying customers.

The Wave Is Already Hitting Small Businesses

The other phone call I had recently was with a dentist. Not my dentist, a customer of ours. He owns two dental practices, but between them they do the patient volume of five, because he's automated most of the usual admin away. His whole thing is business efficiency through technology.

And he'd hit the same problem as the refurb guy. He wanted a single piece of software that did exactly what his practices needed. The only off-the-shelf answer was to stitch together four or five different subscriptions.

So instead, he built the thing himself. A CRM with lead tracking and marketing. A finance dashboard that integrates with Dentally. A built-in learning management system. All in one platform, running production-quality code. He isn't doing it solo. He hired a developer with about ten years of experience who's now all-in with AI coding. Together they wrote the documentation first, then fed it into Claude Code. Eight weeks later, they've got a working prototype, and he's planning to launch it as a SaaS to other dental practices.

This isn't a one-off. Right now at We UC, we've got three open integration requests from customers who've either built their own custom CRM from scratch or are in the middle of doing it. Three, just from our own customer base. People who, a few years ago, would never have imagined themselves building software at all.

This is the thing I want small business owners and founders to understand. It's happening everywhere, behind the scenes, inside ordinary SMBs. Every one of those founders is going to run straight into the vibe-versus-professional line at some point. Usually the moment they sign up real customers, or something breaks under load, or they need to add a feature the prototype can't support.

Where This Fits in the Bigger Picture

There's a useful framework from Dan Shapiro that maps this territory. He describes five levels of AI coding, running from "spicy autocomplete" at level zero to what he calls the "dark factory" at level five, where software is generated fully autonomously from specifications with no human in the writing loop. A company called StrongDM claims to be operating at level five already. They only hire developers who don't write code.

Most dev teams I talk to are sitting at level zero or one without realising it. Most vibe coders, meanwhile, are actually operating somewhere around level four, writing specifications in plain English and directing the AI without ever touching the code. The gap isn't the level of autonomy. The gap is engineering discipline.

Know Which Side You Need to Be On

I'm not anti-vibe-coding. I vibe code things on the side for fun. I love it. It's a genuinely useful skill for prototypes, internal tools and low-stakes builds.

But if your business is shipping software to real customers, or holding data that matters, or running on the assumption that more users will join next month, vibe coding alone will eventually bite you. The foundation simply isn't built for the weight you're going to put on it.

The businesses that win with AI coding over the next few years will be the ones that recognise this line early, and plan the transition from vibe coding to professional AI coding before it's forced on them by an outage or a security incident. That transition is exactly what we're working through at We UC, piece by piece, starting with the analytics module.

Vibe coding is for prototypes. Professional AI coding is for production.

The line is almost invisible right now. The founders who learn to see it will ship better software, for longer.

Be one of them.

The video version of this drops on YouTube tomorrow. Same content, different format. If you're not subscribed to the channel already, that's where to find it: youtube.com/@axelmolist.

If running a business through the AI transition is on your plate, I also wrote The CEO Operating System, the framework I use to run multiple companies without burning out. It's free. axelmolist.com/ceo-os

Got thoughts, pushback, or a story of your own on this? Hit reply. I read every email.

Thanks,

Axel.

If your business builds software - even a little - your dev team is changing faster than you realise. Not the people. The work itself.

I'm running a 20-person team building We UC, our unified communications platform. And over the last six months, I've watched something strange happen. The bottleneck in software development isn't where it used to be. It's moved.

And if you're hiring developers right now - or trying to figure out why your team isn't shipping faster despite using AI tools - you need to understand this shift.

This is not just for tech CEOs. If you have two developers and a Claude Code subscription, this applies to you. If you run a services business that hired a dev to build an internal tool, this applies to you. If you are a founder vibe-coding your own MVP in Replit, Lovable or Cursor, this applies to you. Anywhere software is being built, the shape of the work has moved.

How Software Development Used to Work

Here's how it worked when I started building We UC.

You hired developers to write code. You measured their output in lines committed, features shipped, story points closed. Code review was the quality gate. If it passed review, it shipped.

The craft was the code itself.

But now with We UC, something fundamental shifted. We started using AI coding tools - Claude Code primarily, with some of the team using Cursor. And the entire rhythm broke.

The code started arriving faster than we could process it. Therefore the job changed.

The Question That Started Everything

Three months ago, one of my senior engineers came to me visibly frustrated. He'd spent two days reviewing pull requests from a junior developer using Claude Code. Thousands of lines. Feature worked perfectly. Tests passed.

But he looked at me and said: "I didn't actually read the code. I couldn't. There was too much of it. What's my job now?"

That question landed. Because I'd been feeling the same thing but couldn't name it.

Around the same time, I came across findings from a Thoughtworks retreat - senior engineering leaders from the biggest tech companies, brought together to figure out what happens when AI writes the code. They didn't leave with answers. They left with a map of fault lines. Places where traditional software development is cracking right now.

And reading through it felt like reading my own notes from building We UC.

Where the Work Migrated

Here's what nobody tells you about AI writing code: the engineering quality doesn't vanish. It just moves upstream.

Think about a normal user story: "As a user, I want to upload a photo."

Your developers know what that means. JPEG, PNG, reasonable file size, progress bar. Cultural context fills in the gaps automatically.

But an AI doesn't have that context.

The 50,000 Email Problem

We learned this at We UC the hard way. One of our developers asked an agent to build a notification system. Simple request. The agent built it. Worked beautifully in testing.

Went to production. Started sending 50,000 emails in three minutes.

Because there was no rate limit in the specification.

The engineering rigour we used to apply after the code was written now has to happen before a single line exists.

We've gone back to techniques that felt dead - structured requirements, state machines, decision tables. The kind of formal documentation agile was supposed to kill.

But here's the thing - that rigour makes the AI incredibly effective. When we feed an agent a state machine showing exactly what states are allowed and what transitions can happen, the code it generates is almost always correct.

The specification became the product. The code? Disposable.

The code died. The spec won.

That is the shift. Everything else is a consequence of it.

If we have a perfect test suite and decide to rewrite our backend from Python to Rust, we just feed the tests to an agent and say: make these pass.

This is a complete inversion of how software used to be built.

The Layer Nobody Named Yet

There's a layer of work emerging in my team that doesn't have a name yet. It sits between writing code and shipping to production.

I call it supervisory work.

Breaking problems into agent-sized chunks. Knowing when to let the agent run and when to step in. Fixing output not by rewriting code but by adjusting the prompt or the constraints.

And here's what surprised me. My team split into two groups.

Group one: the seniors who understand the whole system. They're drowning. The juniors and agents generate code at 10x speed, but code doesn't ship itself. It needs architectural review. It needs to fit legacy systems. It needs to be unblocked. My senior engineers became traffic controllers, too busy reviewing AI output to actually build anything themselves.

Group two: the juniors who just started. They're thriving. No muscle memory telling them to write code a certain way. They treat the AI as a teammate, not a threat to their identity.

And the net-negative phase is gone. We used to hire a junior and they'd drain productivity for six months whilst learning where everything is. Now? A junior with Claude Code ships useful code in week one.

The Danger Zone: Mid-Level Engineers

But there's a danger zone nobody's talking about. The mid-level engineers. Three to five years of experience. Just enough skill to be set in their ways. Not enough to be true architects.

Retraining them - teaching them to supervise agents instead of writing syntax - that's the hardest organisational challenge we're facing as a company.

So here's what I'm learning as a CEO hiring developers. The job description just changed. If you're looking for people who write code fast, you're hiring for the wrong skill.

You need people who can architect systems, write unambiguous specifications, and supervise non-deterministic agents. That's a completely different person.

What Breaks: The Tribal Knowledge Problem

Last month, our server went down at 2am. Error code 503: Service unavailable.

On-call engineer - sharp, capable - asked an AI assistant for help. AI read the documentation. Said: restart the server.

He did. Crashed again five minutes later. Restarted. Crashed. Restarted. Crashed.

By the time he escalated to me, we'd restarted the server six times.

I looked at the logs for 30 seconds and knew exactly what it was. Database connection pool was full because a marketing batch job was running.

That's not documented anywhere. It's tribal knowledge. Lived experience.

An AI doesn't have that. It sees 503, reads the manual, restarts the server. Over and over.

This is why all the hype about "self-healing systems" is rubbish right now. To make an agent effective during an outage, you need to build what the Thoughtworks retreat called an "agent subconscious" - a knowledge graph of every incident, every weird edge case, every bit of undocumented institutional knowledge that lives in your senior engineers' heads.

We're starting to build that at We UC. Every time something breaks, we document not just what happened but why someone with experience would know what to do.

The Yes-Man Problem

But there's another problem. AI agents are trained to be helpful. They're yes-men.

During an incident, you don't want a yes-man. You want someone to challenge your assumptions. One engineer at the Thoughtworks retreat suggested we need "angry agents" - specifically prompted to poke holes in your theory. Because otherwise the human and the agent will just agree with each other whilst the server burns.

Here's the point. If your business is betting on AI to make your software team faster, you need the prerequisites first.

Documentation that actually captures how things work. Seniors who can architect, not just code. And a system for preserving institutional knowledge before the AI makes everyone forget how things actually work.

The Graphics Card Analogy

So here's what I've learned running a dev team in the age of AI agents. The work isn't disappearing. It's moving from execution to supervision.

Think about graphics programming in 1992. Engineers hand-coded the maths to draw a single polygon on the screen. Calculating exact pixel positions. By 1994, the GPU arrived. Hardware did the polygons.

If you insisted on hand-coding polygons in 1995, you weren't a specialist. You were obsolete.

The engineers who survived became lighting engineers, animators, physics programmers. They weren't telling the computer how to draw a triangle. They were telling it how light reflects off a wet street.

Nobody hand-codes polygons anymore. We all work in game engines.

Software engineering is hitting that exact moment right now.

What to Look for When Hiring

So if you're hiring developers, here's what to look for. Not coding skills. Architectural thinking. Judgement under uncertainty.

Can they write a specification tight enough that an AI can't misinterpret it?

Can they design a test suite that catches hallucinations before production?

Can they debug a system they didn't personally write?

At We UC, that's what we hire for now.

The Cognitive Debt Problem

And here's what keeps me up at night. For decades, code review wasn't just about catching bugs. It was how developers learned the system. If agents write all the code and your team stops reading it, they become strangers in their own codebase.

When something breaks at 3am, they're staring at code written by a machine, trying to reverse-engineer the logic whilst your customers are screaming.

We're building tools for what we call continuous comprehension. AI that summarises architectural changes. Weekly sessions where the team architects together even though agents write the code.

Because you have to schedule time to understand your own software now. It won't happen naturally anymore. The speed of AI demands it.

What This Means If Software Is Built Anywhere in Your Business

So look, if software is being built anywhere in your business - or you are thinking about starting - the ground is shifting.

Your seniors are drowning in review. Your juniors are thriving with AI. Your mid-levels don't know which way to jump.

The companies that win will be the ones that see this shift coming and retrain before it's too late.

I'm not pretending I have all the answers. We're figuring this out in real time at We UC. Making mistakes. Adjusting. Learning what works and what doesn't when you're leading a dev team through this transition.

But one thing is clear: the best founders I know aren't panicking. They're adapting.

Be one of them.

If running a business through the AI transition is on your plate, I wrote The CEO Operating System - the framework I use to run multiple companies without burning out. It is free. axelmolist.com/ceo-os

I am in Spain right now, spending a few days with the family. And when I get time like this - away from the day-to-day, away from the noise - I tend to reflect.

I thought I would put together a list of my fundamentals. The guiding principles I use for business and life in general. Not because I have it all figured out. I definitely do not. But because I think there is value in hearing how other people think about these things. Maybe some of it resonates. Maybe it helps you put into words something you already felt but had not formalised yet.

A bit of context if this is your first time here. My name is Axel Molist Cordina. I am originally from Spain, and I have been living in the UK since 2008. I founded a telecoms services company called circle.cloud - built it from scratch to about 140 people - and I now run a telecoms software company called We UC, which we are in the process of launching as a SaaS product. So I have been building for over a decade. Everything I am about to share comes from that experience.

These principles are not for everyone. They are what works for me. But if the rationale behind any of them feels right, then perhaps they will be useful for you too.

1. Love What You Do

This is the foundation for everything else.

I genuinely believe the only way to do great work is to love what you do. Building something - a company, a product, anything worthwhile - is incredibly hard. There are countless moments where a rational person would simply walk away.

The only people who push through are the ones who actually love the work itself. Not the money. Not the status. The work.

Steve Jobs put it well in his 2005 Stanford commencement speech: "The only way to do great work is to love what you do." He also said that only the people crazy enough to think they can change the world are the ones who actually do. I think he was right. You have to be obsessive. You have to love it.

And if you do great work, money follows. Not immediately. Not always on your timeline. But it follows. The mistake is chasing money first and hoping quality comes later. It does not work that way.

2. Keep Your Word

There is a line from Scarface that has always stuck with me: "All I have in this world is my balls and my word, and I don't break 'em for no one." It resonated because there is genuine truth in it.

You have to keep your word. If you say you are going to do something, do it. It does not matter how small the commitment seems. If you said you would call on Tuesday, call on Tuesday. People remember when you follow through. And they remember even more clearly when you do not.

I stay true to my word. Always. It is not negotiable. Your reputation is built one kept promise at a time.

3. Do the Right Thing

This one sounds obvious until the moment arrives when the right thing is also the harder thing. The slower thing. The less profitable thing in the short term.

I have watched people cut corners because they could see a quick win. But that quick win sometimes meant hurting someone, or doing something ethically grey, or going down a path that bypassed lessons they actually needed to learn.

Do not take the shortcut. Even if doing the right thing takes three times longer to get you where you are going, you will arrive with your integrity intact. And that matters more than speed.

4. Be Patient but Relentlessly Persistent

There is an old saying that a woodpecker does not peck a thousand trees once - it pecks one tree a thousand times and gets dinner. I love that because it is exactly how building a business works. You pick a thing. You commit to it. And you keep going.

Most things take longer than you expect. That is fine. The people who stay the course - who do not jump to the next idea every time things get hard - are the ones who eventually break through.

5. Ask for the Order

Do not be shy. Ask for what you want.

I have lost deals simply because I did not ask for the order. I was waiting for the customer to say yes. They did not. Sales is not just about building relationships. At some point you have to say, "Let's do this." That is it. Assume you have the order. That is the part most salespeople avoid.

It is the same outside of sales. If you want something - a meeting, a favour, an introduction - ask. If you do not ask, you do not get. It really is that simple.

6. Mueve el Culo (Move Your Arse)

This one is related but different. Do not wait for things to come to you.

Some companies build their entire model on referrals and word of mouth. That is fine. But I believe you also need to go and get the business. Pick up the phone. Show up. Speak to people. Meet new people. Move. Be proactive.

The phone is not going to ring itself. And opportunities do not land on your lap. You have to go out and create them.

7. Set Unrealistic Deadlines

I set myself deadlines for everything, and I make them optimistic on purpose.

When you give yourself a tight amount of time, you fill that time with focused work. Give yourself two weeks, it takes two weeks. Give yourself five days, you find a way. That is Parkinson's Law in action.

Many of my projects have overrun their original timeline. That is fine. The deadline is not there to punish me. It is there to create urgency. Without a deadline, things drift. And drifting is what kills most projects.

8. Think Ten X

However big you are thinking, think bigger.

Whenever I come up with a goal or an idea, I ask myself: can we do ten times this? Can we make it bigger, better, bolder? That does not mean every idea needs to be massive. It means you should test the ceiling before accepting the floor.

Most people set goals based on what feels safe. Safe goals produce safe results. Push the number. You can always scale back. If the idea does not scare you a little, you are probably not pushing far enough.

9. Get Out of Your Comfort Zone

Your comfort zone is your limiting zone.

Every significant thing I have done - the first cold call, hiring my first employee, stepping back from the company I built, making videos like this one - felt uncomfortable at the time. That discomfort was not a warning. It was a signal that it mattered.

If you are not regularly doing things that make you uncomfortable, you are not growing. It is that simple. Push yourself out of the comfortable space. That is where progress lives.

10. Action Trumps Inaction

Move. Act. Stop thinking about it.

Overthinking kills more progress than bad decisions ever will. There is a real cost to inaction. A wrong decision gives you information - you learn, you correct, you move forward. No decision gives you nothing. You are just stuck.

I would rather make a move and get it wrong than sit and analyse until the moment passes. If you got it wrong, you will figure it out. But you have to move first.

11. Follow Your Gut

They say your gut is your second brain. There is real science behind it - neurons exist in your gut, and that is what people call the "gut feeling."

I think it is how you connect your conscious mind to your subconscious. In so many decisions I have made in business and life, I have made them when the decision felt right - not when the spreadsheet told me to act.

Our brains are far more powerful than we give them credit for. I believe your gut is your gateway to that deeper level of intelligence. Your intuition. I trust my gut on every major decision, and so far it has served me well.

12. Don't Trust No One

My father always told me something his mother used to say.

"No et fiis ni de la teva mare." That is Catalan. It means "do not trust even your mother."

It sounds extreme - and it is extreme - but the principle behind it is sound. Be careful with people. Especially when money is involved. I have seen people do surprising things when the stakes are high. People I thought were solid.

Trust with limits. Do not trust anyone entirely.

13. Hire Based on Attitude

When hiring, attitude beats skills. Every time.

Skills can be taught. You can teach someone a system, a tool, a process. But attitude - which is based on their perspective on life - determines how they show up, how they handle pressure, whether they actually care. All of that is rooted in how they see the world. And you cannot teach that. It is who they are.

I have learned this the hard way. I have hired people with incredible CVs who simply did not have the right attitude. And I have hired people with very little experience who turned out to be brilliant because they genuinely wanted to learn and improve.

Find people who care. Teach them the rest.

14. Learn to Delegate

This one is hard. Genuinely hard.

I founded circle.cloud. Built it from nothing. Did the telemarketing, the sales, the installations, the billing, the support - all of it. But in order to grow the business, I had to step back. I hired an operations manager, an engineering manager, a sales manager, and eventually a board of directors and a CEO. I moved to chairman. The business operates without me day to day now.

For a founder, letting go feels like losing control. But it is the opposite. It is gaining freedom.

And I believe your leadership team needs to be genuinely invested. The only way I have found to make the key people in your business feel like owners is through equity. Give them a minority stake. Something that aligns their incentives with the long-term success of the business, not just a salary. Never give away control. But give them something to care about.

15. Empathy Is Your Superpower

This one is underrated.

Being able to see things from someone else's perspective - understanding how they actually feel in a situation, not how you think they should feel - gives you a genuine edge. It changes how you lead, how you sell, how you handle conflict. Everything.

Most people listen to respond. Very few people listen to understand. There is a massive difference.

16. Make Time to Think

I have a policy: no meetings before 11 AM, unless completely necessary.

The morning is when my brain is sharpest. That is when I think, plan, and work on the hardest problems. Most people fill their mornings with meetings and emails - other people's agendas - and by lunchtime they have spent their best cognitive hours on things that could have waited.

I use my mornings to putter. To think about business direction, company structure, whatever the biggest challenges are. Sometimes I do not produce anything visible. But that thinking compounds over time.

Spend time alone. Ruminate. Let your mind work through the hard problems before the day takes over.

17. One Thing at a Time

When your to-do list is a mile long and everything feels urgent, the worst thing you can do is try to deal with it all at once.

One thing at a time. Give your full attention to the thing in front of you. Finish it, or get it to a point where you can move on, and then - and only then - shift to the next thing.

This is not about productivity. It is about preventing overwhelm. When you try to hold ten problems in your head at once, your stress rises and your output drops. Deal with one. Then the next. It sounds too simple to work, but it does.

18. Focus on the Signal

Every day there is noise. Emails, messages, requests, small fires. Most of it does not matter.

The signal is the one or two things that actually move you forward. Everything else is noise. And the hard part is not ignoring the things you do not want to do - it is ignoring the things you do want to do.

There is a story about Steve Jobs. Jony Ive said Steve used to ask him how many things he had said no to. And when Jony listed a few, Steve was not impressed, because Jony did not want to do those things anyway. That is not focus. Focus is saying no to the things you want to do with every fibre of your body - because the signal matters more.

Increase the signal-to-noise ratio. Say no to everything that is not the main thing. And do the main thing until it is done.

19. The 80/20 Rule

When deciding what to work on, do the work that will produce the majority of the results first.

That is the Pareto Principle - roughly 80% of your results come from 20% of your effort. So when prioritising, ask yourself: what is the thing that will get me the biggest result in the least amount of time?

Start there. Because that early progress gives you momentum. It gives you a feeling of accomplishment that you can carry forward - either onto the next task or to keep pushing on the one you are on.

Most people spread their effort evenly across everything. Do not. Find the 20% that produces 80% of the output. Hit that first. Then reassess.

20. Prioritise Sleep

I think sleep is the most underrated performance tool there is.

I aim for seven and a half hours every night. I do not always hit it, but I know the difference it makes. Everything deteriorates when you are under-slept. Your decisions, your mood, your patience, your clarity, your ability to handle stress. Everything.

And the data supports it. Sleep deprivation has been shown to impair cognitive function to the same degree as having a few drinks. That is not a small thing.

I have learned to treat sleep as infrastructure. Not a reward for finishing work. Not something to sacrifice to get more done. It is the thing that makes everything else possible.

21. Eat Well

This one is straightforward. Eat good food. Cut out the processed stuff. Do not overeat - that is one I still struggle with.

And do not eat within four hours of bed. That has been massive for me. Eating late wrecks sleep quality, and then everything cascades from there.

I am not extreme about diet. I do not follow any particular plan. I just try to eat real food, eat reasonable amounts, and give my body time to digest before sleeping. It is simple, but the impact on how I feel day to day has been enormous.

22. Train Every Day

I try to train at least five days per week. Weights. Ideally I would do something every single day, even if it is just a lighter session.

I am not perfect at this. Travel disrupts my routine. Bad sleep undermines my motivation. But I am working on making it non-negotiable. Because when I am consistent with training, everything else improves - my energy, my focus, my resilience, my mood and my sleep.

Your body is the engine for everything else. If the engine is not looked after, nothing else runs properly.

23. Ditch the Alcohol Trap

Alcohol is a trap. And I say that from experience.

A few years ago I read a book called This Naked Mind and it made me think about something simple. We were all happy as kids. No alcohol. Perfectly content. So why do we believe we need it as adults? We do not. We are habituated to it.

I stopped drinking for over a year. I felt amazing. Then on holiday, my wife suggested I have a beer. And I thought, well, I will just have one. Within a few months I was back to drinking almost daily.

January of this year I stopped again. Currently just over two months in. I feel great. No plans to go back.

Not drinking has improved my sleep, my clarity, my productivity, my mood - everything. If there is one thing on this list that has made the biggest difference for me recently, it is probably this one.

24. Practise Gratitude

I have a lot already. More than I sometimes realise. More than I ever imagined as a kid. And I take it for granted more than I should.

But when I actually stop and remind myself of what I have - where I am, who I am with, what I have built - I feel genuinely happy. Not in a forced way. In a real way.

It is easy to always be chasing the next thing. Gratitude is the counterbalance. It is what stops ambition from becoming a treadmill.

25. Embrace Being Different and Stop Caring What Others Think

Last one.

Everyone is different. Embrace what makes you different. There is nobody out there like you, or like me. Which makes it pointless to compare your life to someone else's.

I think we have fallen into this trap because of social media. We see other people's highlight reels and believe we are falling behind. But you are not behind. You are on your own path.

And the freedom that comes with genuinely accepting this is enormous. Stop caring so much about what other people think. We are only here for a short amount of time. Everyone is busy with their own lives. They are not thinking about you anywhere near as much as you imagine.

I used to care a lot more than I do now. And that freedom has changed how I make decisions, how I work, and how I live.

Final Thought

Those are my guiding principles. Twenty-five things I come back to, especially when I need to make a decision or when things get complicated.

I am not perfect at all of them. Some I have followed for years. Some I am still working on. But having them clear in my head helps. And I hope putting them into words helps someone else too.

If you want to go deeper into how I structure my days and my decision-making, I have put together something called the CEO Operating System. You can find it at axelmolist.com/ceo-os.

Last week I attended the Cavell Summit Europe in central London - a one-day conference that brings together the major telecoms providers, carriers, and product builders across the UK and Europe. The room was full of founders, CEOs, and market analysts. The day was packed with talks, panel discussions, and live audience polling.

I went in expecting a conversation about the state of the telecoms industry. I came out thinking about something much bigger. Five themes kept surfacing throughout the day - and they tell you a lot about where this industry is heading.

1. Data Sovereignty is No Longer Optional

Sovereignty was one of the headline topics of the conference, and rightly so.

The concept is straightforward: data should stay within the country or region it originates from. But in practice, particularly in telecoms, it gets complicated quickly.

If you are running a voice service and your session border controllers sit in the public cloud - Amazon Web Services in the US, for example - it is entirely possible that a phone call made by your customer in London traverses the Atlantic before coming back. The call itself may be encrypted, so eavesdropping is unlikely. But the moment you introduce AI into the equation - transcription, call analysis, sentiment scoring - the data starts moving. A call recording might be sent to OpenAI for transcription. That transcription might then be processed by another service for analysis. Each hop is a potential sovereignty issue.

And the risk is not just theoretical. A US-based AI provider could receive a subpoena from the Department of Justice, and suddenly the contents of a business phone call are in the public domain. That is not a far-fetched scenario - it is a legal reality of hosting data in another jurisdiction.

The large carriers are responding by establishing physical data centres in every country they operate in. They guarantee to customers that their data does not leave that geography. When it does, the customer is told explicitly. Google announced a partnership with Mistral, a French AI company, to deliver a sovereign AI product for the European market. If a company the size of Google is partnering with a French company specifically to address European sovereignty concerns, something significant is happening. There is regulation being implemented over the coming months that will make this even more prominent.

For anyone running voice services to businesses - enterprise or SME - the question "where does my data go?" is no longer theoretical. Customers are asking it. They understand enough about the cloud to know that "the cloud" is not one place. They want specifics. And they are right to ask.

We self-host our infrastructure at We UC. Our servers sit in the UK. We run data centres in London and on the South Coast, and we even run our own AI service on our own infrastructure. All the call recording transcription, analysis, and summarisation happens locally. You do not need the most powerful models in the world to do transcription and summarisation - that is a common misnomer. We have managed to do this on our own infrastructure, keeping all data within the UK. It is one of the decisions we made early on, and watching this conversation unfold at the conference reinforced that it was the right one.

2. AI is Not a Feature - It is the New Electricity

There was a lot of talk at the conference about how AI is going to disrupt the workplace. How AI will impact telecoms. How businesses should plan for AI.

It struck me that the conversation is framed incorrectly.

AI is not a feature you bolt on. It is not a module you activate. It is closer to electricity - so fundamental, so omnipresent, that discussing "how electricity will impact our business" would sound absurd. Yet that is essentially how parts of the telecoms industry are still treating AI. As something new. Something to plan for. Something to discuss at conferences.

The reality is that AI has already changed how most knowledge workers operate. It has already rewritten the economics of software development, customer service, content production, and data analysis. Treating it as an upcoming disruption misses the point. It is the new baseline.

I think this reflects a divide that has been growing for years - between traditional telecoms companies and modern software companies.

Traditional telecoms providers are, by nature, infrastructure businesses. They operate on BSS and OSS systems that were built decades ago. Their software development practices prioritise stability and basic functionality over innovation. The interfaces are over-complicated. The architecture is legacy. The appetite for rapid change is low - not because the people are not smart, but because the systems and culture were built for a different era.

On the other side, you have companies like ElevenLabs. Born in the modern era. Running on Kubernetes. Advanced CI/CD workflows. AI woven into every part of how they build and ship. They care about design, about user experience, about craft. They do not have twenty years of technical debt weighing them down. They move at a completely different speed.

The telecoms industry is full of companies operating like it is still 2010. Meanwhile, modern software companies are building products that interact with the same customers, solve the same problems, and move ten times faster. That creates a gap - and it is widening.

3. Voice AI Was the Real Story

The conference organisers positioned sovereignty as the main theme. And it was well covered. But the topic the audience actually wanted to discuss - overwhelmingly, based on a live poll at the start of the day - was voice AI.

It is not hard to see why.

One of the demonstrations came from Bandwidth, an international carrier with a strong presence in Europe. They partnered with a hotel chain and implemented a voice AI solution that handles the front desk. Guest calls about room service orders, booking modifications, general enquiries - all handled by AI with access to the hotel's booking system. The problem it solved was simple: during busy periods, the hotel did not have enough staff to answer every call. Guests were left waiting. With voice AI, the constraint disappears. You can have thousands of agents handling calls simultaneously, freeing human staff to focus on face-to-face interactions.

Another example: a restaurant chain facing the same problem. At peak hours, waiters cannot answer the phone. Customers calling to book a table, modify a reservation, or ask about the menu are left on hold or unanswered. A voice AI solution with access to the restaurant's systems solves this immediately.

These are not theoretical use cases. They are live deployments.

The interesting tension in this space is between two camps. On one side, tech startups are building voice AI solutions rapidly but often know nothing about telecoms. They do not understand session border controllers, call switches, or quality of service at the network level. They route calls through an API to something like Twilio so they can make and receive phone calls, and they ship the product. They know the customer. They win the deal. But the quality of service cannot be as good as if they owned the whole stack. If these startups understood how a soft switch works, how to route calls on-premise, how to run phone calls at scale on their own network - the call quality would be better, the troubleshooting faster, and the whole thing cheaper and more stable long-term.

On the other side, traditional telecoms providers understand the infrastructure deeply but are too slow to build these solutions themselves. They provide the telecom services but not the value-added solutions on top. Meanwhile, the startups are putting voice AI products in front of the telco solution and extracting margin from providers who should be delivering it themselves.

There is a gap between the two. And I believe We UC sits in that gap. We have the software skills and the pace of a modern company. We also have the telecoms experience - the soft switch experience, the network we are running ourselves. We are positioned at the intersection of a modern software company and a traditional telco. That middle ground is where the opportunity is. It is also where we are building Ringup, our voice AI product that will be built directly into We UC.

4. Voice is Going to Zero

A recurring message at the conference: the traditional telephony pricing model is dying.

The argument is straightforward. Services like WhatsApp have normalised free communication. A WhatsApp call costs nothing because it does not touch the public telephone network - both endpoints are controlled by the same company within a closed environment. But that creates a perception that all voice communication should be free. The ten or fifteen pounds per user per month model, with bundled minutes and a standard feature set, is gradually losing its value.

Businesses still have phone numbers. That is still the universal method for communicating with businesses through voice. But the pricing pressure is real.

So how do telecoms companies remain profitable?

The answer that emerged clearly from the conference: value-added services.

What does that mean in practice? Three things stood out.

First, data analytics and reporting. Connecting a customer's CRM, financial system, and phone platform so that data appears in one place - dashboards and scheduled reports that cover not just call activity but business performance.

Second, voice AI. Tools like Ringup, which we are building into We UC, that give businesses the ability to implement AI agents within their phone system. Not just agents that answer calls and take voicemails, but agents that can perform actions - booking appointments, modifying reservations, updating records - because they plug into the CRM integrations already in place.

Third, integrations themselves. Most businesses run a CRM or a financial system or some kind of platform to manage their operations. Integrating into these platforms allows a productivity boost, an efficiency boost, and allows customers to do their best work by having access to the best technology for their business.

The core voice licence becomes the entry point. The real margin lives in the solutions built on top of it.

For anyone building in the telecoms space, the message was clear: the commodity is the phone line. The value is everything you build around it.

5. Specialisation is the Only Way to Stand Out

The final theme that stayed with me is about focus.

We are preparing to sell We UC as a software-as-a-service product. In a crowded market - and unified communications is a very crowded market - having a product that solves many problems for many people is not a differentiation strategy. It is a path to invisibility.

I remember a marketing brochure from about ten years ago, when "cloud" was the buzzword. The headline was: "How do you stand out from the cloud?" It was a clever line then. It is even more relevant now, because the market is noisier than it has ever been.

The approach we are evaluating is straightforward: specialise.

In order to stand out, you need to understand the customer and understand their workflow. You need to know how they operate day to day and know what problems they have so well that you can create a solution that removes friction - so they can solve those problems faster and better with your product. The only way to do that at scale is to specialise.

Either you verticalise - specialise in a particular industry and solve a problem that industry has, because you understand it deeply enough to solve it well. Or you specialise in a particular solution that applies across multiple industries, but you solve the problem within that solution extremely well.

We are evaluating both paths right now. But the principle is clear: in a noisy market, the businesses that succeed are the ones that are laser-focused on solving one problem better than anyone else. Not something generic. Not "we do everything for everyone." Something specific for one specific type of customer - and being the best in the world at it.

That is what we are going to focus on with We UC. Once we have made the decision on which segment, every piece of marketing and every product decision will be shaped by it.

What I Took Away

The Cavell Summit condensed a lot of the themes I have been thinking about into a single day. Sovereignty is real and getting more urgent. AI is not a feature - it is the foundation. Voice AI is the most immediate disruption in telecoms. Traditional pricing models are eroding. And the only way to build something visible in a crowded market is to be specific about what you do and who you do it for.

None of these ideas exist in isolation. They overlap. The company that builds a communication platform with AI at its core, that handles data in a sovereign way, that is able to solve really specific problems better than anyone else, and that specialises in a particular vertical or solution - those are the companies that will win.

That is what we are building with We UC. And conferences like this one remind me that we are heading in the right direction.

If you want my operating framework for running at full capacity as a founder and CEO, it is free at axelmolist.com/ceo-os.

I have been fat. I have been thin. I have been somewhere in between. And the honest truth is that I have never stayed in one place for very long.

My weight has fluctuated my entire life - from childhood through my twenties, through building a business, through a wedding, through fatherhood - and it continues to fluctuate now. I am not writing this because I have solved it. I am writing this because I have not.

The Earliest Memory

The first time I remember being aware of my weight, I was about seven or eight years old. I did not feel fat. I only realised it when I compared myself to the other kids. Looking back, the explanation is straightforward: I was eating more than I was burning. That is always the explanation.

I do not believe genetics make weight loss impossible. Metabolism varies between people, and a smaller body burns fewer calories than a larger one - that is basic thermodynamics. But the principle is always the same. Calories in versus calories out.

The more interesting question is not why I was fat. It is why I was eating so much.

Food as Dopamine

Food is a dopamine release mechanism. Everyone knows this on some level, but not everyone experiences it the same way. For me, food has always been connected to pleasure in a way that goes beyond hunger. It is comfort, reward, and ritual.

As a child, I think I was chasing that dopamine without understanding what it was. My mother used to hide the biscuits around the house because I would find them and eat them all. She hid the mayonnaise for the same reason. At the same time, she would tell me to finish everything on my plate - food should not go to waste. That combination of abundance and obligation likely planted something deep.

This is not blame. It is observation. If my own son had the same tendencies, I would try to intervene, but I am not sure I could prevent it either.

The Obsessive Personality

I recognise something about myself that connects all of this: I am obsessive. When something gets into my head, I cannot shift it until I have either completed it, learned everything about it, or experienced everything I can about it. I am all in or not in at all.

This trait has served me well in business. It is the same quality that allowed me to build circle.cloud from nothing, working eighteen-hour days because I knew exactly what needed to be done.

But with food and weight management, it is more of a liability than an asset. The same intensity that drives productive obsession also drives destructive patterns. The dopamine chase that makes me relentless at work is the same one that makes me eat twelve hundred calories at half past ten at night when I know I do not need them.

The Alcohol Parallel

I stopped drinking alcohol a few months ago, and this is not the first time. A couple of years ago, I spent just over a year without drinking. It was a year of clarity - calm, collected, sharp thinking. I did not want or fancy alcohol in any form.

Then my wife suggested I have a beer with her at lunch on holiday. Just one. It would not hurt. And she was right - one beer did not hurt. But one beer became another, and another, and slowly I returned to the same patterns that made me want to stop in the first place.

Alcohol follows a predictable cycle. You have a drink and your mood lifts from baseline to somewhere above it. When the effect wears off, you do not return to where you started - you land slightly below baseline. So the next time you drink, you are starting from a lower point, and you need slightly more to reach the same feeling. Over time, the baseline keeps dropping.

I do not know anyone who has been drinking consistently for ten years and drinks the same amount today as they did at the start. The trajectory is always upward. Alcohol is a net negative to peace of mind, and I include it here because it operates on the exact same dopamine principle as food.

The Timeline

At fourteen, I decided I wanted to lose weight. I started skateboarding, running, swimming. I told my mother to give me less food. I made my own plates instead of having them served to me.

I remember walking downhill toward town one afternoon, probably around four o'clock, having skipped lunch. I was so hungry I felt like my body was consuming itself. That feeling has stayed with me. Every time I lose weight now, I remember it, and I think: this hunger means my body is burning fat. This is progress.

The problem is that this state is not sustainable. You cannot restrict yourself severely and expect the result to hold. Heavy restriction leads to heavy compensation later.

I fluctuated between sixty-five and seventy-five kilograms through my late teens and twenties - small ups and downs, nothing dramatic. Then I started my business, entered a long-term relationship, and stopped paying attention.

By 2017 or 2018, the weight started creeping up. Seventy-five. Eighty. Eighty-five. Ninety. At ninety, I essentially gave up. The business needed all my attention. I told myself I would deal with my body later.

Later arrived in late 2020 at a hundred and ten kilograms.

The Juicing Experiment

My son was two. My wedding celebration was coming up in October 2021. I watched a documentary about an Australian man who spent three months driving across America, consuming nothing but freshly juiced vegetables and fruit. He lost a tremendous amount of weight.

The approach appealed to my obsessive nature perfectly: extreme action, extreme results, clear rules, defined timeline. I bought a juicer and started.

After a couple of weeks, I found the process messy and time-consuming, so I discovered a London company called Prescription Juices that delivered freshly pressed juice frozen to my door each week. Their formulations were designed by dietitians and doctors - each day included juices with dates, nuts, celery, kale, oranges. Proteins, fats, carbohydrates, micronutrients. Around five hundred calories per day.

I juiced for ten weeks and went from a hundred and ten kilograms to sixty-seven. I felt on top of the world.

After the wedding, I hired a dietitian. That worked for three or four months. Then the old habits crept back in. Beer after work. Nuts with the beer. Wine with dinner. By 2023, I was back at eighty-five.

I hired a personal trainer, cut out most of the poor food choices, stopped drinking. Dropped to seventy-five. I have been fluctuating around that number since - down to seventy-two, up to seventy-eight, back to seventy-four.

Right now, I am at seventy-seven. My goal is sixty-five at around twelve percent body fat. I am currently at twenty-two percent. There is work to do.

Last Night

Here is where the self-awareness becomes both useful and frustrating.

Last night, I was at a boardroom event with a group of founders and CEOs. It ran from half six to half nine. I did not get back until half ten. I was not particularly hungry - I had eaten some snacks at the event - but I had not had dinner, and my brain decided that meant I deserved something.

I did not need a meal. I could have gone to bed. Instead, I walked to the shop and bought a wrap, peanuts, a yoghourt, a protein drink, and a chocolate bar. Instead of a hundred or two hundred calories, I consumed twelve hundred.

Why? Because my body wanted a small hit of dopamine before sleep. A comfort. A ritual to close the day. And I gave in.

This is the part that demoralises me. I am fully aware of what I am doing. I can describe the mechanism in detail. I know I am trading short-term pleasure for long-term progress. And I still do it.

Does this mean I do not care enough about the goal? Does it mean immediate gratification matters more to me than long-term results? I do not think so, not in the grand scheme. But something in the moment overrides what I know to be true.

I have not mastered this. I am still working on it.

The Types

One thing I have observed, and perhaps this is obvious but worth naming, is that people fall into distinct categories with weight:

1. You carry extra weight and struggle to lose it
2. You are thin and struggle to gain it
3. You fluctuate - a tendency toward one direction, interrupted by intense correction in the other

I am the third type. I have a tendency toward gaining weight because I have a tendency toward overeating. But I also have the capacity for extreme restriction - juicing for ten weeks, fasting for seven days, cutting out entire food groups overnight. The result is a life spent oscillating between states rather than settling into one.

Everybody is different. That is not a revelation. But naming the pattern you belong to is the first step toward working with it instead of against it.

Fasting as Clarity

The juicing journey introduced me to fasting, and fasting gave me something I did not expect. It was not the weight loss - although that helped. It was the mental clarity.

When I fast, I enter a state of enlightenment that I do not experience in normal life. There is peace in not having to think about food. There is a sharpness that arrives somewhere around the twenty-four-hour mark and intensifies at forty-eight hours.

This makes evolutionary sense. When our ancestors needed to hunt, they did so while hungry. The body adapted to be sharper when fasted - alertness was a survival advantage.

The longest fast I have done was seven days. Water and black coffee only, while working alone in Dubai. Physically, I felt incredible - like God, honestly. Mentally, every single day was harder than the last. Being surrounded by people eating in a hotel cafe while you are on day four of not eating takes a toll that is difficult to describe.

I broke the fast with a steak. It was probably the nicest tasting steak I have ever had, even though it was not a great steak. I followed it with a salted caramel iced coffee, which was so good I immediately had another one.

That experience was so intense it has actually put me off long fasts since. It was mentally draining in a way I was not expecting. But I will fast again. Fasting is no longer a weight loss tool for me - it is a reset. A way to achieve a temporary state of clarity and discipline that recalibrates everything.

If your doctor approves and you are healthy enough, I would recommend trying it. Start with a day. See how it feels. The sharpness alone is worth the discomfort.

Where I Am

I am at seventy-seven kilograms. I want to be at sixty-five. I have cut out alcohol again. I know what I need to do. I know the mechanisms that work against me. I know my obsessive personality will drive me to extreme measures and then pull me back toward excess.

I am closer to peace with this than I have ever been. Not because the battle is over, but because I finally understand the battlefield. The dopamine. The obsessiveness. The short-term override. The restriction-compensation cycle.

I do not have the answer yet. But I have the awareness. And I think awareness, honestly pursued, is the only foundation from which an answer can eventually come.

This is my journey. It is ongoing. And I suspect it always will be.

Everyone tells me the same thing. Just resell someone else's platform. It would be cheaper. It would be faster. It would make more business sense.

They are not wrong about any of that.

But they are wrong about what matters.

Selling Boxes Under Desks

My journey in telecoms started in 2012. I was working for a company that sold Siemens phone systems - physical boxes the size of three shoeboxes, plugged into walls underneath desks or shoved into corridors. On-premise PBXs for small businesses with five to ten users.

I could see that cloud was the future. It was obvious to me. I went to the owners and told them we needed to be selling cloud telephony. They disagreed - there was not enough money in it.

So I set up a company on the side. I got sacked for it. And that company became circle.cloud.

That decision - following my gut when the economics said otherwise - set a pattern I have repeated ever since.

The Search for the Right Platform

When I started circle.cloud, I needed a platform to resell. The obvious choice was Horizon by Gamma - solid, well-known, built on Broadsoft under the hood. But it was what everybody else was selling. I wanted something different.

I found a company called The Voice Factory, run by a man named Paul Harrison. Paul used to work at Broadsoft, and after he left he set up The Voice Factory and invested in his own Broadsoft platform. He believed in me at a time when I was just a person with a brand new company. Getting a reseller agreement with a telecoms carrier in 2015 was not as easy as it is today. You needed trading history, investment, industry connections. I had none of that. Paul took a chance on me anyway, and I have a tremendous amount of appreciation for that.

What drew me to Broadsoft was its architecture. The platform separated every service into its own cluster - one for the application layer, one for the database, one for media, and so on - all isolated, all horizontally scalable across multiple zones, meaning multiple data centres. You simply stack more servers in each zone when you need more capacity. It was the industry standard for good reason. Companies like Telefonica, Vodafone, and BT run their telephony on Broadsoft. You needed around four million pounds in capital to get a carrier-grade Broadsoft installation and licences, which was well beyond our reach at the time.

The initial years went well. We grew. But our billing costs grew too. We were spending around twenty thousand pounds a month on licence fees.

That made me start looking for alternatives.

The Outages That Changed Everything

I found a company called Bicom Systems that built their own cloud PBX on Asterisk. The licence fees were dramatically lower - charged per server rather than per user, with each server handling around 1,500 users. We made the switch.

At first, our software ran on Bicom's servers in their data centre. Then they had an outage in Milton Keynes. Two to three hours of no service for our customers. It made my blood boil. Their infrastructure standards were not where ours needed to be.

So we found our own data centre - a company called Netwise Hosting in central London, run by two founders who had built something remarkable. Small team, but the quality was extraordinary: diverse network paths, multiple carriers, Cisco routers in the core, multiple generators, multiple fuel contracts. We bought a quarter rack, installed our own servers, and ran the Bicom software on our hardware.

Then Netwise got hit with a DDoS attack. Not targeting us - targeting another customer. But because we shared the network, our service went down for three to four hours.

That was the moment I decided we would never again run our infrastructure on someone else's network. We invested in our own routers, our own switches, and established direct relationships with carriers for connectivity into our data centre.

Looking back, the evolution was a staircase:

1. First, we got our own software licences instead of paying per user per month
2. Then we hosted that software in a data centre we controlled
3. Then we ran it on our own network
4. Then we replaced the third-party software with our own

Step four is where the real story begins.

Finding Kazoo

I knew what I wanted: a platform with the scalability of Broadsoft but without the four-million-pound licence fee. Broadsoft had been acquired by Cisco by this point. I actually inquired heavily about obtaining a Broadworks platform, but the economics did not work.

The breakthrough came almost by accident. I was on a call with a telecoms consultancy from Argentina. Our requirements did not quite match what they could offer, but at the end of the conversation, one of them mentioned a small company in San Francisco called 2600 Hz that had built something called Kazoo. I had never heard of it. I made a note and moved on.

Months later, I hired a systems administrator named Konstantins - highly skilled, had built software products before. When I told him my goals, he said we could build something with one developer and have it in the market within six months. That turned out to be optimistic, to say the least.

What made Kazoo compelling was that it was architected as an open-source alternative to Broadsoft. Multiple application servers, multiple media servers, multiple SBCs, a distributed message bus - all capable of running across geographical zones. You could have a cluster in London and another in Amsterdam, failing over between them seamlessly. It was built for carriers and for scale. And it was open source, which meant no licence fees and full control.

We installed Kazoo, set it up in a distributed architecture, and started building.

Becoming a Software Company by Accident

The original plan was modest. Kazoo came with an open-source frontend called Monster UI, and we started by building a call recording application on top of it. That was meant to be the missing piece.

Within two months, Konstantins saw something bigger. Instead of bolting applications onto Monster UI, we should build our own platform from scratch - our own API, our own interface, our own product. One that talked to Kazoo for the PBX features but was entirely ours in terms of the user experience.

That decision changed everything.

We called it Circle UC at first. Then one day, the name We UC came to me. I was in the circle.cloud office and overheard Adam, one of the sales team, say, "I am just going to transfer this call to my director." Not our director. My director. We had grown fast - from ten employees to fifty or sixty in a few months - and somewhere in that growth, people had stopped thinking of the company as a team. It became "us and them."

The name "We" came from that realisation. It is inclusive. It promotes collaboration, not just communication. It makes people think of a company as a single force rather than separate departments. That is exactly what a unified communications platform should do. We paired it with UC - unified communications - and We UC was born.

What started as building a custom proposition for circle.cloud turned into something much bigger. We hired more developers. We set up sprints, CI/CD pipelines, infrastructure, DevOps processes. We registered We UC Ltd. We built native iOS and Android apps, a desktop app, a web app. We now have a team of over twenty people.

We became a software company almost by accident. And I love it.

What We UC Is

We UC is a modern business phone system. A unified communications platform that handles calls to telephone numbers via audio, internal calls via audio or video, messaging, meetings, call reports, and analytics - all in one application.

The basics are now solid. We are on par with our previous platform in terms of features and stability, and we are onboarding customers. One recruitment business is already running on We UC, with more to follow.

But the basics are just the foundation. What excites me is what comes next.

We are building customisable dashboards that do not just display telephony data but pull in information from CRMs, support systems, and accounting platforms - a small business BI tool that gives founders a 360-degree view of their operation in a single screen. We are building voice AI agents that sound human, connect to business systems via MCP servers, and can handle tasks like restaurant bookings or appointment scheduling. We are building omnichannel messaging that brings WhatsApp, email, Facebook Messenger, and Google My Business conversations into a single interface alongside internal chat.

These are not features for the sake of features. They are tools that will genuinely impact small businesses' efficiency and profitability.

Enterprise companies have had this technology for years - data warehouses, Power BI, AI assistants, omnichannel support. Small businesses are still logging into six different platforms every morning and lack a centralised view of their data and operations. I want to change that.

That is the real answer to why I built this. Not because someone asked. Because someone should have. As Steve Jobs put it: "People don't know what they want until you show them."

What I Have Learned

Five years of building something nobody asked for has taught me a few things.

Follow your gut, even when the economics say otherwise. Every major decision I have made - leaving my first job to start circle.cloud, moving off Broadsoft, investing in our own infrastructure, choosing to build from scratch on Kazoo - looked questionable on a spreadsheet. Every single one turned out to be right.

Control your stack. When something goes wrong and your service runs on someone else's network, on someone else's software, on someone else's servers, you cannot fix it. You can only wait. That is an unacceptable position. The buck has to stop with us.

Building it yourself takes longer but lasts longer. We could have hired consultancies to build everything and moved faster. Instead, we learned Kazoo ourselves, hired expertise in-house, built the knowledge internally. It took more time. But now we own every layer of understanding, not just every layer of technology.

Craft is not a luxury. We care about details nobody will ever see. The architecture of the codebase, the elegance of the API, the precision of the UX. That care comes through in the final product, even when the customer cannot point to exactly why it feels different.

You do not need permission to build what you believe in. Nobody asked for We UC. The market did not demand it. A consultant would have told me to keep reselling. But the best products are built by people who see something that does not exist yet and refuse to accept that gap.

Kazoo itself is open-source software, and we are actively contributing back to it - working alongside carriers from all over the world, maintaining a shared codebase. That is the beauty of open source. You build on something great and make it greater. But for us, Kazoo is just the PBX engine. On top of it sits everything from messaging to video calling, online meetings, call recording transcription and summarisation, and much more - all wrapped around a user experience that is entirely ours.

The Road Ahead

I have no plans to sell We UC. I want to build it and keep building it. That is what I enjoy doing.

We are launching in the UK first, then the US, Europe, and potentially Australia. We are selling through circle.cloud's existing sales engine and, soon, via a self-service SaaS model - which is entirely new territory for me and genuinely exciting.

I want We UC to become a recognised name in unified communications. Not because it is the biggest, but because it is built with more care, more craft, and more attention to detail than anything else in the market.

That is what five years of building something nobody asked for has given me. Not just a product, but a conviction: the things worth building are rarely the things that make obvious sense at the start. They are the things you cannot stop thinking about. The things that keep you working not because you have to, but because you genuinely want to.

And I have never wanted anything more.

We are told that beauty is subjective. In the eye of the beholder. That there is no right or wrong.

But is it? Because nature does not seem to think so.

Look at a shell. Look at the spiral on it. Now look at the spiral of a galaxy. They are the same shape. That is not a coincidence. What makes a face beautiful? Symmetry - one side mirrors the other. What makes a flower beautiful? The geometry, the way the petals are arranged. What makes great architecture? The way the shapes and the sizes complement each other.

These are mathematical patterns. And they keep showing up across nature, across history, across everything we find beautiful.

Beauty has structure. It is not random. And two things arrived in the same week that gave me the language for something I have felt my entire life but never quite managed to put into words.

The first was Paul Graham - the founder of Y Combinator, one of the sharpest minds in technology - resharing an essay he wrote in 2002 called Taste for Makers. I read it and sat quietly for a minute afterwards, because someone had articulated the idea that taste is not preference. It is real, it is identifiable, and it is a skill that can be developed.

The second was the Steve Jobs Archive publishing a collection called Letters to a Young Creator. Over thirty letters from the people who knew Steve, worked alongside him, were shaped by him. Released on what would have been his 71st birthday. And Jony Ive - the man who designed the iPhone, the iMac, the iPad alongside Jobs for fifteen years - wrote a letter about what it actually means to care about making something beautiful.

Together, they point at something I think is the most important conversation happening in technology right now. Not about tools. Not about speed. About what we believe the people who use our work actually deserve.

The Comfortable Lie

We are told from childhood that taste is personal, subjective, that there is no right or wrong.

It sounds generous. It sounds democratic. But it is a comfortable lie we tell each other to avoid conflict.

Graham opens his essay with a question that sounds almost naive: is there such a thing as good taste, or is taste just personal preference? And then he answers it in a way that stopped me cold. He says if taste were just preference, then everyone's taste is already perfect. There would be no way to get better at designing things. No direction to improve towards. But we all know that is not true. We know when we are looking at something genuinely beautiful versus something that has just been assembled. We feel it. We just lack the confidence to trust that feeling.

And then he goes further. He identifies the principles that keep appearing across every field - mathematics, architecture, painting, writing, engineering. Simplicity. Symmetry. Resemblance to nature. As if beauty is not subjective at all. As if there is a deeper truth to it that transcends medium and era and culture.

Steve Jobs believed it too. He famously said that Microsoft had no taste. People thought that was arrogant. But I do not think he was being cruel. He was being precise. He was saying: they do not ask whether something is good - they ask whether it works and whether it sells. Those are not the same question.

Taste is the ability to know the difference.

The Bull

For me, Picasso is the most powerful illustration of what simplicity actually means.

In 1945, he made a series of eleven lithographs called The Bull. He starts with a detailed, realistic bull - muscular, anatomically complex. The kind of drawing that makes you think: this person can really draw.

But then - over eleven iterations - he strips it. Removes muscle. Removes shadow. Removes everything that is not essential. Until at the end he has five or six lines. And those lines contain the entire essence of a bull - the power, the weight, the character - more completely than the detailed version ever could.

That process - that brutal, disciplined act of subtraction - is what decades of mastery actually earns you. Not the ability to add more. The ability to know what to take away. The confidence to take it away. And the skill to make what remains feel not sparse, but complete.

Graham makes the same observation across fields. In mathematics, a shorter proof is a better proof. In writing, say what you mean and say it briefly. In architecture, beauty depends on a few structural elements, not a profusion of decoration. Good design uses symmetry. Good design resembles nature. And good design looks easy - even though getting there is incredibly hard.

Most people think simplicity is the easy option. That minimalism is about doing less. It is the opposite. Simplicity is the hardest version of the thing - the version where there is nowhere to hide. Where every single element has to earn its place.

That is what Jobs did to the phone. That is what Ive did to every product they made together. And it is no coincidence that Ive's greatest influence was Dieter Rams - the German designer whose philosophy fits in three words: less, but better.

Protecting What Is Fragile

Ive's letter from the archive is not what you might expect. He does not talk about products. He barely mentions the iPhone or the Mac. He talks about how Steve thought. He says: "The way he thought was profoundly beautiful." He describes Jobs's curiosity as "ferocious, energetic and restless" - not limited by his knowledge, not casual or passive, but practiced with intention and rigor.

And then he writes something I keep coming back to: "Ideas are fragile. If they were resolved, they would not be ideas - they would be products. It takes determined effort not to be consumed by the problems of a new idea."

We live in a world obsessed with shipping. Validate fast. Move fast. Get feedback fast. There is wisdom in that. But there is also a kind of violence in it if applied too early.

There is a moment in the creative process where an idea is alive but not yet strong enough to survive scrutiny. It exists as a feeling, a direction, an instinct - before it has the language or form to defend itself. Expose it to criticism too soon and you kill it. Not because the criticism is wrong, but because the idea has not had time to become what it could be.

Jobs and Ive understood this. They spent their afternoons in what Ive calls "the sanctuary of the design studio." Protected space where ideas could evolve before they were tested.

I think about this in my own work building We UC. There is constant pressure to ship, to show progress, to validate early. That pressure is mostly healthy. But I have also killed ideas by letting the committee into the room before the thing had legs. The skill is knowing when something needs protecting and when it needs testing. I am still learning that.

Graham says great design is redesign. Leonardo's drawings often show five or six attempts at a single line. The Porsche 911 only emerged from the redesign of an awkward prototype. First answers are almost never the best answers.

Taste as Love for the Craft

Tim Cook's letter describes the moment he decided to join Apple. The company was struggling. Most people thought it would not survive. Then he heard Steve speak.

Cook writes that when Jobs spoke, "any trepidation I harboured instantly dissolved." Not because Steve had a perfect plan. Because he had complete clarity of purpose. Cook says he had never met someone with so much passion and vision. And he says he traded a job for a purpose the day he joined.

That distinction matters. A job is a set of tasks. A purpose is a reason. People will do extraordinary things in service of a genuine reason in a way they never will for a task list.

And I think that is what taste really is. It is not snobbery. It is love for the craft. It is caring so deeply about what you are making that you refuse to accept anything less than beautiful. Not because you want to show off. But because you believe the person on the other end deserves it. And because you want to apply your own style to it - to make it not just functional but uniquely, thoughtfully yours.

Ive understood this. He closes his letter with something I think is the most important line in all of this. He writes: "He truly believed that by making something useful, empowering and beautiful, we express our love for humanity." And then: "My sincere hope for you and for me is that we demonstrate our appreciation of our species by making something beautiful."

That is not a design philosophy. That is an ethical position. When you choose the good-enough option - the it-works-so-why-bother option - you are making a choice about how much you value the person on the other end.

Why This Matters Now

I do not think this is just a conversation about Apple or Picasso or Dieter Rams. I think it is the most urgent conversation in technology right now.

Because we are drowning in output. AI can generate volume. It can generate competence. What it cannot generate is taste - the love for the craft that makes someone obsess over getting something right. The intolerance for ugliness that comes from a person who has stared at their work long enough to hear the voice that says: there must be a better way.

That voice is the thing. Not the tools. Not the frameworks. Not the ability to produce faster and cheaper. The voice. The one that looks at something functional and says: this is not good enough.

Graham wrote his essay twenty-three years ago. Before the iPhone. Before AI could write code or generate images. Every word is more relevant today than when he wrote it. Because the cheaper it becomes to produce things, the more valuable taste becomes. When anyone can generate output, the differentiator is whether someone cared enough to make it right.

Nature's ratios. Simplicity. Symmetry. These are not trends. They are truths. Picasso's five-line bull took a lifetime to earn. Jobs spent decades obsessing over details most people would never notice. Dieter Rams designed products in the 1960s that still look contemporary because the principles underneath them are true.

The world does not need more output. It needs more people who refuse to accept that good enough is good enough. People who understand that simplicity is not the absence of effort but the highest expression of it. People whose taste comes not from judgement but from genuine love for what they are making and genuine respect for the people experiencing it.

I still get this wrong. I still ship things I know could be better. But I never stop hearing that voice. And the message I take from all of this - from Graham, from Ive, from Jobs - is: do not explain it away. Cultivate it. It is the most valuable thing you have.