Dev Tools: Splitting Shell And Edit For Efficiency

Hey guys! Let's dive into an interesting discussion about streamlining developer tools, specifically focusing on splitting shell and edit functionalities. This is a crucial step in making our development workflows more efficient and organized. We'll be drawing inspiration from existing tools and addressing the ongoing efforts within the block/goose project. So, buckle up and let's get started!

The Current State of Developer Tools

Currently, the developer MCP (Multi-Cloud Platform) is like a Swiss Army knife – it's packed with various tools, which, while versatile, can sometimes feel a bit clunky. Think of it as having all your kitchen utensils in one drawer – it works, but finding the right tool can be a hassle. As highlighted in the issue https://github.com/block/goose/issues/2830, there's a growing need to reorganize these tools for better usability and maintainability. Recently, in https://github.com/block/goose/pull/3976, some functionalities were moved to computercontroller, signaling a move towards a more modular architecture. This is a positive step, but there's more to be done. Splitting the developer MCP into distinct components like shell and edit is the next logical move. This approach not only aligns with best practices in software design but also mirrors how other successful tools, such as Gemini CLI and Claude Code, are structured.

The primary goal here is to create a clearer separation of concerns. By decoupling functionalities, we make it easier to understand, maintain, and extend our tools. Imagine trying to debug a complex issue when the code responsible for shell interactions is intertwined with the code for editing files. It's like trying to untangle a ball of yarn with multiple knots. By separating these concerns, we create a cleaner, more modular codebase, which translates to fewer headaches down the road. Moreover, this separation allows us to optimize each component independently. For instance, the shell component can be fine-tuned for performance and security, while the edit component can focus on providing a rich and intuitive editing experience. This specialization leads to better overall performance and user satisfaction. From a user perspective, having distinct tools for shell interactions and editing tasks can significantly improve workflow efficiency. Instead of navigating a monolithic tool, developers can quickly switch between specialized tools tailored to their specific needs. This streamlined experience reduces cognitive load and allows developers to focus on their core tasks.

This initiative is not just about rearranging code; it's about fostering a more developer-friendly environment. By embracing a modular design, we empower developers to work more efficiently, collaborate more effectively, and ultimately, build better software. So, splitting the developer MCP is not just a technical decision; it's a strategic move towards a more robust and developer-centric ecosystem.

Inspiration from Other Tools

To further solidify the case for this split, let's take a look at how other prominent tools handle these functionalities. The Gemini CLI, for instance, provides dedicated tools for both shell and edit operations. Similarly, Claude Code features separate