Beyond the Green PR: Human Control for Agentic Java

HITL and EU-aware governance for brownfield systems

Juan Antonio Breña Moral

Duke, the Java mascot

Who I am

Juan Antonio Breña Moral
Engineering @ IG Group, EU Division

Twitter | GitHub | LinkedIn
"Make it work, make it right, make it fast."
- Kent Beck

"Lead me, follow me, or get out of my way.",
"Pressure makes diamonds."
- George S. Patton Jr.
Source: Leavitt's Alignment Model (1965) >> People, Process and Technology Framework

Agenda (30 minutes)

  • A green PR can still be wrong · 10 minutes
  • HITL at the PR: from review to decision · 11 minutes
  • Governance that changes engineering decisions · 6 minutes
  • Classify, challenge, and trace · 3 minutes

ACT I

A green PR can still be wrong

Implementation accelerates. Context and review capacity do not.

Everything can be green—and production can still break

✓ Compiles
✓ Unit + integration tests
✓ Security scans
✓ Acceptance criteria

💥 Production breaks

The checks proved the implementation—not the whole consequence.

A locally correct Java rename can break the system

Rename customerId to clientId.

record Order(String clientId, BigDecimal total) {}
					

Locally correct. What else depends on this contract?

The blast radius is larger than the repository

Mobile API
OpenAPI + Jackson
ORDER SERVICE
customerId → clientId
Database
Flyway migration
Kafka event
schema
Fraud + notifications
Data lake + ETL
BI + documentation

The repository cannot always be the unit of correctness.

Brownfield context does not accelerate with the code

Working software

Behavior already exists in code, data, and operations.

Fragmented knowledge

Decisions and ownership span teams, repositories, and time.

Live dependencies

Consumers and contracts can fail outside the changed repository.

AI can produce the rename quickly. Discovering its consequences still requires people, evidence, and time.

System awareness changes the implementation strategy

Repository-only view

Rename customerId
to clientId

System-aware view

  1. Introduce clientId compatibly
  2. Read and write both names
  3. Migrate and observe consumers
  4. Remove customerId after adoption

Same requirement. Different context. Different plan.

Parallel Change: expand → migrate → contract

Agents see tasks first; dependency failures live beyond them

ORGANIZATION -> ownership · decisions · business constraints
SYSTEM -> consumers · contracts · other repositories
REPOSITORY -> code · tests
TASK

Most coding agents start at task and repository.
Many dependency failures live outside them.

Agentic speed makes conventional PR review insufficient

Usually visible

Diff
Repository tests
CI status
Agent summary

Often missing

External consumers
Uncertainty
Applicable controls
Decision authority

Without system context, a merge approval can become cosmetic oversight.

ACT II

HITL at the PR: from review to decision

Classify → Expose evidence → Route → Decide → Observe.

The PR control loop turns review into a decision system

1 · CLASSIFY
Impact + uncertainty
2 · EXPOSE
Context + evidence
3 · ROUTE
Accountable reviewers
4 · DECIDE
Approve · modify · escalate · stop
5 · OBSERVE
Outcome + corrective action

Autonomy may propose. Authority must decide. Evidence must connect the two.

Why green PRs can still fool humans

Automation bias
Green and polished feels safe
Correlated evidence
The agent writes code and tests
Context gap
Consequences live elsewhere
Queue pressure
Generation outpaces review

A human presence does not guarantee a human judgment.

Meaningful HITL requires sight, accountability, and power to act

See enough
Context + evidence
Be accountable
Competence + authority
Be able to act
Time + intervention

Without them, approval is human-as-a-button.

1 — Classify the change before choosing the review

Start with impact and uncertainty. Autonomy, reversibility, data, rights, safety, sector, and applicable law can raise the level.

REVIEW LEVEL 1
Local and reversible
Docs · formatting · contained tests
Policy-defined review
REVIEW LEVEL 2
Application behavior
Code owner + test evidence
REVIEW LEVEL 3
Cross-system or sensitive
Contracts · schema · personal data · security
Specialist reviewers
REVIEW LEVEL 4
Rights, safety, or regulated operations
Accountable owner + controlled release

The goal is effective control where consequences matter, not approval everywhere.

2 — Expose the rename as an evidence package

