ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
50% Positive
Analyzed from 190 words in the discussion.
Trending Topics
#event#code#becoming#expensive#trading#model#may#must#remain#global

Discussion (2 Comments)Read Original on HackerNews
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.