Where Should People Be in the Loop While AI Does the Work?

💡 Summary: Key Takeaways

• A specification is not complete before the work begins. Decisions that were invisible in the original request emerge while people work through the code, document, or analysis.
• AI can accelerate the “how.” It does not automatically preserve the feedback between “what” and “how.” If people write the brief and return only to approve the final output, the company can lose what implementation taught it.
• Removing entry-level work can also weaken future judgment. Less experienced employees need to participate in real scenarios, source and data choices, exceptions, and outcome reviews.

When AI does the work, people cannot be limited to writing the brief at the beginning and checking the output at the end. What the work actually requires becomes clearer through exceptions, missing definitions, and contradictions that appear during implementation. People need to stay in the whole loop: framing the question, weighing options, interpreting what implementation reveals, and testing the result in real conditions.

This article starts with a software-development example. The same issue appears when a team prepares a substantial document or builds an analytics system; the coding example is simply the most visible starting point.

Imagine a product team asked to let customers pause a subscription from inside an application. The brief specifies the form fields, confirmation button, and email. A coding agent produces the interface, service, and tests quickly.

Then the questions begin. What happens when the pause date falls in the middle of a billing period? Does access stop immediately? Does the customer keep the old price when the subscription resumes? Can an account with an open order be paused?

These are not items on a technical cleanup list. Each one changes the promise made to the customer, the financial records, and the support process. As the team works through how to implement the feature, it also learns what the feature needs to be.

Correct, fast code does not remove that need. The same mechanism appears in a major report or an analytics system. Building the sections and evidence for a document exposes decisions that have not been made. Bringing data together can reveal that different parts of the company use the same metric to mean different things. What AI uncovers while producing the work can change the scope of the work itself.

If a company treats “what” as a box completed by people and “how” as a separate box delegated to AI, it can cut one of its most valuable feedback paths.

Requirements become clearer during implementation

Unmesh Joshi, Rebecca Parsons, and Martin Fowler explain why software development cannot be reduced to translating finished requirements into code in their conversation about LLMs and the “what/how” loop. Their immediate subject is software design: building systems that can accommodate change and developing the abstractions that make this possible.

Software development is the source's direct scope. Extending the mechanism to major reports and analytics systems is my inference. If AI's production choices expose unresolved objectives, definitions, and contradictions, similar feedback can arise in those forms of work too.

The “what/how” loop treats a requirement as something that continues to develop during implementation. Working through a data model, scenario, test, or constraint in an existing system changes the team's understanding of what should be built.

This conversation is not empirical evidence that teams using LLMs perform better. It is a design argument developed by three experienced software practitioners. Its contribution is to show that implementation does more than realise a decision; it can also improve how the decision is framed.

In software, a scenario, data model, or test may expose a boundary drawn incorrectly in the first request. In a major report, the structure and sources may reveal two objectives that the evidence cannot support together. In an analytics system, the way a metric is calculated may show that managers answer the same question differently.

An LLM can surface alternatives quickly and make a first version cheaper. The more durable value comes from feeding what the team learns during that work back into the problem definition.

Three kinds of output, one learning problem

In the subscription example, the agent can produce a working screen. But if the billing, access, and price-protection rules are still open, the software may encode the wrong business rule correctly. The customer's real problem might not even be the missing pause option. It might be the lack of support after an incorrect charge.

If the person involved writes the initial request and then returns only to inspect the finished screen, those signals disappear. The agent can make reasonable assumptions and produce internally consistent code. A bad business assumption is then embedded faster.

Now consider a team preparing a market-entry assessment for its board. The brief asks for market size, competitors, costs, risks, and a recommendation. AI can search sources and assemble a comprehensive document. Once the sections come together, the team may discover that the market-size figures refer to different product categories, the cost model excludes integration, or the legal requirements conflict with the proposed timetable.

Those are not minor footnotes. They can change the decision to enter the market, the budget, or the timing. If a person reviews the document only for fluency and formatting, unresolved decisions can disappear inside a polished report.

A third team is building an analytics system to identify customer churn early. AI can prepare a data flow across CRM, billing, and support systems. During implementation, the team may discover that “churn” has no shared definition. Do paused accounts, failed payments, and downgrades belong in the same group? Does the clock start on the contract date or the first payment?

The system can apply any of these choices consistently. Deciding which definition serves the company's decision requires business judgment. If AI chooses the definition and a person approves only the chart, the analysis may calculate correctly while answering the wrong question.

User interviews, scope work, source review, or data-definition work performed before AI enters the process could change all three projects. The right intervention may not be new software or another AI system. When AI is the right tool, the exceptions and contradictions found during implementation still need to return to the problem definition.

