A few years back, when LLMs started showing up, the code produced for exotic languages like ABAP was of questionable quality. Not to mention when it came to SAP-specific frameworks like RAP, CAP or UI5. The LLMs weren’t trained for these “edge” scenarios. Focus on showcasing what’s possible to a greater technology savvy audience was important. Write working Python, JavaScript or Java code was more important. This has changed drastically. Over the years, LLMs were trained not only to produce working SAP code, but to understand SAP-specific frameworks. LLMs gained better knowledge of how SAP works and what to consider. This improvement was expected. It was just a matter of time.

Today we are in a phase that can hardly be described as “expected”. Copilot, Claude, Codex, etc. are used not only by developers, but by “regular” people too. Companies give their employees access to LLMs—be it Claude or a private LLM running on Ollama. People get access to a Web UI, agents, and MCP servers, while advanced users work directly in an IDE.

With this, the way problems are solved is changing. Connect the AI to your landscape and let it deploy the solution? Sure, why not? Most people would fail if tasked with copying & pasting the code, compiling it, and figuring out how to make it available in a DEV environment. The AI makes it possible to get a runnable piece of code deployed, which is good and bad at the same time. It is good because the result of the coding process can be evaluated in minutes. It is bad because AI-coded solutions are not created in a vacuum. There are established guidelines and rules that dictate how to implement solutions. Guidelines made for the sole reason of ensuring a certain quality standard before any code makes it into production, or even touches a DEV system.

You shall not pass

For decades, companies have created structures to ensure that not just anything gets implemented. This makes it hard to realize an idea that might solve a problem. However, it also means that companies have a full set of guidelines and rules available: quality gates, minimum requirements to fulfill, and so on. One goal of these gates is actually to filter out projects. Everything that violates the rules is marked as “not to be realized.” Even a good idea might not pass a quality gate if documentation is missing, a roadmap is lacking, or it is impossible to fund a 5-person support team. The list goes on and on.

These rules make sense, as companies do not want to have a solution in production that is actively used and has dependent users, only for the team behind it to be unable to support it or be dismantled after three months. These are “Zombie solutions”: looking alive from a distance, but already dead. As you can see, the rules and guidelines put up by companies make sense. And yes, the organizational structures put in place to enforce those rules are a real innovation killer at the same time. At least for regular people or smaller projects. Knowing how to follow a certain framework, handling documentation, releases, support options, naming conventions, communication, and access is complicated for a single person or a small team.

You might pass

It is not as if all projects that are not 100% aligned with corporate rules fail to pass. There are hard requirements that will stop you, but others can be negotiated. It is not uncommon to get a solution live by using a fast track or an exception, promising to close a gap later on. The promise usually goes like this: “Yes, I know something important is still missing, but I will solve it right after go-live.” If you are smiling right now, you have worked long enough in the IT business to know that this rarely happens. But having the illusion documented counts. At best, someone will promise to look at it again in two years. Sometimes, this is the only way to get things done.

Whether a project passes also depends on how many times missing requirements were actually implemented afterwards; and how often they weren’t. Often, the people who waived a project in the past get burned later on, making them less likely to let your project through a fast track. Do not put too much hope on the fast track or solving requirements later. Those exceptions are mostly granted for soft requirements. Things that can be measured are less likely to be waived. The reason is simple: anything code-related can be captured automatically. Some things that must be solved right now are mostly code-related, such as insufficient code coverage, missing unit tests, a lack of UI tests, or missing documentation.

AI shall pass

Especially those rules and KPIs centered around code are now solvable thanks to AI. Requirements regarding code quality, documentation, or generating training material: it’s just tokens. Before AI, this was almost unsolvable for a “regular” person. Today, it is solvable. Give the rules to the AI and make sure it follows them. The real challenge is making these rules available in an AI- and LLM-friendly format. An important task that will keep companies busy is transforming their guidelines into something their AI solution can understand—something the AI will follow and that can be measured.

The question to answer for AI-coded solutions will be: Did the AI follow my guidelines? Does it meet my quality criteria? And: How do we measure this? You can ask your AI: “Did you follow the rules?” But don’t trust the answer. You need a validation process that runs a quality gate over what your AI created, a process that checks the delivered artifacts.

An interesting fun fact is that the side responsible for delivering the metrics will change. Before AI, requirements that made people give up were subjective demands like: “Make it faster,” “It must look prettier,” or “It must be easier to understand.” Enterprise architects and governance teams could simply demand these. Now, they have to bring concrete metrics to the table.

The roles are inverted. Faster? OK, compared to what? How do you measure it? In short: define “faster.” Prettier? Does that mean using Tailwind CSS, Bootstrap, Material Design or following the Fiori guidelines? Show your design tokens. The ones previously demanding are now the ones that will need to remove the subjective dimension. If it is a deterministic measurement, the AI can deliver a solution that follows it.

AI coded? Good. Out of the door. Line on the left. One cross each

For companies, the task for the near future will be to ensure that their guidelines and measurements are available at a level of quality that allows them to produce solutions that meet requirements more or less automatically. Laying the foundation for AI-supported coding means providing these guidelines: blueprints that can be followed, clearly defined rules, and the ability to generate the metrics needed to know if a KPI is met.

Thanks to AI, more and more projects can now be realized. The frequently raised concern that too many projects will be created and organizations will fail to maintain quality is only true for companies that are unable to provide the tools to measure the results. The feedback must be provided in a way that an AI can understand, allowing it to start improving the solution until it meets the missing requirement. If there are rules regarding coding quality, automatic measurement must be possible. This can be a linter, ATC in the SAP universe, security checks, unit tests, documentation, and so on.

All of the heavy lifting can be done by AI. Small teams, people who are less exposed to the IT world but closer to the business world, and end users can get a working app deployed in PRD that follows company guidelines—provided the company ensures an AI-friendly process.

This is what companies should aim for, even when AI might not be seen as a critical driving force. Simply because everything regarding prodcut quality that is easily accessible can also already be used by humans. This is what companies should aim for, even if AI isn’t currently seen as a critical driving force. Simply because everything regarding product quality that is made easily accessible for AI can also immediately be used by humans.

Therefore, the call to action is: get rid of proprietary formats, locked documentation vaults, and any implicit assumptions. Write it down.

Corporate guidelines must be available as rules, tools and skills. If they cannot be used to define the harness of an agent, they need to be adjusted.