AI Is the Engine. The Program Manager Is the Wheel.
Capacity is no longer scarce. Focus, boundaries and closure are.
On a personal project of moderate complexity, I handed execution to AI: code, test cases, UI prototypes, architecture options. Output multiplied several times over. The project still slipped — I lost focus, the scope kept widening, and I missed the release date.
That is not a competence problem. The bottleneck had moved. For most of software’s history the constraint was capacity: too few people, slow coding, slow testing. Engineers sat at the core because capacity was what pushed a project over the line. Once AI can produce any development artifact cheaply and at volume, capacity stops being scarce — direction becomes scarce.
The consensus is that engineers and architects benefit most from AI, because their output can be generated directly. That holds at the level of individual productivity; it does not hold at the level of project success.
Heading 2 — AI fit is not role value
The reflex is to ask whether AI will replace your job. The more useful question is whether a role produces artifacts or constrains them.
| Role type | Roles | Core work | What AI changes |
|---|---|---|---|
| Producing | Software Engineer, QA, UI/UX, Architect | Produce artifacts: code, test cases, UI prototypes, architecture docs | Takes over ~80% of repetitive, standardised production; single-point output multiplied |
| Orchestrating | Product Manager, Program Manager | Constrain content, align goals, close the loop | Absorbs administrative work, freeing capacity for goal control and scope decisions |
Producing roles accumulate output. Orchestrating roles accumulate leverage. AI amplifies both, but only one of them decides what stops.
Heading 2 — Where AI genuinely runs out of road
- It does not know the core goal of the current phase, or which priority outranks which.
- It cannot see implicit business constraints, team capacity limits, or cross-team blockers.
- It expands indefinitely — it does not trim scope, trade requirements, or manage risk.
- It cannot align stakeholders, resolve conflict, or guarantee a closed delivery loop.
Those gaps are the job description of the Product Manager and Program Manager. My own failure landed on the first one: output sped up, focus evaporated.
Heading 2 — The ranking nobody expects
| Type | Role | AI fit | Position in an AI delivery team |
|---|---|---|---|
| Orchestrating | Program Manager | ★★★★★ | The global core; AI only multiplies its value |
| Orchestrating | Product Manager | ★★★★★ | Demand-side focus; decides what to build and what to drop |
| Producing | Software Engineer / Architect | ★★★★☆ | Best production partner; fast, but prone to the detail trap |
| Producing | QA / UI/UX Designer | ★★★☆☆ | Support role; value shifts to strategy and validation |
Program Manager (★★★★★) — project plans, task breakdowns, Gantt charts, weekly reports, meeting notes, risk lists: AI generates all of it. That work should be handed over, so the PM can spend time on what is genuinely irreplaceable — goal control, scope constraint, cross-team alignment, risk anticipation, value landing.
Product Manager (★★★★★) — feedback synthesis, competitor research, requirements drafts, prototype variants in hours. But AI will not say which requirement is real, which is theatre, and which nobody will ever use. The cheaper requirements get, the more expensive “no” becomes.
Engineer / Architect (★★★★☆) — boilerplate and first-draft designs are fair game; trade-off calls, risk judgement and global architecture planning are not. Failure mode: sinking into detail and losing the business goal.
QA / UI/UX (★★★☆☆) — the durable value moves to test strategy, experience judgement, and risk validation.
Heading 2 — Three shifts in the PM role
From tracking progress to tracking value. AI keeps the schedule current; the PM decides whether the output serves the goal and which approaches get dropped.
From firefighting to steering. Faster iteration produces more scope creep and coordination friction; the PM bounds them before they cost a release.
From following threads to running the system. Every role now produces independently with AI, so fragmentation is the default; the PM is the only place scattered output becomes one shippable result.
Heading 2 — Where this argument stops
“Engineers are the real winners.” True for individual output. But output is not the constraint any more, so more output does not produce an on-time release on its own — it produces more scope to argue about.
“AI can do the PM’s admin too.” It can, and that is the point. Weekly reports, Gantt charts and meeting notes are already handled well. What AI cannot yet do is decide what must be cut this phase, or bring conflicting stakeholders to the same decision.
“Small teams don’t need a PM.” The administrative part can be absorbed by a founder. The moment requirements arrive from several directions, convergence work exists — the title may change, the work does not disappear.
One caveat stated plainly: this ranking describes role properties, not individual competence, and it comes from my own field observation. Treat it as a hypothesis to test against your own delivery data.
Conclusion & further reading
- AI races on capacity; Program Managers race on resolve.
- The scarce skill in an AI-native team is not generating more — it is knowing what to stop.
- Related reading on this site: the AI-assisted delivery notes under knowledge.
Did your team’s AI rollout break on quality, on coordination, or on the ability to say no? I would like to hear where it broke first.