Time between disengagements: the rise of the software conductor

Software engineering is undergoing a sea change. It's real, we feel it every day and it's happening right now. Once sacred IDE loyalties are given up as even die-hard vim users fluidly switch among VS Code forks (Cursor, Windsurf) and VS Code Copilot, fueled by a stream of free-flowing Claude 3.7 tokens. Companies like Salesforce, Google, and Goldman Sachs are downsizing their engineering teams in the wake of change. Nearly a quarter of recent YC startups, AI-generate 95% of their code. The pace and output expected from software engineers and their teams has never been higher. While AI-proficient, high-curiosity engineers thrive and vibe in their flow state, others are pushed into an identity crisis because change is hard.

How do we see clearly in a space that's changing at hyper-speed? Our guiding mental model on what happens in the next eighteen months is the concept of 'time between disengagements' inspired by autonomous vehicles.

Measuring autonomy - from seconds to days

In self-driving cars, 'time between disengagements' measures how long a car drives autonomously before a human needs to intervene. Similarly, in software engineering, it measures how long software engineering agents work independently before needing human input:

• Seconds (low autonomy): The system requires constant human input. For cars this is lane assist, hands-on steering wheel. For AI assistance it's code completion tools like GitHub Copilot, Cursor, or Windsurf, where you tab-tab-tab forward to your next line-by-line change.
• Minutes (moderate autonomy): Next-gen agents (i.e., Cursor's YOLO mode, Windsurf's Cascade, Cline, Claude Code) autonomously execute multi-step tasks, but occasionally tap your shoulder for feedback and guidance.
• Hours (high autonomy): Systems like Devin aim at sustained autonomy for hours, initially targeting senior-level tasks but currently settling at intern-level proficiency.
• Days (AGI): Achieving autonomy lasting days would signify reaching human-level software engineering capabilities, nearing AGI. At this point we would reasonably expect an AI agent to operate at "staff engineer level" - or whatever the superhuman equivalent of that is.

Even today's 'seconds-to-minutes' autonomy has completely altered productivity benchmarks. But to turn hours of autonomy into productive outcomes, we must tackle three fundamental barriers.

1. Freedom to operate securely

To increase autonomy, software engineering agents must execute code and modify files independently. If humans must approve every command or file change, they remain a productivity bottleneck. How do you feel about an AI agent YOLO-ing arbitrary commands (think rm -rf /) near sensitive data and credentials? Increasing autonomy demands robust zero-trust environments and secure execution contexts.

With increasing autonomy, agent identities become critical. While humans control actions at seconds-level autonomy, agents at minute or hour levels make decisions independently. This raises key questions about permissions - should agents use developer credentials for code pushes or database access? Autonomous agents need unique identities and authentication to safely interact with external systems like repos and databases. As autonomy increases, secure machine-to-machine authentication becomes essential.

Lastly, today most compliance frameworks mandate human review. Regardless of autonomy, agents serve human purposes under human oversight. With code production volumes increasing exponentially, controls, interfaces and interaction patterns used for supervision will evolve significantly.

2. Context, context, context

Context matters greatly. Tools like Cursor popularized specific context like explicit file references (@file) and narrowly scoped instructions. But when was the last time you told your coworker to edit index.ts and component.tsx? Instead, you'd reference the Linear/Jira ticket, components, customer calls, user stories or design documents directly.

• Seconds: AI handles simple file or function-level changes easily, can navigate codebases but might need specific file/function-level pointers.
• Minutes: Full issue-level context, clearly defined implementation plans and standardized development environments become essential.
• Hours/days: True autonomy demands broader context from design docs, architectural decisions, product requirements—information currently scattered across docs and team knowledge.

With increasing autonomy, context turns from a technological limitation into a means to specify intent and desired outcomes. Not because the agent can't access this context independently, but because it's a means of communication between the engineer and their tool.

Some of this context is ephemeral and inaccessible. Think of the conversation with colleagues at the water-cooler, over lunch or coffee. Much like we needed to figure out efficient context-sharing within hybrid and remote teams, we will need to evolve our means to share high-level context with coding agents.

3. Interaction modes for parallelism and deep work

For decades we have celebrated deep work, focusing intensely on one task at a time. Single-task immersion defined how we built software, structured teams, and created tools. Not anymore. As autonomous agents handle larger tasks, the engineer's role shifts radically—from hands-on craftspeople deliberately crafting every line of code, to conductors elegantly orchestrating a symphony of agents operating in parallel.

Human attention is now the critical bottleneck. Traditional IDEs built for deep, singular immersion feel increasingly outdated. Engineers will require a "command center" that nudges them only when necessary, eliminating context-switching friction. As the engineering role evolves, we need new interfaces to support the different levels of engagement developers have with software. Staff level engineers excel at their ability to quickly switch between higher and lower abstraction levels, moving from a business or architecture discussion to 'deep coding mode'. Similarly, engineers are expected to fluidly and swiftly transition between interaction modes based on the complexity of the task:

• A conversational mode lets you direct autonomous SWE agents with simple commands (e.g. "Fix issue #6100") without leaving your current context or interface from Slack, Teams, or a dedicated portal UI.
• A transient editing mode in a lightweight, yet powerful editing environment that opens instantly in your browser without installation or configuration. For smaller, directional changes where you don't need a full desktop editor, but want access to code, not just a chat interface.
• A deep coding mode where traditional IDEs and editors remain essential for complex, nuanced tasks requiring in-depth control. This is what most developers are doing already today.

Picture this: an agent tackles a task while you focus elsewhere. When done, it notifies you to review changes in your browser tab. You only switch to 'deep coding mode' and open an IDE/editor with one click when truly necessary. It's all about reducing cognitive load by eliminating context switching costs through great, powerful tools.

Transitioning from craftspeople to software conductors

Every day you are asked to do more, and higher autonomy levels will give you the means to get there. To turn autonomous agents into productivity, we must stop doing all work sequentially. True leaps in engineering productivity will come from effective parallelism and frictionless multi-track development. It's the era of the software conductor.

Software conductors will seamlessly move between interaction modes to match the task complexity in front of them. They will discover unknown superpowers and hit peak productivity and joy. To achieve fast, inexpensive context switches, software development must decouple from rigid, local-file-system-bound development environments and become AI-first. Otherwise autonomy will stay limited to seconds or minutes. Automated, context-rich, secure, and ephemeral development environments in the cloud will become the new scalable baseline for agent fleets. And finally, we need novel interfaces and interaction modalities purpose-built for parallel development that we fall in love with.

To thrive in this fast-moving time, engineers must rapidly grasp both business context and technical requirements. Success relies heavily on quickly assessing priorities, breaking complex challenges down into manageable parts, and skillfully orchestrating their fleet of faithful AI collaborators. It's about clarity of the goal, while swiftly navigating through implementation details—precisely how great engineers have always operated.

Extending the time between disengagements from seconds to minutes to hours is our own product development benchmark at Gitpod. Increasing this interval translates directly into sweeping productivity gains and, importantly, more joy in building software. There's no better time than now to be an engineer; we are given magic.

At Gitpod, we're building the complete engineering productivity platform for humans and their agent fleets. We're working in fast-tracked weekly cycles with Fortune 500 companies to shape the modalities and interfaces of this new world.