> 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?
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?
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.