AI-Native Tooling for Java Development

Juan Antonio Breña Moral
Leandro Loureiro

Duke, the Java mascot

Who I am

Juan Antonio Breña Moral 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.

Who I am

Leandro Loureiro Leandro Loureiro
Engineering Manager @ ING

GitHub | LinkedIn
I'm from Portugal, living in Amsterdam
Spent most of my career as a Software Engineer in Financial Services
Engineering Manager for the last 4 years
Passionate about travel and DIY electronics
Source: Leavitt's Alignment Model (1965) >> People, Process and Technology Framework

Talk's scope

Specialized LLMs for Enterprise

Train Specialized LLMs

Fine-tuning, LoRA/QLoRA, Distillation, ...

AI Agent Orchestration & Pipelines

Automate stable processes using AI Agents

Spring AI, LangChain4j, Embabel, ...

AI Harness Engineering FOCUS OF THIS TALK

Software Engineering enhanced with AI

SDD, Java Skills, MCP-Servers, Knowledge bases, ...

Agenda · 180 minutes

  • Introduction
  • What is Plinth?
  • Exercise 1
    • AI-Native development workflow
    • Refactor Java code with Skills
  • Exercise 2
    • AI-Native development workflow
    • Refactor Java code with Skills
  • Takeaways
  • Questions & Answers

Introduction

The usage of AI in software engineering is changing the way we work, but that change brings new challenges to address.

Three project realities

Greenfield

Design the context

Define boundaries
contracts
and owners

Brownfield

Discover and connect context

Trace dependencies
document decisions
and close gaps

Legacy

Recover and validate context

Read behavior
data and incidents
then test assumptions

What is Plinth?

Plinth is an AI-native engineering toolkit for modern Java enterprise SDLC.

It started as Cursor rules for Java and evolved into reusable agent skills, agents and commands that guide AI assistants through the whole SDLC.

2 years of work and iteration, and its skills are popular on Skills.sh.

This workshop succeeds if, by the end, you understand the concepts behind implementing features with harness engineering.

Whether or not you use Plinth later, you leave with a solid starting point.

Plinth workflows

Project scope:

1 · Build a feature (Workshop included)
AI-Native development workflow
Takes an issue through functional spec, technical spec and build
2 · Improve existing code (Workshop included)
Collection of Agent Skills for Java
Applies focused skills to existing code: modern Java, design, testing, Maven
3 · Capture knowledge
Knowledge Base & Skill Registry
Builds a wiki that the agent maintains from your sources, next to a registry of skills
4 · Reuse knowledge
Knowledge Base MCP Client
Lets your coding agent query the knowledge base through MCP

AI-Native development workflow

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

github.com/jabrena/plinth

Refactor the code with Skills

Modern Java

141-java-refactoring-with-modern-features
142-java-functional-programming
143-java-functional-exception-handling

Design

121-java-object-oriented-design
122-java-type-design
123-java-design-patterns

Coding

126-java-exception-handling
128-java-generics
124-java-secure-coding

https://www.skills.sh/jabrena/plinth

Plinth benchmarks

Read the following articles about Plinth benchmarks:

Exercise 1

In this exercise, you will learn how to use the Plinth framework to develop AI-native Java applications.

https://github.com/jabrena/dvbe26-workshop

AI-Native Java development workflow

Installation

Install every skill for your preferred agent. Execute the command in a terminal:

                        
npx skills add jabrena/plinth --skill '*' --agent cursor -y
npx skills add jabrena/plinth --skill '*' --agent claude-code -y
npx skills add jabrena/plinth --skill '*' --agent codex -y                        
                    

Installation

Install every command for your prefered agent. Execute the command in your prefered agent:

                        
install @004-commands-installation cursor
install @004-commands-installation claude-code
install @004-commands-installation codex
                       
                    

Installation

Install every agent for your prefered agent. Execute the command in your prefered agent:

                        
install @005-agents-installation cursor
install @005-agents-installation claude-code
install @005-agents-installation codex
                       
                    

Demo: Install Plinth in your repository

Installation

Once the installation finishes, your repository is ready to run the AI-native workflow and deliver any feature of a Java Enterprise project.

AI-Native development workflow

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

github.com/jabrena/plinth

/onboarding


