Your AI dev stack should get smaller
By Andrew D. Anderson
The AI developer stack is expanding faster than most teams can absorb it.
There is a tool for the coding agent, another for its worktree, another for preserving its conversations, another for review, another for remote execution, another for automations, and another for deciding which model should do the work.
Many of these tools are good. Some are excellent. The problem is not that the individual pieces should not exist.
The problem is that using all of them can turn software development into a job of moving context between surfaces.
That is probably not the final form.
Context is becoming the work
An issue is not separate from the agent conversation that implements it.
That conversation is not separate from the terminal output, the branch, the diff, the test results, or the review that follows. They are different views of the same work.
But most tools do not see the whole chain. One knows the issue. Another knows the conversation. Another knows the filesystem. Another knows the commit. The developer is left to carry the relationships between them.
That cost is easy to miss because it arrives in small pieces: copying a link, finding the right terminal, restating a decision, opening the correct worktree, explaining what the first agent tried before handing the task to a second one.
Agents make this more important, not less.
They increase the amount of work a developer can have in flight. More work in parallel means more state to recover, more decisions to preserve, and more opportunities for one part of the system to lose track of every other part.
When the context is fragmented, the human becomes the integration layer.
Compression is more than aggregation
Putting ten tools behind one sidebar does not make them one system.
The value comes from the relationships between them.
An issue should become an agent task without being rewritten. The conversation should stay attached to the work it produced. The terminal should already be in the right project. The diff should carry the history of how it came to exist. A second agent should be able to continue without asking the developer to reconstruct the first agent's attempt. A teammate should be able to understand the outcome without archaeology.
Each connection removes a context switch. More importantly, each connection makes the rest of the workspace more useful.
Session history is more valuable when it knows about commits. Review is more useful when it can reach the decisions behind the diff. Automations become more powerful when they can create work inside the same environment where humans and agents will inspect the result.
That is tool-stack compression: not deleting capabilities, but collapsing the boundaries between them.
The workspace should outlast the tools
The underlying stack will keep changing.
The best model will change. Agent harnesses will improve. Open-source projects will invent better workflows. New companies will build useful products at layers that do not have names yet.
A durable workspace should benefit from all of that movement.
It should not need one model company to win forever. It should not require every useful idea to have been invented in-house. Its job is to give the best available agents and tools a coherent place to work together.
That neutrality matters because consolidation should not mean capture.
A smaller stack should give developers more choice, not less. When a better model or agent appears, adopting it should improve the workspace instead of forcing the team to rebuild its workflow inside another ecosystem.
More capability, fewer boundaries
Agentic development will continue producing specialized tools. That experimentation is healthy. The market is still learning what the new development loop needs.
But developers will not want to operate every layer as a separate destination forever.
The winning ideas will be absorbed into workflows where the issue, conversation, terminal, code, review, and outcome understand their relationship to one another. The capabilities will multiply while the number of boundaries the developer feels should shrink.
That is the thesis behind hob.
We are not trying to win every layer of the AI development stack. We are building the place where those layers come together.
The AI development stack will keep expanding. The developer's experience of it should get smaller.