Smarter AI, Safer Java: The Workflow That Stops Slop in Legacy Codebases

A practical blueprint for Java developers to use AI effectively in complex systems—reducing rework, improving clarity, and keeping behavior predictable.

AI coding tools are finally good enough that we can’t ignore them anymore. But they’re also unpredictable enough that we shouldn’t trust them blindly. Dex Horthy’s talk, “No Vibes Allowed”, crystallizes something many Java teams feel but rarely articulate: AI does not magically make legacy complexity go away. It just makes bad habits scale faster.

Below I’ve separated the talk’s core ideas from my own experience building AI-driven workflows around large Java systems, including everything I’ve written recently about Bob, contextual intelligence, modernization, and sensible architectural guardrails.

This isn’t about hype.
It’s about keeping large Java systems stable while the development model shifts underneath us.

What Dex Said (and why it matters)

Brownfield systems break AI-assisted coding

Dex is blunt: AI performs best in greenfield scenarios and produces “slop” in older systems. In real terms, that means: if your Java application has been running for 8 years and carries domain logic embedded in XML configuration, annotations, and tribal knowledge, an AI model has no idea what not to touch.

This maps exactly to enterprise Java:
• distributed legacy microservices,
• JPA entities with footguns,
• business logic leaking into startup listeners,
• hidden coupling between REST resources and data layers.

AI can speed up everything except discernment.

Context Engineering as a necessary discipline

Dex argues that the model is only as good as its context window. Once you fill it with noise, the model falls into the “dumb zone.” His solution: Intentional Compaction—compressing the thread into a small, clean, curated summary, then starting fresh.

Practically, this is exactly how you prevent AI from hallucinating new REST endpoints or misinterpreting Java module boundaries.

Research > Plan > Implement

This is the part that resonated most strongly. Dex advocates an explicit RPI workflow:

Research: Understand how the system actually behaves.
Plan: Write out the exact steps and expected changes.
Implement: Execute only when the plan is clear and correct.

For Java teams, this mirrors classic architecture review cycles but compresses them into an iterative loop suitable for AI-driven coding.

Do not outsource thinking

His most important point.
AI amplifies clarity and amplifies confusion.
A bad plan generates bad code faster.

This is not “prompt engineering.” This is engineering.

What I Think (and what Java teams should do)

Every enterprise Java estate I see today deals with the same hard constraints:

• Maintain stability and performance across large, heterogeneous systems.
• Reduce architectural drift before it becomes unfixable.
• Introduce modern patterns safely—without breaking business rules hidden in code paths no one remembers.
• Ensure code, configuration, and documentation reflect intent, not history.
• Deliver user-visible improvements without catastrophic regressions.

AI doesn’t remove these constraints.
It magnifies them.

But Dex’s framing gives us tools to make AI productive in this environment.

Below is how I translate his ideas into Java architecture practice.

Treat context as a dependency, not a convenience

In modern Java systems, especially Quarkus and Spring Boot estates, your “context” is not just code. It includes:

• configuration overlays,
• health checks,
• build-time flags,
• JPA load-time behavior,
• classpath vs module-path quirks,
• platform-specific integrations (OpenShift, ECS, Lambda),
• distributed tracing headers,
• messaging schemas,
• ancient controllers wired to fragile JSON structures.

AI agents need curated, intentional visibility into these domains.
Not raw dumps.
Not a wall of YAML.
Not 300 files of “look at everything.”

Dex’s point about the “dumb zone” is exactly what happens in Java when the model sees too much and understands little. It starts making up behaviors that contradict real constraints: transaction boundaries, entity cascades, CDI scopes, or security interceptors.

This is where modern Quarkus practices like build-time augmentation, Dev Services, structured IO, give us an advantage. They provide stable, explicit boundaries that are easier for an agent to reason about when reinforced with compacted context.

Research is where you discover hidden coupling

Most Java systems have surprises:

• a service that fails when a feature flag flips,
• entity graphs that load half the database,
• async code that isn’t actually async,
• two modules sharing a DTO “temporarily” since 2016.

AI cannot guess this.

But AI can help explore it—if research output is small, vetted, and grounded in actual code. Our earlier discussions about Bob’s contextual UI point to the future here: combine explicit agent research with contextual, real-time system annotations so developers see downstream effects before anything is modified.

Research isn’t just for the agent.
It’s for the human reviewing the agent’s understanding.

Planning is the antidote to architectural drift

Dex calls it “compression of intent.”
I call it the first real way to make AI predictable inside a legacy Java estate.

Plans shift the conversation from “what changed” to “why these changes are the correct ones.”

A good plan in a Java codebase looks like:

• exact files and methods being touched,
• expected behavior before and after,
• test assertions stated upfront,
• configuration changes explicit and isolated,
• migration notes included for reviewers,
• CI impact described (ports, environments, feature flags).

This accomplishes something vital:
It forces alignment before a single line of code exists.

In large Java programs, alignment is more valuable than velocity.
Misalignment is how regressions happen.

Implementation becomes mechanical and not creative

Once the plan is clear, implementation by the agent feels less like “AI magic” and more like a deterministic compiler front-end. The work becomes safe because the thinking already happened.

This is where Bob’s agentic extension model fits perfectly:
turn plans into structured, trackable units of work that maintain traceability across services, environments, and modules. Not vibes. Not conversational drift. Structured execution.

This model aligns with enterprise reliability goals:

Predictability over spontaneity.
Traceability over speed.
Stability over novelty.

AI should not replace the architecture runway

Modernizing a large Java estate is already difficult:

• Keeping Quarkus and Spring Boot versions aligned
• Removing ancient XML config without rewriting the world
• Introducing event-driven components safely
• Migrating JPA queries to repositories without rewriting business logic
• Refactoring long-lived clusters to serverless boundaries
• Consolidating auth flows without breaking SSO

The RPI approach does not remove this runway.
It stabilizes it.

Your team stops burning cycles rediscovering domain knowledge.
You avoid re-learning why a certain module “must never” use a certain service.
Your documentation becomes executable.
Your architectural intent stops being tribal knowledge.

This is exactly where enterprises start winning with AI:
not in greenfield speed, but in brownfield clarity.

What leaders must enforce

None of this works if leadership expects AI to replace design.

Architects and tech leads need to:

1. Establish context engineering as a team discipline
   No long conversations, no bloated context windows, no vibes-driven prompts.

2. Make plan review the new code review
   Diffs don’t show intent. Plans do.

3. Require validation before implementation
   Especially in systems with non-obvious coupling.

4. Invest in workflow, not tool-hopping
   Switching between models creates noise, not clarity.

5. Treat modernization as an ongoing architectural responsibility
   Not a one-off migration project.

AI is powerful, but without guardrails it accelerates architectural entropy.

Leadership must design the guardrails.

Dex’s talk nails the technical truth: AI needs structure to be effective.
But for large Java estates, the cultural truth is even more important:

We don’t need faster code. We need clearer intent.
AI can help with the first only after we master the second.

In case you’re interested in reading more: