Long live the IDE
A thesis of Software Engineering as scoping, orchestration and taste
Authored by Nico Rakover, Lead Research Engineer
Over the last two decades, the Integrated Development Environment (IDE) emerged as the central hub for software engineering productivity. It became the workbench where engineers spent most of their building hours – writing code, debugging, refactoring, and deploying. While many engineers – especially those in leadership roles – also make use of task trackers and collaborative prose-writing tools, these surfaces have remained peripheral and largely tailored for non-engineering activities and non-engineer users.
Unsurprisingly, the dramatic investment in AI-assisted software engineering tools over the past ~2 years has been overwhelmingly IDE-centric. The driving intuitions: meet developers where they already are, minimize workflow friction, and avoid disrupting established engineering practices. Companies like GitHub and JetBrains have doubled down on this thesis with Copilot and AI Assistant, respectively, while upstarts like Cursor and Windsurf (Codeium) were born as AI-native variants of the IDE. These tools optimize for the single-threaded speed of the individual engineer – suggesting completions, generating functions, and explaining error messages, all without the engineer ever leaving their editor.
At Solver, we believe there's a more powerful paradigm: autonomy and elastic capacity as the ultimate force-multiplier. The crux of this thesis is that human attention will always be the bottleneck if it needs to scale linearly with engineering output. You can try to make the human faster by speeding up each unit of work, but their attention will always be a fixed resource and you can only scale so much if they need to supervise every minute unit of output.
We're building for a world where effective engineering fundamentally shifts towards scoping deliverables, orchestrating work, and exercising taste about what to build – with implementation details increasingly delegated to autonomous systems. When this shift occurs, engineering output can scale super-linearly relative to human attention. We’ll enter a paradigm where engineering output scales with compute, where the bottleneck is no longer how fast an individual can type or reason through implementation challenges, but rather how effectively they can direct and supervise autonomous systems working on their behalf.
Here's the challenge: the IDE is the wrong tool for this job. Modern IDEs are optimized for a human engineer's perception and reasoning capabilities – real-estate is dominated by source code or other modalities presenting a single-threaded view of the work. They're built around the assumption that a human will be doing the implementation work, not delegating it.
On feedback and conviction
During our private beta for Solver’s first cloud-based agent system, early user feedback highlighted a common friction point when using Solver’s out-of-IDE surface: high context-switching costs when moving between our webapp and the engineer’s IDE. The gut reaction, which we contemplated, would be to build tighter IDE integration – maybe a VS Code extension or JetBrains plugin.
Instead, we asked “why” a few times. Why were users switching back to their IDE so often? The specifics varied, but it boiled down to two fundamental issues, which all early agentic systems share:
- Solver's development environment was not a high-fidelity replica of the user's own environment. As a result, users often needed to eject in order to take mechanical actions such as running linters, formatters or tests.
- For the small tasks users naturally first experiment with, the “cost of specification” – clearly articulating what needs to be built – often dominated the actual time savings from delegation. Writing code is often easier than describing it precisely, in isolation, so users may not internalize the potential of this paradigm if only trying small, isolated, well-understood tasks.
Armed with this insight, we chose to double-down and tackle these root issues within the paradigm we are convinced will win, making two significant product investments:
1. Execution Environment
A cloud-native environment optimized for the agent’s operation, but facilitating the user’s customization, allowing Solver to work with greater autonomy and reliability within an environment matching the user’s. Solver can easily be configured to use your language stack, your testing frameworks, your toolchain.
Configuring Solver’s environment is as simple as providing a Docker image containing the relevant toolchain, or starting from a barebones image and asking Solver to install the required dependencies. We’ve tuned Solver to adeptly leverage this environment to accomplish tasks, whether by writing and running tests to check its work, or using team-standard formatters and static analysis tools as it iterates. Combined with our Memories feature, this offers robust and expressive knobs to onboard Solver onto your team’s best practices.
2. Projects
A pioneering UX allowing users to collaborate with Solver on dramatically larger scope and complexity, by working in two phases: (1) interactively authoring a robust, structured technical plan for a project, and (2) one-click dispatch of execution the resulting graph of tasks, asynchronously and autonomously.
Projects is the most direct manifestation of our vision of engineering as scoping, orchestration and taste. The Planning phase provides a UX custom-made for AI-augmented iteration on requirements and design, clarifying their taste and preferences in a high-leverage way, while the Execution phase gives the user a bird’s eye-view of implementation progress, without pulling them unnecessarily into the weeds. Check out our previous post on the Projects feature and why we think it’s so essential.
A new hub for engineering productivity
Engineers need a new surface that’s built from the ground up for the shape of work they will spend most of their time on – scoping, orchestration, and low-touch supervision rather than implementation. We’ve built Solver with laser-focus on this emerging need, carefully incorporating the best of other modalities, such as task trackers and technical writing tools, but tailor-made for engineering.
With Solver, you get to focus on the “what” and “why”, rather than “how”. In this paradigm, taste and grounded understanding of business goals are the most valuable assets. Experience plays into considering high-level approaches, how to prioritize, and the right questions to ask.
To be clear, we're not predicting the death of the IDE – rather, a complementary but diminished role. IDEs will continue to be essential tools when an engineer needs to take the reins. But increasingly, they'll become auxiliary to a new hub of engineering productivity. The best engineers of tomorrow will focus almost-exclusively on higher-multiplier activities, leveraging tools like Solver, to focus on what to build rather than how to build it.
Long live the IDE 🍻