Before
Requirement and scope
Known consumers
Risk classification
Decision
Compatibility strategy
Assumptions and limits
Required owners
After
Consumer evidence
Rollout and rollback
Monitoring and audit trail

The diff proposes the change; the evidence package makes the consequence reviewable.

Challenge the evidence before accepting the claim

“The customerId migration was validated successfully.”
Cosmetic review

Checks are green.
The diff looks reasonable.
APPROVE

Effective review

Which consumers were checked?
What remains unverified?
How is compatibility preserved?
What triggers rollback?

3 — Route the PR to accountable reviewers

API · event · schema
Domain + system owners
Auth · secrets · dependencies
Security + platform
Personal data · retention · logs
Privacy + data owners
Money · rights · safety · regulation
Business + compliance + safety

The right reviewer depends on the risk, not on who is available.

4 — Decide: approve, modify, escalate, or stop

APPROVE
Evidence is sufficient
MODIFY
Request changes or more proof
ESCALATE
Another owner must decide
STOP
Risk or uncertainty is unacceptable

A reviewer needs real alternatives to “Approve.”

5 — Observe: merge is not the end of the loop

Monitor, roll back, preserve evidence, and improve the control that failed.

Agent-created PR
Controlled release
Observe outcome

Prediction ↔ outcome ↔ corrective action

ACT III

Governance that changes engineering decisions

Laws, standards, and frameworks become useful when they change engineering decisions.

Governance is a control stack

HITL is the decision mechanism connecting policy to execution.

Laws & obligations
Standards
Frameworks
Organizational governance · policy · risk appetite · decision rights · owners
Engineering controls · permissions · PR gates · tests · reviewer routing · rollout
Evidence and outcomes · decision · deployment · monitoring · audit · corrective action

Classification comes before compliance claims

Regulated AI system

Article 14 requires effective human oversight for applicable high-risk AI systems.

AI-assisted development

Using an AI coding agent does not by itself classify the software being changed as a high-risk AI system.

Classify the deployed system and use case first. Apply human review, intervention, auditability, and rollback as engineering controls regardless.

Regulation (EU) 2024/1689

Three trigger families keep governance actionable

AI system risk
EU AI Act
Classify the system and use case · define oversight when applicable
Personal data
GDPR
Minimization · access · retention · rights · accountable data owner
Cybersecurity and resilience
CRA · NIS2 · DORA
Supply chain · vulnerabilities · continuity · incidents

These are routing signals—not final applicability determinations. Put broader product, platform, and market lenses in the appendix.

The rename raises three different governance questions

What can break?
OpenAPI · Kafka · Flyway
Compatibility plan + consumer owners
How was it produced?
AI-assisted development
Generated artifacts + limits + human decision trace
What is the system?
Applicable AI · data · resilience classification
Specialist owner + required controls

Development governance controls the agent-created PR. System regulation depends on what the deployed system does and where it operates.

CLOSE

Classify, challenge, and trace

Turn human presence into accountable human judgment.

What can a team do next Monday?

  1. Label agent-created PRs and record generated artifacts.
  2. Add risk triggers to the PR template.
  3. Route high-impact changes to accountable specialist owners.
  4. Require explicit limits, rollback, and monitoring evidence.
  5. Review incidents and near misses as control failures—not only code failures.

A green PR is evidence—not permission

Agents may propose.
Accountable humans decide.
The system must remember why.

Classify · Challenge · Trace

References

Q&A?

🙏 Thank you 🙏

Appendix: standards make governance repeatable

ISO/IEC 42001

AI inventory · ownership · generated-code review · provider and data boundaries · risk treatment · monitoring · corrective action

ISO/IEC 25010:2023

Functional suitability · performance · compatibility · interaction · reliability · security · maintainability · flexibility · safety

Appendix: additional EU routing signals

Data and platforms
Data Act · DSA · DMA
Product and safety
Product Liability
Financial markets
MiFID II · MAR

Use these as prompts for accountable legal and compliance owners, not as automatic applicability claims.

Slides

jabrena.github.io/plinth/dvbe26/

Slides


jbang trust list
jbang cache clear
jbang catalog list jabrena
jbang qr-code@jabrena \
  --url https://jabrena.github.io/plinth/dvbe26/
						

Other Slides