The software conductor's handbook: maximize autonomy for AI software development agents

Lou Bichard / Product Manager at Gitpod / May 8, 2025

TL;DR; Software development is shifting from manual coding to orchestrating AI agents, with success being measured by ‘time between disengagements’ of agents. In this guide you’ll learn:

• Why developers limit AI’s potential by treating it as a code snippet generator or Google replacement, leading to poor outcomes, wasted time, and agent babysitting
• How to shift your mindset from ‘thinking by writing code’ to becoming a ‘software conductor’ who coordinates AI agents working effectively
• How to drive up agent autonomy and time between disengagements by writing detailed ‘agent PRDs’ including goals, code snippets and step-by-step implementation
• How to use automated development environments to increase agent autonomy and security for agents to work independently without interference

The era of AI agents is here, with fleets on the horizon

Software development is undergoing a significant shift. Nearly a quarter of recent YC startups generate 95% of their code using AI. Instead of writing every line by hand, engineers can now work with AI agents capable of understanding context, following long-form instructions, and executing complex tasks. This shift has created both opportunities for AI-proficient engineers and identity crises for others struggling with the pace of change.

Unlocking this potential requires a new mental model—one where developers stop ‘thinking by writing code’ and start behaving like conductors. While individual agents are becoming increasingly capable, we’re quickly moving toward a future where engineers will orchestrate multiple agents working in parallel—a development that will require both new techniques and tools. This guide is your playbook to achieve more with greater agent autonomy.

Source: Revenge of the junior developer

Time between disengagements

Our CTO Christian Weichel recently wrote a blog about how AI autonomy is changing software engineering. In his blog post, Chris makes the point that significant productivity gains for developers will come from effective parallelism and frictionless multi-track development.

This is an analogy borrowed from autonomous vehicles. If you’re interested in the original post, you can read it here: time between disengagements: the rise of the software conductor.

For software development, the ‘time between disengagements’ currently looks like:

• Seconds: Tools like GitHub Copilot that require constant human input
• Minutes: Tools like Cursor executing tasks with occasional feedback
• Hours: Systems aiming for autonomy currently at intern-level proficiency
• Days: Human-level capabilities representing staff engineer-level proficiency

Rewire your brain for context-rich agent interactions

Software engineers traditionally ‘think’ by coding—they explore ideas by diving directly into the code implementation. This has served developers well for decades and has become a very strong muscle memory response to problem-solving for many. Yet, when these same developers encounter AI they apply this same code-first mindset, giving only simple and basic prompts to their AI and expecting outsized results. This expectation mismatch leads to frustration and often blaming the technology itself.

AI agents possess capabilities fundamentally different from human developers. While AI lacks a programmer’s intuition and creativity, it excels at processing vast amounts of code and documentation at pace. To put these strengths to work, developers must tame their natural instincts and invert their workflows from a code-first to a plan-first approach. The most productive workflows emerge when developers resist jumping into coding and invest time articulating context-rich plans that agents can execute with minimal intervention.

Moving beyond basic uses of AI

Many software developers today use AI in limiting ways—copying and pasting snippets in and out of code editors, giving minimal prompts, and treating AI as a Google replacement without enough context. As a result, these developers experience challenges both with agents lacking autonomy, such as:

• Wasting hours with agents working on incorrect parts of the codebase
• Completing unnecessary work like complex internationalization logic

And also with their development environments:

• Code snippets that don’t build or run (e.g., don’t lint, pass unit tests, etc.)
• Resulting code that doesn’t work in the deployment environment
• Installed conflicting packages and broken machine dependencies
• Agents with excessive permissions exposing sensitive data
• Agents struggling to conduct their work due to machine resource constraints

For agents to be successful, we cannot treat them like simple tools as providing minimal context leads to poor output, requiring constant correction and resulting in more time ‘babysitting’ agents. Successful software conductors view agents almost as junior developers who need clear specifications to work effectively.

Achieving autonomy through an ‘agent PRD’

