You don't have to be technical to own the architecture

AI is changing everything. And it's changing nothing at all. All at the same time.

On social media you hear about new tools, new platforms, and new models, every single day. But since they're always changing, those can't be the real moat. Right?

So how do you know what to embrace? How do you figure out what you lean on, or what you trust?

In other words, when your time is as scarce as any other point in your life (and maybe feels even more pressing), what do you spend time learning?

Domains, Systems Thinking & Architecture

I'm going to suggest three ways to invest your time:

First, there's your domain. You already know things about your customers, your industry, and the dynamics of your operations. That's a data set no one else knows as well as you do. But you know even more than that, you know the exceptions and nuances. AI doesn't and can't. So dig in, go deeper, and learn more about your domain.

Second, there's systems thinking. It's the way things connect. When one thing happens, you know and predict what other things may happen, because you know the connections that others may miss. If a decision in one part of the business will impact 4 other parts of your business, you can find the leverage faster than any AI tools that run towards the symptoms.

Lastly, there's architecture. This is what most people skip over when they ask GPT 5.5 or Claude Code to build them software. They're delegating the load-bearing decisions to an AI that has tons of downstream consequences. But that's where you want to spend more time working out the specifics about what you care about (even if you don't think of it as 'architecture').

Non-Obvious Examples of Architecture

The other day I told you about a Lovable prototype I generated, to help with a conversation with my buddy Aaron.

I also told you that I'd circle back to tell you more. And when I mentioned "architecture" just now, I can imagine you might have thought, to yourself, I don't know anything about architecture.

But I was clear to say, keep the "core decisions about what you care about" as one of those areas you focus on. And while I call it architecture, it doesn't have to be deeply technical.

Here's what I would have written to Lovable after it first generated this prototype:

When you build this app, please follow these rules and tell me explicitly when you've done each one:

No secrets in the repo. Put API keys, passwords, and tokens in environment variables. Make sure the file holding them (usually .env) is in .gitignore from the very first commit. Confirm in writing: "no secrets are committed to git."

Server-side rules, not just screen rules. For every rule like "only the owner can edit this" or "only paying users can do X" or "max 5 per account", enforce it in the database or backend, not only by hiding the button. Tell me which rules are enforced where.

Show me errors. When something fails (a save, a login, a payment), I want a visible message. Never swallow errors silently. If you call something and it returns an error, show it to the user or log it where I can see it.

Tell me what happens if two people click at the same time. For anything with a limit ("first 10 signups," "claim this slot," "only one winner"), explain how you prevent both people from succeeding. If you can't, flag it.

Tell me what happens when a second customer / group / team signs up. Will they see each other's data? If this app is supposed to be private per account, show me the rule that enforces that.

Confirmations should reflect reality. Don't show "Saved!" unless it actually saved. Don't show "Sent!" unless it actually sent. If part of the operation failed, say so.

Test with two accounts. Before saying "done," walk me through how you tested it as User A and User B logged in at the same time, and what each one sees.

Don't invent loading states. If data is loading, show a loading state. If it's empty, show an empty state. If it failed, show a failed state. Three different things, three different screens.

Doesn't come across as architecture, does it? Because it doesn't use the words "scale" or "concurrency". But it's what I care about. And it's those load-bearing decisions I was talking about.

Some Things Will Never Change

Here's what I know, that single write-up would prevent the majority of issues in a typical AI-generated app.

But I also know that Lovable isn't the only product of its kind. Replit and others exist. And more will come. That's why this isn't about Lovable.

And it's not about LLM models, those will change too. And it's not harness solutions (Claude Code, Codex, Command Code, Hermes). Those will change.

In the world of AI, three things are going to matter: your domain expertise, systems thinking, and architecture. Because those things will never change.