Greetings from Atlanta. I am writing this somewhere between my third coffee and my next session, on conference Wi-Fi that is doing its very best.
TechXchange 2026 runs from 26 to 29 October at the Georgia World Congress Center. There are more than a thousand sessions across five tracks, hands-on labs, and the usual hallway track, where the best conversations happen anyway. If you have never been, imagine every IBM product team, a few thousand practitioners and a large crowd of IBM Champions in one building, all of them with opinions. It is wonderful.
Getting there: no driver required
One evening I ordered an Uber to get across town, and the app asked me something I did not expect: would I be OK with an autonomous vehicle as my taxi? Yes, please. A few minutes later a Waymo pulled up, with nobody in the front.
It was not my first. I got to know Waymo in Phoenix a while ago. But it does not get old. It took me through the city in the evening traffic calmly and without any fuss, and I enjoyed every minute.
After twenty-five years in automotive software, it is a strange and slightly emotional experience. For someone who has spent a career talking about state machines, safety cases and “what happens if the sensor lies”, sitting in that back seat feels like watching your own field grow up. Somewhere in that car are a great many states and transitions that somebody had to explain to an assessor. I hope they used a model.
The theme of the week: software development in the age of AI
You could not miss it. The main-stage panel was literally called “The Future of Software Development in the Age of AI”, and almost every keynote came back to the same question: what does it mean to build and maintain software when an AI is doing a good part of the typing?
For IBM, a large part of the answer has a name, and it is a name I have been using every day for months: Bob.
Who is Bob?
IBM Bob is IBM’s AI development partner. It became generally available in April. It is not “autocomplete with ambitions”. Bob works across the whole lifecycle: planning, writing code, testing, reviewing, deploying and modernising. Under the hood it sends each task to the model that suits it, whether that is a frontier model, an open-source model or IBM’s own Granite models.
What makes it different, at least for me, is how it works with you:
- Modes. You can ask Bob about your code, let it plan before it touches anything, or let it write. You decide how much rope it gets.
- You stay in charge. Bob proposes, and you approve before anything changes in your source. I have spent 25 years explaining to safety assessors why the code is what it is, so that matters to me.
- MCP. Bob speaks the Model Context Protocol, so it can reach the tools and data you already have instead of living in its own little bubble.
- Subagents. For bigger jobs Bob splits the work into focused tasks that run in parallel, and you approve each one before it starts.
This week IBM added more. There is a self-hosted deployment option for organisations that cannot let their code leave the building, and there are Premium Packages for Z, for i, for Java and for DevSecOps. If you have a mainframe estate, or a Java 8 application that everyone is afraid to touch, go and have a look.
How I use it: Bob writes my Rhapsody MCP tools
Here is where it gets personal. Regular readers know I have opinions about MCP, mostly good ones. The Model Context Protocol is how an AI assistant reaches a Rhapsody model: it reads states, blocks and requirements, and it writes them back. My Rhapsody MCP tools are exactly that bridge.
And these days Bob writes the code for them.
There is a nice recursion in that. An AI development partner writes the tools that let AI assistants work on models, so that humans can review a model instead of 2,400 lines of generated C. That was the whole argument of my WoTS talk last month, and now my own toolchain runs on it.
The way of working is the one I keep preaching:
- Plan first. I describe the tool I need: which Rhapsody elements it touches, what it may and may not change. Bob comes back with a plan, and I read it.
- Then let it write. Only when the plan is right does Bob write the code. I approve the changes step by step.
- Verify against something real. The tool has to work on an actual Rhapsody model, not on Bob’s idea of one. The model is the oracle.
It is also why my IBM Champion work has become a lot more fun. Being a Champion means talks, demos and this blog, and the demos only work if the tools behind them work on the day. Keeping a growing set of MCP tools up to date with new Rhapsody releases used to eat my evenings. Now I spend those evenings on the interesting part: deciding what the tools should do. Bob does the typing.
Retired, not gone, as I wrote in April. But retired with a good colleague turns out to be a lot more fun.
The honest bit
Bob is not magic. Like every model under the hood, it is probabilistic, and it can be confidently wrong. The approval steps are not bureaucracy, they are the point. Read what it proposes, and keep your models and your tests as the thing you verify against. Do that, and Bob is the most productive pair-programming partner I have had in years.
The real reason to come: the people
Sessions you can watch afterwards. What you cannot watch afterwards are the evenings: old friends, new friends, Champions from all over the world, and a beer that IBM has quite rightly put in a branded glass.
And then, every now and then, you find yourself standing next to Tim O’Reilly. Yes, that O’Reilly: the publisher of whom every self-respecting nerd owns at least ten books. The ones with the animals on the cover.
Come and find me
If you are in Atlanta this week, come and say hello. I am the Dutchman in the blue Champion jacket with opinions about modelling and MCP, and I will happily show you what Bob and Rhapsody can do together. If you are not here, the keynotes are on the TechXchange site, and I will write a proper round-up when I am back home and my body clock has worked out which continent it is on.
More soon, from Atlanta.
— Walter