A Product Requirements Document (PRD) is a technique used by high-performing software engineering teams to specify the requirements of a specific increment of software. Creating planning documents like PRDs is the bedrock to driving up the autonomy and the ‘time between disengagements’ of your software agents. You can draft these PRD documents for agents with tools like ChatGPT or Claude, but it can be especially effective when drafting inside your editor using tools like Cursor or Windsurf that have access to your codebase, filesystem, and additional context.

Agent PRD example structure

The following are the basic elements required in an Agent PRD. As you explore the technique you will likely want to adjust the structure however these basic elements form the foundation.

• Goal
• Current implementation
• Proposed solution
• Implementation steps

Let’s go through each of these elements one-by-one with example prompts.

Goal

The goal section should describe the ‘business outcomes’ of the task or feature you’re implementing. A best practice is to imagine this being read by someone non-technical and should answer the question of ‘what is the value of doing this work to a user or customer.’

Example prompt:

I am writing a PRD document to make a plan for the implementation of a new feature.
Please create a file plan.md and add the following information to it. Do not write any code or start the task.
First, I need to craft a clear and concise goal statement for my PRD document.
This should explain why we're making this change and what problem it solves.
Ask me questions to clarify what the goal and objective is of the feature or change.

Some questions to consider:
- What specific problem or opportunity does this feature address?
- Who are the primary users or stakeholders that will benefit?
- How does this align with our broader product strategy?
- What measurable outcomes do we expect from this change?

When writing the goal, avoid technical jargon and focus on the business value.
The goal should be understandable by non-technical stakeholders.
If you need more context about our product or users to craft an effective goal, please ask me specific questions.
Again, do not write any code.

Current implementation

Here we want to ask the agent to step through the codebase and pull out any specific files, directories, or folders that it thinks it should update. Instruct the agent to grab precise snippets and detail why each snippet is relevant to the change.

Example prompt:

Update the PRD in plan.md.
Add a section that documents the current implementations in the codebase that we'd likely need to change to achieve the goal of the PRD.
You do not need to know the planned solution yet as we are only information gathering from the codebase to then later propose a solution.
Iterate through the file system and extract any necessary files, directories and code snippets.
Do not edit any code, only update the plan file.

For each code snippet include a reason about why that code might change as a result of the feature and include the file path and directory.
Please include relevant code examples or architectural diagrams if applicable.
The description should be technical enough for developers to understand what's changing.
But also provide context for product managers and designers to understand why those files or parts of the system might need to be updated.

Some questions to help frame this section:
- Which components, services, or code patterns are involved?
- Will the database model be updated?
- Will we require updates to the design system?
- What frontend components might be updated?
- What APIs might change as a result?

If you need to ask me clarifying questions please do so that I can point you to parts of the codebase or for brainstorming additional considerations.

Proposed solution

Once you have the goal established and understanding of the current implementation then you can address the proposed solution. It’s vital to include the current implementation information in the PRD because that will give the agent a better understanding of the various files to be changed and will enable a more comprehensive solution.

Example prompt:

I need to now update the PRD in plan.md with a proposed solution.
The document contains the goal of the feature/change and the current implementation.
Taking into account the goal and the current constraints of the system, outline a solution to address the goal.
Include the relevant files that would need to be changed, how those files would be changed and why.

Questions to consider:
- What approach are we taking to solve the identified problem?
- How does this solution improve upon the current implementation?
- What are the key components or changes in this solution?
- What alternative approaches did we consider, and why did we choose this one?
- Are there any trade-offs or limitations to be aware of?

If you need more information about our technical constraints, preferred patterns, or business requirements to refine this solution please ask specific questions or clarifications.

Implementation steps

The final part of the PRD is to give implementation steps to the agent. Without implementation steps, the agent will choose where to start writing code, and commonly it will choose points that lead to iterating in loops and getting stuck. By giving the agent specific ordering steps, you’ll drastically increase success.

Example prompt:

