> AI coding has created a strange inversion: writing code is becoming cheap, while understanding what all that code will do together is becoming expensive
I'm pretty sure it has always been that way. Isn't that the reason for the whole field of Software Engineering?
Maybe better to say the volume of code that looks superficially correct has dramatically increased. That velocity is overwhelming the rate at which existing practices could gate the flow to production.
Similar to moving from bespoke car manufacturing to a production line. The tolerance checking had to evolve in step with the rate of car production.
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
I come from an electronic-trading background. When an AI model is deployed inside an operational trading system, the model may be probabilistic, but its guardrails, permissions and surrounding behaviour must remain predictable.
We found that wiring these systems is expensive, error-prone and difficult for any one developer to hold entirely in their head. LLMs can make this harder: locally reasonable changes may silently alter the global execution order and introduce subtle bugs.
My thesis is that, for a closed object graph with declared local event semantics, much of the global orchestration can be derived. Components declare local intent through event handlers, triggers and lifecycle methods; a compiler can then calculate the coordination plan and generate a fixed, deterministic orchestrator for that event processor.
I included a browser-based playground in the article so you can inspect the Java components, inferred graph and generated orchestrator side by side, without installing anything or signing up.
I’m interested in where people think the boundary should lie between orchestration that must remain dynamic at runtime and coordination that can be derived and compiled.
> AI coding has created a strange inversion: writing code is becoming cheap, while understanding what all that code will do together is becoming expensive
I'm pretty sure it has always been that way. Isn't that the reason for the whole field of Software Engineering?
Maybe better to say the volume of code that looks superficially correct has dramatically increased. That velocity is overwhelming the rate at which existing practices could gate the flow to production.
Similar to moving from bespoke car manufacturing to a production line. The tolerance checking had to evolve in step with the rate of car production.
> 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
Hi HN, author here.
I come from an electronic-trading background. When an AI model is deployed inside an operational trading system, the model may be probabilistic, but its guardrails, permissions and surrounding behaviour must remain predictable.
We found that wiring these systems is expensive, error-prone and difficult for any one developer to hold entirely in their head. LLMs can make this harder: locally reasonable changes may silently alter the global execution order and introduce subtle bugs.
My thesis is that, for a closed object graph with declared local event semantics, much of the global orchestration can be derived. Components declare local intent through event handlers, triggers and lifecycle methods; a compiler can then calculate the coordination plan and generate a fixed, deterministic orchestrator for that event processor.
I included a browser-based playground in the article so you can inspect the Java components, inferred graph and generated orchestrator side by side, without installing anything or signing up.
I’m interested in where people think the boundary should lie between orchestration that must remain dynamic at runtime and coordination that can be derived and compiled.