Build to Last, eight months on: code gets cheaper, judgment gets pricier

Recently I read a piece on fast.ai called Build to Last.

It isn’t new. It came out at the end of October 2025, almost eight months ago.

But I think it’s worth rereading today.

Because in the past eight months, AI coding agents have clearly gotten stronger again: they no longer just fill in a few lines of code for you; they can read a codebase, edit multiple files, run tests, fix bugs, even complete parts of a full development task.

That’s exactly why the question in this piece has become sharper:

As AI gets better and better at writing code, what do humans still need to understand?

1. What is this piece about?

Build to Last comes from fast.ai.

Its main body is a conversation between Jeremy Howard and Chris Lattner.

Jeremy Howard is the founder of fast.ai and has long focused on AI education and learning by doing.

Chris Lattner is a key figure behind LLVM, Clang, Swift and MLIR, and a co-founder of Modular and Mojo.

If ordinary app development is like building a house, Chris Lattner is more like someone helping design “the foundations, rebar and construction methods of the modern software world.”

So the angle of this piece isn’t “how to make a quick demo with AI,” but:

how to keep building software that can truly withstand long-term evolution in the AI era.

2. The core ideas of the original

The piece isn’t against AI writing code.

What it’s against is:

people no longer understanding what they’re building because AI can write the code.

It discusses a few core concepts.

First, software craftsmanship

You can think of it as the craft, or artisanship, of software.

It isn’t about writing pretty code, nor is it engineers’ professional vanity.

It’s closer to a kind of responsibility:

• understanding what problem you’re solving;
• understanding why the system is designed this way;
• addressing the root cause when fixing a bug, not just making the error go away;
• writing things others can understand and maintain;
• making the system clearer, not messier, with every bit of building.

The piece stresses that AI can generate code, but it can’t own the team’s understanding of the system for them.

Second, architecture

Architecture here doesn’t mean drawing a complicated technical diagram.

What matters more is:

• where a change should happen;
• which modules can change independently;
• whether a bug stays local or spreads across the whole system;
• whether the system gets clearer or harder to maintain as new features are added.

A bad system doesn’t die right away.

It usually goes bad like this:

each time you can “patch it for now,” but each patch makes it a little harder to understand.

In the end the system still runs, but nobody dares touch it.

Third, dogfooding

Dogfooding means the team really uses its own product.

The piece compares Swift and Mojo.

A product that lives only in mockups, meetings and test environments for a long time can easily look reasonable.

But once you actually use it yourself every day, you run much faster into the problems users find hard to describe:

• where it’s slow;
• where it’s confusing;
• which flow is hostile to humans;
• which error message drives you up the wall;
• which feature looks useful but has no value in real use.

Fourth, a tight iteration loop

That is, a tight feedback loop.

Don’t have AI change a whole pile of things at once and only discover at the end that everything’s a mess.

A better way is:

change a little, run it; look at the result, understand the change; change a little more, verify again.

The piece argues that people should stay in continuous contact with the system, rather than throwing the whole process into an AI black box.

3. Eight months on, how much of this still holds?

I think it falls into three groups.

What still holds

1. “It runs” still isn’t “I understand it”

AI really is stronger now.

But a feature running still doesn’t mean you understand:

• where the data comes from;
• where state changes;
• where permissions are checked;
• how errors are handled;
• whether future features will break the current structure.

This matters especially for indie developers.

Because when you build a product alone, nobody catches you.

If the project becomes a black box that even you don’t dare change, then although you shipped it, it no longer really belongs to you.

2. The verification environment matters more

We might once have thought that the bottleneck in AI coding was the model not being smart enough.

But it’s becoming clearer and clearer that:

whether AI does a good job depends largely on whether the task is clear, whether the codebase is well structured, whether the tests can run, and whether errors can be fed back to it.

In other words, the important skill in the future isn’t only “can you write prompts.”

It also includes:

whether you can build AI a clear, verifiable, iterable working environment.

3. Professional judgment hasn’t disappeared; it’s worth more

AI can offer lots of options.

But it can’t judge for you:

• whether this problem is worth solving;
• whether this complexity is necessary;
• whether this technical debt is acceptable;
• whether now is the time to validate fast or to lay foundations slowly;
• where you can cut corners, and where you absolutely can’t.

As code gets cheaper, judgment gets more expensive.

What’s been challenged

1. AI understands systems better than it did eight months ago

If the piece implicitly assumed that “AI doesn’t really understand complex systems yet,” that needs revising today.

Today’s coding agents can read many files, track context, run tests and keep editing based on errors.

They’re no longer just fancy autocomplete.

On tasks with clear boundaries, good tests and clear goals, AI can already do a great deal of real development work.

So we can no longer simply say:

“AI doesn’t understand systems.”

A more accurate statement is:

AI can understand part of a system’s explicit structure, but still struggles to hold the full implicit context.

It can read the code.

But it doesn’t necessarily know:

• why a compromise was made three years ago;
• which customer depends on some odd piece of logic;
• which feature looks useless but can’t be deleted;
• which requirement is really about business, compliance or organizational issues.

2. “Build to last” doesn’t suit every stage

