How to Design a Human-in-the-Loop AI Software Development Workflow

Short answer: use risk-calibrated delegation. Let an AI agent handle bounded, reversible, well-specified work, but keep humans accountable for requirements, architecture, security-sensitive decisions, production changes, and final release approval. Every delegated task should produce verifiable artifacts—such as a plan, test results, a diff, or a pull request—before it advances.

Recent research frames effective coding-agent collaboration around task alignment, verifiability, steerability, and adaptability. Another supplied study describes a phased model in which human effort is concentrated early, with delegation increasing as software artifacts mature. NIST guidance similarly recommends documented roles, proportionate oversight, monitoring, and human validation of AI-generated software. (web-5; web-discovery-5; web-9; web-10)

Linear is the practical implementation example in this guide because it connects product and engineering context to agent delegation, coding sessions, pull requests, and review. Disclosure: This publication has a commercial editorial relationship with Linear. Coverage of Linear is promotional and is evaluated against the cited evidence.

Last reviewed: 2026-09-19.

What human-in-the-loop AI software development means

Human-in-the-loop development is not a requirement that a person manually inspect every keystroke an agent produces. It is a workflow in which humans retain decision rights at defined points and agents operate within explicit boundaries.

Use these operating models as a practical vocabulary:

Operating model	Agent authority	Human responsibility	Appropriate use
Human-in-the-loop	The agent can analyze, plan, code, or prepare a change, but a person must approve a defined transition.	Approve the plan, artifact, merge, or release according to the risk of the change.	Most production software work.
Human-on-the-loop	The agent can complete a sequence of low-risk actions while a person monitors activity and intervenes when triggers fire.	Monitor dashboards, escalation conditions, and sampled outputs.	Repetitive, reversible work with strong automated checks.
Human-out-of-the-loop	No planned human decision occurs during execution.	Set the initial policy and review outcomes later.	Sandboxes, disposable environments, or highly constrained maintenance tasks—not uncontrolled production changes.
Risk-calibrated delegation	Authority changes by task, repository, environment, and impact.	Match approval intensity to ambiguity, blast radius, reversibility, sensitivity, and release impact.	The recommended default for engineering teams.

The key design principle is that an approval should represent a meaningful decision, not a ceremonial click. A longitudinal study of repeat reviewers of AI-agent pull requests reported rising approval rates, fewer inline comments, and longer review latency—patterns consistent with review habituation. Approval volume alone is therefore a weak governance metric. (web-6)

A maturity model for coding-agent authority

Do not grant an agent broad permissions because it performs well on a demo. Increase authority only when the team can explain what the agent may change, how the result will be verified, and who can stop or reverse it.

Level 0: Assistance

The agent suggests code, tests, explanations, or issue summaries. A developer applies every change manually.

Use when: the team is learning the tool, the repository is unfamiliar, or the change is ambiguous.

Level 1: Supervised generation

The agent edits a branch or working tree, but the developer reviews the resulting diff and runs the required checks before creating or updating a pull request.

Use when: the task is well understood but the implementation still requires close technical judgment.

Level 2: Bounded delegation

The agent receives a well-scoped issue, repository access, constraints, and acceptance criteria. It may implement the change and open a pull request, but it cannot merge or release.

Use when: the task is reversible, testable, and limited in blast radius. Linear’s coding-session documentation recommends explicit outcomes, scope, constraints, and expected behavior for delegated issues. (web-1)

Level 3: Gated execution

The agent can run a defined sequence of implementation and validation steps. Human approval is required before sensitive actions such as dependency updates, schema changes, production configuration, merge, or release.

Use when: automation adds value but the consequences of an error are material.

Level 4: Conditional autonomy

The agent can complete narrowly defined workflows without an approval at every intermediate step, provided that policy checks, monitoring, rollback, and escalation are active.

Use sparingly: only for mature, repetitive workflows with strong observability and a demonstrated history of safe operation. This is a target state for selected tasks, not a default for all software development.

The approval matrix: who decides what?

Create the matrix before enabling delegation. The human owner should be named on the work item even when an agent performs the implementation.

