Recently, I watched the first episode of Bob TV, hosted by Maximilian Jeesh, featuring Neel Sundaresan, General Manager of Automation and AI at IBM and one of the key leaders behind IBM Bob. What started as a discussion about AI coding assistants quickly evolved into a much broader conversation about software engineering, enterprise innovation, AI adoption, and the future of technical careers.
What struck me most was that very little of the discussion was actually about generating code. Instead, it focused on how AI is changing the way software is designed, maintained, modernized, secured, and delivered. That distinction feels important because much of the public conversation around AI still centers on code completion and productivity metrics. Neel's perspective was that software engineering is undergoing a much deeper transformation.
Long Before AI Coding Was Popular
One of the fascinating parts of the conversation was hearing how Neel started working on AI-assisted development years before the current wave of large language models existed. Today it is easy to assume that AI coding assistants appeared because ChatGPT arrived on the scene, but the reality is much more nuanced.
While working at Microsoft, Neel became interested in the enormous volume of code available across GitHub repositories. His belief was that developers repeatedly write variations of code that already exist somewhere else. If machines could learn patterns from previously written software, perhaps they could help developers by recommending APIs, parameters, and implementation patterns.
At the time there were no frontier models, no trillion-parameter systems, and no transformer-driven coding assistants. The team built recommendation systems using traditional machine learning techniques, and while the accuracy wasn't spectacular by today's standards, developers still found the tool useful because it eliminated friction.
That lesson has remained surprisingly relevant. The goal of AI isn't necessarily perfection. Sometimes simply reducing friction creates value.
Being Too Early Isn't the Same as Being Wrong
Another theme that resonated with me was Neel's attitude toward failed ideas and early experimentation. Many people describe projects that don't immediately succeed as mistakes. His view was that many of those initiatives are actually good ideas that arrive before the supporting technology is ready.
AI for software development is a perfect example. The concept existed years before it became commercially viable. The vision was there long before the GPUs, infrastructure, models, and datasets necessary to support it.
Instead of seeing early failures as wasted effort, Neel viewed them as preparation. By continuing to explore ideas before the technology matured, teams become ready when the environment changes. When foundation models, scalable infrastructure, and modern AI tooling finally arrived, the work that had been done years earlier suddenly became practical.
That mindset applies well beyond AI. Many innovations appear impossible until the surrounding ecosystem catches up.
Building a Startup Inside IBM
One of the questions Max asked was how IBM Bob was created so quickly inside a company with hundreds of thousands of employees.
The answer surprised me.
Bob didn't begin as a massive strategic initiative with huge teams and extensive resources. There was no large organizational structure dedicated exclusively to the project. Instead, the team operated much more like a startup than a traditional enterprise software group.
Neel explained that small teams can move quickly, experiment freely, and recover from mistakes without creating significant organizational disruption. That flexibility allowed the team to test ideas, gather feedback, and iterate rapidly.
An especially interesting detail was that Bob helped build Bob. The team actively used the product while developing it, creating a feedback loop where they could quickly identify weaknesses, improve workflows, and validate new features.
The lesson is clear: innovation often starts small. It doesn't require massive organizations. It requires focused people, a clear goal, and the willingness to learn continuously.
Enterprise AI Is a Different Challenge
The discussion then shifted toward one of the most important distinctions in the AI industry: the difference between consumer AI and enterprise AI.
Many coding assistant demonstrations focus on creating new applications. A user asks an AI to generate a website, an API, or a microservice, and everything looks impressive. However, enterprise software development rarely revolves around greenfield applications.
Most enterprise engineering effort is spent on modernization, migration, maintenance, security, governance, compliance, and integration.
Organizations still run business-critical workloads built over decades. They maintain Java systems that have existed for years. They modernize mainframe applications, migrate infrastructure, address security requirements, and comply with regulatory frameworks.
That reality fundamentally changes what an AI assistant needs to do.
Rather than focusing exclusively on code generation, IBM Bob was designed to help with COBOL modernization, enterprise Java workloads, governance workflows, compliance requirements, migration projects, and other tasks that dominate real-world enterprise engineering.
The AI challenge isn't simply writing code.
The challenge is helping organizations evolve complex systems safely.
Why IBM Bob Doesn't Let You Choose Models
One of the more controversial design decisions discussed was intelligent model routing.
Many AI products emphasize model selection. Users are constantly encouraged to choose between the latest reasoning model, coding model, or thinking model.
Bob takes a different approach.
Instead of asking the user to pick the model, the platform determines which model is most appropriate for the task. Neel compared this to transportation choices: you don't use the same vehicle for every situation.
Some tasks require powerful reasoning models. Others benefit from smaller, faster, and more efficient systems. The optimal choice depends on the problem, not on which model happens to be trending.
To make this work, the Bob team continuously evaluates models across several dimensions:
- Accuracy
- Latency
- Cost
- Productivity impact
- User experience
The result is a system where developers focus on solving problems while the platform handles the complexity of model selection. As the number of available models continues to grow, this approach seems increasingly relevant.
AI Is Not Replacing Software Engineers
Eventually, the conversation reached one of the most common questions in technology today.
Will AI replace software developers?
Neel's response was straightforward: no. In fact, he argued the opposite.
Many engineering organizations have extensive backlogs filled with projects that have lacked the resources, skills, or time to complete. AI helps teams address those opportunities. When repetitive tasks are automated, engineers can dedicate more energy to solving complex problems.
Neel described this using a simple idea:
Automate the mundane and augment the complicated.
Testing, documentation, boilerplate generation, and repetitive implementation work can often be accelerated by AI. At the same time, system architecture, business logic, evaluation, governance, and decision-making remain deeply human challenges.
The result isn't fewer engineers. It's engineers working on higher-value problems.
A Better Onboarding Experience for New Developers
Another part of the discussion that I found particularly interesting involved junior engineers. Historically, new developers often spent months getting comfortable with a company's codebase, infrastructure, and development practices. Many were hesitant to ask questions because they worried about interrupting senior colleagues, while others simply waited until someone had time to help them.
According to Neel, every new engineering hire at IBM now receives Bob from day one. That dramatically changes the onboarding experience. Instead of waiting for answers, new developers can immediately begin exploring systems, understanding architecture, learning internal terminology, and asking questions as they work.
AI doesn't replace mentorship, but it dramatically increases access to information and guidance. For a new engineer, that means becoming productive faster and building confidence earlier.
What Students Should Focus On
The final section of the discussion focused on the next generation of engineers. A common assumption is that students should now focus on prompt engineering because AI will handle coding. Neel disagreed.
His advice was surprisingly traditional.
Build strong foundations.
Develop analytical thinking.
Understand systems.
Develop expertise in a specific domain.
His reasoning was that AI lowers the barrier to implementation, but domain knowledge remains invaluable. Whether someone works in software engineering, finance, healthcare, manufacturing, or law, understanding the problem space becomes increasingly important.
Programming languages become easier to access.
Expertise becomes harder to replace.
The people who thrive in the AI era will likely be those who combine domain knowledge, critical thinking, and AI-assisted workflows.
References
Bob TV – Episode 1
Host: Maximilian Jesch, Outbound Product Manager for IBM Bob
Guest: Neel Sundaresan, General Manager of Automation and AI at IBM
Topics discussed included:
- The history of AI-assisted software development
- Building IBM Bob inside IBM
- Enterprise AI versus consumer AI
- Intelligent model routing
- The future of software engineering
- AI and developer productivity
- Skills students should focus on in the AI era
Credit: Full credit to Maximilian Jesch and Neel Sundaresan for the original Bob TV conversation and the insights shared throughout the session. This article is a paraphrased interpretation and summary of the discussion.
Top comments (0)