> AI can generate components faster than humans can understand their combined execution

That is true but you are still responsible for the code that gets checked in. So slow down and make sure you do understand it before committing it.

Its the confidence we can trust a tool with. We trust compilers 100% and do not check their output as it is deterministic process that is well proven. We slow down and check where we have less confidence.

What I am saying is orchestration code can be generated deterministically and then we trust it. Agreed AI can generate the code that is invoked and we need to check the workings of a function. But the order which functions are executed can be moved to a mechanical process and trusted.

If AI generates the orchestration code you would need to validate every execution path in the system. At that point a developer would need to keep a global dispatch table in their head and check the AI generated orchestration code against that mental model.

What you raise is an interesting point should a developer understand everything in a program or accept contracts and work within those trusted boundaries? We work with a 7 layer OSI model and plug into without validating it. Do you need to understand every execution path in the program? In a microservices architecture we code a service to a specification and then deal with the orchestration as a separate issue. If that orchestration of a microservice based system is left to a trusted separate team then our focus of correctness is local and not global. If that orchestration team is sometimes unpredictable we lose faith but if it is predictable we can move forward with confidence.

Potentially that leaves us with three options for orchestration: 1. The developer is all knowing and validates all execution paths 2. Orchestration is a separate problem handled probalisiticaly by AI 3. Orchestration is a separate problem handled mechanically as a compiler style operation