Makes the repository ready to work with Plinth AI native workflow
by securing two prerequisites:

Root AGENTS.md
Repository-specific instructions for the coding agent
Interactive: asks 6 questions, one by one
  1. Role · backend, full-stack, DevOps, architecture…
  2. Tech stack · Java version, build tool, frameworks
  3. File structure · read-only vs. editable folders
  4. Commands · build, test, run
  5. Git workflow · commit style, PR checklist
  6. Boundaries · always, ask first, never
Init OpenSpec project
Creates OpenSpec project structure by running openspec init

* Only needs to be done once per repository / project.

Demo: Prepare your repository for use AGENTS.md & OpenSpec

Pick up an issue

Source: https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/define-features-epics?view=azure-devops&tabs=agile-process

Why the separation and order matters

Two artifacts, two questions, two audiences

Functional Specification
What the system must do, and why
approved by the business
Technical Specification
How to build and verify it
approved by engineering
Decide the how first and it silently becomes the what

Functional Specification


/update-issue
→
/explore-problem
→
/create-acceptance-criteria

Good specifications require time

AI makes implementation 10× faster.
Understanding intent, constraints, and consequences still runs at 1×.

The Three Amigos!


Source: https://www.imdb.com/es-es/title/tt0092086/

The Three Amigos is an Agile practice where three perspectives review an increment of work before, during, and after development: Business, Development & Testing.

/update-issue


Rewrites an existing issue description as structured, evidence-backed content

Input
  • GitHub or Jira issue number, key or URL
  • Optional source: notes, discussion, user story, file path
  • Current issue body and discussion are read first
Output
  • Structured user story in the issue description
  • Acceptance criteria or scenarios when applicable
  • Updated issue reference and URL

/explore-problem


Evaluates the issue through five lenses and produces a Functional Specification

Problem framing
Problem statement, current and desired state, stakeholders, success criteria
Root cause
Five Whys, Fishbone, Current Reality Tree, constraints
Assumptions
Assumptions, unknowns, validation plan
Context mapping
Existing systems, integrations, ownership, external dependencies
Quality attributes
Discover and prioritise what the solution must satisfy
Each lens asks clarifying questions when its content is vague

/create-acceptance-criteria


Turns the Functional Specification into observable Gherkin scenarios

Input
The Functional Specification resulted from /explore-problem
Output
# Acceptance Criteria
Feature: <name>
  Scenario: <observable>
    Given <context>
    When <event>
    Then <outcome>

turns what and why into something checkable and easier to review

Demo: Define functional specifications

HITL: Verify functional specification before moving to technical specification

Technical Specification


/create-spec
→
/explore-design

What is OpenSpec?

A lightweight and configurable framework for creating and managing software specifications.

Build the right thing, and build it right

Capture what you want to build in a spec, and keep your team and your coding agents aligned as the work evolves.

Refine
the requirements
Validate
that they describe the right thing
Verify
that the implementation matches
Plinth orchestrates spec implementation by reusing OpenSpec primitives

/create-spec


Turns approved material into a validated OpenSpec change

Input
  • Issue or user story with its acceptance criteria
  • Approved design, ADRs or implementation plan
  • An existing OpenSpec change to update
Output
  • Proposal, design, specs and task list
  • Requirements as Given / When / Then scenarios
  • Validation and traceability report

/explore-design


Refine the technical design of an issue or OpenSpec change before implementation.

Input
  • OpenSpec change with an unresolved approach
  • Architecture context and constraints
Output
  • Alternatives, trade-offs and rejected options
  • Recommended direction with rationale
  • Components, data flow, failure handling, testing strategy
  • ADR candidates and open questions
  • A recommendation is not a decision: nothing is approved until a human confirms it

Demo: Define functional specifications

HITL: Verify technical specification before moving to implementation

Build


/implement-spec
→
/close-spec

/implement-spec


Delivers an approved task list through framework-aware delegation

Input
  • Validated OpenSpec change or approved plan
  • Acceptance criteria and testing strategy
  • Repository conventions and build commands
Output
  • Code and tests for each completed task
  • Build and test run as evidence
  • Delegation does not transfer accountability: the diff is still reviewed by a human

/implement-spec

The tech lead agent runs the process, but it never writes code itself

