The Orchestrator

A developer usually begins with implementation. What function needs to change, which service should own it, what database table is involved — and those questions still matter. They are not going away.

An orchestrator asks a few more on top of them. What is the actual goal? Which systems or people can contribute? What information does each one need? How will the work be checked? What happens when the result is wrong? Which changes can be reversed? How can the system improve without quietly granting itself more authority?

You are entitled to an opinion about how something should be built, and you will often need one. But you get far more out of these tools once you stop treating your opinion about the implementation as the entire job. The job becomes designing a structure in which the implementation can be produced, tested, corrected, and maintained. That is the difference between using an agent to write a file and building a system that can understand a request, change the right files, run the tests, deploy without interrupting current work, and tell you what it could not verify. The second is not magic. It is more engineering. It just moves some of the engineering from typing code to designing the work around the code.