I need to now update the PRD in plan.md with a step-by-step implementation plan.
Help me outline detailed implementation step.
This should provide a clear roadmap for developers to execute the solution.
Do not update any code, only plan.

Questions to consider:
- What specific files, components need to be modified?
- What new code or functionality needs to be created?
- What is the recommended sequence of changes?
- Are there any dependencies or prerequisites?
- What testing approach should be used to validate the changes?
- Are there any migration considerations?

Please break this down into discrete, actionable steps.
The implementation steps should be comprehensive enough that a developer could use them as a guide without needing to ask many additional questions.
If you need more details about our tech stack, coding standards, or existing architecture to provide appropriate implementation guidance, please ask.

Bonus: task management

When it comes to executing the plan, giving your agents a way to manage their own tasks also increases autonomy. A task management system can be as simple as asking the agent to convert the implementation steps into a checklist and go through each step one by one, marking them off as completed. You can re-use your agent PRD document for this or experiment with other techniques depending on the tool you’re using.

Example Agent PRD

When pulling it all together, below is a simple example of how this PRD might look:

## Goal
GitpodFlix needs to optimize content delivery costs while maintaining streaming quality during peak viewing hours. Our current static CDN allocation wastes resources during low-traffic periods [...]

## Current implementation
Our content delivery currently uses a static allocation model where CDN resources are provisioned based on historical peak usage:
// Current CDN resource allocation logic in cdn-manager.js
function allocateCdnResources(region) {
  const peakBandwidth = getHistoricalPeakBandwidth(region);
  return {
    bandwidth: peakBandwidth * 1.2 // 20% buffer
  };
}

## Solution
We will implement a dynamic CDN resource allocation system that adjusts capacity based on real-time and predicted viewing patterns.

## Implementation Steps
- [ ] Extend Telemetry API - Add regional traffic aggregation endpoints to telemetry-service. Implement 5-minute data caching layer to prevent redundant queries
- [ ] Create Dynamic Allocation Service - Implement rate-limited API client for CDN adjustments. Set up authentication with rotational keys

The need for isolated development environments

When following the agent PRD techniques above, you’ll watch your agents gain greater autonomy in completing tasks with less human intervention.

Today when running AI agents on your local machine you likely experience several pain points:

• Agents installing unwanted packages that conflict with other projects
• Gigabytes of dependencies being downloaded onto your computer
• Security concerns when agents run code with your permissions
• Resource constraints as agents compete for your local machine’s capacity
• Watching what the agent is doing to prevent breaking your computer

Isolated development environments provide an immediate solution to these challenges by:

• Sandboxing environments where agents can operate without affecting your machine
• Preventing security issues by limiting permissions in a controlled environment
• Eliminating dependency conflicts between different projects
• Providing resource isolation so agents don’t slow down your computer
• Not putting an artificial limit on how many agents can run in parallel

Preparing your foundation for the future of agent fleets

As agent capabilities continue to advance, the ability to run multiple agents in parallel will become increasingly important. As you shift into the role of a software conductor, you’ll soon face practical challenges that your tooling needs to addressBy using automating and standardizing your development environments you’ll be prepared to:

• Run agents on different parts of your codebase simultaneously
• Scale resources automatically based on agent needs
• Maintain security boundaries as agent capabilities grow
• Orchestrate multiple agents without manual environment setup

Drive your developer productivity up with development environments designed for autonomous agents

Get started developing with autonomous agents today:

1. Sign up for Gitpod and connect your code repository
2. Launch a new isolated environment with a single click
3. Connect your favorite AI code editor or assistant such as Cursor or Cline
4. Use the agent PRD technique to craft instructions for your agents
5. Let your agent work in its own isolated and secure environment
6. Spin up more secure environments to run agents in parallel

Gitpod is soon launching software engineering agents designed to collaborate seamlessly with both humans and other agents. These agents support multiple interaction modes, making it easy to orchestrate between agent sessions, run quick code checks, or switch to deep coding mode in the IDE.