Graph Engineering
Graph Engineering
Shaping the work of building software as a dependency graph, where nodes are small self-contained jobs and an edge exists only when one job's output feeds another.
Graph engineering models the work of building software as a dependency graph. A node is one small self-contained job: one input in, one output out, ideally a schema-validated one. An edge exists only when a downstream node reads an upstream node’s output. Nodes and edges are ordinary graph terms, scheduling work as a dependency graph is what build systems have done for decades, and nothing in the vocabulary is specific to code. The membership test runs at every “and then”: does the next step read the last step’s output? A linear “A then B then C” script is already a graph, just a chain, and most of its arrows record the order the steps were written in rather than data one step needs from the last.
Parallelism comes from the edges: jobs with no edge between them can run at the same time. The common shape is fan-out/fan-in: independent jobs run at once, plain code merges their outputs, and the final result builds from the merge. Scatter-gather is the narrower case, one request out and the replies aggregated. Decomposition cuts the job into nodes; the graph records which ones depend on each other. A node can be an agent or plain code, and the coordination between nodes is code, so it costs no model call. A pipeline streams items through the graph as branches produce them; a barrier makes every branch wait for the slowest, which earns its cost only when a step needs every prior result at once.
Orchestration tracks execution, and a second layer tracks truth: a claim graph, statements about the product that tests can prove or refute, linked by dependency. The claim graph yields what can start right now; only long or crowded runs need a separate work graph for owners and gates. A job’s result stays a candidate until it is checked against the claim’s test and written into the record. Climbing the graph is the loop: pick an unblocked claim, build toward it, mark it true only when its test passes. A correct loop can run on a wrong graph: the cut itself stays unverified until its claims pass their tests.