The Strategists – Business Analyst & Solution Architect

In the previous post I described the four systemic problems I kept running into when using AI coding assistants: the concept problem, the rule violation problem, the duplication problem, and the focus problem. And I formulated a consequence there: I no longer think in prompts, but in processes. Processes need roles.

In this post I introduce the first two roles in my agent team: the Business Analyst and the Solution Architect. Both handle the planning phase before a single line of production code exists. And both are built around a principle that only became clear to me through experience: Human-in-the-Loop.

Why Two Agents for Planning?

In the post about copilot-instructions.md and AGENTS.md I described how to give an assistant project-specific ground rules. That improved the quality of the outputs – but did not solve the fundamental problem I had described: a model that simultaneously analyzes requirements, designs a concept, and writes code only does half the work on all three.

The solution sounds trivial once you say it: separate the phases and give each one its own, focused agent.

Phase 1 is: what needs to be built? What are the use cases? Which workflows must function, and which must not?

Phase 2 is: how should it be built? Which layers are affected, which schema changes are needed, which existing patterns can be reused?

This clean separation is nothing new. It mirrors what has worked in classical software development for decades: first requirements, then architecture, then implementation. AI needs the same structure – not because it can't do better, but because a limited context window makes no exceptions.

The Business Analyst

The first agent in my workflow is called the Business Analyst. Its sole task: turning vague requirements into precise, machine-readable use case documents.

That sounds like bureaucracy. In practice it is the opposite of overhead – it is the foundation that makes all subsequent steps work at all.

A use case produced by the Business Analyst has a clear structure: a main flow (the happy path), alternative flows (the deviations), error cases (the unhappy paths), pre- and postconditions, and two Mermaid diagrams. One shows the technical interaction between user, component, composable, and backend as a sequence diagram. The other shows the user journey – all screens, decision points, success and failure paths in a flowchart.

The foundational idea for this approach came from the BMAD methodology – an open-source project dealing with the structured use of AI agents in the development process. I looked at it, tried it out, and extracted what was relevant to me: specifically the thinking in explicit use case structures with happy and unhappy paths as a bridge between requirements and technical implementation. Not everything from BMAD fit my workflow – I consciously selected and left the rest out.

These artifacts land as Markdown files in the project, in a structured docs/usecases/ directory. They are simultaneously readable by humans and usable as context by subsequent agents.

What matters most to me: before the actual elaboration, the agent asks targeted follow-up questions. It asks about actors, scope boundaries, and known error cases. At most six questions, only when necessary. And then it waits – it does not simply proceed, but waits for an explicit confirmation.

Now the human has the opportunity to check whether the AI agent has understood them correctly and whether their requirements make sense and fit well in the current project. They can resolve ambiguities the agent had assumed. They can refine the requirements before they are cast into a concept. And that is the decisive point: the earlier I resolve ambiguities, the cheaper it is.

This use case description serves the Solution Architect as context for planning the technical implementation. It is the single source of truth for the requirements that the Coding Agent will later implement.

The Solution Architect

The second agent in the planning duo is the Solution Architect. It takes the use case from the Business Analyst and translates it into a technical solution design.

Its output is a structured document under docs/loesungskonzept/, which takes the current codebase as its starting point. Before drafting anything, it reads the existing code. It inspects the database schema. It searches for existing logic that can be reused rather than rebuilt from scratch. Only then does it design the target state – with class diagrams, sequence diagrams, and a tabular action catalog that lists every change with file path, effort estimate, and dependencies.

The solution design is not finished code. It is a blueprint. And this blueprint fulfills an important function: it is the context that the Coding Agent receives in the next step – precise, complete, and focused on the essentials.

The solution design contains items such as:

## 1. Management Summary

## 2. Current State

## 3. Target State

## 4. Technical Design

## 5. Design Decisions

## 6. Action Catalog

## 7. Test Plan

## 8. File Overview

## 9. Risks & Mitigation

