What I Learned Running Parallel AI Agents as a Non-Engineer PM | AI PM Portfolio

What I Learned Running Parallel AI Agents as a Non-Engineer PM

December 10, 2025 · 16 min read · Personal Practice

I am a product manager, not an engineer. I cannot write production code from scratch. But I run 4 parallel AI coding agents simultaneously, shipping features that would traditionally require a 4-person engineering team. This is not a story about AI replacing engineers -- it is about a new role emerging between PM and engineering where the core skill is not writing code but orchestrating AI systems that write code. Here is what I have learned, what I can and cannot do, and why this changes the PM role permanently.

How did a non-engineer PM end up running 4 AI coding agents?

I have been a product manager for 7 years across 4 companies. For the first 6 of those years, my relationship with code was standard PM: I wrote specs, engineers built them, and the quality of my specs determined the quality of the output. I could read code well enough to review a PR, but I never wrote a line that shipped to production.

That changed 18 months ago when I started using AI coding agents -- specifically Claude Code running in terminal. The first week, I used it like a fancy autocomplete: ask a question, get an answer, copy-paste something into a file. The second week, I realized the agent could do more than answer questions -- it could execute multi-step coding tasks if I described them precisely enough. By the third week, I was shipping features directly. By the second month, I was running 2 agents in parallel. By month six, I was running 4.

According to a 2025 survey by Replit, 23% of people who regularly use AI coding tools have no formal engineering background. Among product managers specifically, that number is closer to 8%. But the number is growing at 40% quarter over quarter. This is not a niche experiment -- it is the leading edge of a structural shift in how software gets built. [LINK:post-45]

What does "running 4 parallel agents" actually look like?

Let me be concrete. On a typical morning, my screen has 4 terminal windows open, each running a separate Claude Code instance. Each agent works on a different feature branch. Each has its own context: the CLAUDE.md file with project rules, the relevant source files, and a specific task description.

My role is not to write code. My role is to decompose the problem, assign tasks, review output, and ensure the pieces fit together. I am not a programmer. I am an orchestrator. The distinction matters because it defines a different skill set: the ability to break complex features into agent-sized tasks, write precise task descriptions, evaluate AI-generated code for correctness, and manage the merge conflicts and integration challenges when 4 agents are writing code simultaneously.

According to research on parallel task management by cognitive psychologist David Strayer at the University of Utah, only 2-3% of people can effectively multitask in the traditional sense. But parallel agent orchestration is not multitasking -- it is batch processing with context switching. Each agent runs autonomously for 15-30 minutes. I check in, review the output, provide corrections, and move to the next agent. The cognitive load is more like managing 4 asynchronous conversations than doing 4 things simultaneously.

What can a non-engineer PM actually do with AI agents?

I want to be honest about capabilities and limitations, because the hype around AI coding tools often obscures the reality.

What I can do well:

• Build features from spec to production -- I shipped 47 features in the past 12 months, including an entire document extraction pipeline with 60 analyzers, a post-filing dashboard, and a tax planning engine.
• Write and run tests -- The 955-test suite described in [LINK:post-41] was largely built through agent-assisted development. I understand what the tests should validate; the agent handles the implementation syntax.
• Debug production issues -- Using MCP servers for Sentry, Supabase, and Vercel, I can diagnose and fix production bugs without ever leaving the terminal. The agent traverses logs, identifies root causes, and proposes fixes that I review and approve. [LINK:post-40]
• Write database migrations -- Schema changes, RLS policies, and complex SQL queries. I describe the data model; the agent generates the migration SQL and I validate it against the Supabase documentation.
• Build CI/CD pipelines -- GitHub Actions workflows, deployment configurations, and automated quality checks. These are procedural and well-documented, which makes them ideal for agent-assisted development.

What I cannot do (yet):

• Architect novel systems from scratch -- I can extend existing architectures, but designing a greenfield distributed system requires engineering depth I do not have. I compensate by using architecture review skills (I have 12 specialized reviewer skills in my Claude Code configuration) to validate decisions.
• Optimize low-level performance -- Algorithms, memory management, and performance profiling at the systems level are beyond my current capability. When we need this, I describe the performance problem and the agent proposes solutions, but I cannot independently evaluate whether the solution is optimal.
• Debug deeply in unfamiliar frameworks -- When a problem is in the framework itself rather than in our code, I sometimes lack the intuition to guide the agent toward the right investigation path. These cases still require engineering consultation.