1 · Gate
Is the spec ready?
  • Change is current, approved and consistent
  • Every scenario has a task, and every task a scenario
  • Workspace is clean
→
2 · Route
Where, and by whom?
  • Feature branch or worktree (main only with explicit approval)
  • Coder matched to the framework: Spring Boot, Quarkus, Micronaut, Java or non-Java
  • Relevant skills picked for that coder
→
3 · Delegate
Who builds what?
  • Tasks split into groups, each owning its files
  • Dependent groups run in order; independent ones run in parallel
  • Each handoff: tasks, acceptance criteria, checks to run
→
4 · Verify
Is it really done?
  • Coder returns changed files, test and build results
  • Task marked done only when its acceptance criteria pass
  • Blockers and risks reported
✗ If any check fails, it stops and reports. Nothing is guessed, bypassed or invented.

/implement-spec

The tech lead delegates the work to specialized coding agents

plinth-tech-lead
Coordinates, never codes
↓
plinth-java-coder
Plain Java, Maven, JVM
plinth-java-spring-boot-coder
Spring Boot
plinth-java-quarkus-coder
Quarkus
plinth-java-micronaut-coder
Micronaut
plinth-no-java
Any non-Java stack

/close-spec


Archives a delivered OpenSpec change and folds it into the specs

Input
  • OpenSpece change whose tasks are complete
  • Evidence that acceptance criteria are met
Output
  • Change archived through the OpenSpec CLI
  • Specs updated to reflect the new behaviour
  • A clean slate for the next change

Demo: Define functional specifications

HITL: Verify that implementation has any gap or something missing before commiting

Refactor the code with Skills

Refactor

Implement and improve Java applications with guidance on:

Modern Java

modern features · functional programming · functional error handling

Design

object-oriented design · type design · design patterns

Coding

exception handling · generics · secure coding

Architecture

diagrams · ADRs

Maven

best practices · dependencies · plugins

Testing

strategies · unit · integration · acceptance

Performance

JMeter · Gatling

Profiling

detect · analyze · refactor · verify

Observability

logging · metrics · tracing

125 Skills

Modern Java

141-java-refactoring-with-modern-features Add Modern Java Features
Lambdas & method references · Stream API · Optional · java.time · var · List.of() · text blocks · Java 25 features
142-java-functional-programming Add Functional Programming style
Records & immutability · pure functions · function composition · pattern matching · sealed types · Stream Gatherers
143-java-functional-exception-handling Apply functional programming approaches for error handling
Optional & VAVR Either over exceptions · sealed error hierarchies · map/flatMap error pipelines
Separate data from behavior with records · immutable data & pure transformations · flat data with ID references · pure validation

Skills inventory for Java

Design

121-java-object-oriented-design Apply Object Oriented Design principles
SOLID · DRY · YAGNI · composition over inheritance · encapsulation · code smells: God Class, Feature Envy, Data Clumps
122-java-type-design Review Type Design in development
Value objects over primitive obsession · type-safe wrappers · generics · fluent interfaces · BigDecimal for money
123-java-design-patterns Select and apply Java, REST, event-driven, persistence, and integration patterns
Creational, structural & behavioral patterns · REST contracts · Kafka outbox & sagas · repositories & transactions · anti-corruption layers

Skills inventory for Java

Coding

126-java-exception-handling Add Exception handling
Specific exception types · try-with-resources · exception chaining · fail-fast validation · translation at API boundaries · retries & timeouts
128-java-generics Apply generics in a class
No raw types · PECS wildcards · bounded type parameters · generic methods · type erasure · @SafeVarargs · generics with records & sealed types
124-java-secure-coding Review my code for Secure Java Coding rules
Input validation · parameterized queries · least privilege · strong cryptography · secrets management · safe deserialization · output encoding

Skills inventory for Java

Architecture

033-architecture-diagrams Generate UML, C4, ER and bounded-context diagrams
UML sequence, class, state-machine & deployment diagrams · C4 model · ER diagrams · bounded contexts · modular step-based process
030-architecture-adr-general Generate Architecture Decision Records (ADRs)
Interactive, one question at a time · context, stakeholders, options & outcomes · auto-numbered ADR files

Skills inventory for Java

Build · Maven

