The robots are ready. But who supplies the requirements?

Why agentic coding could also change how domain knowledge reaches engineering, how engineering roles develop, and how product development is organized.

A modernized factory with no material

Imagine a factory whose production has been designed around a particular pace for years. Its employees could make only as many products as their machines, workflows, and working hours allowed. Material supply, production planning, and quality control had adapted to that throughput. The system may not have been especially fast, but its parts fit together reasonably well.

Then the company invests in new robots. Several steps can suddenly run in parallel, routine work is automated, and manufacturing itself needs far less human intervention. Predictably, the first discussion concerns the productivity of the new machines—and, before long, how many employees the company will still need.

Except nobody has adjusted the material supply.

The new production line now has much greater capacity, but it is not receiving a corresponding increase in usable material. Its capabilities are impressive. That alone does not make the factory more productive as a production system.

This is the image that comes to mind when I follow the current discussion about coding agents. We talk a great deal about how quickly code can be generated, how many tasks can run in parallel, and which activities used to occupy entire development teams. I hear the follow-up question much less often: how does an organization ensure that this new implementation capacity works on the right problems?

Software is not an assembly-line product, of course. Requirements are not interchangeable raw materials poured in at one end and collected as finished features at the other. In complex products, our understanding of the problem and its solution often develop together. Still, the metaphor helps me make a possible new bottleneck visible: we automate production while treating the work that supplies it with domain knowledge and decisions as though nothing had changed.

More implementation capacity alone does not create throughput. The factory is a metaphor: requirements and solutions evolve through feedback.

Open the full-size graphic

Three workstreams are not three new domains

In my personal development work, I am deliberately exploring how to use several coding agents in parallel. I might have three different workstreams in progress: one feature is receiving its finishing touches; for a second, we are developing the domain and visual concepts and starting the initial implementation; elsewhere, I am defining a new theme and evaluating variants.

This works because the activities place very different demands on my attention. Once the main decisions for a feature have been made, an agent can implement or correct it relatively independently. Meanwhile, I can work on a UX idea, review a design, or prepare the next domain decision. I am not trying to understand three unfamiliar domains at once. I am trying to use my limited human attention so that the agents spend as little time waiting for me as possible.

I like this kind of parallel work a great deal. But it does not magically multiply my cognitive capacity. Three agents can edit code at the same time. I cannot think through three complex decisions with equal depth and reliably accept three results at the same time. Choosing the workstreams is therefore almost more important than counting them.

At work, I sometimes encounter the opposite situation. Several products need maintenance and further development, but not enough clarified, prioritized requirements are coming through. I can improve the architecture, reduce technical debt, or consolidate existing structures. That is useful work, and I enjoy it. It does not, however, create a product roadmap.

In those situations, someone occasionally says: “You just need to understand the domain. Then you can define the requirements yourself.”

For me, this is where the real mistake begins. Not because developers should avoid understanding the domain, but because we often conflate three things: understanding a domain problem, helping shape a solution, and having the authority to decide which business rules should apply. These activities are connected. They do not automatically require the same background, expertise, or responsibility.

Eight days of geoinformatics—without being a geoinformatics specialist

A recent project showed me what becomes possible when those conditions are in place. I was asked to implement demanding geoinformatics functionality in an existing application. It involved geometries, vectors, geographic boundaries, calculations, and their representation on maps. This was not another CRUD screen. The task involved domain concepts and mathematical relationships well outside my own area of expertise.

Geoinformatics is a specialization in its own right. In a study published in 2025, the German Economic Institute reported exactly 1,694 employees subject to social security contributions in Germany in 2023 within the narrowly defined occupational category “Geoinformatics—expert (master’s degree/Diplom).” That does not mean only 1,694 people in Germany could implement this kind of software. The figure describes a statistical occupational category, not the pool of qualified developers. It does help explain why I could not take the domain expertise behind this task for granted.

I am a software architect, not a geoinformatics specialist. And I have to admit that I initially had serious doubts about whether we would solve the problem as intended.

What we did have was an unusually good specification. It described the domain expectations precisely enough that we did not first have to invent geographic rules or guess the intended result from vague examples. Instead, we could systematically compare the existing implementation with the requirements, identify gaps, understand the relevant data and calculation models, and turn that into an actionable plan.

