The bar for building software has shifted. It used to be: can you build it? Now, with AI, almost anyone can.

With tools like Google Antigravity, the cost to create an application has dropped dramatically. You can delegate entire tasks to AI agents. You can ship without fully understanding what you shipped.

But understanding isn't required to build anymore. It is required to maintain.

Building an app is no longer impressive on its own. The new question is: how long did you maintain it? Because that takes real understanding.

Why Maintenance Is the New Proof

I've been reading Clean Code while refactoring CodeMaster. Each chapter sends me back through the codebase looking for places to improve. Here's what I've learned: when you're working with a mature codebase, most of the decisions have already been made.

That's a double-edged sword. Early on, large sweeping changes were easy because my patterns weren't established yet. The code was flexible. But as the project grew, those early decisions hardened into constraints I had to live with or fight against.

Some of those early decisions were mistakes I didn't recognize until maintenance forced me to.

The Mantine Problem

When I started CodeMaster, I asked AI what stack would make the most sense for a Chrome extension. I didn't look too deeply into the npm packages it recommended. I searched them to make sure they existed and that the documentation said they could do what I needed. That was enough to move forward.

Mantine was one of those choices. A React component library. Clean, well-documented, easy to use. AI suggested it, the docs looked good, so I went with it.

Towards the end of the project, right before releasing to the Chrome Store, I noticed something: I had a lot of Mantine style overrides in my CSS. When I was implementing the onboarding flow, I was constantly fighting with Mantine's styles. Every component needed tweaks. Every layout required workarounds.

Then I stopped and asked: why am I doing all this work to fix a problem that shouldn't exist?

Mantine is designed for standalone applications. I was using it in a content script that overlays LeetCode pages. The styles were conflicting because the library wasn't meant for my use case. I had to pull Mantine out of the content script entirely. I still use it for the dashboard pages where it works fine, but that refactor cost me time I wouldn't have spent if I'd understood the constraint from the start.

AI recommended the library. AI couldn't tell me it was wrong for my architecture. That required understanding the system I was building.

Why Architecture Matters Now

The Mantine problem wasn't just a maintenance issue. It was an architecture issue. I didn't understand how the pieces of my application fit together.

AI can write components. It can't decide where they belong.

It used to be that you had to build applications backwards. You had the big picture of what you wanted, then you broke it into confetti and had to piece it back together. You built your UI component by component, like assembling a puzzle one corner at a time. Then you moved to your backend. Then you figured out your services.

Now you can bring your full idea to AI. We don't have to carry the little pieces of the picture anymore. AI handles the confetti.

So what's left for the developer? Seeing how the pieces fit. Knowing which pieces to use in the first place. Knowing that a standalone component library doesn't belong in a content script. That's architecture—understanding your system well enough to make decisions AI can't make for you.

I don't think AI will ever create an application end-to-end with just one prompt. It works in controlled environments. "Build a Facebook clone" gets close because there's plenty of documentation. But for something truly new, AI can only remix the old. It can tell you what's likely to work and what won't. It can't envision what doesn't exist yet.

And it can't see your whole system at once. It doesn't know that your Chrome extension has three different contexts: background script, content script, dashboard. Each with different constraints. It doesn't know that a choice that works in one context creates problems in another. Only you can hold that picture in your head.

The New Developer

With this level of abstraction, you need a new type of developer. One who can zoom in and out.

Zoom in: debug the CSS conflict, trace the state bug, understand why this specific component breaks in this specific context. Zoom out: see how the content script relates to the background script, understand why a library that works in one place fails in another, hold the whole architecture in your head.

AI is excellent at the zoomed-in work. It can write the function, fix the syntax, suggest the solution. But it can't zoom out. It doesn't have the context. It doesn't know your system.

Creation is cheap now. The value is in understanding: how the system is designed, how long you can keep it running, how deeply you know what you built.

The most important question when building is why. Why this architecture? Why this tool? Why does this piece belong here and not there? Features don't matter unless they're connected to a reason. The applications that succeed have a clear why behind every decision.

AI doesn't know your why. That's still yours.