The Data Architect in the Time of AI

🌐 Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 7 of 7 in the chapter Thinking Like a Data Architect, the first chapter of the Data Architect course. Each module stands on its own. Previous: Know Your Tools: The Nine Questions · Next: the next chapter: Data Modeling

The question this module answers: What does AI change for the data architect, and what doesn’t it change?

AI changes architecture, but maybe not in the way people first think.

Remember where this chapter started: I’ve spent most of my career as a builder. For most of that time, building software was expensive. You needed people with specialized skills, and writing code, building integrations, creating applications and testing all took time; even experimenting with an idea was a meaningful investment. AI is changing that equation. Today I can describe what I want and have AI generate a data model, Apex, a Flow, a Lightning component, an integration, tests or documentation remarkably quickly, and tomorrow it will do even more.

So it’s reasonable to ask: if AI can do so much of the building, what happens to the architect? I think the answer is that architecture becomes more important, not less.

AI Is a Rocket Booster

I’ve used this analogy in my talks:

AI is the rocket booster. Architecture is the guidance system.

AI gives us extraordinary acceleration. We can generate applications, data models, integrations, tests, and documentation faster than ever. But a rocket booster doesn’t decide where the rocket should go. It supplies thrust. The guidance system determines the course and makes corrections along the way.

Without sound guidance, more thrust doesn’t help. It gets you to the wrong destination faster. The architect’s job isn’t to slow everything down; it’s to make sure we’re accelerating in the right direction.

Image generated with AI.

Imagine an AI tool that builds an application ten times faster than we could before. That’s great if it’s the right application. But what if the data model is wrong, or we picked the wrong standard object, or misunderstood where the master data belongs, or the design works at today’s volume and collapses with another zero? AI hasn’t removed the mistake. It has helped us build the mistake faster, and build much more on top of it before anyone notices.

Cheap Implementation Moves the Value

When implementation is expensive, attention naturally goes to implementation: who can build it, how long it will take, whether it can be made to work at all. As implementation gets cheaper, a different question matters more: what should we build? That’s an architecture question.

AI can generate twenty objects; the data architect decides whether we should have five. AI can generate an integration; the architect decides whether the data should be copied at all. AI can create a field in seconds; the architect asks whether it has a clear meaning, an owner and a reason to exist. AI builds what we ask for, so the quality of what we ask for matters more than ever.

Generation Is Not Judgment

AI is very good at generating options, and that’s enormously useful. I ask it for three ways to model something, for the trade-offs, to challenge an architecture, to tell me what happens at 100 million records or where a design could fail, or to give me an alternative where Salesforce isn’t the system of record. I want architects doing this.

But generating options and judging them are different things. AI can tell me what Option A and Option B each offer. Someone still has to understand the business well enough to know which advantages matter, which constraints are real, what risk is acceptable, and when an answer is technically plausible but wrong for this organization. That’s judgment, and that’s architecture.

Here’s how that shows up in my own work. Within the last year, I’ve stopped writing most code myself. I give AI the details and ask it to generate the screens and the back-end code, and it’s remarkably good at it.

But it doesn’t step back and take a deeper analytical look. If there’s a flaw in the data model or the design, it doesn’t question it. It treats what’s already there as an assumption and builds on top of it, quickly and competently. It rarely stops to say, “Before I add this, the model you already have might be worth changing.” Looking at what exists and asking whether it’s right, not just whether we can build the next thing on it, is still the architect’s job. If you want AI to question an assumption, you have to ask it to.

The Reversibility Test Still Applies

Go back to module 3’s question: how difficult will this decision be to reverse? AI changes the cost of generating and changing software. It doesn’t change the cost of changing reality. Once 100 million records are loaded, they exist. Once twelve systems depend on an identifier, those dependencies exist. Once customers use a process, or analytics depend on what a field means, changing it has consequences. And once data has been shared somewhere it shouldn’t have been, no amount of new code puts it back.

Irreversible is still irreversible.

Agents Are a New Kind of Data Consumer

We used to design data for two kinds of consumer: humans and software. A person reads a record; a report, an integration or an application reads the data. Now there’s a third: agents. An agent may retrieve data, interpret it, combine it with other information, decide and act, sometimes with no human in between.

That raises the stakes. What a field means, who owns it, how current and trustworthy it is, whether it’s sensitive, whether an agent can and should see it, what happens when two sources disagree: these used to be documentation. Now they’re how an intelligent system understands the business.

And bad data doesn’t get smarter because AI reads it. Garbage in, garbage out still holds. Duplicate customers, unclear ownership, inconsistent identifiers and conflicting systems of record don’t go away when you connect an agent; the consequences just get more visible. A person looks at a field and knows nobody has updated it in three years. The agent doesn’t have that institutional knowledge, and it may act confidently on data everyone else quietly knew not to trust. Data architecture becomes part of AI architecture.

Watch for Schema Sprawl

AI also makes it incredibly easy to create things. Need another object, six more fields, another automation? Generate them. Each decision seems cheap, but remember architectural gravity from module 3: those objects and fields gather dependencies (automation, integrations, reports, agents), and soon you have a data model that nobody designed. It simply grew.

The architect has to be willing to ask, “Do we actually need this?” Sometimes the most valuable decision is not to create something. Good architecture is as much about what you leave out as what you put in.

Human Review Isn’t a Ceremony

When I say a human architect should review an AI-generated data model, I don’t mean “AI created it, and Steve looked at the diagram for five minutes and approved it.” That’s not oversight. The architect has to understand the model: why these objects, why these relationships, which alternatives were considered, where the keys and the master data are, what happens as volume grows, what the access implications are, and which trade-offs were made. If I can’t answer those, I don’t own the architecture; I rubber-stamped it. AI can contribute to an architecture, challenge it and document it, but the human architect has to be able to defend it.

The same goes for facts. I use AI constantly for learning and research, and my rule is trust but verify. Ask the question, ask for the explanation, the alternatives and a challenge to its own answer. Then, for anything that matters to your architecture, follow the link, read the documentation, check the limit, confirm the licensing and test the behavior. AI can be very convincing when it’s wrong, and telling facts from assumptions is now an even bigger part of the job.

AI Doesn’t Shorten the Journey

There’s a line I use when I talk about becoming an architect:

AI doesn’t shorten the journey. It can make every step count more.

You still need to understand data, security, integration, the platform and the business, and you still need the experience of making decisions and living with the consequences. AI can speed up your learning, show you scenarios you haven’t met, explain things, challenge you, help you build and give you a second set of eyes. Use all of it. Just don’t confuse an AI that knows the answer with you understanding the answer.

The Architect Directs

We started this chapter with the person holding the blueprint. AI gives that person extraordinary new tools: an assistant that can draw parts of the blueprint, research materials, propose alternatives, calculate loads, write the documentation and even spot problems you missed. Use it. But someone still has to understand the whole building, ask whether it’s the right building, know what happens when the requirements change and which decisions will be expensive to undo, and be accountable for the result.

That’s why this course’s last level is called Direct. You may not write every line of code, create every Flow or build every object. Someone still has to direct the solution, and that’s the architect. AI isn’t eliminating architecture; it’s changing where architects create value. It’s an extraordinary time to become one.

What an Architect Decides Here

• What should be built at all, now that building is cheap: which objects, fields and integrations earn their place.
• Which AI-generated options fit this business, and which are plausible but wrong.
• Which decisions AI is speeding past that will be expensive to reverse.
• What agents may read and act on, and whether the data is good and well described enough for them to do it.
• Which facts from AI need verifying before they shape the design.

That’s thinking like an architect in the time of AI.