Why Software Engineers Are Becoming Managers of 20 AI Agents

Written by Ty Sutherland in AI and Society

group of person playing violin

Something shifted quietly in how the best software engineers describe their work. They stopped saying “I wrote this” and started saying “I directed this.” The code still ships. The product still works. But the process looks nothing like it did three years ago. One engineer managing a swarm of 20 coding agents, reviewing outputs, catching errors, setting direction — that’s not science fiction anymore. It’s Tuesday.

Reid Hoffman put a number on where we are in February 2026: roughly 5% of where AI ends up. Maybe 2%. If that estimate is even close to right, the engineers, marketers, analysts, and operators who are figuring out how to conduct this orchestra right now are building a skill that compounds for the next decade. Everyone else is falling behind and doesn’t fully realize it yet.

The Conductor Metaphor Is Literally What’s Happening

When Hoffman says software engineers are becoming conductors managing 20 coding agents rather than players writing every note, he’s not reaching for a metaphor. He’s describing an operational reality that’s already visible in engineering teams at companies actually using tools like Cursor, GitHub Copilot with agents, and Devin-style autonomous coding setups.

The conductor doesn’t play every instrument. The conductor knows what the piece is supposed to sound like, notices when the violins are slightly off, knows which sections need more rehearsal, and makes the call on tempo. That’s exactly the skill stack a software engineer needs in 2026: systems thinking, code review at a higher level of abstraction, an ability to decompose problems into parallelizable tasks, and the judgment to know when the AI output is subtly wrong in ways that will cause problems later.

What this means practically: the engineers who are thriving right now aren’t the ones trying to out-type the machines. They’re the ones who’ve gotten genuinely good at prompt decomposition, at running multiple agents on different sub-problems simultaneously, at synthesizing outputs into coherent systems. The ceiling on what one person can build has risen dramatically. A two-person startup can now ship what used to require a team of eight — not because the AI writes perfect code, but because a skilled conductor can catch and correct at speed.

The more important point, and one Hoffman is emphatic about: this isn’t just a software story. The generalized reasoning capability that powers code generation is the same capability that helps a travel agent build custom itineraries, an archaeologist analyze site data, a podcast operator manage a content pipeline, an investor run due diligence at scale. The conductor model is coming for every knowledge worker. Software engineers just got there first because the AI capabilities were most legible in that domain.

The $300 Billion SaaS Earthquake

There’s a specific, uncomfortable fact that every B2B software company is sitting with right now: Claude’s 200-line code release wiped $300 billion of B2B market value. Not because of panic. Because the market updated on something real.

The traditional SaaS moat was always two things: the product was genuinely expensive to build (so nobody built their own), and switching costs were high enough that companies stayed even when they were annoyed. A mid-sized company running Salesforce wasn’t going to rip it out because the alternative was worse, slower, or riskier. That calculation is changing. When AI can help a company’s own engineering team — or a small team of AI conductors — build and maintain custom CRM functionality at a fraction of the cost of a Salesforce license, the moat starts looking like a ditch.

This doesn’t mean enterprise software companies disappear next quarter. Legacy integrations, compliance requirements, and organizational inertia are real. But the trajectory is clear enough that investors repriced fast. The long-term question for every SaaS company is: what’s our moat when custom software becomes cheap?

The flip side — and this matters — is that software engineers don’t disappear in this scenario. They disperse. They go everywhere. Every grocery chain, every law firm, every hospital system, every mid-sized manufacturing company becomes a software company in the sense that they’ll need people who can direct AI coding agents to build and maintain the custom tools they actually need. The demand for skilled AI conductors may be larger than the demand for traditional software engineers ever was, just distributed completely differently.

The Playbook for Doubling Your Value in the Next Two Years

Hoffman’s 2-year warning is specific: people have roughly two years to adapt before the transformation becomes something you can’t prepare for, only react to. That window is already open. Here’s what the actual playbook looks like, without the vague advice about “learning AI.”

The Foundation Most People Skip

Two habits that sound small but compound fast:

  1. Use voice, not text. You speak dramatically faster than you type, and the conversational register tends to produce better, more natural outputs from models. This alone changes the texture of how useful AI feels day-to-day.
  2. Ask the AI to write the prompt. Instead of spending twenty minutes trying to engineer the perfect research query, ask: “Write me the right prompt to research fusion technology investments.” Then run that prompt. Most people have never done this once. The people who do it reflexively are operating at a different level.