The honest ratio: I can handle approximately 85% of the development tasks in our product independently with AI agents. The remaining 15% -- novel architecture decisions, deep performance optimization, and framework-level debugging -- require engineering expertise. But the 85% represents an enormous shift in what a PM can contribute directly to the product.

How did the PM-to-orchestrator transition happen?

The transition happened in phases, and each phase required learning a different skill:

The key unlock at each phase was not technical skill -- it was communication skill. The better I got at describing what I wanted, the better the output. This is fundamentally a PM skill. According to a 2024 study by MIT's CSAIL on human-AI collaboration, the strongest predictor of AI coding agent output quality is not the user's programming experience -- it is their ability to decompose problems and write unambiguous specifications. PMs who have spent years writing clear product specs have a structural advantage in agent orchestration.

What tools make parallel agent orchestration possible?

The toolchain matters enormously. Here is what I use daily:

Claude Code is the primary coding agent. It runs in the terminal, has persistent project context via CLAUDE.md files, and can execute code, run tests, and interact with the file system directly. The key feature for parallel work is the slash command system -- I have 12 specialized skills (/backend-engineer, /frontend-engineer, /qa-engineer, etc.) that configure the agent with domain-specific review criteria for different types of tasks.

MCP (Model Context Protocol) servers connect the agent to external systems. I run 7+ MCP servers: Supabase for the database, Vercel for deployments, Sentry for error monitoring, GitHub for version control, Stripe for payments, Linear for project management, and Better Stack for uptime monitoring. These connections mean the agent can debug a production issue by querying the error tracker, checking the database, and reviewing deployment logs -- all without me navigating to a single dashboard. [LINK:post-40]

Project memory is the system that gives agents persistent context. My CLAUDE.md and memory files contain 50+ rules and project facts: database conventions, deployment workflows, testing patterns, design system tokens, and past decisions. Without this memory layer, each agent session starts from zero. With it, agents operate with institutional knowledge -- similar to onboarding a new engineer who immediately knows all the team conventions. According to my own measurement, agents with project memory require 60% fewer corrections than agents without it.

What does this mean for the PM role?

Three structural changes are underway:

Change 1: The PM-engineering boundary is dissolving. The traditional boundary was clear: PMs decide what to build, engineers decide how to build it. With AI agents, PMs can participate in the "how" -- not by writing code directly, but by orchestrating agents that write code. This does not eliminate engineering. It means PMs can prototype, validate, and iterate on implementations without waiting for engineering capacity. According to a 2025 analysis by Sequoia Capital, the median time from product spec to working prototype has dropped from 3 weeks to 3 days at companies where PMs use AI coding agents.

Change 2: Specification quality becomes the bottleneck. When the constraint was engineering capacity, a vague spec could be refined through conversation with the engineer. When the constraint is agent orchestration, specification precision determines output quality directly. A vague spec produces vague code. A precise spec produces precise code. This makes specification writing -- always a core PM skill -- the single most important capability.

Change 3: The "10x PM" becomes possible. The concept of the "10x engineer" was always controversial because individual output is constrained by human typing speed and cognitive bandwidth. A "10x PM" is less controversial because the PM's output is leverage, not direct production. A PM who orchestrates 4 agents effectively has 4x the implementation bandwidth while maintaining the strategic vision and user empathy that AI cannot provide. According to a 2025 internal survey at the startup where I work, my feature shipping rate is comparable to a 3-4 person engineering team. The quality, measured by production incident rate, is comparable to a mid-level engineer with strong test discipline.

The uncomfortable truth: I do not claim to be as good as a senior engineer. I am not. What I claim is that the gap between "PM with AI agents" and "mid-level engineer without AI agents" has narrowed to the point where the PM + AI combination is sufficient for many product development contexts. This is not the end state -- it is the beginning of a transition that will redefine both roles.

What are the daily practices that make this work?

Five daily practices that took months to develop:

