AI Is a Brilliant Builder. It Still Needs an Architect.

Why “AI-powered” SAP transformation still needs the one thing AI cannot yet provide on its own: Design.

I’ve been in the technology space for a long time - my grey hair is proof of it. There’s a lot I’ve seen. More than twenty years ago, Netscape, then the dominant browser on the internet, decided to throw its codebase away and rewrite it from scratch. The code was old and messy. A clean rewrite would be faster in the long run, management reasoned. It wasn’t. During the three-year rewrite, Netscape lost its market to a competitor that kept shipping. In a famous essay on that decision, Joel Spolsky, a Microsoft veteran who had become one of the most-read voices in software engineering, argued that the crufty-looking parts of a mature codebase encode “hard-earned knowledge about corner cases and weird bugs”, knowledge you throw away when you start over.

The story is old. The lesson is not. And it is about to be repeated at enterprise scale, or better at SAP scale, by organizations taking the wrong lesson from the AI hype of 2026.

A new chorus of vendors has arrived with a compelling offer: AI will rewrite all of your custom code for you. For CIOs and CFOs under real pressure, with tight budgets, looming S/4HANA deadlines, and enormous volumes of custom code, the appeal is obvious. For those of us who have watched rewrites fail before, it is a familiar scene.

Let me be clear on where I stand. I am not anti-AI. Embedding AI inside our own transformation platform has been one of the most exciting pieces of engineering we have done in years. Coding assistants help our engineers move faster. Agentic systems chain complex tasks together and produce in minutes what used to take hours. When AI is given the right context and the right boundaries, it is one of the real productivity breakthroughs of my career.

That is exactly why the title of this post deserves explaining. AI is a brilliant builder. It still needs an architect. A transformation without architecture is not a transformation — it is a rebuild. And rebuilding decades of tested, battle-hardened SAP custom code is almost always the most expensive path, measured in dollars and in years, disguised as the shortcut.

Your real asset is the design inside the code.

Here is a truth I would like more SAP leaders to internalize: the custom code in your landscape is not the only asset. The design embedded in it matters as much; it is the foundation the code rests on.

By design, I don’t mean a slide deck full of boxes and arrows, and I don’t mean what a product manager sketches for a new feature. I mean something much bigger: the entire accumulated intent that sits behind your running system. Decades of business requirements, process flows, edge cases, regulatory answers, and exception handling, all compounded over time as new rules were layered on top of old ones and re-adjusted in the code. That compounding is the point; a modern “requirements document” does not capture it, because it was never a single document. It is the record of what the system means, which is a different thing from the code that implements it.

At this point, a reasonable counter-argument appears. Can’t AI read the source code, infer the design from it, and generate a new, modern implementation that preserves the same behavior? This is the pitch behind several AI-only SAP transformation tools on the market today. On paper, it is elegant. In practice, it is more fragile than it looks.

Source code is implementation, not intent. A line that filters by a particular region code might be capturing a deliberate regulatory requirement — or it might be a workaround for a bug that was fixed upstream fifteen years ago but never cleaned up here. Only someone with context can tell the difference. AI sees the same signal in both cases.

And the workshop is not in the codebase. The design of a business process lives in the discussions, trade-offs, and alternatives that people considered and rejected. The code records only the winning decision, not why it won or what else was on the table. When AI “extracts the design” from code, it is really extracting a reconstruction of the winning answer, without any of the context that makes it safe to change, preserve, or regenerate.

Those Z-programs and append structures did not appear by accident. Each one was a deliberate answer to a question the standard could not solve at the time: how this company prices a customer, how it routes an exception, how it meets a regulatory obligation specific to its geography or industry. Some of those answers were elegant, others were expedient, but your company reached its current market position through them, not despite them. That is the Netscape lesson transposed to SAP: what looks like crufty legacy code is often the written record of decisions that no one re-documented after the workshop.

My friend Chris Hanshew, our VP Product, frames this same insight from the transformation side in his piece on Repository Simplification: the conversation should not be “revert to standard,” it should be “simplify deliberately” – retiring what no longer serves a purpose, adopting standard where it now genuinely covers the need, and modernizing what must stay custom so it works with SAP’s architecture instead of around it. That distinction is the whole game.

Notice what “simplify deliberately” actually is – it is itself a design act. It is the deliberate decision about which custom logic still earns its place, which should retire, and which must be modernized to work with SAP’s new architecture. And that decision becomes the design we then hand to the machine – to rules where rules suffice, and to AI where judgment is needed. Seen that way, AI is not a substitute for design. It is the efficient way to implement a deliberate design, once we have one.

