The Manager's New Brief

12.1

Ch. 12 — Leading Hybrid Human + AI Workflows

Part IV — Management in the AI era

💡 Core idea

The new unit of work is a workflow, not a job title. The manager designs who — or what — does each step, who reviews it, and who is accountable when it fails.

Buying a tool and hoping a workflow will invent itself is the usual failure. Agents and copilots can draft, summarize, retrieve, route, and sometimes act. They still cannot be trusted alone with accountability, taste, novel judgment, or the customer relationship. Your job is to design the path of the work, including the stops.

Stuart Winter-Tear puts the constraint on the operating model, not the tool: “Agentic AI is a mirror. It does not invent coordination, clarity, or trust. It reflects whatever is already present.” And: “AI won’t fix your system. It will only show you what’s broken, faster.” Atlassian’s AI Collaboration Index (2025), a vendor survey of 180 Fortune 1000 executives and 12,000 knowledge workers, reports that workers “say AI makes them an average of 33% more productive,” while “transformation is rare”: “96% of companies have not seen dramatic improvements in organizational efficiency, innovation, or work quality.” Self-reported perceptions, not audited outcomes. If ownership, judgment, and the right to say no are weak, agents will inherit that — only faster (Chapters 1 and 15).

Design the harness, not only the prompt

Lukas Niessen, in a deep dive on harness engineering, describes an agent as a model plus a harness: the team-owned layer of context, tests, standards, and stop conditions. A source-code study of eleven coding agents by Barbaste and colleagues at Wavestone AI Lab reaches the same definition: “An agent is a model plus a harness: the runtime that couples an LLM to the world through a loop, tools, context management, safety controls, orchestration, and extension surfaces.” The paper compares how those systems are built; it does not rank their performance. Prefer sensors — tests, types, checks — over ever-longer instruction files. A central rule in that piece, as the author’s digest notes it: the agent must not be the one who decides it is done.

Anthropic, in “Building effective agents,” argues for simple, composable patterns rather than hiding an architecture choice behind the word “agent.” Martin Fowler describes encoding team standards so assistants produce work that matches the team’s bar, and knowledge priming: load project context before a session, rather than hoping the model remembers what you meant.

Context quality is not a nicety. Bousetouane (2026), in a controlled study that held the model fixed and varied only the operating context, found that moving from a poor context to a structured one raised the mean final score from 3.15 to 5.49, hallucination resistance from 3.21 to 5.61, and tool-use from 3.46 to 6.25, while critical failures fell from 4.11 to 1.33 per evaluation (300 multi-turn evaluations; 7,500 turns). Grounding sufficiency correlated with hallucination resistance at r = 0.63. This is a preprint, scored with the author’s own evaluation harness, so treat the exact numbers as early evidence, not settled law. The implication you can use now is still clear: if the context is thin or wrong, do not trust the output. Adding more rules (“hardening”) improved measured context quality but did not raise every behavioral score — more constraints can make the agent more conservative.

Martin Fowler offers language for the human role in this design: the “conductor,” who directs agents rather than only producing first drafts. Aaron Levie describes a related role as “the agent deployer and manager in teams”: find the highest-leverage workflows, redesign them, get the agent the context it needs, figure out “where the human interfaces with the agent and at what steps,” and run evals and KPIs. He expects one or more of these people on every team, not only in a central AI group. Arthur Mensch, testifying before the French National Assembly on 12 May 2026, said that at Mistral “les ingénieurs n’écrivent plus de lignes de code” and now work as “des managers, des donneurs d’ordres,” asking agents to write code from specifications. He added that a person alone can go “dix ou vingt fois plus vite,” but “dans une très grosse entreprise, il faut lever les goulots d’étranglement organisationnels.” You may not want the title. You do want the function: someone designs the workflow, sets the human checkpoints, and remains accountable. Chapter 13 returns to the skill side of this.

Zach Lloyd defines a “software factory” as “A measurable, improvable cloud-based system for scaling coding agents for maximum ROI and productivity across your organization.” The claim to take is not the slogan. It is that scaling agents is an engineering and measurement problem, not a prompting tip. Anthropic reports that its monorepo went from around 2,500 code changes merged per day in May 2026 to more than 30,000 per day in September, and that the bottleneck became infrastructure built for human scale. That is Anthropic’s account of its own workload; the authors note how unusual that volume is and do not present it as a general productivity law. Chapter 15 returns to measurement.

