Supervisory Programming
The emerging practice and role in which a developer supervises, coordinates, and evaluates the output of many AI coding agents — accountable for what the agents produce rather than writing it directly — including the still-undesigned skills, career paths, and dignity of this new supervisory work.
Also known as: supervisory engineering work, supervisory engineering, supervisory programmers, supervisory programmer, herding a bunch of agents, driving many agents, driving a bunch of agents
Part of: Human as Orchestrator of Agents
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| Finding Comfort in the Uncertainty Annie Vella · 2026-07-07 | supervisory engineering work | A new category of engineering work — supervising, orchestrating, and evaluating AI output — emerging as implementation is delegated to agents; the author's coinage from her Masters research |
Documents (6)
- The Work Behind Delegation: A Framework for Supervising AI Coding Agents Yeon Su Park; Nadia Arvi; Hae Ri Lee; Sehoon Lim; Qianou Ma; Juho Kim · 2026-09-22 Reader 🖥️
Developer supervision of AI coding agents is not a single activity performed at fixed checkpoints but a connected process organized into seven distinct, loop-connected stages (Plan, Monitor, Wait, Review, Teach, Manual Fix, Update Assets) -- a reconfiguration of Sheridan's classical five-stage human-supervisory-control framework made necessary by agents' greater autonomy -- and developers manage the resulting cross-stage demands (alignment, quality, understanding) by concentrating effort in planning, distributing supervisory work to other agents and automated hooks, and externalizing recurring corrections into reusable assets. - LIVE: Uncle Bob on Software Fundamentals in the Age of AI Matt Pocock (host) with Robert C. Martin ('Uncle Bob') · 2026-08-19 source ↗ Reader 🖥️
Software fundamentals (clean, well-partitioned, deeply-structured, well-tested code) matter just as much in the agentic era as before — not despite AI's speed but because of it — because agents hit the same complexity wall humans always have, just at a different threshold; the right response is not to impose human disciplines (like strict line-by-line TDD or heavyweight upfront specs) on agents, but to encode human values as deterministic, automated gauntlets (crap scores, mutation testing, dependency rules) that agents must pass through, while reserving strategic judgment — architecture, module boundaries, what's worth building — for humans who must now learn that judgment by experiencing the agents' own tactical gauntlet. - What's an Orchestrator—and Why Does Software Need One? Tim O'Brien · 2026-08-17 source ↗ Reader 🖥️
Software development is splitting the 'developer' role into an 'orchestrator' — a generalist who directs delegated-intelligence systems, remains accountable for what they produce, and can support them without AI — and this role should be professionalized (apprenticed, certified, insured) the way medicine and engineering are, because its holders now carry outsized responsibility without the licensing structures that responsibility normally requires. - Finding Comfort in the Uncertainty Annie Vella · 2026-07-07 source ↗ Reader 🖥️
The most valuable takeaway from a gathering of leading software practitioners on AI's impact is that nobody has it figured out — and that this shared uncertainty, together with a convergent set of hard questions the field is only beginning to name, is itself the ground for progress and a source of comfort rather than alarm. - How I write software with LLMs stavros.io · 2026-03-09 source ↗ Reader 🖥️
A solo practitioner can now sustain multi-week, tens-of-thousands-of-line AI-written software projects at a lower defect rate than hand-writing, but only by replacing 'ask one model to do everything' with a fixed division of labor across models (a strong model as architect doing interactive up-front design, a cheaper model as developer doing strict implementation, and one-to-three structurally independent models as reviewers) plus explicit human approval gates -- and only on technology the human already understands well enough to catch bad architectural decisions before the agent compounds them. - Fragments: February 13 Martin Fowler · 2026-02-13 source ↗ Reader 🖥️
As LLMs become established coding collaborators, software development is reorganizing around 'supervisory programming' in which developers herd fleets of agents — a shift that recasts the profession's central challenges as preserving a team's shared understanding of the system (cognitive debt), sustaining a developer experience that is effectively identical to agent experience, and containing the work-intensification and context-switching that driving many agents creates.
Propositions touching this concept (4)
By publication month, oldest first (extraction month when no publication date is known).
2026-02
- explicitTwo humans driving a bunch of agents may outperform a single programmer driving agents, combining the benefits of pairing with the greater code-generative ability of the LLMs.
- explicitA supervisory engineering 'middle loop' is emerging as a distinct new category of work between writing code and shipping it.
- explicitA new 'middle loop' of supervisory engineering work is forming that nobody in the industry has yet named or formalized
2026-07
- explicitcorroboratedA new category of 'supervisory engineering' work — supervising, orchestrating, and evaluating AI output in a 'middle loop' between the automated inner loop of coding and the outer loop of delivery — is emerging, but its skills, career pathways, and even its dignity have not yet been designed.
Tensions
Is the value question genuinely settled by evidence, or does uncertainty and sampling bias still dominate?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Notes from FOSE Europe (Giles Edwards-Alexander): The evidence is in; the value is clearly here and here to stay.
- Finding Comfort in the Uncertainty (Annie Vella): Nobody has it figured out; there is more uncertainty than certainty, and the shared set of questions is the real outcome.
- What Survived Contact (Sam Ruby): 'Rigor migrates' is about as settled as this young field gets, but the room is a non-random, incumbent-tilted sample, and the doubt is currently better evidenced than the hope.
Assessment: The single sharpest divergence, and it sits directly under the headline whether-to-how convergence: they narrate the same shift but disagree on what it establishes. Edwards-Alexander and Herlein read the room's confidence as evidence; Vella and Ruby read the same room as a self-selected in-group. Ruby has the better of it methodologically — he is the only one to interrogate the sample and to notice the evidence is asymmetric (upside anecdotal, downside studied), which is uncomfortable precisely because the cohort's confidence is built on the weaker side.
If code is no longer the bottleneck, what is the new binding constraint?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Finding Comfort in the Uncertainty (Annie Vella): Decision capacity and downstream absorption — 'humanity is not ready for this much software'; decision fatigue is becoming the real bottleneck.
- Notes from FOSE Europe (Giles Edwards-Alexander): Learning is the constraint now, not engineering delivery.
- We've Stopped Arguing About Whether AI Changes Software (Greg Herlein): Knowledge — the tacit, unwritten 'why' behind past decisions — is the scarce resource, not code.
Assessment: They agree code/delivery has ceased to be the constraint but name three different successors, with different investment implications — expand decision-making capacity (Vella), optimise for learning (Edwards-Alexander), or capture tacit knowledge (Herlein). These are complementary in principle but rivalrous for attention and budget; the disagreement matters because each implies a different 'first thing to fix.'
Does AI adoption improve output and developer experience together, or do they decouple — with more output bought at the cost of the developers?
from: What is the future of software development in the agentic/AI age?
- Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat (Jimmy Nilsson): Harmony: adoption is energizing and the human element flourishes ('Extreme Humanism'); reasons for optimism.
- Why did Martin Fowler invite 60 engineers to a ski resort? (Ivett Ördög): Liberation: adoption frees engineers from CRUD toil to focus on hard problems — 'exciting times.'
- The Future Of Software Engineering (Thoughtworks): Decoupling: organizations can gain output while developers report lower satisfaction — productivity and experience are coming apart.
- Finding Comfort in the Uncertainty (Annie Vella): Hidden cost: the engineers going hardest on AI are being exhausted by it, and the warning signs are easy to miss.
- Fragments: February 13 (Martin Fowler (Feb 13)): Intensification risk: teams stay the same size and 'do much more,' but doing much more is exactly what drives burnout.
Assessment: This is the specific, evidence-bearing form of the optimism/pessimism split, and it cuts directly against any simple reading of 'DevEx = AgentEx' as good news. The harmony camp (Nilsson, Ördög) speaks from felt experience and in-group mood; the decoupling camp (Thoughtworks, Vella) and Fowler's own cited HBR study bring the harder data, and it shows output and wellbeing pulling apart. Notably Fowler holds both 'same-size teams do much more' and the burnout finding without resolving them — the single clearest internal contradiction in the corpus, and a sign the harmony framing is doing more reassuring than the evidence supports.
If code was never the bottleneck, what is the binding constraint now?
from: What is the future of software development in the agentic/AI age?
- Finding Comfort in the Uncertainty (Annie Vella): Human decision capacity and downstream absorption — 'decision fatigue is becoming the real bottleneck.'
- Notes from FOSE Europe (Giles Edwards-Alexander): Learning — 'learning is the constraint now, not engineering delivery.'
- We've Stopped Arguing About Whether AI Changes Software (Greg Herlein): Knowledge — the tacit, unwritten 'why' is the scarce resource agents starve for.
Assessment: A productive three-way split downstream of the shared 'code was never the bottleneck' finding. They are not incompatible so much as differently located — decision capacity (Vella) is organisational, learning (Edwards-Alexander) is about the team's rate of understanding the problem, and knowledge (Herlein) is about capturing rationale. But they imply different investments: expand downstream absorption, restructure around learning, or build knowledge-capture pipelines. The corpus has not reconciled which is the true binding constraint, and each author generalizes from a different vantage (a retreat-floor convergence, an org-design frame, a knowledge-engineering frame).
Open gaps (7)
- incompleteSeveral teams describe routing around specialist teams entirely -- no networking team for the Kubernetes fix, no engineer for the designer's state-management changes, no IT for Legal's internal tools -- which the report frames purely as a productivity win, but never asks what happens to the bypassed teams' institutional knowledge, their own skill maintenance, or their future role once this kind of self-service becomes routine.How Anthropic Teams Use Claude Code — read next: A follow-up examining second-order organizational effects: whether specialist teams (networking, platform/IT, dev support) see reduced demand, redefined scope, or an erosion of the tacit knowledge that made them the escalation point in the first place.
- illogicalThe article asserts a trend toward needing less human review per model generation (line -> function -> architecture, possibly disappearing next year) while simultaneously asserting that the workflow's core safety property depends on a human who deeply understands the architecture catching bad decisions before they compound. If review granularity keeps moving upward to the point of disappearing, the same logic implies the human safety net the rest of the article depends on would disappear with it -- a tension the piece never surfaces or resolves.
- incompleteThe costs of the prescribed safety apparatus -- up to three reviewer models per change, an architect conversation that can run thirty minutes, and an explicit human approval gate -- are never weighed against the speed/defect-rate benefits the article narrates in detail. There is no accounting of total token spend, wall-clock time, or how the cost/benefit shifts for a less important change where the author says he uses fewer reviewers.
- incompleteThe article never specifies the accountability mechanism when multiple orchestrators, or an orchestrator and a vendor/platform, jointly produce a system that fails — it only asserts that delegated intelligence is 'always traceable back to an accountable operator' without addressing shared or contested authorship, which is the common real-world case (an orchestrator directing a third-party agent platform built by another company).What's an Orchestrator—and Why Does Software Need One? — read next: Multi-party AI liability and supply-chain accountability frameworks (e.g. the enterprise-as-accountable-integrator argument in extract-outsourced-ai-still-own-the-risk); agent identity/attribution mechanisms that bind actions to a specific accountable principal.
- illogicalThe '100x productive, 100x responsible' claim underlying the insurance/licensing prediction is a bare assertion with no supporting mechanism — it isn't clear that liability scales linearly (or at all) with output volume rather than with the severity and irreversibility of specific decisions, which is how liability actually tends to be assessed (e.g. malpractice law weighs harm caused, not cases handled per year).What's an Orchestrator—and Why Does Software Need One? — read next: Legal/insurance literature on how liability and malpractice exposure are actually assessed for high-throughput professionals; the clinical-vs-legal-standards-of-proof distinction between diagnostic usefulness and legal culpability.
- incompleteThe article asserts that finishing and delivering software 'takes the same effort, energy, and technical expertise... as it always has,' which sits in tension with its own DRM anecdote showing a months-long task compressed to 40 minutes — it never reconciles why orchestration effort is claimed to be unchanged in kind when the article's own evidence shows it collapsing by roughly two orders of magnitude in time.What's an Orchestrator—and Why Does Software Need One? — read next: Measured before/after productivity studies of AI-assisted delivery (e.g. time-to-10th-PR, throughput metrics) that could clarify whether 'effort' and 'elapsed time' are being conflated here.
- incompleteThe workflow-diagramming method relied on retrospective reconstruction after a single ~40-minute task, and participants were introduced to Sheridan's five-stage framework before drawing their own diagrams -- a sequencing the authors themselves flag (§9) as a possible anchoring effect on how participants segmented their own supervision, even though they were explicitly told not to follow it.The Work Behind Delegation: A Framework for Supervising AI Coding Agents — read next: A within- or between-subjects comparison of workflow diagrams elicited with versus without prior exposure to Sheridan's framework, to measure the anchoring effect directly rather than only naming it as a limitation.