This gives me as a human the opportunity to judge the proposed solution on a technical level before it is cast into code. I can check whether the proposed measures make sense, whether they harmonize with the existing architecture, and whether they actually meet the requirements I confirmed.

The Solution Architect also does not simply end with the document. It presents the concept, summarizes the key points – and then waits. Only after an explicit approval is the concept considered accepted.

The Artifacts as Single Source of Truth

Both agents produce documents. And that is precisely the point: these documents are not documentation in the classical sense, written after the fact and quickly becoming outdated. They are the source from which the Coding Agent later draws its context.

When the Coding Agent begins an implementation, it does not receive a chaotic transcript of a long discussion. It receives a clean use case document with clear flows and a solution design with concrete measures. Its context window is therefore not filled with background noise, but with precise, structured information.

This is the answer to the concept problem from the last post: the Coding Agent no longer needs to invent anything. The concept already exists. Its task is only: implement.

As inspiration for the document structure I looked at, among other things, OpenSpec – an approach for machine-readable, human-friendly specifications. I did not adopt the complete standard because that would have been too much overhead for my setup. What I took from it is the underlying idea: a specification should be understandable by humans and processable by machines as structured context at the same time. That is precisely the claim my use case and solution design documents must fulfill.

This document also needs to be reviewed and approved by the human, because only the human can judge whether the proposed solution actually meets the requirements, harmonizes with the existing architecture, and aligns with the future product and its planned feature scope.

Human-in-the-Loop (HITL): Not a Brake, But a Steering Wheel

Now I come to the part that occupied me the most – and about which I thought the longest before I could formulate it this way.

The Human-in-the-Loop principle sounds at first like a limitation. As if you distrust the AI and therefore build control points everywhere. And yes – I do distrust the AI. Deliberately, and for good reason.

My own experience and the scientific evidence I described in the previous post are unambiguous on this point: AI agents produce plausible-sounding output that can be wrong, incomplete, or architecturally problematic in the details – often in ways you only notice when you look closely. Anyone who accepts these results unchecked is baking problems into the code that will cost hours or days to fix later. I want to be able to see, review, and approve what the AI produces before it gets processed any further.

But HITL is not only a verification mechanism. It is also something I only really understood through practice: A Human-in-the-Loop checkpoint is not only control. It is also a course correction while it is still free.

If a Business Analyst designs a use case and I read it and say "no, that is not the scope I meant" – then this correction costs one minute. If the same misassumption only surfaces in the finished code, it costs hours in the best case.

This is not an academic point. It is the principle behind the well-known phenomenon from software engineering that an error in the requirements phase is ten times cheaper to fix than in the design phase, and a hundred times cheaper than in the implementation phase (Barry W. Boehm, Software Engineering Economics, 1981). AI has not repealed this law.

What the checkpoints also achieve: they force me to think for myself. When an agent presents me with a use case and asks "is this the scope?", I have to answer the question. I can't just skip past it. And in the moment I formulate the answer, I often realize that I hadn't thought precisely enough myself.

That sounds inefficient. In practice it is the opposite: it forces me to resolve ambiguities early – exactly where it is easiest.

What Research and Practice Confirm

The principle is now well substantiated. An empirical study with 120 professional software developers examined what happens when you deploy AI assistants without human oversight: productivity rose by a notable 31.4% – but at the same time 23.7% more security vulnerabilities crept into the code (Empirical Analysis of AI-Assisted Code Generation, 2025). Speed and quality decouple as soon as the human is taken out of the loop.

At ICSE 2025 (International Conference on Software Engineering) the HULA framework was presented – Human-in-the-Loop LLM-based Agents. The researchers empirically demonstrated that autonomous agents score excellently on historical benchmarks but systematically fail in real projects when the human does not intervene correctively at every phase – planning, architecture, code (HULA Framework, ICSE 2025). Atlassian also reached a similar conclusion in a 2025 field study: fully autonomous agents for resolving Jira tickets failed at verification. Human intervention was not needed for writing the code – but for judging the logic behind it.

