Twitter: @juanantoniobm

AI-Native Java Engineering

From Local Correctness to System-Aware Java Engineering

Juan Antonio Breña Moral

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 (45 minutes)

  • Introduction (7 min)
  • The problem (8 min)
  • Local correctness (8 min)
  • System awareness (12 min)
  • Operating at scale (7 min)
  • Takeaways (3 min)

ACT I

Introduction

Introduction

The usage of AI in software engineering is changing the way of work but with the change appear new challeges to address.

Three project realities

Greenfield

Design the context

Define boundaries
contracts
and owners

Brownfield FOCUS OF THIS TALK

Discover and connect context

Trace dependencies
document decisions
and close gaps

Legacy

Recover and validate context

Read behavior
data and incidents
then test assumptions

Focus: brownfield enterprise systems—working software, fragmented knowledge, and live dependencies.

ACT II

The problem

Implementation accelerates. Context does not.

Everything can be green—and production can still break

✓ Compiles
✓ Unit tests
✓ Integration tests
✓ Acceptance criteria

💥 Production breaks

The checks proved the implementation—not the whole consequence.

How can a change be completely correct and still be wrong?

Communication boundaries become system boundaries

Organizations design systems that mirror their communication structures.

Paraphrased from Melvin Conway, 1968.

AI may amplify Conway's Law

Weak communication boundary
→
Agents generate changes faster
→
Inconsistency propagates faster

AI accelerates technology—not the whole system

People

Ownership
Communication

Process

Specification
Validation

Technology

Agents
Tools

AI accelerates technology.
System correctness still depends on all three.

ACT III

Local correctness

Specification constrains the work inside the visible boundary.

Prompting is not specification

Add rate limiting to the Java API.
Per user, API key, or IP?
Which endpoints?
Which limit and window?
Distributed?
Retry-After?
How is it observed?

Implementation is not the problem. Ambiguity is.

Specify before generating

Intent
→
Constraints
→
Implementation

Evidence closes the loop.

Correct generation needs behavior and implementation constraints

Functional — Why / What

Business rules
Acceptance criteria
Constraints
Quality attributes

Technical — How

Components
Interfaces
Migration
Validation

OpenSpec makes technical decisions explicit.

Specifications solve task ambiguity.
They do not solve system blindness.

What should this change do?
What else will this change affect?

ACT IV

System awareness

The blast radius extends beyond the repository.

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.

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.

What should an organizational product provide?

  • Structure knowledge about domains, subdomains, ownership, and technical dependencies.
  • Register approved, versioned skills for engineering work.
  • Expose relevant knowledge and skills to agents through MCP.

🤔 One product. Three capabilities.

ACT V

Operating at scale

Turn organizational knowledge and engineering skills into governed, queryable infrastructure.

Large organizations need a shared knowledge product

Knowledge base

What is true here?

Domains, subdomains, systems, owners, decisions, and dependencies

MCP server

How do agents access it?

Query knowledge and discover relevant skills on demand

Skills registry

How should work be performed here?

Approved, versioned engineering policies and practices

One product structures knowledge, registers practices, and exposes both consistently.

The knowledge model connects ownership to technical dependencies

WHERE? · Business

Domain → Subdomain
→ Bounded Context

WHO / WHY? · Organization

Team → Owner
→ Criticality → Decisions

WHAT DEPENDS? · Systems

Service → API
→ Event → Database

DDD locates the change; technical relationships reveal its blast radius.

MCP gives agents a wider organizational horizon

Knowledge product
Context + skills
→
MCP server
Query + discovery
→
Engineers + AI agents

Retrieve the relevant organizational context and approved practice for each change.

Model Context Protocol

Trusted context is a socio-technical system

People

Owners define context and coordinate change

Process

Publishing and validation keep it trustworthy

Technology

Knowledge base, skills registry, and MCP server scale access

Technology scales access; ownership and process sustain trust.

Plinth operationalizes the engineering workflow

The organization owns its context

Domains → Systems
→ Owners → Contracts → Decisions

Plinth guides execution

Issues → OpenSpec
→ Commands → Agents → Skills

Implementation → Validation → Evidence

The organization supplies its knowledge; Plinth turns intent into validated change.

github.com/jabrena/plinth

From organizational intent to validated change

An opinionated AI-native workflow for evolving modern Java Enterprise SDLC practices

/onboarding
↓
Issue
↓
/update-issue → /explore-problem → /create-acceptance-criteria
↓
/create-spec → /explore-design
↓
/implement-spec → /close-spec

github.com/jabrena/plinth

CLOSE

Takeaways

Takeaways

  • Formalize cross-team communication to avoid "Frankenstein" systems.
  • Architects must strengthen consistency across domains, subdomains, and teams.
  • Use monorepos to facilitate the AI-agent harness.
  • Every large organization needs a governed knowledge product, a skills registry, and an MCP interface for agent access.

Takeaways

  • An AI-agent harness is not a silver bullet.
  • Specify before generating.
  • Engineer the workflow, not just the prompt.
  • Optimize for system awareness and system correctness.

References

Q&A?

🙏 Thank you 🙏

Slides

jabrena.github.io/plinth/jcconf-2026/

Slides


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