AI Isn’t Expensive. Your Architecture Is.

I keep seeing people panic about AI costs, token usage, shrinking context windows, and how "AI stops being useful" once a project gets large.

But the problem is not the AI. And most of the time, it's not even the prompt.

The real problem is how we build software

For years, we repeated the same engineering principles:

• keep code clear and concise,
• separate responsibilities,
• isolate behavior through architecture,
• use packages and modules with specific purposes,
• design systems that can scale without collapsing.

Then generative AI showed up, and suddenly everyone wants to ignore decades of software engineering by dumping an entire application into a single gigantic prompt.

Honey, no. That's not how it works. And I seriously doubt it ever will.

If you want to build software seriously with AI, you need to go back to fundamentals:

• small modules,
• isolated responsibilities,
• focused functions,
• bounded context,
• clear dependency structures,
• architecture before generation.

AI performs dramatically better when the system itself is well designed. Because AI does not magically "understand your product." It operates on context. And the more chaotic your context becomes, the more tokens you waste, the more hallucinations appear, and the more expensive everything gets.

A lot of developers are trying to use AI as a replacement for architecture. But AI does not replace architecture. It makes architecture even more important.

Interactive // What a change pulls into context

Pick the module you want to change. Compare a monolithic prompt with a modular architecture, then improvise and mix responsibilities.

Monolithic prompt Modular architecture

Improvise: mix responsibilities

Module to change

UI shell Auth Users Catalog Orders Billing Notifications Search Reports

ChangedLoaded into context

3 of 9 modules in context

Bounded context: only the module you are changing and the contracts it depends on.

At enterprise scale, yes, token consumption can become massive. But even as a solo developer and product manager, I can build highly scalable systems while almost never running out of context.

And the few times it happened?

It was because I drifted away from the architecture. I started improvising features. I tested unnecessary ideas. I mixed responsibilities that should have stayed isolated. That's when context explodes. That's when prompts become massive. That's when AI output starts degrading.

Because the problem was never the model. Maybe a few times it was. But the real problem was always the system.

Today more than ever, building with AI requires thinking about software like an actual old-school software developer:

• defining boundaries,
• designing contracts,
• separating domains,
• planning scalability,
• creating reusable packages,
• adding features without breaking the rest of the system.

Architecture first, features second

This requires skilled developers, yes. But more than anything, it requires a mindset shift: think about features from an architectural point of view. Not just "what do I want this to do?" but "how do I add this without breaking what already exists?"

Diagram // A feature, seen architecturally

1. 01Featurewhat do I want this to do?
2. 02Boundarieswhich domain does it belong to?
3. 03Contractswhat does it depend on?
4. 04Generationwith bounded context, without breaking what exists

Sure, for an MVP or proof of concept, you can throw everything together and move fast.

But if you never do the hard work afterward (isolating responsibilities, restructuring the architecture, organizing the system properly), then AI eventually becomes an operational nightmare.

And that's when everyone says: "AI is too expensive."

No.

Improvisation is expensive. AI just exposes it faster.

But here's where it gets complicated

Everything I've described so far is manageable when you're a solo developer. You make the architectural decisions. You set the boundaries. You control the chaos.

Now add a product team. Add stakeholders who think in features, not systems. Add developers who each have their own interpretation of what "clean code" means. Add sprint pressure, roadmap commitments, and a CEO who just saw a demo and wants that feature by Friday.

Suddenly, "think architecture before features" stops being a technical principle and becomes an organizational challenge. And most teams are completely unprepared for it.

In the next article, I'll dig into exactly that: how architectural thinking needs to live not just in the codebase, but in how product and development teams are structured, how they communicate, and how they make decisions together before the AI even opens a file.

See you soon.