Graph Engineering Needs a Compiler — Fluxtion blog

← All posts AI can generate components faster than humans can understand their combined execution. Graphs make the application structure visible. A compiler can turn that structure into a deterministic orchestrator.

AI coding has created a strange inversion: writing code is becoming cheap, while understanding what all that code will do together is becoming expensive.

An LLM can add a handler, connect an API, introduce a queue, implement a retry, update some state and call another service in minutes. Each change can look perfectly reasonable when read on its own.

The problem appears when those reasonable pieces interact.

The real behaviour of an application is rarely contained in one method. It emerges from the order in which callbacks, listeners, timers, queues, retries, lifecycle hooks and state changes combine.

An LLM can now generate this orchestration faster than a human can reconstruct the execution model it is creating.

This is one reason graph engineering is attracting attention. LangChain recently used the term to describe constructing agentic systems as graphs containing deterministic code, model calls, tools and complete agents. The graph constrains the paths the system may follow instead of leaving every decision to an LLM.

That is an important improvement — but making the graph visible is only half the solution. The other half is deciding exactly how the graph executes.

AI writes locally. Systems execute globally.

LLMs are often very good at implementing local behaviour.

Suppose an application receives a trade and must:

Update position<br>Recalculate risk<br>Publish the result<br>An LLM might generate:

updatePosition(trade);<br>publishPosition();<br>recalculateRisk();<br>Every method call is valid, the code is readable, and the implementation may compile and pass many tests. But the global ordering is wrong.

Nothing in those method signatures tells the compiler that risk must be recalculated before the position is published. That requirement exists somewhere outside the code: in an architecture document, in a test, in a comment, or in the mind of an experienced developer.

The dangerous AI-generated code is not usually obvious nonsense. It is locally plausible code that subtly violates a global invariant .

The problem compounds over time. One prompt introduces retries. Another moves work onto an executor. A third adds metrics. A fourth supports another event type.

Each change may be reasonable in isolation while changing:

execution order;

state visibility;

reentrancy;

failure handling;

completion semantics;

replay behaviour.

The application gradually develops an execution model that no person—and no single prompt—ever explicitly designed.

The loop is not the villain

A small loop can be perfectly deterministic:

while (running) {<br>Event event = queue.take();

updateState(event);<br>calculateRisk();<br>publishResult();<br>Given the same initial state and the same ordered inputs, this loop can produce the same result every time.

The problem is not that loops are inherently unpredictable. The problem is that real applications rarely remain one loop.

Over time, updateState publishes another event. A listener receives it. A timer refreshes reference data. A retry schedules more work. A framework invokes a lifecycle method. A callback observes some state before another callback has finished updating it.

The original loop has not disappeared. It has become distributed throughout the application:

Event loop<br>├── listener<br>│ └── callback<br>│ └── queue<br>├── scheduled task<br>├── retry handler<br>└── asynchronous publisher<br>Someone still has to understand the complete sequence.

In a conventional project, that person is often a senior developer who has accumulated an unwritten model of the system over several years.

In an AI-generated project, we risk asking an LLM to become that global coordination engineer. That is a poor division of responsibility.

Graph engineering makes the application model visible

A graph replaces implicit control flow with explicit relationships:

Trade<br>Position<br>Risk<br>Policy<br>Route<br>The graph says that risk depends on the updated position, policy depends on risk, and routing depends on the policy decision.

That is easier to inspect than equivalent behaviour spread across queues, callbacks and listeners.

It is also a natural model for systems that combine ordinary code with probabilistic components:

Request<br>Classification agent<br>Policy validation<br>Human approval<br>Approved action<br>The classification agent may remain probabilistic. The surrounding graph constrains where the model can operate and what must happen before an external action is permitted.

Current agent graph frameworks generally make this graph explicit: nodes perform work, while edges or routing definitions determine what happens next. Microsoft’s Agent Framework, for example, describes workflows as directed graphs of executors and edges; LangGraph similarly uses nodes, state and...