Rendered at 19:46:26 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
kkkqkqkqkqlqlql 1 hours ago [-]
> 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?
v12technology 40 minutes ago [-]
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.
v12technology 5 hours ago [-]
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.
I'm pretty sure it has always been that way. Isn't that the reason for the whole field of Software Engineering?
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.
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.