As a Customer Success Manager, I spend most of my time helping customers achieve value from technology rather than building software myself. However, software development is not new to me. I used to work as a developer and spent my days designing, building, and troubleshooting applications.
Although I no longer write code professionally, I still enjoy building things and experimenting with new technologies. Recently, I decided to use IBM Bob to build a small application and see how far I could get with modern AI-assisted development.
What I found most interesting wasn't just the coding itself. It was how Bob helped structure the entire journey, from planning and environment setup to documentation and troubleshooting.
Start Small, Start with a Plan
The biggest lesson from my experience came before a single line of code was written. When I first described what I wanted to build, Bob did exactly what I hoped it would do: it asked a series of questions to better understand the requirements, desired functionality, and overall scope of the application.
At first, I was tempted to ask for everything. After all, if AI can help build an application, why not include every feature, every future requirement, and every nice-to-have from the start? Bob took all of that information and produced a plan. Looking at that plan became a pivotal moment in the project.
The proposed solution made sense, but I quickly realized it had become much larger than what I actually needed for an initial proof of concept. The architecture was reasonable, but if I had immediately started implementing it, I would likely have spent a lot of time and effort building capabilities that weren't yet necessary.
Instead of jumping straight into coding, I stepped back and focused on the plan. I reviewed it, simplified it, and reduced the scope to something I could fully run locally and understand end-to-end. The objective became clear: validate the idea first, then worry about scaling, production requirements, and advanced features later.
In hindsight, this planning phase saved a significant amount of time, and quite a few tokens as well.
By agreeing on a realistic scope before implementation started, Bob and I were able to focus on building exactly what was needed for the proof of concept, rather than continuously changing direction during development.
What I particularly appreciated was that Bob didn't lose sight of the future. While helping design a smaller local solution, it also explained what would need to change if the application later evolved into a production-ready system. That allowed me to keep the implementation simple while still understanding the path forward.
For me, this was one of the biggest takeaways from the entire experience: The best use of AI isn't necessarily to start coding as quickly as possible. It's to spend time creating the right plan first.
Environment setup was surprisingly helpful
Once the plan was clear, I asked Bob to set up the development environment. This was more useful than I initially expected.
Rather than making assumptions, Bob first checked what was already available in my environment. It identified what was present, what was missing, and what needed to be configured before we could move forward.
Getting a new project running often involves a surprising amount of setup work. Having Bob guide this process removed much of the friction and allowed me to focus on the actual application.
The feature that impressed me most was something developers often know they should do more often: documentation.
Throughout the project, Bob continuously maintained a status document that tracked:
At first, this seemed like a small detail. Over time, I realized how valuable it actually was.
Most of us have experienced projects where we're focused on getting things to work. Once they work, we move on. Documentation is left for later and often never happens. A few weeks later, it becomes difficult to remember exactly what was done, which issues were encountered, or why specific decisions were made. Bob addresses this problem by documenting as it goes.
The documentation evolves alongside the project, creating a record of progress, decisions, and next steps. Instead of trying to reconstruct the journey afterward, the journey is captured while it happens. For me, this was probably the standout feature of the entire experience.
Clear explanations every step of the way
Another aspect I appreciated was the transparency. Bob consistently explained what it was doing, why it was doing it, and what it expected to happen next. When implementing functionality, it described the reasoning behind its choices. When something failed, it explained the likely cause and the steps required to resolve it. As a result, I never felt like I was blindly accepting generated output. I felt informed and involved throughout the process. There was always a sense that I remained in control while receiving guidance from an experienced assistant. That educational aspect made the experience significantly more valuable.
I found IBM Bob to be most valuable not because it writes code, but because it helps structure the entire development process.
The things that stood out most were:
If I had to summarize my experience in a single sentence, it would be this:
Bob helped me stay organized and informed while building, not just productive.
For someone like me, technical, but no longer a full-time developer, that made a real difference.
After more than 15 years away from software development, I was able to go from idea to working proof of concept while maintaining a clear understanding of what was happening along the way. And in the end, that's what impressed me the most: not that Bob helped build the solution, but that it helped me understand and document the journey from concept to implementation.
Interested?
Interested in getting hands-on with IBM Bob? Go to IBM Bob where you can download a fully working trial with (at the time of writing) 40 Bobcoins for 30 days, enough to build your own application.
#community-stories2