What AI cannot do, the uncomfortable evidence

I called AI a builder rather than an architect. Here is why that framing is accurate rather than rhetorical.

AI today is, at its core, a very sophisticated pattern-recognition engine with a strong command of language. That is genuinely useful. It can summarize code, identify structural similarities, and propose refactoring candidates. What it does not do is stop and ask a clarifying question when the requirements are contradictory. It does not sit in a workshop and reconcile the sales team’s notion of “customer priority” with operations’ version of the same term. It does not have good judgment. And this is the subtle part: AI always produces a judgment, confidently, every time it is asked. An untrained developer reads the plausible-sounding answer and acts on it. But a judgment without the right context behind it is a guess dressed up as a conclusion. Given the raw source code, the model’s verdicts are frequently wrong. Given a structured representation of your existing design and rules, they improve dramatically. The quality of AI judgment is a direct function of the quality of context it is given.

Under uncertainty, what it does instead is hallucinate plausibly. Published research from 2025 and 2026 is sobering. Hallucination rates on enterprise benchmarks range from 15% to 52% across commercial LLMs. Code-generation tasks trigger hallucinations on up to 99% of prompts involving fictitious libraries. One large study found that nearly 20% of package recommendations pointed to libraries that did not exist.

Now scale that to an SAP custom code base of millions of lines. Even a best-in-class 3% hallucination rate means hundreds of wrong assumptions, silently baked into generated code. These errors do not surface in the vendor demo. They surface in the month-end close.

Chris has made the same point from the engineering side: autonomous agents and blind trust do not scale into the complexity of connected SAP development. He is right. The question is not whether AI can write ABAP. It is whether AI, left unsupervised, can be trusted with thirty years of your company’s operating logic.

AI + design = scalable modernization

The math only gets worse at scale. In our own work, the median SAP custom code base we address runs around two million lines; the largest we have seen reached twenty million. A volume that size is impressive whether you intend to re-document it, re-design it, or re-write it, and sobering when you realize AI is being proposed to do all three at once. That is why I keep coming back to the phrase AI needs design. It is also the posture we take at smartShift.

Our patented approach does two things in sequence. First, a rule-based engine parses the entire custom codebase into a structured metamodel: a queryable representation of every object, every dependency, and every pattern. This is boring, precise, engineering work. For the technical modernization — outdated coding practices, technical debt, Level-C and Level-D customizations that need to move to SAP’s Level-A or Level-B extensibility patterns — rules do the job better than any language model. Our automation runs at 99.999% precision across millions of lines of code. Compared with the assumed 3% or, in the worst case, 15% to 52% hallucination rates I cited earlier, the case for determinism where determinism is available makes itself.

Second, for the work that cannot be reduced to rules, the functional redesigns, the places where the standard has changed shape, and a table no longer exists, AI becomes genuinely valuable. Especially because we are not asking it to reverse-engineer a thousand objects from raw source. We hand it precisely the slice of the metamodel that is relevant. That is the difference between a model hallucinating its context and a model reasoning over a structured context.

This is what I mean when I say AI needs design. Not AI instead of design. AI with design, inside an engineering discipline, fed the right representation of your existing assets. It is also why our approach aligns naturally with SAP’s Clean Core direction: our rules do the heavy lifting of moving modifications and implicit enhancements into released extensibility patterns, and AI contributes where human-readable, stakeholder-aligned decisions are actually required. Our CTO, Jagdish, has written in more depth about how this scales to enterprise custom code bases with millions of lines. For customer examples and the full picture, see our Automation Engine article.

Three questions to ask before you hand over your SAP custom code base

If you are evaluating an “AI-powered” SAP transformation offer in 2026, I would ask three questions before signing anything.

One: What design is the AI being given to work from, or is it being asked to invent the design by reading code?

Two: What does the vendor do when the AI is wrong? Rules? Human review? Another AI?

Three: At the end of this, will we still own the logic that made our company competitive, or will we own a plausible-looking replacement of it?

The goal of an S/4HANA transformation is not to arrive at S/4HANA. The goal is to arrive there without losing what made your business competitive along the way. AI is a powerful ally in that work. It is not a substitute for the design that got you here, and it is not yet capable of producing the design that will get you where you are going.

It is a brilliant builder. Use it. Just make sure there is still an architect in the room.