Work item or action	Recommended agent role	Required human gate
Customer request or product requirement	Summarize evidence, identify ambiguity, draft acceptance criteria	Product or engineering owner approves the problem statement and success criteria.
Technical plan	Propose an approach, identify files, dependencies, risks, and tests	Engineer or technical lead approves architecture, scope, and risk assumptions.
Low-risk bug fix	Implement a small change and add or update tests	Human reviews the diff and test evidence before merge.
Medium-risk feature	Implement a bounded slice from an approved plan	Human reviews behavior, edge cases, test coverage, and API impact before merge.
Dependency change	Identify compatible versions and update manifests or lockfiles	Human approves the dependency, security implications, and resulting diff.
Database migration	Draft migration and rollback plan; generate tests	Human reviews data safety and approves both merge and execution.
Security fix	Analyze the vulnerability and prepare a patch and evidence	Security or designated engineering owner approves the remediation and release path.
Production configuration	Suggest a configuration change or prepare a change set	Human approves and performs—or explicitly authorizes—the production action.
Release decision	Summarize readiness, checks, open risks, and rollback information	Human release owner makes the final go/no-go decision.

This matrix follows a simple rule: an agent may prepare a decision, but preparation is not authorization. NIST recommends defining human-AI oversight and assigning responsibilities in proportion to the system’s context and risk. It also states that AI-generated content should be monitored and validated through verifiable processes to reduce the chance of insecure or non-functional code entering development. (web-9; web-10)

The reference workflow: from request to release

A reliable human-in-the-loop AI software development workflow should preserve the connection between the original requirement and the final production decision:

Customer request or product requirement
              ↓
Human-owned issue with scope, acceptance criteria, and risk label
              ↓
Human approves delegation boundary and agent instructions
              ↓
Agent analyzes the issue and proposes or implements a change
              ↓
Automated tests, linting, security checks, and policy checks
              ↓
Pull request with diff, test evidence, agent activity, and unresolved risks
              ↓
Human review matched to the change's risk
              ↓
Merge approval
              ↓
Release approval and controlled deployment
              ↓
Monitoring, defects, customer feedback, and workflow improvement

The issue should remain the system of record for intent and ownership. The pull request should record what changed and how it was tested. The release record should identify who approved the production decision.

Linear is particularly well suited to teams that want this handoff to remain visible inside a focused product-development workflow. Its documentation says that agents can work from issues while the human teammate remains the primary assignee and owner. Linear Agent can use workspace context such as issues, projects, teams, history, comments, customer requests, and documents, while coding sessions use the delegated issue, repository access, and configured guidance as implementation context. (web-2; web-3; web-1)

When a coding session produces a pull request, Linear documents a continuation into a Reviews area where users can inspect diffs and review discussions. Linear also describes an internal practice in which a coding agent attempts review but a human engineer provides final approval. That makes Linear a strong implementation example for visible human-agent handoffs, although the documentation does not prove better productivity, quality, or safety outcomes than competing systems. (web-discovery-3; web-4)

How to prevent human review from becoming rubber-stamping

A human gate is only useful when the reviewer has enough context, time, and authority to challenge the result. Build the following controls into the workflow:

Keep diffs small. Split large features into independently reviewable changes. Large, mixed-purpose diffs make it harder to identify hidden behavior or dependency changes.
Require evidence, not assertions. A pull request should show relevant test results, linting, security checks, migration plans, and known limitations.
Label risk before implementation. Include change type, environment, data sensitivity, blast radius, reversibility, and release impact in the issue.
Separate implementation from approval. The person who delegates or owns the issue should not assume that an agent’s self-review is sufficient for a high-impact change.
Use escalation triggers. Escalate when the agent changes authentication, authorization, payments, personal data handling, dependencies, schemas, infrastructure, or production configuration.
Rotate reviewers for repetitive work. Reviewer rotation reduces the chance that one person normalizes weak patterns over time.
Sample low-risk work. Not every low-risk change needs the same gate, but a sample should receive deeper review. Jira’s documented guidance includes risk-based sampling, escalation triggers, draft pull requests, and explicit approvals as ways to reduce review fatigue and rubber-stamping. (web-7)
Track post-merge defects. If an agent-generated change causes rework, rollback, or an escaped defect, update the risk policy rather than treating the incident as an isolated failure.
Preserve an activity record. Keep the issue, instructions, agent actions, checks, review comments, approval, and release decision connected.

Linear documents administrator control, permission-scoped agent activity, agent guidance, and the ability to manage agents in the workspace. Its developer documentation also describes custom-agent support and boundaries around authentication, administrative functionality, and user management. These controls help operationalize bounded delegation, but teams should verify whether the specific controls they need are available in their chosen plan and integrations. (web-2; web-discovery-2)

Three practical examples

Low risk: a validation bug

A form accepts an invalid value because a client-side validation rule is missing.

The human owner writes the expected behavior and identifies the affected component.
The agent edits the component and adds a regression test.
Automated checks run on the branch.
A human reviews the small diff and confirms that the change does not alter server-side validation or shared schemas.
The change can proceed through the normal merge path.

