As agentic development continues to evolve, most tutorials focus on features. You'll find walkthroughs showing how to generate code, build a new application, or automate a simple workflow. Those examples are useful, but they rarely reflect what happens in real projects.
Real software engineering involves large codebases, legacy systems, evolving requirements, conflicting constraints, multiple contributors, and projects that last months or years rather than hours.
The Getting the Most Out of Bob guide is valuable because it doesn't focus on a specific feature. Instead, it explains the habits, structures, and mental models that emerged from building IBM Bob and working with practitioners across industries. The result is less about how to use an AI tool and more about how to work effectively with agentic software engineering over long periods of time.
The Biggest Failure Mode: Lack of Structure
One of the most important ideas presented in the guide is that the biggest failure mode in agentic software engineering is not model performance. It's the absence of structure.
Traditional software development naturally encouraged structure because writing code was slow. Developers spent time understanding requirements, planning changes, implementing solutions, reviewing outputs, and testing assumptions. The cost of implementation forced people to think before acting.
AI changes that dynamic completely.
Code has become extremely cheap to generate. An implementation that once required days of effort can now appear in minutes. While that sounds like a huge advantage, it removes some of the natural friction that previously encouraged discipline.
Without structure, developers often end up doing everything in a single conversation. Planning, implementation, exploration, debugging, architecture discussions, and verification become mixed together. The conversation feels productive, but eventually confusion accumulates and quality suffers.
The guide proposes a simple framework to restore structure:
Explore → Plan → Implement → Verify
Each phase has a distinct purpose.
- Explore produces understanding.
- Plan produces decisions.
- Implement produces code.
- Verify produces evidence.
What makes this framework so effective is that it mirrors how experienced engineers already think about software development. AI doesn't eliminate the need for those activities. If anything, it makes them more important.
Why the Context Window Is Your Most Valuable Resource
The second major concept in the guide is surprisingly practical. The real scarce resource isn't model intelligence.
It's context.
Many people use AI tools as if conversations have memory. They don't. Every interaction takes previous messages, files, tool outputs, modes, skills, and supporting context and sends them together as the next prompt. The larger the conversation becomes, the more information competes for attention.
IBM Bob V2 provides a large context window, but even large context windows eventually fill.
- Repository rules
- Mode descriptions
- MCP tool definitions
- File reads
- Skill activations
- Tool outputs
- Subagent findings
All of these consume context before the user even writes a prompt. Once a conversation becomes large enough, Bob begins compacting information into summaries. This keeps work moving, but it is inherently lossy. A summary can never preserve every detail. The practical lesson is that developers should treat context as a valuable asset rather than an unlimited resource.
Working With the Context Window Instead of Against It
The guide offers several useful habits for maintaining high-quality context.
The first is keeping conversations focused. One task should generally have one conversation. Separate architecture work from implementation work. Separate debugging sessions from feature design.
The second recommendation is to roll back rather than argue. If a conversation drifts off course, returning to a previous checkpoint often produces better results than spending many messages correcting mistakes.
The third recommendation is especially important. Anything worth keeping should live in a file rather than a chat.
Plans, findings, architectural decisions, investigation results, and implementation notes become reusable assets when stored externally. Chat histories rarely serve that purpose effectively.
The final recommendation is leveraging subagents whenever possible. Subagents allow Bob to perform investigations and gather information without bringing every intermediate detail back into the main context window.
The result is cleaner conversations and better overall performance.
Understanding Guides and Sensors
One of the more interesting concepts in the article is the distinction between guides and sensors. Over time, software quality depends less on Bob itself and more on the mechanisms used to shape and evaluate Bob's work.
Guides influence behavior before work happens. Examples include:
- Rules
- Skills
- Modes
Sensors provide feedback after work happens.Examples include:
- Tests
- Linters
- Type checkers
- Security scanners
- AI review agents
The guide compares these to feedforward and feedback systems. Guides steer the work. Sensors evaluate the work.Strong projects typically require both these factors.
A project filled with guides but no sensors often generates confidently wrong solutions. A project filled with sensors but no guides spends too much time correcting avoidable mistakes.
Why Planning Has Become More Important
A particularly insightful section focuses on planning. Many people assume AI reduces the need for planning because implementations can be generated rapidly. Implementation has become cheaper than planning. That means the quality of the plan now has disproportionate influence on the outcome.
A strong plan should:
- Be concise
- Define success clearly
- Identify uncertainties
- Document assumptions
- Exist outside the chat
The guide argues strongly that plans should live in files rather than conversations. Plans become organizational assets. Chats are temporary. Another interesting discussion involves spec-driven development. The guide presents specifications as a spectrum rather than an absolute practice.
At one end, specifications simply guide implementation. At the other, specifications become the source from which implementations are generated.
Different teams and industries will land at different points on that spectrum, but the central idea remains the same: Good implementation starts with a good specification.
Implementation Is Now the Cheap Part
One statement from the article stood out:
The code is the cheap part.
This represents a major shift in software development economics. For decades, implementation consumed most of the effort. Today, AI can generate working code extremely quickly. That means the value increasingly shifts toward understanding requirements, making architectural decisions, identifying constraints, and validating results.
If implementation goes poorly, the root cause is frequently an inadequate plan rather than a coding mistake. That's why the guide recommends returning to planning whenever implementation repeatedly requires intervention.
Verification Is Where Confidence Comes From
The final stage in the cycle is verification. The guide splits verification into two categories:
Automated Verification
This includes:
- Unit tests
- Integration tests
- End-to-end tests
- Type checking
- Security scanning
- Static analysis
- Linters
These provide deterministic feedback and allow Bob to catch many mistakes automatically.
Manual Verification
Manual verification answers a different question:
Does the solution actually achieve the intended goal?
Sometimes the implementation matches the plan, but the plan itself is flawed. Verification therefore becomes a process for evaluating both the code and the assumptions behind it. The guide also highlights the value of extending verification into CI/CD pipelines through automated review agents and validation workflows.
The Future of Team Development
One of the strongest closing points in the article is that AI changes how work moves through teams. Implementations arrive faster. Pull requests become larger and context becomes harder to preserve.As a result, the "why" behind a change becomes increasingly important.
Plans, assumptions, design decisions, verification results, and implementation rationale become critical assets during code review. The future of software development may not be defined by how quickly AI generates code. It may be defined by how effectively teams preserve understanding while AI accelerates execution.
Final Thoughts
The biggest lesson from Getting the Most Out of Bob is that AI does not eliminate software engineering discipline. It increases the value of it. As implementation becomes cheaper, understanding becomes more valuable. As code generation becomes faster, architecture becomes more important and as conversations become larger, context becomes more precious. This means creating software easier, structure becomes the factor that separates productive teams from frustrated ones. The developers who succeed with agentic development will likely not be the ones who write the most prompts. They will be the ones who build the best systems around those prompts.
Reference
Original article: Getting the Most Out of Bob
IBM Bob Blog
Read the full guide here:
https://bob.ibm.com/blog/getting-the-most-out-of-bob/
Credit: This article is a paraphrased summary and interpretation of concepts shared by the IBM Bob team.
Top comments (0)