Why Graph Engineering Will 10x Your Claude and Codex
You hand one big job to an AI and it runs the whole thing in one straight line. Somewhere in the middle it takes a wrong turn, everything after that gets built on the wrong turn, and you do not find out until the very end.
That is the default failure mode of Claude Code, Codex, and every other coding agent. It is not a model problem. It is a shape problem. The job was handed over as a line, so it ran as a line.
Graph engineering is the fix, and it is the single highest-leverage habit you can build on top of these tools. It is not a framework and there is nothing to install. It is a way of drawing the work before you hand it over, and it changes what the same model is capable of.
The same job, two ways
Take a real task: work out whether there is a business in doing the bookkeeping for small online shops.
Run it as one long instruction and it goes off in a line. Forty minutes later the research is thin, so the answer built on top of it is thin too.
Draw it as a graph and you send three pieces of research out at the same time. Nothing further down starts until that research is good enough. The whole thing lands in twelve minutes with an answer you can actually trust.
Same model. Same prompt budget. The only thing that changed was the shape.
Why it is a 10x, not a 10 percent
Three things happen when you stop handing over a line.
The work that can run together finally does. A straight line makes every step wait for the one before it, even when it never needed to. The step looking at pricing is not touching the step looking at customers. Drawn as a graph, they run in parallel, and your wall-clock time collapses.
A wrong turn gets caught early. In a line, a bad decision at minute 2 is discovered at minute 40, after everything downstream has been built on top of it. A graph puts a checkpoint right after the risky step, so the wrong turn is caught at second 30 — before it has cost you anything.
A weak result is cheap to fix. When one box comes back thin, you rerun that one box. In a line you rerun the whole thing. The graph turns a total re-do into a one-node retry.
That is where the multiplier comes from. Not a smarter model — a shape that lets the model parallelise, fail fast, and recover cheaply.
A graph is two things
The boxes are the pieces of work. The arrows say what has to finish before something else can start. There is no new tool here and no syntax to get wrong.
That is the whole data structure. Everything below is just how to draw it well.
The three moves
You do not need to be clever to draw the boxes. It comes down to three moves.
Order. For every piece, ask what has to be true before this can start. If the answer is nothing, it goes at the top.
Parallel. Anything that gave that same answer goes side by side. Three researchers who each need nothing all start together.
Gate. Between a group and what comes after it, you put one question that has to come back yes. “Is the research good enough to build on?” If it is not, nothing downstream starts.
Order, parallel, and a gate. That is the whole method.
The real dependency is reads and writes
Almost everybody gets this wrong the first time. They ask “what order feels right?” That is not it.
You ask what each piece reads and what each piece writes. Reading is anything a step has to look at before it can start. Writing is anything it produces or changes. Those two words do all the work.
If a step reads something that another step writes, it has to wait — there is nothing there to read until the other one has finished. That is the real dependency, and it earns an arrow.
When you actually write down the reads and the writes, you usually find that most of the job was never sequential. It was only ever written down as a list.
The trap that looks right and is wrong
Here is the failure that catches everybody, and it is worth knowing before it catches you.
If two steps write to the same place, they cannot run at the same time, even when they look completely unrelated. They both append to the same sheet, or both pull from an account that allows one connection at a time. So they run together, one quietly overrides the other, and what you get back looks finished and is missing half its work.
The check takes ten seconds. For every pair of steps you are about to put side by side, ask what they both touch. If the answer is nothing, you are fine. If they touch anything at all, either they go in order or you give each of them its own place to write.
The reason this one stings is that it does not crash. A crash you would notice. This just hands you an answer that is wrong and looks right.
Gates that can actually fail
A gate is a question with a yes-or-no answer sitting between one part of the graph and the next. Most gates people write are useless because they can never fail. “Is the research done?” Well, yes, it ran. That gate did nothing.
A gate has to be able to say no. If you cannot picture the run actually stopping there, what you have drawn is a formality to make yourself feel organised.
Good gates: do we have at least three real sources that are not the same company’s own blog? Did every receipt come back with an amount on it? Is there a claim in here you would put your name against? Each takes about ten seconds to answer — deliberately, because a gate that takes an hour to check costs more than the mistake it was catching.
Then decide who answers it. The AI can handle some on its own, like counting sources or looking for blanks. Others need you, and that is fine — thirty seconds of your attention at the right moment saves the entire run underneath it.
The three shapes you will keep seeing
Once you have drawn a few, the same three shapes turn up over and over.
Fan out and fan in. Several things go off at once and all come back to one place. Three bits of research pulling into one thesis.
A chain. One thing follows another because each genuinely needs the one before it. Thesis, then script, then diagram. Chains are fine when the dependency is real. The mistake is drawing one where you never needed it.
A map. Any time you have a pile of the same thing. Twenty receipts in a folder, and on every one you open it and pull the amount. That is one box that runs twenty times, not twenty different boxes.
Almost every real job is those three stitched together: a fan out, then a gate, then a chain hanging off it.
Loops and branches
Real work does not always run forwards. Sometimes the gate says no and the right response is to go back and try again differently, not just stop. That is a loop.
A loop has to change something on the way around — different sources, a narrower question, more time. And it needs a limit on how many times it is allowed to try. Without one, an agent will cheerfully go around twenty times and burn your whole budget on a question that was never going to work. Two or three attempts, then stop and tell me, is almost always the right setting.
A branch is different. That is when what you find changes what happens next. If the receipts are PDFs you read them one way; if half are photos you need something that can read images. Same job, two paths, and you choose at the point where you actually know which one you are in. A branch point is a place where you learn something you could not have decided at the start — which is exactly why it belongs in the graph instead of being a guess you made on Monday.
What you actually type
Drawing boxes is nice, but at some point you say it out loud to the agent.
Name the parallel work first: “go and do these three at the same time, and do not start anything else until all three come back.” Then say what the three are. Then write the gate as a question it can genuinely answer: “when those three come back, tell me whether we have at least three real sources that are not the same company’s own blog.” Then say what happens on a no: “if we do not, stop and tell me, and do not start on the thesis.”
Three sentences and a question. The shape you drew is doing all the work.
The tool is the last thing you decide, not the first
The simplest version of a graph is you. You have drawn it on paper, you run the prompts yourself in a few tabs, you read what comes back, and you decide whether the gate passes. That is a graph. It works, it costs nothing, and you could do it this afternoon. Most of the value already arrived when you drew it.
The next step up is handing the graph to an agent that can run several things at once. There are tools built for exactly this shape, where you wire the boxes together and they handle the retries and branches. They earn their keep once the same graph runs every week. Before that they are mostly overhead.
So the order is: draw it, then run it by hand once, then automate whichever part actually hurt. If you pick the tool first, you will bend the work to fit whatever the tool happens to do well, and that is exactly backwards.
Keep more than the answer
When the graph finishes, you want more back than the final answer, because everything it collected on the way is worth keeping. Four things, every single time:
- The sources — the actual links, not a summary, because in three weeks you will want to check one.
- The intermediate results — the customer file and the pricing file as they were, not only the thesis they turned into.
- The decisions — which way each gate went and one line on why, because that is the part you would otherwise reconstruct from memory and get wrong.
- The version of the instruction you actually ran — because you will change it, and you will want to know which version produced which answer.
One folder per run, with the date in it, is genuinely enough. Then the next run reads that folder before it starts, and the second time you look at a market you already have the competitor list. That is the moment this stops being a way to run one job faster and starts being a thing that gets better every time you use it.
When not to draw one
The most valuable habit is knowing when to skip all of this.
If the job is one step, do not draw a graph — just ask for the thing. If you do not know what the steps are yet, do not draw one either; go and poke at the problem first, because a graph of a job you do not understand is a very confident way of doing the wrong thing efficiently. And if it is a genuine one-off, probably not.
The rule I would use: draw a graph when a mistake in the middle would be expensive, or when you know you will run the same shape again. Everything else is just a prompt, and a prompt is completely fine.
When it is worth it, the payback shows up in three places. The obvious one, where half the job stops queuing behind itself and you get twenty minutes back. The bigger one, where a gate catches a wrong turn at second 30 instead of minute 40. And the quiet one, where every graph you draw leaves the next one somewhere to start from.
Graph engineering is the difference between an AI that occasionally produces something brilliant and an AI you can actually rely on for real work. It is also exactly the kind of small, sharp discipline we install during a 1 Week Sprint — so by Friday your team is not handing the model a line and hoping, they are drawing the shape and shipping.