The result surprised me: two days of planning, two days of agentic implementation, two days of review, and two days of acceptance. Across that eight-working-day process, acceptance uncovered only one minor rendering issue.

To give some sense of the scale: we ended up with just under 5,000 lines of domain implementation code and around 10,000 lines of test code. I found the roughly 800 tests motivated by domain requirements particularly striking. They allowed us to check the described requirements and numerous relevant scenarios. These are rounded figures from personal experience, not exact scientific measurements.

Code volume is not a quality measure in itself, and even a large number of tests does not guarantee correctness in the domain. For me, the scale does make the extent of the technical implementation tangible. The precise specification gave us a foundation for systematically modeling a complex problem, implementing it with agents, and checking it through numerous tests motivated by domain requirements. Acceptance by people with the necessary domain expertise remained essential.

I explicitly do not want to turn this into a productivity benchmark. The effort spent writing the specification was not included in those eight days. An application already existed, allowing us to compare the requirements with its current behavior. Nor did I conduct a controlled comparison of how long the same work would have taken without coding agents.

I still find the distribution interesting. Agentic implementation accounted for only two of the eight days; the other six went into planning, review, and acceptance. The domain specification was work that had already been done. The engineering task was to translate it into a sound solution, rather than learn the science of geoinformatics from scratch on the side.

For me, this experience is a strong personal argument for how effective a good division of work can be. An experienced engineer does not have to master every discipline if the necessary domain knowledge is available as understandable rules, constraints, and verifiable expectations. But the engineer must recognize where the specification ends, which technical questions remain open, and when a real domain expert needs to make the next decision.

Observed distribution: 2 + 2 + 2 + 2 working days. Writing the specification is excluded; one practical experience, not a benchmark. Rounded figures from experience: just under 5,000 lines of domain implementation code, around 10,000 lines of test code, and roughly 800 tests motivated by domain requirements. Acceptance uncovered one minor rendering issue. Code volume and test count do not guarantee correctness in the domain.

Open the full-size graphic

“You just need to…”

That phrase contains a second problem, one that has almost become more important to me. It rarely begins with an organization explicitly demanding that every developer master every discipline. Instead, the expectation grows through small, reasonable-sounding steps.

You just need to understand the domain a little better. You just need to adjust the pipeline. You just need to take care of the deployment. Security should obviously be considered from the start, too. You can help shape the UX. And while you are at it, perhaps Kubernetes could use some attention as well.

Each individual request may be justified. Together, they produce a skill profile that hardly any one person can fully satisfy. Software engineering alone contains many distinct fields of knowledge. Frontend, backend, distributed systems, databases, platform engineering, cloud infrastructure, security, observability, test automation, and software architecture cannot simply be stacked up at expert level. Every time I think I have a reasonably good grasp of engineering, Kubernetes turns up with a few more things to learn.

And now every developer is supposed to become a domain expert as well?

I know people who are passionate about domain processes. They enjoy working with users, want to understand business rules, and do their strongest work where engineering meets the product. We should absolutely support them. Others are primarily excited about software engineering. They want to solve complex technical problems, design systems, understand algorithms, and develop clean abstractions. They should be able to grow in that direction, too.

I am particularly cautious when it comes to people who love both. Not because there is anything wrong with that combination; it can be extraordinarily valuable to a team. But those people are especially likely to take on more and more work out of curiosity, because they can, because they want to help, and because it initially works well. The organization quickly learns to approach the same person with the next unanswered question.

Eventually, every decision has to pass through that person. Exceptional commitment has become a single point of failure. Enthusiasm can turn into overload long before everyone recognizes the imbalance.

Perhaps that is the father in me speaking. I do not want to take away anyone’s enjoyment of learning or growing beyond familiar boundaries. But willingness to learn is not an unlimited resource, and enthusiasm for two disciplines does not amount to consent to carry full responsibility for both indefinitely.

To me, cross-functionality therefore means that a team collectively has the skills it needs. It does not mean that every individual must be able to do everything. That is also the basic idea behind cross-functional teams in the Scrum Guide. Self-management does not erase different accountabilities—much less the limits of what one person can sustain.

A specification does not replace collaboration

My GIS example could easily give the impression that I want to return to traditional handoffs between domain departments and IT: the domain specialists write a perfect specification, the requirement disappears into development, and the result comes back a few months later.

