Human-in-the-Loop Software Development Explained

"Human in the loop" is easy to claim and hard to verify. In software development it should mean something specific: at defined points, a qualified person looks at what the AI produced, can say no, and is accountable for the outcome. This article explains those points and how to tell whether a team actually practices them.

Where the human sits in the loop

Coding agents such as Claude Code, OpenAI Codex or Cursor can read a codebase, propose changes, run commands and iterate. That capability makes it tempting to hand over the whole job. A well-run loop keeps people at five checkpoints:

1. Intent: a person decides what is being built and what is out of scope.
2. Design: a person chooses architecture, data handling and third-party services.
3. Change review: a person reads each change before it is merged.
4. Verification: a person runs the app on real devices and checks behavior against the intent.
5. Release: a person approves what goes to users and answers for it.

Review is the core control

Reviewing a diff is different from skimming a summary. The agent's own description of its work can be accurate and still hide a problem, because it describes what it meant to do. A reviewer compares the change against the intent and looks for what is missing: an authorization check, an error path, a test that fails when the feature breaks. Smaller changes make this realistic, which is why disciplined teams ask agents to work in small, reviewable steps.

Signs the loop is real

• You can see pull requests or commits with review history, not one giant dump.
• Reviewers have names and sometimes reject or rework agent output.
• Tests exist, run automatically and fail when behavior breaks.
• There is a written policy for what agents may access, including secrets and production data.
• Someone specific is on call after launch.

Signs it is only a slogan

• "Our AI wrote it and a human glanced at it."
• No difference in outcome when you ask which parts were reviewed.
• Testing limited to the agent's own claim that it works.
• Nobody can say who approved the release.

Why speed and oversight are not opposites

A common worry is that oversight cancels the speed benefit. In practice the opposite tends to hold for anything beyond a throwaway prototype: unreviewed output creates rework, security incidents and store rejections, which cost more time than review does. Good process makes the fast parts safe to use. The same idea underlies the broader model described in AI Development Services: AI Speed, Human Responsibility.

How apprat.io runs the loop

At apprat.io, the loop is part of the delivery process of jocapps GmbH. Senior AI Code Engineers plan the work, agents implement in small steps, every change is reviewed by an engineer, and the app is tested on real iOS and Android devices before store submission. Because quality and information security processes are ISO 9001 and ISO 27001 certified, these checkpoints are documented and repeatable instead of depending on one person's habits. The engineers who release the app are the ones accountable for it afterward.

A short example

Suppose an agent is asked to add a password reset feature. It writes the endpoint, the email template and the screen. A reviewer reading the diff asks three questions: does the reset token expire, can it be used twice, and does the response reveal whether an email address is registered? The agent did not consider any of them because nobody asked. The human supplies the missing questions, the agent implements the answers, and a test is added so the behavior stays correct. That small exchange is the loop in miniature: the machine produces, the person questions, the machine corrects, and the result is verified.

The same pattern applies to non-code decisions. When a feature would require a new permission, a human decides whether the benefit justifies a longer store review and a more detailed privacy disclosure.

Applying the idea in your own team

If you run your own agents, you can adopt the same checkpoints without adding a lot of bureaucracy. Require pull requests for all agent-generated changes, keep tasks small, protect the main branch, and write down what agents are not allowed to touch. For teams that want help setting this up, governance workshops are one way to do it, and if you would like to talk through your situation you can book a call for free.