7.1 Start with the structure around the code
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, because 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, because 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 one is not magic; it is more engineering, moved from typing code to designing the work around the code.