I Stopped Looking at the Code

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.