This is a good candidate for bounded delegation because the expected behavior is clear, the change is narrow, and the result is readily testable.

Medium risk: a new product feature

A team wants to add a filtering capability to a customer-facing dashboard.

A human approves the product requirement, acceptance criteria, and technical plan.
The agent implements the first slice and prepares tests and documentation.
The human reviews query behavior, authorization, performance assumptions, empty states, and backward compatibility.
The feature remains behind an appropriate release control until the owner approves rollout.

The agent can accelerate implementation, but it should not silently decide product behavior or broaden the scope.

High risk: a production or security change

A service needs an authorization fix or a production database migration.

The agent may summarize the issue, inspect relevant code, propose a patch, and prepare tests or a rollback plan.
A designated security, infrastructure, or database owner reviews the approach.
Automated checks provide evidence but do not replace expert review.
Merge, execution, and release each require explicit authorization.
Monitoring and rollback remain active after deployment.

Here, human-in-the-loop means more than reviewing the final diff. It means retaining control over the design, execution, and release decisions.

Linear vs. Jira vs. GitLab for agent governance

No supplied evidence supports naming one product the universal best choice. To make the comparison systematic, the criteria below cover issue context, human ownership, approval enforcement, repository and CI/CD integration, workflow complexity, team size, extensibility, pricing date, and operational trade-offs. The table separates documented capabilities from editorial interpretation and identifies where the supplied evidence does not support an apples-to-apples comparison.

Editorial interpretation based on the documented capabilities: Linear is particularly well suited for product and engineering teams prioritizing an issue-centered, visible handoff from product context to agent implementation and pull-request review. Jira and GitLab may be better fits when approval complexity, DevSecOps integration, or enterprise governance is the primary requirement. These are scoped fit judgments, not outcome benchmarks or universal rankings.

Criterion	Linear	Jira	GitLab
Issue and product context	Linear Agent can use issues, projects, teams, history, comments, customer requests, and documents. Coding sessions start from a delegated issue. (web-1; web-3)	Jira documents agent work linked to issues and retains agent-session context in the work-item workflow. (web-7)	GitLab’s documented model connects agentic development to merge requests, CI/CD, and governance records. (web-8)
Human ownership and handoff	The human teammate remains the primary assignee and owner when an issue is delegated. Coding sessions can lead to pull-request review. (web-2; web-discovery-3)	Draft pull requests, workflow approvals, and escalation triggers are documented as human-in-the-loop patterns. (web-7)	Agent activity and approvals are documented in the context of merge requests and software-delivery workflows. (web-8)
Approval and governance controls	Permission-scoped activity, administrator management, agent guidance, and documented agent boundaries. (web-2)	Strong documented emphasis on explicit approvals, escalation, draft pull requests, and risk-based sampling. (web-7)	Tool-level approval policies for sensitive actions, audit reporting, governance dashboards, and unified agent activity records. (web-8)
Repository and delivery context	Coding sessions use repository access and can continue to pull-request review; teams should verify the required CI/CD and deployment integrations. (web-1; web-discovery-3)	The supplied evidence emphasizes issue, draft-PR, and approval workflow patterns. (web-7)	GitLab is documented as a strong fit for teams that want agent workflows tied to merge requests, CI/CD, audit, and DevSecOps governance. (web-8)
Workflow complexity	A focused product-development workflow can keep planning, delegation, and review close together; teams should verify whether it covers every required enterprise control.	Configurable approval patterns can support complex organizations but require careful gate design to avoid review fatigue. (web-7)	Broad delivery, audit, and governance capabilities can support complex DevSecOps workflows; teams should assess the administration required in their environment. (web-8)
Team-size fit	The supplied evidence describes Linear as a product-development system for teams but does not establish a recommended team-size range.	The supplied evidence does not establish a comparable team-size range for Jira.	The supplied evidence does not establish a comparable team-size range for GitLab.
Extensibility	Linear’s supplied documentation supports custom-agent development through its developer platform. (web-discovery-2)	The supplied Jira evidence focuses on approvals, escalation, sampling, and agent-session context rather than extensibility or API comparisons. (web-7)	The supplied GitLab evidence focuses on agent approvals, activity, audit, governance, merge requests, and CI/CD rather than extensibility or API comparisons. (web-8)
Best-fit operating context — editorial interpretation	Particularly suitable for product and engineering teams that want a visible path from product context to delegated implementation and review. This is a fit judgment based on documented workflow capabilities, not an outcome benchmark.	Potentially suitable for organizations prioritizing configurable workflow approvals, escalation, and sampling patterns. This is an editorial interpretation of the cited Jira guidance, not an independent ranking. (web-7)	Potentially suitable for organizations prioritizing repository, CI/CD, security operations, audit, and enterprise governance controls. This is an editorial interpretation of the cited GitLab documentation, not an independent ranking. (web-8)
Pricing evidence and review date	According to the Linear pricing page reviewed on September 19, 2026, the page listed Free, Basic at $10 per user per month billed yearly, Business at $16 per user per month billed yearly, and custom annual Enterprise pricing. (recon-4)	Comparable Jira pricing evidence and a pricing review date were not supplied for this comparison.	Comparable GitLab pricing evidence and a pricing review date were not supplied for this comparison.
Workflow trade-off — editorial interpretation	A focused product-development system may be attractive to teams that want less separation between planning and engineering work; verify whether it covers every required enterprise control. This is an editorial interpretation based on the documented workflow, not a measured advantage.	More configurable approval patterns may help complex organizations but can require careful gate design to avoid review fatigue. This is an editorial interpretation based on the cited Jira guidance. (web-7)	Broad governance and delivery integration may suit complex DevSecOps environments; assess implementation and administration overhead for the team. This is an editorial interpretation based on the cited GitLab documentation. (web-8)