110-java-maven-best-practices Analyze your pom.xml and apply Maven best practices
Dependency management with BOMs · version centralization · plugin configuration · multi-module structure · build profiles
111-java-maven-dependencies Add Maven dependencies for improved code quality
JSpecify nullness · Error Prone + NullAway · VAVR · ArchUnit · JavaMoney · only what you actually need
112-java-maven-plugins Update your pom.xml with Maven Plugins
Enforcer · Surefire & Failsafe · JaCoCo · PIT · SpotBugs & PMD · OWASP · Spotless · Versions · Jib · JMH

Skills inventory for Java

Testing

130-java-testing-strategies Apply testing strategies
RIGHT-BICEP to guide test creation · A-TRIP for test quality · CORRECT for boundary conditions
131-java-testing-unit-testing Apply Unit Testing best practices
JUnit 5 · AssertJ · Mockito · Given-When-Then · parameterized tests · test independence · no reflection or shared mutable state
132-java-testing-integration-testing Set up integration test infrastructure with WireMock
BaseIntegrationTest · WireMock JSON mappings · stubs isolated per test · verified HTTP interactions · no mocked HTTP clients
133-java-testing-acceptance-tests Implement acceptance tests from Gherkin scenarios
@acceptance scenarios · RestAssured · DB/Kafka fixtures · WireMock for external REST · *AT classes run by Failsafe

Skills inventory for Java

Performance

151-java-performance-jmeter Run a performance test with JMeter
run-jmeter.sh script · load tests with loops, threads & ramp-up · test plans generated from your REST endpoints
152-java-performance-gatling Set up Gatling performance testing
Gatling dependencies & Maven plugin · Java simulations · gatling:test · assertions & feeders · report review

Skills inventory for Java

Profiling

161-java-profiling-detect Profile your application at runtime and collect evidence
async-profiler · CPU, memory, threading, GC & I/O · JFR recordings · flamegraphs · interactive profiling scripts
162-java-profiling-analyze Analyze the evidence and generate reports
Flamegraphs · CPU hotspots · allocation patterns · threading issues · problem categorization · Impact/Effort prioritization
163-java-profiling-refactor Refactor code to fix the bottlenecks found
Targeted changes for CPU, memory & threading issues from the analysis reports · verified with ./mvnw clean verify
164-java-profiling-verify Compare results before and after the changes
Baseline validation · before/after metrics · side-by-side flamegraphs · regression detection · final results report

Skills inventory for Java

Observability

181-java-observability-logging Apply logging guidelines
SLF4J with Logback/Log4j2 · proper log levels · parameterized logging · correlation context · no sensitive data in logs
182-java-observability-metrics-micrometer Apply Micrometer metrics best practices
Timers, counters, gauges & distribution summaries · naming & tag conventions · cardinality control · Actuator/Prometheus
183-java-observability-tracing-opentelemetry Apply OpenTelemetry distributed tracing
Span modeling · context propagation · semantic conventions · sampling strategy · privacy-safe attributes · OTLP collectors

Skills inventory for Java

Demo: Refactor the solution using a specific Skill

HITL: Verify that implementation has any gap or something missing before commiting

Exercise 2

In this exercise, you will learn how to use the Plinth framework to develop AI-native Java applications.

https://github.com/jabrena/dvbe26-workshop-exercise-2

Takeaways

Takeaways

Know what to build before you build it

  • The functional spec (what and why) is settled before the how
  • Specs are based on the real issue, codebase and constraints
  • Acceptance criteria make "done" verifiable

Takeaways

Humans stay in control

  • HITL checkpoints after the functional spec, the design and the build
  • Agents recommend; humans decide and approve
  • Delegating to agents does not hand over accountability

Takeaways

Modular, adapt it to your case

  • Run the full workflow, or pick single commands, skills or agents
  • Greenfield, brownfield or legacy projects
  • Plain Java, Spring Boot, Quarkus or Micronaut; Cursor, Claude Code or Codex

Takeaways

Context that persists

  • Issues, specs, acceptance criteria and ADRs are kept as traceable artifacts
  • Context outlives a single chat and is easy to share and review
  • Teammates and agents reuse it for the next change

AI speeds up delivery;
specs, verification and human checkpoints keep it on track

🙏 🙏 🙏

Thanks