Chris Lattner works on infrastructure like LLVM, Swift and MLIR.

Those systems naturally need to be long-lived, stable and able to evolve.

But when an indie developer builds an early MVP, the goal often isn’t “a ten-year architecture.”

The goal is to first find out:

Does anyone need it? Do users understand it? Are they willing to start using it? Is this problem worth continuing with?

If you design at infrastructure level from the start, it easily turns into sophisticated procrastination.

So the piece can’t be read as:

“Every small product should pursue perfect architecture from day one.”

A more reasonable order is:

When you don’t yet know whether it’s worth doing, build to learn. Once you’ve confirmed it’s worth doing long term, build to last.

What’s been borne out

1. The stronger AI gets, the more it needs people to define boundaries

AI is best at tasks with clear boundaries.

For example:

• fixing a specific bug;
• adding a particular field;
• refactoring a well-defined module;
• continuing to edit based on failing tests;
• explaining why a piece of code goes wrong.

But many of the truly important problems have fuzzy boundaries to begin with.

For example:

• Why exactly aren’t users using it?
• Is the product positioning wrong?
• Should I keep going in this direction?
• Is this feature necessary, or am I avoiding customer acquisition?
• How small should the current minimum viable version really be?

AI can help you analyze these questions, but it can’t carry the judgment for you.

2. Only knowing how to “have AI generate it” will be less and less enough

AI coding has lowered the barrier to making things.

That’s great.

But it also means more and more people will be able to make demos.

What becomes truly scarce may be:

• whether you can define a real problem;
• whether you can judge what’s worth doing;
• whether you can understand the critical parts of the system;
• whether you can keep correcting the product from user feedback;
• whether you can make clear-headed trade-offs between speed and quality.

In other words, the AI era doesn’t mean skills aren’t needed.

It’s just that the center of gravity of skill has shifted.

4. Takeaways for indie developers

I think what’s most valuable in this piece for indie developers isn’t telling you to write elegant code.

It’s the reminder:

don’t build a product you don’t understand and don’t dare maintain.

It breaks down into a few concrete suggestions.

1. Early on, build to learn first

Before the need is validated, don’t over-engineer.

What you really need to validate is:

• whether users have this problem;
• whether they’re willing to start using it;
• whether they’re willing to complete the key flow;
• whether they come back;
• whether they’re willing to pay or recommend it.

At this stage, AI helping you build it fast is a good thing.

Don’t chase perfect architecture from the start.

2. But the critical parts can’t be a complete black box

Even if you’re not an engineer, you should at least understand:

• where the core data lives;
• how user login is handled;
• where permissions are checked;
• which information involves privacy;
• how to locate a problem when something goes wrong;
• where it’s deployed;
• what would be affected if the database went wrong.

You don’t have to write every line of code yourself.

But you need to know where the product’s skeleton is.

3. Have AI make smaller changes each time

Don’t keep throwing AI a huge task like:

“Refactor my whole product.”

A better way is:

“First explain which files you plan to change.” “Why change it this way?” “How will this change be verified?” “Is there a simpler option?” “If this change is wrong, where is it most likely to have an effect?”

An indie developer isn’t just AI’s client.

You should also be AI’s reviewer.

4. Treat AI as a learning tool, not just an outsourced engineer

Every time AI writes important code, you can ask a few more questions:

• What does this code do?
• Why is it in this file?
• What are the alternatives?
• Where is a bug most likely to show up here?
• How should I verify it myself?

If you understand the system a little better with each feature, AI isn’t just raising your output; it’s helping you build up skill.

If each time you just copy, run, hit an error and have AI fix it again, what you get may be a project, not a skill.

5. Takeaways for people working in the field

This piece isn’t only useful for indie developers.

It applies to product managers, designers and engineers too.

AI will make a lot of execution-type output cheap:

• copy;
• pages;
• demos;
• code;
• plans;
• summaries;
• test cases.

But that also means delivering these outputs alone may no longer be enough.

What matters more:

• whether you can define the right problem;
• whether you can judge what users really need;
• whether you can identify the risks behind a solution;
• whether you know when to go fast and when to go slow;
• whether you can give the team a shared understanding of the system;
• whether you can take responsibility for the results.

AI can boost execution.

But it won’t automatically give you judgment.

6. My own take

The piece is called Build to Last.

But I don’t want to read it as “everything should be built heavy.”

For indie developers, the more realistic version may be:

build to learn first, then build to last.

First reach real users in the fastest way and validate whether the problem holds.

If it doesn’t, let go gracefully.

If it does, then build seriously:

data structures, permissions, stability, maintainability, user experience, a long-term roadmap.

Otherwise you end up at one of two extremes:

At one end, you pursue long-termism too early, and before the product is validated, you’re already trapped by your own architecture.

At the other end, you only ever write throwaway code, and as soon as the product gets a few users, it starts turning into ruins.

The reminder this piece gives me is:

AI can help us build faster.

But we still have to decide:

what’s worth building; why to build it this way; where we can go fast; where we can’t cut corners; and whether this product can keep growing in the future.

Code may keep getting cheaper.

But understanding, judgment and a sense of responsibility may keep getting more expensive.