That would be a misunderstanding. A good specification need not be especially long or finalized before implementation begins. Complex requirements often become clear only through shared models, questions, prototypes, and initial results. In our geoinformatics example, we still had to compare the current state with the requirements and identify gaps. This worked because we had a reliable reference point, not because every conceivable question had been answered once and for all.

Requirements engineering describes precisely this interdisciplinary collaboration. ISO/IEC/IEEE 29148:2018 addresses eliciting, analyzing, verifying, validating, communicating, and managing requirements throughout a system’s lifecycle. The standard distinguishes whether requirements are well formed from whether they actually describe the system stakeholders intend. Separate again is the later technical verification of whether the implemented system satisfies its specified requirements.

I do not see this as an argument for more bureaucracy. Quite the opposite: the faster we can implement, the more valuable short, precise, verifiable decisions become. An unambiguous rule, a good sample dataset, clear acceptance criteria, or an available domain contact can be far more useful than a large document full of unresolved statements.

Developers should understand domain relationships, recognize contradictions, and actively help find solutions. But the authority to make a domain decision must remain with people and roles competent and authorized to make it binding. Understanding the underlying data model does not qualify a developer to make a medical judgment. And a passing test does not make an incorrectly specified business rule right.

Collaboration therefore needs to become closer, rather than more rigidly separated. My criticism concerns something else: when domain responsibility is missing from the organization, it is often quietly shifted to whoever happens to be able to implement the feature.

What coding agents change about the supply

Why is this old question becoming more pressing now? Because technical implementation can become faster without the clarification of domain questions accelerating to the same degree.

An agent can derive a plausible data model, user interface, services, tests, and a complete change across multiple files from a description. That is impressive and often extremely useful. But it can also add domain assumptions that nobody with the relevant authority has confirmed. Technical consistency is not domain authorization.

Research is beginning to provide indications of this distinction. ClarifyCodeBench, a 2026 preprint by Fang and colleagues, uses an interactive benchmark with six models to investigate how well LLMs independently recognize ambiguous requirements and clarify them through questions. The results suggest that strong code generation does not automatically imply strong requirements clarification. Additional reasoning effort brought only limited improvements in identifying ambiguities, especially when several ambiguities occurred together.

SpecBench by Hamblin and colleagues, also from 2026, examines a related but different capability: agents must identify omissions, contradictions, and incorrect assumptions in design proposals from real RFC processes in Kubernetes, React, Rust, TVM, and vLLM. The best agent evaluated achieved 44.4 percent accuracy. This is not a general error rate for product ownership, nor does it show that future models cannot do better. It shows only that reviewing a specification remains a demanding task in its own right, one whose quality cannot be inferred from a good coding result.

And of course AI can improve the supply, too. I use it myself to structure domain questions, compare UX approaches, expose ambiguities, and turn settled decisions into concrete implementation assignments. The interesting boundary is not between “AI may implement” and “AI may not work on requirements.” It is between developing proposals and making binding decisions about their validity in the domain.

The 2025 DORA report describes AI as an amplifier of organizational strengths and weaknesses. That fits my observation, but does not prove that product ownership must become the new bottleneck in companies using coding agents. That further conclusion is my hypothesis.

Count decision capacity, not Product Owners

Previously, depending on maturity, product, and complexity, a Product Owner could support several developers or more than one team. The more implementation work the technical side had to do, the more time there was to prepare new requirements and coordinate existing decisions.

If coding agents now drastically reduce some of that implementation time, the balance between domain preparation and technical execution could shift. My initial intuition was that a ratio of around one Product Owner to ten developers could become much closer in some settings. I would not turn that into a new target ratio of one to one or one to three. After all, a Product Owner is not the same thing as requirements engineering, UX, domain expertise, and acceptance combined.

What interests me is the decision capacity available to each simultaneously active workstream. How many domain questions can an organization answer in time? How many UX concepts can it assess competently? How many requirements are concrete enough to implement and later accept against verifiable expectations? How much time passes between a question and a binding answer?

If a development team spends most of its time looking for its own tasks because clarified requirements are missing, that is not automatically a failure on the developers’ part. More coding agents will not close that gap by themselves, either. Additional production capacity can create value only when it is clear what value should be created.

