Build to Last

A few days ago I listened to a conversation between Jeremy Howard (fast.ai) and Chris Lattner — the creator of LLVM, Swift, and Mojo. An hour of calm, grounded discussion. No slides, no hype. Just two engineers refusing to give in to the ambient panic.

I listened to the whole thing in one go. That almost never happens.

Because what Lattner says there hit me directly. Not like some distant conference about "the future of dev". More like a mirror held up to 18 years of design decisions, refactors, apps maintained, abandoned, or rewritten from scratch.

The central question they ask is simple. Almost trivial.

How do you build a system that lasts more than six months?

The answer is anything but simple.

LLVM: the compiler nobody asked for

Christmas 2000. Chris Lattner, a PhD student, starts writing LLVM on his own. Not to solve a specific problem. Not to answer a brief. To answer a fundamental question: what should a compiler infrastructure fundamentally be?

Twenty-five years later, LLVM is everywhere. Rust, Swift, Julia — entire languages have been built on top of it. Clang, the C/C++/Objective-C compiler Lattner himself created, is the official frontend — the one running inside Xcode since 2013, behind every build of every iOS app.

That's not luck. That's architecture.

And to understand why it holds so well, you need to grasp one key concept in LLVM's design: the intermediate representation, or LLVM-IR.

The idea is elegant. Instead of compiling C++ (or Swift, or Rust) directly to machine code — which would require rewriting everything for each processor, each architecture — LLVM introduces a universal intermediate step. Every language first translates to LLVM-IR. Then LLVM transforms that IR into optimised machine code for the target: an iPhone, an Apple Silicon Mac, a Linux server.

Think of it as a pivot translator. You speak French, English, Spanish — doesn't matter. Everything first goes through Esperanto, and from there it's translated to the final destination.

This three-stage pipeline — source → IR → machine code — is what allowed Rust to exist without rewriting a full compiler, Swift to run on iPhone from day one, and Xcode to use LLVM in production for years. Plug in a new language at the front. Plug in a new processor at the back. The core doesn't move.

That's first principles. Not a solution for today. A foundation for languages that haven't been invented yet.

"Systems that crumble under their own weight do so because their architecture was broken from the start. Those that last, it's because someone took the time to understand what they were building — and why." — Chris Lattner

I recognise this mindset. It's exactly what separates an iOS app that holds for two years from one you're rewriting from scratch six months in. It's not code quality in the syntactic sense. It's the quality of the thinking that came before the code.

Architecture is what you can't see — but what decides everything.

Vibe coding: symptom of an era

Today the mandate is clear: ship fast, ship often, use AI to go 10x faster. CEOs publicly brag that their teams generate 10,000 lines of AI-written code per day.

10,000 lines a day.

Lattner has a word for that: a useless metric. Or worse, a dangerous one.

"I'm not a CEO bragging about the number of lines generated by AI. I see that as a liability, not an asset. What matters is: is the product getting better? Do people understand what they're building?"

Vibe coding — spinning up an agentic loop and hoping something useful comes out — is gambling dressed up as productivity. Howard put it exactly like that: "It's like pulling the lever on a slot machine. You lose, you pull again. You lose, you pull again."

The story that chilled me

Lattner tells a concrete case. A senior engineer, bug reported, agentic loop fired off, PR generated. The PR passed the tests. The bug "disappeared".

Except it hadn't. The symptom was masked. Under the surface, the codebase had just absorbed a time bomb: code in the wrong place, doing the wrong thing, about to create three new bugs subtler than the first.

The code had been merged without anyone really understanding what it did.

That's not a tooling problem. It's a culture problem. A culture that has learned to make symptoms disappear rather than understand causes.

What this means for an iOS developer

I've been building iOS apps since 2007. I've watched the paradigms come and go: Objective-C, ARC, Swift, SwiftUI, MVC/MVVM/TCA. I've rewritten entire apps. I've maintained others for years.

And I can tell you one thing: technical debt never sleeps.

It waits. It accumulates. And it wakes up at the worst moment — when you have a deadline, when Apple ships a new iOS version, when a user reports a bug you no longer understand because the person who wrote that code is gone. Or it was you, three years ago, and you can't remember the reasoning anymore.

AI hasn't changed that reality. It's accelerated it.

With Onyria, I made a conscious choice: use AI as an accelerator, not as an architect. The structural decisions — how to manage user credits, how to orchestrate calls to the Reve API, how to sync data across devices via SwiftData without an external server — those decisions are mine. AI can help me write boilerplate, explore alternatives, spot edge cases. But it can't understand the constraints of the Apple ecosystem for me.

That's 18 years talking. And that doesn't get automated.

The bifurcation

Howard makes a diagnosis that stopped me cold:

"There's going to be two groups. Those who've developed learned helplessness — who don't really know what they're doing without AI anymore. And that smaller group everyone will wonder about: 'How does this person know everything? They're incredible.'"

We're already seeing it. App Store review times are stretching because submission volume is exploding — but quality isn't. Apple is tightening its guidelines (4.1, 4.2, 4.3) against prompt-generated clone apps. The bar is rising.

For developers who actually understand what they're building, that's good news. The ecosystem is cleaning itself up. Competence becomes a real competitive advantage — not just a theoretical one.

The question Lattner asks every engineer is direct:

"When the hype settles — and it always settles — where are you? Have you grown? Or did you spend two years pulling levers, hoping AI would make you better by osmosis?"

How I actually use AI

Lattner uses AI. He talks about a 10–20% productivity gain. But he maintains what he calls a tight iteration loop: edit, compile, run, debug. At every moment, he knows what his code is doing.

That's exactly my approach.

AI helps me:

• Explore an API I'm not yet familiar with
• Generate boilerplate I don't want to write by hand
• Challenge my architecture before committing to it
• Spot edge cases I might have missed

What it doesn't do for me:

• Decide the architecture
• Understand the business constraints
• Maintain consistency over time
• Validate that what comes out makes sense in the broader context

The difference between the two is the difference between a tool and a crutch. A tool amplifies what you already know how to do. A crutch compensates for what you don't know — and stops you from learning.

What I take away

Lattner's interview isn't an anti-AI manifesto. It's a reminder that the fundamentals aren't obsolete.

Architecture. Understanding. Craftsmanship.

The same principles that allowed LLVM to run 25 years after it was created. The same ones that make a well-designed iOS app hold up, evolve, and survive platform changes.

AI is a remarkable tool. But tools have never replaced judgement.

And judgement is built in the trenches — in the bugs you spent three days understanding, in the painful refactors you saw through to the end, in the architectural decisions you owned over time.

It's not what AI generates that defines your value as a developer. It's what you understand about what it generates.

The full interview is available onfast.ai_. Highly recommend it.
Here's the video.

_