One more thing that trips up even regular AI users: models are typically 18 months or more out of date on training data. If you’re asking about current tools, current prices, current market conditions, or anything time-sensitive, explicitly ask for live web research. Otherwise you’re getting confident-sounding answers about a world that no longer exists.

The Advanced Layer (No Coding Required)

Role stacking is underused and genuinely powerful. Instead of asking a question once, ask the same question from the perspective of a technologist, then a VC, then a policy person, then a safety expert. Then ask the model what roles you missed. You end up with a multi-dimensional analysis that’s more rigorous than what most teams produce in week-long offsites.

Pair this with adversarial prompting: explicitly ask the model to argue against your own idea. Tell it to be the contrarian. If your business plan survives that, you’ve pressure-tested it. If it doesn’t, you found out cheaply.

For anyone running a content or media operation — take a podcast workflow as the example. Using Claude Projects, you can set up a separate project per show, loaded with performance data, past scripts, audience goals, and brand voice. That’s mid-level AI operations. The advanced version: a meta-agent that synthesizes across all your projects, identifying what’s working, spotting through-lines, and importing ideas from adjacent fields you’re not watching. That’s a small media company running with the analytical capacity of a much larger one.

The Career Move That’s Actually Available Right Now

If you’re making $80,000 a year in finance, marketing, sales, supply chain, or any domain with real business stakes, the path to doubling that income is more specific than “learn AI.” It’s:

  • Become demonstrably proficient at applying AI to your specific domain — not AI in the abstract, but AI for financial modeling, or AI for supply chain optimization, or AI for marketing attribution.
  • Make yourself findable. LinkedIn, social c

    How to Actually Become an AI Conductor: A Working Setup

    The gap between “I use Copilot sometimes” and “I conduct 10 agents in parallel” is not a gap in tools. It’s a gap in how you decompose work. Here’s the exact setup and workflow that gets you to the conductor level.

    The Tool Stack That Works Right Now

    You don’t need everything. Pick a setup and get fluent in it:

    • Claude Code (Anthropic CLI) — best for autonomous multi-step tasks, long context, and when you need an agent to hold a whole codebase in mind. Runs in your terminal. Takes instructions, executes shell commands, edits files, runs tests.
    • Cursor — best for staying inside an IDE while directing agents on specific files or features. The Composer agent mode lets you describe a task and watch it work across your repo. Good for iterative, contained changes.
    • Aider — open source, runs in terminal, pairs well with git. Strongest when you want an agent that commits its own changes and you review diffs. Good for engineers who want full control over what gets staged.
    • GitHub Copilot Workspace — good entry point if your team is already on GitHub. Creates a plan before touching code. You review the plan, then it executes.

    For the workflow below, the primary tools are Claude Code for autonomous subtasks and Cursor for synthesis and review. You can run Claude Code in multiple terminal windows simultaneously — that’s your parallel agent setup.

    How to Decompose a Real Task: Build a REST API Endpoint

    The task: add a POST /users/:id/notifications endpoint to an existing Express + PostgreSQL app. It should validate input, write to the database, and return appropriate status codes. A solo engineer used to write this start to finish. The conductor breaks it into parallel streams.

    Here’s the decomposition:

    Agent Tool Subtask Dependency
    Agent 1 Claude Code Write the database migration and query functions None — runs first
    Agent 2 Claude Code Write input validation schema using Zod None — runs in parallel with Agent 1
    Agent 3 Cursor Composer Wire the route handler using outputs from Agents 1 and 2 Waits for Agents 1 and 2
    Agent 4 Aider Write integration tests for the new endpoint Waits for Agent 3

    This is not theoretical. Agents 1 and 2 run at the same time in separate terminal windows. While they work, you’re reviewing the existing route structure in Cursor and preparing the synthesis prompt for Agent 3. Total elapsed time drops significantly — not because each agent is faster than you, but because the work runs in parallel and you’re never blocked.

    What the Actual Prompts Look Like

    This is the part most tutorials skip. Directing agents is a different writing style than writing code. You’re specifying constraints, context, interfaces, and output format — not implementation details. You’re the architect handing off a scoped spec, not a pair programmer thinking out loud.

    Agent 1 prompt (Claude Code, terminal):

    Open a terminal in your project root and run claude, then send:

    “You are working in an Express + PostgreSQL app. The existing db connection is in src/db/client.ts and uses the pg library. Do three things: (1) Create a migration file in migrations/ that adds a notifications table with columns: id (uuid, primary key), user_id (uuid, foreign key to users.id), message (text, not null), created_at (timestamp, default now), read (boolean, default false). (2) Write a function createNotification(userId: string, message: string) in src/db/notifications.ts that inserts a row and returns the created record. (3) Write a function getNotificationsByUser(userId: string) that returns all notifications for a user ordered by created_at desc. Use TypeScript. Do not modify any existing files.”

    Agent 2 prompt (Claude Code, second terminal window, running simultaneously):

    “You are working in a TypeScript Express app that uses Zod for validation. Create a file at src/validators/notificationValidators.ts. In it, write a Zod schema called createNotificationSchema that validates a request body with one required field: message (string, minimum 1 character, maximum 500 characters). Export the inferred TypeScript type as CreateNotificationInput. Do not modify any existing files.”

    Agent 3 prompt (Cursor Composer, after reviewing Agent 1 and 2 outputs):

    “Using the functions in src/db/notifications.ts and the validator in src/validators/notificationValidators.ts, create a route handler at src/routes/notifications.ts. It should handle POST /users/:id/notifications. Validate the request body with createNotificationSchema. If validation fails, return 400 with the Zod error details. If the userId in the path does not match a UUID format, return 400. Call createNotification with the userId param and validated message. Return 201 with the created notification object on success. Return 500 on database errors — log the error but do not expose internal details. Register this route in src/app.ts under the existing route setup.”

    Agent 4 prompt (Aider, after Agent 3 is reviewed):

    Run aider src/routes/notifications.ts src/db/notifications.ts then send:

    “Write integration tests for the POST /users/:id/notifications endpoint. Use Jest and supertest. Test the following cases: (1) valid request returns 201 and the created notification object, (2) missing message returns 400, (3) message over 500 characters returns 400, (4) invalid UUID format for userId returns 400. Mock the database calls using jest.mock on src/db/notifications.ts. Put the tests in src/routes/notifications.test.ts.”

    What You’re Actually Doing While the Agents Work

    This is the conductor part. While Agents 1 and 2 are running, you are not waiting. You’re doing three things:

    1. Reviewing the existing codebase for patterns the agents might violate — error handling conventions, naming standards, how other routes are structured. You’ll catch mismatches before they compound.
    2. Writing the Agent 3 prompt. A good synthesis prompt requires you to understand what Agents 1 and 2 will produce. Drafting it in advance forces you to think through the interface contracts.
    3. Checking Agent outputs as they finish. Before Agent 3 runs, you read what Agents 1 and

      How to Actually Become an AI Conductor: A Working Setup

      The conductor metaphor is useful until you have to sit down and actually do it. Here is a concrete setup that works in 2026, using tools you can install today, with real prompts you can copy and adapt.

      The Tool Stack That Makes Multi-Agent Work Practical

      You do not need every tool. You need a small, composable set where each piece has a clear job:

      • Claude Code (Anthropic CLI) — best for long-context reasoning tasks, architectural decisions, and generating code that needs to understand a large existing codebase. Run it in your terminal with claude after installing via npm install -g @anthropic-ai/claude-code.
      • Cursor — best for in-editor agent work, inline iteration, and tasks where you want to see diffs in context. Use Cursor’s Agent mode (Cmd+I, then toggle to Agent) for multi-file tasks.
      • Aider — best for running a persistent coding agent against a Git repo from the command line. Install with pip install aider-chat. It automatically commits after each change, which makes it easy to review or roll back.
      • A task decomposition doc — a plain markdown file or Notion page where you break the work down before any agent touches it. This is your conductor’s score. Do not skip it.

      The pattern: you use Claude Code or a plain Claude chat window to decompose and plan, then you route subtasks to Cursor (when you want IDE integration) or Aider (when you want CLI speed and automatic commits). You review, you catch errors, you synthesize. That is the whole loop.

      A Real Example: Building a REST API Endpoint Across Three Agents

      Task: Add a POST /api/v1/orders endpoint to an existing Express.js app. It needs input validation, a database write to PostgreSQL via Prisma, and a confirmation email via SendGrid. A junior engineer might spend four to six hours on this. With three agents running in parallel, you can have reviewable drafts of all three layers in under thirty minutes.

      Before you touch any tool, write the decomposition. This is the conductor’s score:

      1. Agent 1 (Aider): Schema and validation layer — Zod schema for the request body, the Prisma model update, the migration file.
      2. Agent 2 (Cursor Agent mode): Route and controller logic — the Express route handler, error handling, calling the Prisma client, returning the right HTTP responses.
      3. Agent 3 (Claude Code): Email integration — the SendGrid helper function, the email template, the call from the controller once the DB write succeeds.

      Here is what the actual prompt looks like for each agent — not a vague description, a prompt you can copy:

      Agent 1 Prompt (Aider, run in terminal)

      Start Aider pointed at your repo with aider --model claude-3-5-sonnet-20241022 prisma/schema.prisma src/validators/, then send this message:

      “Add an Order model to the Prisma schema with fields: id (cuid), customerId (string, required), items (Json, required), totalCents (Int, required), status (enum: PENDING CONFIRMED FAILED, default PENDING), createdAt, updatedAt. Then create a Zod schema in src/validators/order.ts that validates the POST /api/v1/orders request body: customerId must be a non-empty string, items must be a non-empty array where each item has productId (string) and quantity (positive integer), totalCents must be a positive integer. Export the schema as CreateOrderSchema and the inferred type as CreateOrderInput. Do not touch any other files. Generate the Prisma migration file but do not run it.”

      Agent 2 Prompt (Cursor Agent mode)

      Open Cursor, press Cmd+I, switch to Agent, attach the files src/routes/ and src/controllers/, and send this:

      “Create a new Express route at POST /api/v1/orders. The controller should: 1) parse and validate the request body using CreateOrderSchema from src/validators/order.ts — if validation fails, return 422 with the Zod error details; 2) write a new Order record to the database using the Prisma client from src/lib/prisma.ts; 3) if the DB write fails, return 500 with a generic error message and log the real error; 4) on success, return 201 with the created order object. Do not implement the email send yet — leave a clearly commented placeholder where it will go: // TODO: send confirmation email. Register the route in src/routes/index.ts. Follow the existing route and controller patterns already in the codebase.”

      Agent 3 Prompt (Claude Code, new terminal window)

      In a separate terminal, run claude and open a session pointed at src/lib/ and src/templates/. Send this:

      “Create a sendOrderConfirmation helper in src/lib/email.ts. It should accept an Order object (use the Prisma-generated type) and a customer email string. Use the SendGrid Node.js SDK (@sendgrid/mail). The email should have subject ‘Your order has been confirmed’, a plain text body summarizing the order (orderId, totalCents formatted as dollars, item count), and an HTML body using a simple template. Read the SENDGRID_API_KEY from process.env and throw a descriptive error if it is missing. Export the function as sendOrderConfirmation. Do not call this function anywhere yet — just build and export it. Add a Jest unit test in src/lib/email.test.ts that mocks @sendgrid/mail and asserts the function calls sgMail.send with the right to address and subject.”

      What You Do While the Agents Run

      This is the actual conductor behavior. You are not watching a progress bar. You are:

      • Reading Agent 1’s Prisma schema output and checking that the model relationships make sense before Agent 2’s controller tries to use them.
      • Spotting that Agent 2 used req.body directly instead of the validated CreateOrderInput type — a subtle error that compiles fine but loses type safety. You catch it in review and send a follow-up prompt: “In the controller, replace the direct req.body reference with the result of CreateOrderSchema.parse(req.body) and use the typed output from that point forward.”
      • Checking that Agent 3’s test actually asserts the right things, not just that it runs without throwing.
      • Wiring the three outputs together once they are each reviewed — dropping Agent 3’s sendOrderConfirmation call into the placeholder Agent 2 left in the controller.

      The Mental Shift That Makes This Work

      Notice what the prompts above have in common. They are not vague requests. They specify the exact file paths, the exact function names to export, what to leave out, what pattern to follow, and what the boundaries are. The single most common reason multi-agent workflows fall apart is underspecified prompts — the engineer gives each agent a rough description and then spends more time untangling conflicting outputs than they would have spent writing the code themselves.

      The conductor’s job is precision before execution, not just review after. The five minutes you spend writing a tight decomposition prompt saves forty minutes of cleanup. That is the skill. Not knowing every API call — knowing how to write instructions that produce composable, predictable pieces you can actually assemble.

      Ty Sutherland

      Ty Sutherland is the Chief Editor of AI Rising Trends. Living in what he believes to be the most transformative era in history, Ty is deeply captivated by the boundless potential of emerging technologies like the metaverse and artificial intelligence. He envisions a future where these innovations seamlessly enhance every facet of human existence. With a fervent desire to champion the adoption of AI for humanity's collective betterment, Ty emphasizes the urgency of integrating AI into our professional and personal spheres, cautioning against the risk of obsolescence for those who lag behind. "Airising Trends" stands as a testament to his mission, dedicated to spotlighting the latest in AI advancements and offering guidance on harnessing these tools to elevate one's life.

      Recent Posts

      Task Layer Best Tool