The answer therefore need not be to hire a Product Owner for every agent. Perhaps the missing capacity is business analysis, UX, real domain expertise, a product lead able to make decisions, or simply a clear product mandate. Even the best distribution of roles is useless if nobody is available to resolve a domain contradiction with a binding decision.

And sometimes the right decision really is to generate no more code. A good product organization is not trying to keep every agent permanently busy. It is trying to deliver the right changes and spare us the wrong ones.

Arrows connect responsibilities and return insights to requirements. The possible bottleneck before implementation remains a hypothesis; it implies neither a fixed staffing ratio nor a waterfall process.

Open the full-size graphic

The hypothesis behind the factory

From these experiences, I draw a hypothesis that has not yet been directly substantiated: the more coding agents accelerate technical implementation, the more a product organization’s overall throughput could depend on its ability to provide requirements validated by domain stakeholders and timely decisions.

That would not automatically mean hiring more people in a particular role. It could mean distributing work differently: more deliberate product discovery, more professional requirements engineering, better technical modeling, earlier UX feedback, and clearly assigned domain acceptance. AI could support these activities as well and reduce some bottlenecks. Whether an organization would need more or fewer people could be assessed only in its specific context.

A second, human dimension matters to me. If an enthusiastic developer already handles frontend, backend, architecture, and deployment, time saved on implementation must not automatically become an invitation to hand that person every domain decision, UX question, and regulatory demonstration as well. Otherwise, we have automated the production line while concentrating all its dependencies on one human being.

Perhaps the ability to help specialists work well together will become one of the most important factors in successful agentic work. Domain experts contribute the depth of their disciplines. Software engineers translate that depth into models and dependable systems. Coding agents take on work where their results can be sufficiently bounded and verified. And everyone stays connected through the necessary feedback loops.

This is not a return to waterfall. It is an attempt to organize the entire value stream so that speed is not bought at the expense of clear responsibility.

Conclusion: the factory has to work as a whole

My geoinformatics example surprised me because it showed how far experienced engineering can go with a good specification and agentic support—without the person implementing the solution also being a specialist scientist. My professional experience with missing requirements shows the other side: even excellent technical production capacity can accomplish little when the domain questions about what should happen next remain unresolved.

We should therefore not narrow the discussion to how many developers coding agents might replace. We also need to examine which prerequisites become more important, and how work shifts among product ownership, domain specialists, requirements engineering, UX, architecture, and implementation.

And we should be careful not to turn people who enjoy looking beyond their own specialty into universal solutions for every organizational gap. A cross-functional team can possess a wide range of skills. An individual developer does not have to be a physician, geoinformatics specialist, UX designer, platform engineer, and software architect all at once.

I find the new capabilities of coding agents impressive. Precisely for that reason, I do not want to measure their success only by how quickly they produce the next implementation. I am becoming more interested in how reliably an organization turns domain knowledge, binding decisions, and good engineering into the right software.

The robots are ready. Perhaps it is time we also talked about the supply, production planning, and quality control.

Sources and context

This article distinguishes personal experience (GIS project: two days of planning, two days of agentic implementation, two days of review, two days of acceptance; one minor rendering issue), related research, and an explicitly open organizational hypothesis. The eight days exclude writing the domain specification and do not constitute a comparative productivity study.

Burstedde, Alexander & Tiedemann, Jurek (2025): Kompetenzbarometer – Fachkräftesituation in Digitalisierungsberufen bis 2028. German Economic Institute, Table 3-1 (employees in 2023: Geoinformatics—expert, 1,694). Study.

ISO/IEC/IEEE 29148:2018: Systems and software engineering – Life cycle processes – Requirements engineering. Standard.

Fang, Zheng et al. (2026): ClarifyCodeBench: Evaluating LLMs on Clarifying Ambiguous Requirements for Code Generation. Preprint.

Hamblin, Grant et al. (2026): SpecBench: Evaluating Specification-Level Reasoning for Software Engineering LLM Agents. Preprint.

DORA / Google Cloud (2025): State of AI-assisted Software Development.

Schwaber, Ken & Sutherland, Jeff (2020): The Scrum Guide.

Further reading in the series: Prompt Engineering Starts Before the Prompt · Generation is cheap, verification is expensive · The Economics of Agentic Work · Software Engineering Was Never Just Coding · AI is accelerating our path to the Big Ball of Mud – a hypothesis.