The scientific consensus is clear: HITL is not a nice-to-have. It is a structural prerequisite for building production-ready software with AI.

Not All That Glitters Is Gold: HITL as Illusory Control

But research also warns of a variant I consider at least equally important: HITL can fail without anyone noticing.

The so-called "Inverted Loop" describes a situation that many will recognize (Spiceworks, 2026): in principle, the AI should work for the human. In practice the relationship reverses. The Coding Agent produces a continuous stream of code, and the developer mutates into a permanent reviewer. What first looks like control becomes cognitive exhaustion. You start rubber-stamping because you simply can't keep up. The system collapses – not loudly, but insidiously. Code quality declines while the illusion of control remains.

A similar analysis (Medium, 2026) warns of a subtler variant: the mere endorsement of AI-generated specifications. When a developer "reviews" a Markdown plan without being able to genuinely follow the technological decisions in it, HITL is nothing but a phrase. The human nominally has control – but not the cognitive substance to question the decisions behind it. And whoever doesn't truly understand what they are approving isn't approving anything – they're just waving it through.

Why the Checkpoint Before the Code Is Decisive

This is exactly where the difference in my approach lies: I place the Human-in-the-Loop checkpoint not at the code level, but at the concept level.

I don't review thousands of lines of code that an agent throws at me. I review a use case. I review a solution design. Both documents are compact, in my own language, at an abstraction level I can judge without a deep code dive. Both arrive at a moment when a course correction still costs nothing. And both describe the what and the how – not the runnable result I would have to tiredly wave through.

This avoids the Inverted Loop because I am not in permanent review mode. It avoids illusory control because I judge requirements and architecture at a level where I can actually make judgments. And it ensures that the Coding Agent that comes after receives a reliable blueprint – not an improvised task description.

In my view, this is an important point: we as humans often see the big picture of the software project. Even though we have a context window, it is significantly larger than the AI's – which is why I want to encourage everyone to place checkpoints not at the code level, but at the concept level. It is the moment where we can still actually exert influence – and that is the moment we should seize.

An Honest Point: Speed Is Not the Primary Goal

I don't want to give the impression that this setup is automatically faster. That's not true.

Two agents that create documents, ask follow-up questions, and wait for approvals before any actual code is produced – that is measurably more process than a simple prompt-response pattern. For small, isolated features this overhead will be noticeable.

But the question is not: "Is it faster than a single prompt?" The question is: "Is it faster than a single prompt plus the hours that follow, fixing architecture breaks, removing duplications, cleaning up spaghetti code, and correcting requirements misunderstandings?"

That second calculation comes out clearly in my favor – as soon as the task exceeds a certain complexity.

And Yes: It Is Also a Workaround

I want to be honest: this setup is, at least in part, a workaround for the current limitations of the models.

An LLM with an unlimited context window that could always perfectly retrieve the full state of a project might not need this decomposition. It could perform requirements analysis, architecture design, and implementation in a single pass without losing quality on any of them.

That is not today's reality. Context windows are limited. Attention is limited. And the more information flows together in a single prompt, the more quality every individual sub-task loses – the research shows this (Liu et al., 2024), and so does my own experience.

The decomposition into specialized agents with clearly delimited context is therefore also a response to this limitation. Small windows, focused tasks, precise outputs.

Whether models in two or five years will make this decomposition unnecessary, I don't know. Perhaps the answer will eventually be "no workaround needed." But today it is the most reliable method I have found.

Conclusion

The Business Analyst and the Solution Architect are not the parts of my workflow that produce the most code. They produce no code at all.

But they are the parts that ensure the code produced afterward implements the right thing – in the right way, consistent with the existing architecture, and based on requirements I have actually confirmed.

The Human-in-the-Loop principle is not a retroactive safety net in this process. It is the actual mechanism that keeps the process headed in the right direction. Because I don't blindly trust the AI – and because I know that course corrections are free at the beginning and very expensive at the end.

In the next post I'll show what the third part of the team looks like: the Coding Agent that receives the blueprint and implements it.