Allocate the work on purpose

For each step in a core process, choose: human, AI, or human-in-the-loop. Enthusiasm is not a criterion. Tey Bannerman publishes a practical human-in-the-loop frame you can sit beside your own review rule. Read it before you copy it; the requirement is already clear: if a human must review, name who, name the bar, and name what happens when they are away.

Ethan Mollick discusses agents that take initiative. Unauthorized action is a management and governance incident (Chapter 14), not a clever demo. If a tool can act, you need an authorization rule, not only a quality rule.

Team shape follows the same design question. Coinbase’s “pirate and architect” pods, described in Chapter 2, are one attempt to put a shipper and a scaler in the same small unit, with agents in the loop. The mode still has to be chosen on purpose.

Quality, rollout, and broken windows

Use a ladder: offline test, shadow mode, a small live slice, then standard use — with a kill switch. Quality is not a later polish. Manager.dev, on the broken-windows theory of coding agents, argues that mess replicates unusually fast when agents copy existing mess. The same logic applies outside code: a sloppy template will be reproduced at volume.

Aviv Ben-Yosef argues that token spend is often the cheap part; the real cost is firefighting, misalignment, and bad process. If you manage the invoice and ignore the workflow, you have missed the job.

Charity Majors argues that once generation became cheap, “Lines of code went from being treasured, reused, cared for and carefully curated, to being disposable and regenerable, practically overnight.” That is not a license to skip review. “Nondeterministic systems will require more engineering discipline, not less.” If “the hardest part of software has never been writing code,” then “even if the economics of code production drop to zero, the hard parts will still be hard.” Put the rigor into evaluation, invariants, and production understanding — not into dropping the bar.

A single-company self-report is Roman Nikolaev’s account of QA at Cambri after the team switched to Claude. The same six or seven developers “finished about 44% more tickets a month than in 2025, not counting bugs, and the PRs merged per month roughly doubled,” while “about half” of 2026 PRs were “reviewed only by their authors with help from AI.” Their rule: “The verdict stays human.” “The agent can never move a ticket to Done, and never files a bug without approval.” The team estimates the agent now does “about 75–85% of the hands-on test execution on a ticket,” “an estimate from a week of sessions, not a measurement.” Treat this as one organization’s self-report, not a general productivity law. The design choice travels: automate execution and evidence-gathering; keep the ship decision human (Chapter 14).

Finish-the-job versus reinvent-the-job

Ryan Wright, writing on what happens after automation, argues that most people will use AI to finish the current job faster, and that organizations change more slowly than the technology. Plan for that, not for a fantasy reorg that has not happened. The “faster” part is real in some settings and misleading in others. Noy and Zhang (2023) found that ChatGPT cut time on midlevel professional writing tasks by 40% and raised output quality by 18% (453 college-educated professionals). Dell’Acqua and colleagues showed the opposite pattern on a consulting task outside the model’s frontier: AI users were 19% less likely to be correct. Design the harness for both cases.

Jurriaan Kamer argues that every upgrade has a downgrade: name honestly what you are willing to lose. (The URL slug on that piece appears to contain a typo, “downrgrade”; use the link as listed.) Speed may cost quality, privacy, or a junior learning path. If you cannot name the cost, you are not finished designing the change.

Watch also for cognitive debt — Simon Willison discussing Margaret-Anne Storey’s term: work that ships without anyone still understanding it. That is not leverage. That is a future outage.

Avoid automation theater: a tool is “adopted,” nobody owns quality, and errors leave the team with more confidence than before.

Tools

🤖 AI-era tip: Name three things before you automate a step — then a fourth

For every assisted step, name (1) the human accountable when it fails, (2) the standard for “good enough to ship,” and (3) the fallback if the tool is wrong or down. If you cannot name those three, you are not ready to automate. Add a fourth: who is allowed to say the agent is finished? If the answer is “the agent,” the harness is incomplete. Also write down what must never be fully automated on this team.

Takeaways

Evidence