In Comprehension Debt: The Bill Comes Due Alone, I examined what happens when a codebase grows faster than the mental model needed to explain it. The risk here is broader. A company may be able to explain its code, report, or analytics system and still miss what it could have learned about the business while creating them.

What is the human doing in the loop?

Many AI workflows place a person at the final checkpoint. The agent performs the work; a person reviews and approves it. That step may be necessary for safety and quality. It still leaves the person's role undefined.

If the reviewer is limited to catching faulty code, an unsupported claim, or a misleading metric, they are a control gate. If they also frame the scenario, evaluate the contradiction exposed during implementation, and change the problem definition, they are part of the learning loop.

The distinction may look small, but the organisational consequence is not. A control gate protects today's output. A learning loop develops the human and institutional knowledge required to make the right decision when tomorrow's requirements change.

Whether an AI agent completed the task is a production measure. Preserving learning requires a record of something else:

A short decision record is enough. There is no need to archive the agent's entire conversation. The team needs to answer not only “How was this output produced?” but also “Why do we now understand the work this way?”

The second cost of losing entry-level work

In The Job AI Won't Take—and the Five It Prevents, I described how AI can reduce demand for entry-level employees without anyone being laid off. That article was about the number of jobs. The “what/how” loop exposes a second cost: people who do not enter the work, or do not participate in real implementation, also miss the path through which senior judgment develops.

Less experienced employees become senior by working through the decisions around an output. A developer sees why one data model makes the next feature harder. An analyst investigates why two reports classify the same customer differently. Someone preparing a major document learns why an impressive claim cannot be supported by the available sources. Over time, they learn to spot a mistake in the “what” by reading the signals in the “how.”

With AI support, a less experienced employee may approach a senior colleague's output on some well-bounded tasks. In Can a Junior Who Uses AI Well Outperform a Senior Expert?, I examined that possibility and where domain knowledge and responsibility for outcomes still set the limit. The next question is where that domain knowledge and judgment will come from in the future.

There is no reason to preserve repetitive work simply to make people learn. Nor should less experienced employees be confined to cleaning up whatever AI leaves behind. They need to participate in problem framing, source and data selection, decisions about exceptions, and reviews of real outcomes. As AI accelerates production, the centre of learning needs to move there.

We need to change the work people are prepared for

In When AI Changes Work, Training Employees Is Not Enough, I argued that a company must define the new role before deciding how to train someone for it. Describing that role as “an employee who uses AI well” leaves learning and decision responsibility unassigned.

In an AI-enabled operating model, people may not produce every part of the output by hand. But someone still needs to own these responsibilities:

1. Define the question and the business outcome.
2. Make assumptions, source gaps, and data definitions visible.
3. Notice when a production choice changes the business decision.
4. Evaluate the agent's alternatives using domain knowledge and evidence.
5. Test the output against real operating conditions.
6. Feed what implementation reveals back into the problem definition.
7. Accept responsibility for the result and the risks that remain.

Assigning all of this to a few senior specialists creates a new bottleneck. Those specialists must review every agent output, carry every business decision, and somehow develop less experienced colleagues at the same time. Entry-level employees remain outside the place where decisions are made.

Team design therefore needs to account for more than production capacity. A less experienced employee can own a user scenario, a claim in a report, or the definition of a metric. They can explain which evidence led them to accept the agent's proposal. When the result is wrong, they can examine not only the correction but also where the original problem definition failed.

What should the next AI project record?

Output volume, completed tasks, and cycle time tell us something about capacity. Different questions show whether the learning loop has survived:

• Which business assumption changed during implementation?
• Who noticed the change, and where was the decision recorded?
• Which decision does the agent's choice of structure, source, or data definition make easier, and which does it make harder?
• Can two members of the team explain the reasoning behind the same output?
• Are less experienced employees cleaning up output, or are they involved in the problem and implementation decisions?
• What will the team do differently on the next similar piece of work?

Without answers, the company does not know what it lost in exchange for faster production.

AI can produce work faster, but it does not remove the responsibility to learn what the work is. The exceptions and contradictions that emerge while code, a report, or an analytics system is being built are not merely problems to resolve. They are feedback that can correct the company's definition of the problem.

A sound AI workflow does not place people only at the beginning of the brief and the end of the output. It keeps them involved in judging what changed during implementation, which decision that change affects, and who owns the result. Designed this way, AI does more than accelerate production; it helps the company develop a better understanding of its own work. Remove people from implementation, and the company may be left with faster code, documents, and analysis—but no organisation that understands why they were produced that way.