2.2 The conflict
Maya’s story takes place inside a gap between individual capability and organizational design, and the survey evidence marks the edges of that gap fairly clearly. Stack Overflow’s 2025 developer survey — a self-selected sample, not a controlled experiment — found that roughly 69 percent of developers who use AI agents agreed the agents increased their productivity, while only 17 percent agreed the agents improved team collaboration: the benefit is arriving inside individual workflows first, while the teams around those workflows still run on the old queues.1
This is not only a developer problem. UpGuard’s 2025 study — 1,020 employees in the United States and United Kingdom, plus 542 security leaders — reported that about eight in ten of those employees used unauthorized AI tools, and that 68 percent of the security leaders admitted using them in their own workflows.2 Those numbers describe those samples; they are not a census of the workplace. What they establish is a direction rather than a magnitude: people are not waiting for a complete corporate program before making their work move, and a great many are innovating straight through corporate inaction.
Nearly every organization knows AI exists — it would be impressive at this point to have missed it. Far fewer have redesigned any work around it. That is the environment Maya works in: widespread use, minimal institutional adaptation, and a small population of people quietly building the next operating model on their own laptops. And there is one more trend no consulting firm can measure, which is that a lot of the people learning to orchestrate intelligent systems are being careful about who they tell at work, because they understand what it changes.
2.2.1 Working alone, unapproved
Maya is in a strange position, and the strangeness is the point. She still has to attend meetings where the customer-service team reads out an endless list of tickets. Over the next three weeks she has at least twenty hours blocked to listen to software engineers debate the right way to fix a bug she fixed on Monday. She has tried to help people see that there is now a faster way to solve these problems. She is not senior enough to change how the company operates, but she is smart enough to know that change happens slowly. Management is starting to realize that when something needs to be done quickly, they talk to Maya.
Meanwhile the company remains committed to a process involving multiple specialist teams and weeks of meetings. Maya has built a faster path alongside teams that are constantly complaining about the process she has already made redundant. The company is also wary of starting to use more AI, because it might affect employee engagement. Plenty of her colleagues would read her work as an existential threat to their jobs, so she is careful about revealing that she can turn customer feedback into action in an afternoon.
No one at the company has a name for what she is doing. This book does: she is an orchestrator — a person directing systems of delegated intelligence before the organization has named, staffed, or budgeted for that responsibility. What matters here is not that she installed a few unapproved tools. It is that she has begun automating the business around the code.
Maya is ahead of her organization, and that carries risks the organization has not yet learned to manage. She is also not unusual. These early orchestrators are not waiting for policy, architecture, and security practice to catch up; they are discovering a genuine step forward in productivity while those disciplines are still adapting around them. That is not the final operating model, and I am not holding Maya up as a recommended one. A later chapter returns to the security and governance systems orchestration requires. For now, it is enough to recognize the pattern: the work is arriving before most organizations are ready to name or contain it.
2.2.2 The threat your colleagues feel
Focus on that last point, because it is the one nobody talks about in the demos. Maya cannot celebrate her best work at work.
The department sees what she does through one filter: what happens to my job. Her results are not a shared win; they are a rebuke to every team that spent a month on what she did in a morning, and a threat to the org chart that gives those teams something to do. The sarcasm from QA was not really about testing. It was about status. The support meeting that runs on tickets she has already read is a meeting whose reason for existing she has quietly removed, and everyone in the room can feel it even if they cannot name it.
This is the conflict’s sharpest edge: the better Maya gets, the more alone she becomes. If she shows her work, she is showing thirty people a faster way to need fewer of them. If she hides it, she carries the system alone, and the isolation compounds: nobody to review with, nobody to learn from, no institutional memory of what she has built, and no safe way to say any of it out loud. The skills advance faster than the relationships that would make them welcome. The result is that the people furthest ahead are often the least able to say so — and the company loses access to exactly the capacity it most needs.
There is a reasonable side to the wariness, and it deserves to be said. The tools are unapproved, the data handling is unreviewed, and Infosec has good reasons for the process Maya routed around. Some of the caution she meets is people doing their jobs. But legitimate security objections do not account for most of what Maya runs into. Slack’s Fall 2024 Workforce Index — more than 17,000 desk workers — found that 48 percent would be uncomfortable admitting to their manager that they had used AI for a common work task; among those, 47 percent said it felt like cheating, 46 percent feared looking less competent, 46 percent feared looking lazy, and only 21 percent cited company policy.3 The pattern is social, not procedural. Much of the caution is about identity, established expertise, team boundaries, and the status attached to doing the work manually — about what the speed makes visible about everyone else’s week.
2.2.3 From authority to execution
Many departments exist to move information toward a decision by hand: project managers collect updates, analysts assemble numbers, and teams hold meetings to explain what the slides already contain.
Much of that process can be automated. Systems can gather the information, analyze it, compare alternatives, and show the likely consequences of each one. People still need to decide what the organization should value, what risks it will accept, and what it is willing to do. But they do not need to spend most of their time moving information from one department to another so that a decision can eventually be made.
For developers reading this and worrying that orchestration means the end of their jobs, that is not the argument I am making. People will still develop software. They will write less of the routine code directly, but they will need to understand the code that systems generate, even if they do not read most of it line by line. The work moves toward defining outcomes, checking results, and deciding whether the system solved the right problem.
The people who should be more worried are the executives and managers who have built organizations around manual coordination. Teams upon teams of people sit in meetings, maintain spreadsheets, manage projects, and prepare presentations so that someone else can decide what to do. Most executives and mid-level managers have become very good at creating more meetings. They have not necessarily become good at creating better outcomes. That kind of meeting-driven organization is much more vulnerable to automated orchestration than the work of developing software.
The change is not that human judgment disappears. It is that the work surrounding a decision no longer has to be performed manually. An orchestrator decides which parts of the process can run without a meeting, what evidence the systems must produce, and where a person still has to make the call.
2.2.4 Make the work visible
Maya knows what her systems are doing. She knows which agents are running, what evidence they found, which branches they created, what remains uncertain, and where human judgment is required. The company knows none of it, which makes Maya the system’s hidden control plane — and if she closes her laptop or takes another job, nobody can reliably say what is running, what has been approved, or what is supposed to happen next.
The first step out of that is a shared register answering seven questions:
| Question | Answer |
|---|---|
| What outcome are we pursuing? | Solve the customer problem without losing the original context |
| What is running? | Support analysis, solution modeling, two code branches, and QA replay |
| What evidence supports the work? | Customer conversations, incident history, API traces, and abandonment data |
| What remains uncertain? | Split payments and partial returns |
| What can the system do? | Read data, model options, write branches, and run tests |
| What requires human judgment? | Customer impact, privacy boundaries, and release approval |
| What stops the work? | Identity exposure, missing tests, or no proven rollback path |
This is not a prompt history and not a task list. It is the operating state of the system: what it is doing, what it knows, what it is allowed to change, and where a person has to intervene. The test of whether it is real is simple enough to run this week — can another qualified person take the work over using the register, the evidence, and the recorded decisions? If not, the workflow still belongs to Maya rather than to the company.
Orchestration is delegated authority, not delegated responsibility. The orchestrator can give automated systems permission to investigate, build, and test, but remains responsible for defining the boundaries, maintaining oversight, and deciding what is safe to release. As these tools move into regulated industries such as healthcare and finance, that balance will become essential. The systems may do more of the work, but responsibility still belongs to people.
Stack Overflow, “AI | 2025 Developer Survey,” 2025, https://survey.stackoverflow.co/2025/ai. The survey reports that approximately 69% of AI-agent users agreed agents increased productivity, while approximately 17% agreed agents improved collaboration. It is a self-selected survey and measures reported experience, not causal productivity.↩︎
UpGuard, “New Research from UpGuard Reveals 68% of Security Leaders Admit to Unauthorized AI Usage,” November 10, 2025, https://www.upguard.com/press/new-research-from-upguard-reveals-68-of-security-leaders-admit-to-unauthorized-ai-usage. The report combines a Prolific survey of 1,020 employees in the United States and United Kingdom with a Dynata survey of 542 security leaders across several regions. The “eight in ten” employee figure describes the 1,020-person US/UK employee sample; it should not be generalized to all workers.↩︎
Slack, “The Fall 2024 Workforce Index,” 2024, https://slack.com/blog/news/the-fall-2024-workforce-index-shows-executives-and-employees-investing-in-ai-but-uncertainty-holding-back-adoption. Survey of more than 17,000 desk workers: 48 percent uncomfortable admitting AI use to their manager for at least one common task; among them, 47 percent said it felt like cheating, 46 percent feared appearing less competent, 46 percent feared appearing lazy, and 21 percent cited company policy.↩︎