Can AI write functional specs? Not on the system — on structured data

Functional specs are the most expensive text in SAP projects. Someone has to understand what the system does today, what it should do tomorrow, and write both down well enough for business, development and test to work from it. Weeks of effort, tied up in exactly the people you need for decisions.

So the obvious question: can AI take that over?

The obvious route — and why it wobbles

The most tempting setup is quick to build: a coding agent like Claude Code, an ADT connection into the system, and the instruction “read the purchasing process and write a functional spec”. Technically, this works. The agent reads code, follows calls, looks into customizing tables. You can watch it happen.

Except: it runs for a very long time — and nobody knows when it is done. That is not a patience problem, it is a structural one:

1. No stopping criterion. An agent working its way through a grown system has no map. It does not know what it has not seen yet — so it cannot know when the picture is complete. It stops when it runs out of steps.
2. The path is arbitrary. Where the agent looks first decides what it finds. Two runs on the same question produce two different specs. For a document a project is built on, that is a serious problem.
3. Code does not show usage. Reading a Z program says nothing about whether anyone runs it. Reading customizing says nothing about which process variant carries the volume. Yet that distinction is what every scoping decision rests on.
4. The output reads well. That is the treacherous part. A fluent, plausible-sounding functional spec whose gaps only surface during testing is more expensive than no spec at all.

On top of that comes the architectural price: an agent with an open connection into the system, deciding at runtime what to read. Why that deserves its own discussion is covered in attached vs. detached.

Where the real dividing line runs

The difference is not a matter of taste. Language models are strong at connecting, organizing and producing language. They are weak at establishing completeness on their own. Put both into one run, and the weakness ends up in the foundation of the result.

The structured approach

The order is what makes the difference:

• Extract. A defined set of data leaves the SAP system once — document data, customizing, repository information, usage data. Defined, not agent-driven.
• Structure. From that, the as-is picture is built deterministically: the real end-to-end processes from the document flows, a feature map of what is implemented and actually used, the custom developments with their business context and usage, the master data quality. No model involved — just data.
• Then let AI write. Only now does the AI come in, on a body of information that is already complete, named and cross-linked. It has nothing left to search for. It organizes, condenses and writes — with references to concrete processes, features and objects you can open and check.

What comes out is verifiable. Every statement in the spec hangs on a data point, and the extract is the complete record of what it was based on. A second run yields the same foundation — not the same prose, but the same facts.

And something else becomes possible that a free-roaming agent structurally cannot offer: traceable decisions. Why is one process variant in scope and another not? Why is this Z program flagged for retirement? Because the source sits right next to it — the document counts, the usage data, the concrete object. Every judgement in the spec can be opened up down to the data it came from, and contradicted there. With an agent on the system, all that remains in the end is a text and the question of what it actually rests on.

A functional spec always has a goal

An as-is picture is not yet a spec. You write a functional spec because you intend to do something — and that intent determines which slice of the as-is picture matters and where the to-be discussion even starts:

• Optimizing what exists — reduce variants, retire special paths, win back standard.
• New modules or processes — what groundwork already exists, which master data holds up, where it breaks.
• Brownfield, bluefield, greenfield — each of the three needs a different spec from the same set of facts: what carries over, what gets rebuilt, what is dropped. And how far the lived process sits from the public cloud standard.

Same structured foundation, different viewing angles. That is the real gain: you gather once and design many times, instead of going back into the system for every new question.

What honesty requires

Two limits worth stating plainly.

Quality depends on the model. Which LLM provider sits behind the writing step makes a noticeable difference in structure, precision and language. A structured foundation lifts every model — but it does not turn a weak model into a strong one.

AI writes drafts, not decisions. A generated functional spec is a solid first pass that saves weeks of legwork. What is kept, cut and decided differently remains the job of the people accountable for the project. The difference from the agent run is this: you argue about content instead of about whether the basis holds at all.

The point is not to keep AI away from the system — it is to take off its plate the work it was never built for.

---

This is exactly how Conjola is built: one extract from your system, turned within roughly 24 hours into a structured as-is picture of processes, feature map, custom code and master data — plus a knowledge base where your specs live right next to that data and link into it. That is where your functional specs get written with AI support: you write, the assistant drafts chapters, condenses them and checks them against the real data — working exclusively on that body of data. The document stays yours. With no live connection into your SAP system — detached throughout.