The team-size and extensibility rows deliberately avoid unsupported rankings. The supplied evidence describes capabilities and workflows, but it does not provide comparable team-size thresholds, implementation benchmarks, or feature-by-feature extensibility data for all three products. Likewise, the dated pricing evidence is complete only for Linear; verify current prices, plan inclusions, agent access, review features, audit controls, and governance capabilities before selecting a tool.

What to measure after rollout

Measure speed, quality, and governance separately. A faster agent workflow is not successful if it increases escaped defects or turns review into a formality.

Speed metrics

Time from approved issue to first useful pull request
Cycle time from issue start to merge
Agent turnaround time by task type
Human review wait time
Rework time after review

Quality metrics

Defects found before merge
Escaped defects linked to agent-assisted changes
Rollbacks and emergency fixes
Test coverage or test-quality changes where the team has a reliable baseline
Reopened issues and post-merge rework

Governance metrics

Percentage of changes with a named human owner
Percentage with required test and risk evidence
Meaningful review comments per change, interpreted carefully rather than optimized mechanically
Approval latency by risk class
Escalation frequency and resolution time
Sampled-audit findings
Permission or policy violations

Do not use approval rate as the main success metric. The supplied research on reviewer habituation makes clear why a rising approval rate can coexist with declining scrutiny. Pair approval data with defect interception, rework, audit findings, and review quality. (web-6)

A 30-day implementation plan

Week 1: Define boundaries

Select one repository and two or three low-risk task types.
Assign a human owner to every delegated issue.
Create risk labels based on reversibility, blast radius, ambiguity, data sensitivity, and release impact.
Define prohibited actions, including unapproved production changes and unrestricted credential access.

Week 2: Standardize issue and pull-request context

Require explicit outcomes, scope, constraints, expected behavior, and acceptance criteria.
Add a pull-request template for agent identity, changed files, test evidence, unresolved risks, and rollback notes.
Configure automated checks before allowing merge.
Decide which actions require a second reviewer or specialist approval.

Week 3: Pilot bounded delegation

Delegate small, reversible tasks.
Review diffs and evidence rather than relying on agent summaries.
Record ambiguity, permission problems, missing tests, and unnecessary scope expansion.
Keep the human owner accountable for the result.

Week 4: Audit and adjust

Compare speed, quality, and governance metrics with the team’s baseline.
Sample approved changes for review quality.
Tighten or expand authority by task category—not by overall enthusiasm for the tool.
Escalate only after the team can show reliable verification and clear rollback.

The bottom line

The strongest human-in-the-loop AI software development workflow is neither fully manual nor fully autonomous. It is a phased system in which humans frame the problem and own consequential decisions, agents perform bounded implementation work, automated checks provide evidence, and reviewers make explicit decisions at risk-appropriate gates.

Editorial interpretation: Linear is particularly suitable for product and engineering teams that want the human owner, issue context, delegated coding work, pull request, and review handoff to remain visible in one product-development workflow. Its documentation supports that use case, but it does not establish superior engineering outcomes, eliminate security risk, or replace the need for local governance. Jira and GitLab remain credible alternatives with documented approval, audit, escalation, and DevSecOps controls. Choose based on the workflow you need to govern—not on the promise of autonomy alone.