Most valuable asset in software development with AI: business knowledge
AI is currently seen as the solution to every problem. At the same time, it is also seen as a threat. People fear that entire software stacks are going to be rewritten by AI. AI will eliminate developer jobs and software companies. The expectation that AI will take over solution development is slightly exaggerated. Smaller, individual apps, for sure. But do not underestimate the complexity of a business process. The complexity of implementing a business process in code is not just about having some input forms to capture data, storing it in a database, and exposing it somehow to other services. There is much more to it.
Capturing all those direct and indirect requirements is the task of the people who work with the process. There is a reason why S/4HANA migration projects are such a challenge. These migrations do not only affect IT. A new ERP system is being implemented. Knowing your business processes is not optional. Many projects fail because companies fail to capture their business requirements correctly. They fail today because they do not fully understand how their processes work. They will fail when AI is added as well. The basic rule of shit in, shit out still applies.
You can already see a change in how AI is used in app development. Vibe coding is still heavily hyped in the press. For professional, enterprise-focused applications, however, the focus has shifted to context. Instructions have basically evolved from “write a form to capture data” to “write a form to capture chemical goods information in process step X and follow company requirements for Europe.” Context is becoming more and more important. The AI must be taught the context in which the application will operate. It is no longer just about a prompt. Markdown files, RAG systems, MCP servers, and access to corporate knowledge that explains how things are done are becoming increasingly important. Spec-driven development is gaining traction. Why is this feature being added? What does it do? How is it implemented? These questions need answers.
The more AI becomes involved in software development, the more important context becomes. Generating code is relatively easy. Understanding the business process, the requirements, the constraints, and the intent behind a solution is the hard part. AI does not remove the need for that knowledge. If anything, it makes it even more important. Code is becoming cheaper. Understanding the business is not. The challenge is no longer writing software. The challenge is knowing what software needs to do.
Once you have the requirements, how AI implements them becomes less important. One trend in AI-supported development is spec-driven development. Good specifications provide the information needed to implement a feature. When you can provide the specifications, and yes, this includes test data, the implementation party becomes replaceable, whether it is AI or humans. For AI, this even means that the coding quality of the LLM is no longer the main aspect. A trained LLM that knows exactly how to write, for example, ABAP certainly helps. It may be able to deliver a working solution faster than an LLM that is less specialized. However, both LLMs still have to implement the requirement and pass the business tests. If one solution is cleaner, nicer, or cooler, who cares? Just look at the code quality of many business applications. They were implemented by humans, often with questionable quality. Yet they work well enough to run the business process. In the end, the business requirement is what matters. The implementation must satisfy the specification and pass the tests. Everything else is secondary.
Fun fact: these requirements are something companies should already have. Or at least they should have a methodology for capturing them. Unfortunately, this is rarely the case. Providing the business context of a change. Defining what needs to be done. Understanding the effects on other components and the overall impact. Test cases, test data, validations. None of this is new. It is simply the process of capturing functional and non-functional requirements. In theory, this should be easy for any company. In practice, it often is not. As the typical S/4HANA project shows, there are gaps. Companies discover that business processes are not documented well enough, requirements are incomplete, exceptions are handled through tribal knowledge, and dependencies are not fully understood.
AI does not replace the need for requirements engineering. It turns requirements engineering into the bottleneck. The companies that know their processes will benefit from AI. The companies that do not will discover the gaps they have been living with for years. LLMs are brutal. Feed them incorrect information and you will get incorrect results. In some cases, they may even hide the errors behind plausible-looking answers. The less you know about your processes, requirements, data, and test cases, the more likely you are to run into serious problems. This is not a flaw of AI. It is a reflection of the information it receives. An LLM can only operate on the context it is given. If that context is incomplete, outdated, contradictory, or simply wrong, the generated solution will be as well.
For years, organizations could compensate for gaps in documentation and requirements with experienced employees who understood the process and could fill in the blanks. AI cannot do that reliably. It forces companies to make explicit what was previously implicit. In that sense, AI acts like a mirror. It exposes weaknesses in process knowledge, requirements management, test coverage, and data quality. Companies with strong foundations will move faster. Companies without them will discover that generating code was never the hard part.
What is needed is not just specification-driven development. It is not merely access to systems and a focus on development activities. What is needed is business context. In other words: business specification-driven development.
AI enables companies to develop the software the business actually needs without relying on developers to translate business requirements into code. For the first time in years, business teams could potentially return to delivering tailored solutions almost instantly. Instead of dealing with complex frameworks and technologies, they can focus on their actual business problems. But there is a catch: they often do not truly understand their own requirements. The struggles many S/4HANA projects face are rooted in a lack of understanding of the countless requirements, dependencies, and constraints that make business processes work the way they do. The technology is ready. The people are not.
Closing these gaps is mandatory for any AI-enabled business solution. Or, more accurately, for any business solution developed with the help of AI. Perhaps the better term is not AI-driven development, but AI-supported development. There is so much information that the business must provide before development can even begin that AI is only a small part of the overall process. If you cannot document your process step by step, in sufficient detail, including all functional and non-functional requirements, test scenarios, business rules, data requirements, exceptions, constraints, and expected outcomes, then you should rethink your approach to developing solutions with AI.
Summary
The value of AI is not that it eliminates the need for understanding the business. It is that it can dramatically accelerate implementation once that understanding exists. AI can generate code, designs, test cases, and documentation, but it cannot compensate for missing business knowledge.
AI does not remove complexity. It changes where complexity lives. The effort shifts from implementation to understanding and describing the business problem. The more AI becomes involved in software development, the more important context becomes. Technology is no longer the primary bottleneck. Understanding the business is.