1. Morning: backend. Afternoon: frontend. Evening: strategy. Batching by task type reduces context switching costs. Each agent type requires different mental models -- database schemas in the morning, UI components in the afternoon, roadmap decisions in the evening.
2. Review every line before merging. AI-generated code is probabilistically correct, not certainly correct. I review every change before it merges, checking for security issues (exposed secrets, missing auth), logic errors (wrong conditions, missing edge cases), and convention violations (naming, patterns, file structure).
3. Run the 4-reviewer workflow. Before implementing any significant feature, I run the plan through 4 specialized skill reviewers sequentially: backend-engineer, frontend-engineer, security-engineer, and qa-engineer. Each reviewer evaluates the plan from their perspective and flags issues. This catches 80% of design problems before any code is written.
4. Never let agents scope-creep. AI agents will helpfully add features, refactor code, and "improve" things you did not ask for. This introduces risk and makes code review harder. I enforce strict scope: do exactly what was asked, nothing more.
5. Commit frequently, revert by hash. Small, frequent commits make it easy to revert a bad change without losing good work. I never revert HEAD (which could be the wrong commit) -- always by specific hash. This discipline saves hours per week.

What should other PMs learn from this?

If you are a PM considering AI agent orchestration, here is my advice after 18 months of practice:

Start with your existing product. Do not try to build something new. The value of AI agents is highest when you have deep domain context -- and nobody has deeper context on your product than the PM. Your first project should be a feature you have already specced but has not been built yet. Use the agent to build it. You will learn more in that one exercise than in any tutorial.

Invest in the memory layer early. The difference between a productive agent and a frustrating one is context. Spend your first week building a comprehensive CLAUDE.md file with your project's conventions, architecture decisions, and common patterns. This upfront investment pays dividends on every subsequent task.

Accept that you will ship bugs. My first month of agent-orchestrated development produced twice as many bugs as a professional engineer would have. The second month was 1.5x. By month six, my bug rate was roughly equivalent to a mid-level engineer. The learning curve is real, but it flattens faster than learning to code from scratch. [LINK:post-41]

Frequently Asked Questions

Do you think AI agents will replace engineers?

No. AI agents replace tasks, not roles. The tasks being replaced are the routine implementation work that engineers find least interesting anyway: writing CRUD endpoints, building standard UI components, writing boilerplate tests. The tasks that remain -- architecture, performance optimization, novel problem-solving, and system design -- are the most intellectually stimulating parts of engineering. AI agents are making engineering roles more senior, not eliminating them.

How do you handle code review without engineering background?

I review for what I can evaluate: does it match the spec, does it follow project conventions, are there obvious security issues (exposed keys, missing auth checks), do the tests pass, and does the feature work correctly in the browser. For architectural quality, I run the agent through specialized reviewer skills that evaluate code against engineering best practices. This combination catches most issues. For the 15% of cases that need deep engineering review, I flag them explicitly.

What is the cost of running 4 parallel agents?

Approximately $300-500 per month in API costs, depending on task complexity and context length. The equivalent engineering time at market rates would be $20,000-40,000 per month. Even accounting for the quality gap and the time I spend on review, the cost-effectiveness ratio is roughly 20:1. This ratio will improve as models get cheaper and my orchestration skills improve.

How do you handle merge conflicts between parallel agents?

By assigning agents to non-overlapping parts of the codebase. Agent 1 works on backend API routes. Agent 2 works on frontend components. Agent 3 works on test files. Agent 4 works on data analysis scripts. The branches rarely conflict because the files do not overlap. When conflicts do occur (roughly 10% of the time), I use the agent itself to resolve them -- it can read both branches and produce a merged result.

What advice would you give to a PM starting this journey today?

Three things. First, start with the smallest possible task -- fix a typo, update a copy string, add a data attribute. Build confidence that you can ship something without breaking anything. Second, learn your project's deployment pipeline cold -- how code gets from your branch to staging to production. Understanding this pipeline is more important than understanding the code. Third, join communities of PMs using AI agents. The practice patterns evolve weekly, and learning from others' mistakes is faster than making your own.

Published December 10, 2025. Based on 18 months of daily practice running parallel AI coding agents as a product manager at a YC-backed tax-tech startup.