Yes, we're already flooded with coding assistants that promise to accelerate development. I myself have been writing extensively on LinkedIn with the results of my research. But I can't ignore the fact that IBM has introduced Project Bob, a tool I haven't been able to work with personally since I'm in waiting list to join the testing program.
Right from the start, it positions itself—or rather, promotes itself—as an AI-based development "partner" that understands developer intent, the complete repository, and organizational standards. Something we've already been reading about and testing from its competitors.
But since I haven't been able to use it yet, I'll try to describe IBM’s bet based on what can be read about the project directly on the internet.
IDE-Based: Genius or Mistake?
IBM has been through this before with generating its own IDEs, and surely that experience helps it understand that developers don't want that. Bob starts from the VS Code base, offering complete control of the environment without the integration problems of an extension with existing tools.
IBM's justification for this architecture is clear and direct: "Reliable AI-assisted development requires ownership of context, execution, and coordinated change across the entire workspace." According to its creators, this level of systemic control cannot be achieved through superficial integration. This is because Bob needs to control the entire toolchain—build systems, test execution, etc.—something impossible for a simple plugin.
This decision represents a tradeoff. On one hand, by controlling the entire environment, Bob can perform deep analysis and coordinated transformations spanning multiple files, configurations, and modules. On the other hand, it introduces considerable friction by asking developers to abandon their highly customized environments. IBM seems aware of this challenge, positioning Bob as a complementary tool for specific tasks, as Markus Eisele illustrates:
"In practice, Bob complements existing tools. Many developers continue using IntelliJ for day-to-day coding and debugging. Bob is opened when the task benefits from deep analysis, planning, or coordinated change."
Think First, Code Later: Focus on Planning
This confirms the agent usage pattern: Project Bob adopts a "plan first, code later" philosophy. This approach materializes in its "Plan Mode," a capability specifically designed for the complexities of enterprise software.
In this mode, Bob doesn't rush to write code. Instead, it analyzes the entire project as an integral system. This process is designed for the reality of "real, legacy Java projects," where development is a game of evolution, not creation. Veteran developers know they spend more time reading code than writing it, and understanding the system is much more critical than writing speed. Bob infers architectural layers, identifies key abstractions, and exposes relationships between different components before a single line is modified.
Bob doesn't want to be a shortcut, but rather a tool for experienced developers and architects. It reinforces disciplined engineering practices, prioritizing systemic understanding over immediate implementation—a characteristic that resonates with the challenges of maintaining and evolving large codebases.
Java Modernization as an Engineering Task
Modernizing legacy Java applications is a complex and costly task. Project Bob addresses this problem not as an act of guesswork, but as a systematic and controlled engineering process.
The documentation describes a structured workflow that follows logical steps: first, it analyzes the project structure and detects the build system. Then, crucially, it automatically creates a Git branch dedicated to the task and generates a visible "to-do list" for the developer. From there, it applies fixes incrementally, grouping errors by their root cause to avoid repetitive attempts, and runs tests after each step to validate changes. This process extends beyond compilation, as it can validate runtime behavior for Spring Boot and Open Liberty applications.
To ensure developer safety and control, Bob implements two key features:
Diff-based changes: All modifications are presented as explicit differences that the developer must review and accept. It never rewrites code silently.
Checkpoints: These function as intelligent restore points. If a modernization task takes a wrong turn, it's faster and safer to restore a checkpoint than to try to correct course with more instructions.
This directly focuses on enterprises managing legacy Java systems, turning a high-risk task into a predictable engineering process.
Agents That Talk to Each Other: The "Software 4.0" Vision
One of Project Bob's most ambitious bets is its vision of "agentic workflows." Instead of being a monolithic AI, Bob breaks down complex tasks and coordinates multiple specialized agents for code, tests, documentation, and pipelines. This approach addresses two types of developer work: automating "mundane tasks" to free up time and augmenting capacity for "complex tasks" where expert judgment is required.
The future vision is that these agents will communicate with each other using natural language to automate complete processes. Neel Sundaresan, General Manager of Automation and AI at IBM, describes it this way:
"Increasingly, as we move into what I call software 4.0, agents talk to other agents automatically in human language. So suddenly you have computers speaking human languages instead of humans speaking computer languages."
This concept represents a paradigm shift at IBM, moving from simple task automation to software development lifecycle automation. While this is Bob's most futuristic claim, it remains to be seen how much of this vision is implemented today and how much belongs to its long-term roadmap.
Transparency: Cost and Tokens Are Not a Secret
In an ecosystem where AI costs are often opaque, Project Bob introduces radical transparency. After completing a major task, such as a framework migration, the tool provides a clear summary that includes token usage and estimated API cost.
This transparency is grounded in a specific cost optimization claim. According to IBM, using Bob for a task would cost "more like 35 cents, 40, 45 cents" for every dollar that would be spent going directly to a frontier AI model provider.
The importance of this feature cannot be overstated. It allows teams to reason about AI usage the same way they reason about CI/CD minutes or cloud spending. This transparency builds trust and enables development teams to make informed economic decisions, correlating AI effort with outcomes achieved—a crucial differentiator versus other tools with less clear pricing models.
IBM's Backing
Every reading of Bob speaks to a comprehensive and opinionated platform that makes a strategic bet on a different development paradigm. This paradigm values system-level understanding, deliberate planning, and engineering discipline that encompasses not only controlled modernization but also integrated security. Bob includes inline vulnerability scanning (via Semgrep) and secret detection directly in the workflow. And of course, the strong backing of IBM.
The real question isn't whether AI can write our code, but whether developers are willing to adopt new workflows to allow it to think alongside them. Is IBM's bet on a "smarter, not just faster" developer the right one for the future of enterprise software?
