Working with an AI That Understands Your Java System, Not Just Your Files
How IBM Bob approaches planning, modernization, and controlled change in large codebases
Before going further, a quick note on context.
I have been working with Bob for a while now, both on my own Java projects and in conversations with teams using it on real, long-lived codebases. I also work for IBM, so transparency matters here.
This article is not sponsored, and it is not a product pitch. I am trying to be neutral and technical, in the same way I would evaluate any other development tool I might consider using myself. I focus on where Bob fits well, why certain design choices were made, and where it meaningfully differs from the AI tooling most Java developers have already tried.
If you want to form your own opinion, you can. Bob can be tried for free by signing up here: https://www.ibm.com/products/bob
If you are interested in a more hands-on, developer-focused angle, I have also written an earlier article that goes deeper into how Bob’s modes work in practice, including building custom modes and integrating them into a Quarkus-centric workflow:
Most AI coding tools shine when the task is small. A single file. A local refactor. A well-scoped question that fits into one prompt.
That breaks down quickly in real Java codebases.
Enterprise Java development is about evolution, not creation. You spend more time reading than writing. Changes cross modules and layers. Architecture lives in annotations, configuration, and build files, not in diagrams. Mistakes are expensive, and understanding the system matters far more than typing speed.
IBM Bob is built for that reality.
Bob is not a chat-based code generator. It is not an autocomplete engine. It is an AI SDLC partner designed to work with real, long-lived Java projects. It supports planning, analysis, modernization, and controlled change across an entire codebase.
Working Where the Code Actually Lives
Bob operates directly on a checked-out workspace. It sees the full project structure, dependencies, configuration, and conventions without asking you to restate context in every interaction.
For Java developers, this matters.
Frameworks like Spring, Jakarta EE, and Quarkus encode intent through annotations, package structure, configuration classes, and build descriptors. Bob uses those signals. It does not flatten everything into a generic prompt.
That makes Bob useful for the problems you already have:
Understanding an unfamiliar service
Planning a refactor across modules
Debugging a failing build
Extending existing functionality without breaking assumptions
Bob is designed for existing systems. Not greenfield demos.
Planning First, Coding Second
Most AI tools jump straight to implementation. Bob deliberately does not.
Planning is a first-class activity. In Plan mode, Bob analyzes your project as a system before touching any code. This goes far beyond listing files or summarizing classes.
Bob infers architectural layers. It identifies key abstractions. It surfaces relationships between components across the codebase.
In a typical Java application, that means understanding how controllers, configuration, repositories, persistence strategies, and cross-cutting concerns interact. Bob builds a model based on the actual implementation, not an idealized architecture diagram.
This is especially valuable in mature systems where architecture exists primarily in code. Bob can surface implicit design decisions, highlight coupling, and show how configuration choices influence runtime behavior.
The output is actionable. You can validate assumptions, spot risks, and decide where changes belong before writing a single line of code. When you move from Plan mode to Code mode, you are executing against a shared understanding.
That mirrors how experienced Java developers already think. Bob removes the manual effort of reconstructing the mental model every time.
Why Bob Is a Full Environment, Not an IDE Plugin
Bob is intentionally not a traditional IDE plugin. That is a deliberate architectural choice.
Reliable AI-assisted development requires ownership of context, execution, and coordinated change across the workspace. That level of control is not possible through a thin integration layered on top of another IDE.
Bob is a complete development environment because it needs to reason about your system as a whole. Planning modes, checkpoints, controlled file access, coordinated transformations, and tool execution all depend on that ownership.
For Java codebases, where meaningful changes often span modules, configuration, tests, and documentation, this matters.
In practice, Bob complements existing tools. Many developers continue to use IntelliJ for day-to-day coding and debugging. Bob is opened when the task benefits from deep analysis, planning, or coordinated change.
You work on a real checkout. You get clean diffs and commits. You return to your primary IDE with changes you understand.
Turning Vague Questions into Useful Analysis
A common failure mode of AI tools is poor input. Developers ask reasonable but underspecified questions, and the AI responds with something technically correct but practically shallow.
Bob addresses this with prompt enhancement.
In Ask mode, Bob can take a short, informal question and expand it into a structured, purpose-driven request. A prompt like “Explain this project to me” becomes a request that covers purpose, scope, architecture, constraints, risks, and impact.
Prompt enhancement is transparent and optional. You see exactly how your request is rewritten. You remain in control. This reduces back-and-forth, improves explanation quality, and makes onboarding and system understanding far more efficient.
Java Modernization Mode: Upgrades Without Guesswork
Modernizing a Java application is rarely about changing a single version number. It is about navigating build failures, dependency conflicts, deprecated APIs, and runtime issues that only appear once everything compiles.
Java Modernization Mode treats this as a systematic engineering task.
Bob starts by analyzing the project structure. It detects multi-module builds, mono-repositories, build systems, and the current Java version before attempting any changes. From there, it follows a structured workflow: build, analyze failures, group errors by root cause, apply fixes incrementally, and test after each step.
This matters in large systems, where one underlying issue can surface as dozens of similar errors across modules. Bob limits repeated attempts, rolls back when fixes fail, and keeps the workspace in a known good state.
Modernization does not stop at compilation. When applicable, Bob runs the application and validates runtime behavior for Spring Boot and Open Liberty deployments. Configuration files are analyzed alongside code to catch issues that only appear at runtime.
Every step is transparent. Changes are applied as diffs. Related files are read together for context. Every action is inspectable and reversible.
Diff-Driven Changes and Safe Experimentation
Bob never silently rewrites your project.
All changes are applied as explicit diffs that you can review. In addition, Bob creates checkpoints during tasks. These act as AI-aware restore points.
If Bob heads in the wrong direction, restoring a checkpoint is faster and safer than trying to steer output through more prompts.
This fits naturally with Git rather than competing with it. Bob assumes professional development practices and reinforces them.
Cost and Token Transparency
AI tooling often hides cost behind abstractions. That becomes a problem when AI performs non-trivial work such as a full migration.
Bob makes cost visible.
After completing a modernization or migration task, Bob provides a concise summary. This includes token usage and an estimated API cost alongside technical results such as build status and compatibility checks.
This allows teams to reason about AI usage the same way they reason about CI minutes or cloud spend. You can correlate effort with outcome and decide when AI-assisted workflows make sense.
Just as importantly, it builds trust. When a task consumes meaningful resources, you see it. When it completes efficiently, that efficiency is visible as well.
Beyond Code Generation
Bob’s architecture also enables deeper forms of code transformation.
Some modes combine static, deterministic transformations with agent-driven reasoning. Static analysis provides safety and repeatability. Agentic workflows add planning, validation, and staged execution across a system.
Coordinating both requires shared context, execution control, and change history. That only works when the development environment itself is part of the system being reasoned about.
An AI Tool That Matches How Java Developers Actually Work
Bob does not try to replace developers. It does not optimize for novelty.
It reinforces discipline. Planning before coding. Analysis before modification. Control over automation.
For Java developers maintaining large systems, that discipline is the feature.
Bob works best when treated not as a chatbot, but as a careful collaborator that understands your codebase, follows your rules, and always shows its work.
IBM Bob is not about faster typing. It is about better understanding, safer change, and controlled modernization of real Java systems.
Used well, it fits naturally into how experienced developers already work.
If you want to form your own opinion, you can. Bob can be tried for free by signing up here: https://www.ibm.com/products/bob