Why I didn't build one AI assistant but a toolkit — and why the biggest lever isn't in implementation.

The Biggest Lever Isn't at the End of the Chain

When AI in software development is discussed today, it is almost always about the same thing: writing code faster. Coding assistants, agents, autocomplete with context awareness. That works — I work that way myself and have written a whole series about it.

But implementation is the last step of a long chain.

Before it come an idea, a requirement, a concept, alignment, a decomposition. If something goes wrong at one of those points, speeding up the last step helps little. You then build the wrong thing faster — at increased speed, at the most expensive point.

Barry Boehm described in 1981 that a defect in the requirements phase is orders of magnitude cheaper to fix than one in implementation. In my Agentic Coding series I used that as an argument for early checkpoints. But you can also turn it around:

If a defect is cheaper to fix up front, then an improvement up front is worth more as well.

That was exactly my motivation. The question was not how I write code faster, but where in the overall process the effort arises that nobody has on their books. In the age of AI and agentic coding, the answer for me clearly does not lie in implementation.

The Problem: Requirements Don't Arrive the Way They're Needed

In many companies there are departments that do nothing but produce requirements. In others, requirements come in from many different stakeholders. Both constellations share the same problem, but from different directions.

In the first case, a requirement comes in at cruising altitude and has to be fleshed out. Whoever does that has to understand the idea, know the company's own processes, and dock the requirement in such a way that nothing existing breaks. That is demanding work, and it depends on experience. Afterwards the result has to go into a company-specific structure so the next department can carry on.

In the second case, an external stakeholder delivers something that does not exist in that structure. Not out of negligence — they simply don't know it. The gaps then get filled by somebody else, in the form of follow-up questions.

Both cost time at the most expensive point: right at the front, before a single line of code exists.

Why a Chat Window Doesn't Solve It

That a language model can phrase requirements properly, check them for contradictions and structure them logically was clear quickly. I tried it on my own projects, refined the prompt, provided enough information (keyword: context engineering) — and the results got better with every pass.

Only none of that carried over. What works privately fails in a company at three points:

The output structure fluctuates. The same task, asked twice, delivers two different formats. I initially solved that by writing the desired structure into the prompt — a minute's work for me alone, an unsolvable problem for a department.

The quality depends on the prompt. Whoever knows how to ask gets good results. Whoever doesn't gets mediocre ones and takes them for the maximum. Prompt competence cannot be rolled out in a training session.

The model lacks access to everything the company already knows.

The obvious consequence would have been to train the business units. I consider that the wrong path:

Nobody should have to be retrained into a prompt engineer in order to do their actual job — at least not if a good working environment is part of the equation.

The Decision: Not a Tool, but a Toolkit

So I didn't build one assistant, but rather the ability to create them.

The starting point was an observation: producing a requirement is a structured procedure. There is an input, a processing step and an output in a defined form. What holds for requirements holds just as much for solution concepts, test cases and fault descriptions — only with different rules.

The flow is identical for every assistant. What differs are task, sources and schema.

An assistant therefore consists of four configurable parts:

Whoever sets up an assistant describes their domain knowledge — not their prompt knowledge. That is exactly where the difference lies between a tool and an enablement. A tool solves the case it was built for. A toolkit solves the cases nobody thought of while building it.

What That Covers

It isn't seven features, but four operations across different artifact types:

Plus an open chat for everything that follows no process — and for refining a generated result.

These four operations are not tied to software development. Every document-driven process knows them: something comes into being, gets converted into the next form, gets reviewed and gets traced back. What changes are the artifacts and the rules — not the architecture.

The Decisions I Made Along the Way

Structure as a Governance Mechanism

Language models are non-deterministic. The content fluctuates, and no schema changes that. But the form doesn't have to fluctuate — and a consistent form is the precondition for somebody without AI knowledge to review reliably.

"Is this requirement good?" is an open question. It requires knowing what good means and, at the same time, spotting what is missing although it isn't there. Under time pressure, that gets answered superficially. "Are all fields filled, and does the content fit in each case?" is a closed question. It can be worked off.

That is the real reason for fixed output schemas: not a love of order, but the condition for human-in-the-loop to scale at all.

The side effect is at least as important: what comes out structured can be processed further directly. Without structure, the effort merely shifts from writing to reformatting — and the time saved is gone again.

Context Was the Actual Bottleneck

At first, requirements were loaded via direct links. That was enough for phrasing and formal checks — but not for the questions that matter: does this requirement contradict an existing function? Does it extend one? Does it perhaps already exist?

What solved that was not a better prompt, but additional sources: automatically following the references in the loaded artifact, plus an upstream service providing solution concepts, documentation and the codebase.

That is the same finding as in a framework migration I accompanied in parallel — two completely different tasks, the same root cause. Why I turned that into a working rule and what it means in practice is covered in a post of its own:

→ Why AI assistants fail on context in the enterprise

Multimodality: Deliberately Left Out

Solution concepts contain diagrams, and often the decisive information sits exactly there. The system does not read them.

The direct route would have been to send images along and query a multimodal model. That changes the cost structure of the entire system, though: what used to be a text call becomes considerably more expensive — for every document, not just the few where it pays off. For a tool meant to be used permanently and by many, the running cost per call decides whether it stays in operation or gets switched off after the pilot year.

The alternative would be to store diagrams as code — Mermaid or PlantUML instead of image files. For new documents that is the right way. For an inventory grown over years, it means converting everything that already exists. The effort is out of all proportion.

So the blind spot stays. Documented, not hidden.

Structure and Conversation Belong Together

A system in which procedures can be configured tempts you into wanting to configure everything. That works exactly as long as reality plays along — and in an environment grown over years, it doesn't.

Why was it decided that way back then? Which component is actually responsible? What does this term mean here? Such questions come up once and never again. They are not an exception to the process — they are everyday life. Not everything can be solved by the book, and a system that pretends otherwise loses against reality.

That is one reason for the chat. The second only became clear to me in use, and it is the more important one.

The Assistant Solves the Starting Problem, the Chat Solves the Rest

With prompting, the hard part isn't the follow-up. The hard part is the start.

Whoever wants to make a good first request has to frame the task precisely, name the right sources, specify an output structure and know what it should be checked against. That is the competence you don't convey in a training session — and it is the point where most people give up and settle for a mediocre result, because they take it for the maximum.

Asking follow-up questions, on the other hand, anyone from the business side can do. "The second error case is missing." "Phrase that acceptance criterion so it can be verified." "What happens if the booking has already been cancelled?" That is a normal domain conversation, not prompt engineering.

This is exactly where the roles split. The assistant takes over the part that requires expertise: prepared task, prepared sources, prepared schema, prepared rules. What comes out is rarely perfect — but it is a result you can work on, instead of an empty input field.

And from there the chat takes over. Not as a fallback, but as the second step of the same procedure: refine, sharpen, add, until it fits.

The assistant delivers the starting point, the chat the last twenty per cent. A chat question that repeats itself is the hint that an assistant is missing.

That answers the question from the beginning: nobody has to become a prompt engineer — because the difficult part sits in the assistant and the easy part in the conversation.

The Rule Behind It

Structure where something recurs. Conversation where it is a one-off. And the line isn't drawn once and for all: if the same kind of question keeps showing up in the chat, an assistant is missing there. Conversely, an assistant hardly anybody used was a misjudgement. Chat usage is therefore also the requirements list for the next building block.

A side effect I had underestimated: whoever has nowhere to take their question goes somewhere anyway — into some arbitrary chat window, with content that doesn't belong there. A tool that doesn't cover everyday life produces shadow IT, and it does so first among the cooperative ones. The open chat prevents that not by prohibition, but by making the right path the most convenient one.

Limits

No writing without review. The system produces and analyses, it does not decide. Every result passes through a human before it moves on.

Structure protects against formal defects, not against wrong content. An assistant can fill in every field correctly and still claim something that isn't true.

No solid impact measurement — but a signal. What I can say is not my own assessment: since context was expanded, users have been reflecting back to me that the results have got better. Before that, this feedback didn't come.

That is worth something, and it is still not a measurement. There was no before/after survey, the feedback arose unsystematically, and whoever is still working with a tool after months is the more benevolent half anyway. In the SPACE framework this would be the satisfaction dimension — standing alone the weakest of the five, but the only one I actually have here.

So I am not claiming a percentage. Why I consider that more important than a nice-sounding figure is covered in my post on impact measurement.

The Assistants in Detail

Each type of assistant gets its own post — with task, sources, output schema and whatever didn't work right away:

1. The Creators — from an idea to a complete artifact
2. The Transformer — from an epic to the user stories
3. The Critics — checking against rules and against what already exists
4. The Tracker — fault localisation in a distributed landscape
5. Why AI assistants fail on context in the enterprise