Austin Marchese reframes prompt engineering as "graph engineering" — designing the shape of the workflow you hand to Claude — based on a course by Andrew Ng. He covers four graph shapes that matter (chain, diamond/fan-out, branch, loop), the "wait test" for finding steps that don't actually need the previous step's output, and the specific failure mode of each shape. The closing argument is that the real transferable skill here is problem solving, not any particular tool.
- A "graph" is just the structure of a workflow or automation; every Claude skill you build is already a graph, and graph engineering is the act of tweaking and optimizing that structure rather than accepting a default sequence.
- The "wait test" is the core diagnostic: at each step ask whether it actually needs the result of the step before it — if not, the dependency is wasted time and the steps can run simultaneously.
- The chain graph (one step after another) is slow and brittle since one failure kills the whole process, but it's still the best place to start because it's easiest to test.
- The diamond graph fans out subagents to work in parallel — good for research from multiple sources or code reviews from different angles like a security audit — and roughly halves the time on the report example.
- The branch graph routes a request down one of several paths based on context; the speaker's daily "improve system" skill uses this, and it's the mechanism behind what he calls skill routing.
- The loop graph has AI produce output, evaluate it, and iterate until it passes — and it only works if you have a genuine verification step, which makes it strongest for objective technical outputs.
- Each shape has a specific side effect: diamonds cause false independence and silent subagent failures, branches invite over-engineering (keep it to five or fewer paths), and loops can run away — one client woke up to thousands of dollars in tokens burned by an infinite loop, so always set a maximum iteration cap.
- The speaker's underlying claim: he was hired at JP Morgan as a software engineer without knowing how to code, and succeeded because problem-solving skill transfers across domains — graph engineering is a lens for problem solving, not a tool to memorize.
The wait test
1:22–2:41
This is the single actionable diagnostic in the video, demonstrated live on a concrete five-step research workflow.
Walk through your graph step by step and at every single step ask the question, does this actually need the result of the one before it? If the answer is yes, then having one step after the other makes sense. But if it's not, that connection is useless.
The infinite loop that burned thousands in tokens
11:22–11:45
A concrete, expensive failure mode with a one-line fix: cap the maximum number of iterations.
This is a horror story from one of the clients that I work with, but he went to sleep and when he woke up, the loop spent thousands of dollars on tokens because it got caught in an infinite loop.
You've been graph engineering without knowing it... Just creating graphs isn't engineering graphs. The process of tweaking, designing, and optimizing is where it becomes graph engineering.
Whenever you create a Claude skill, it's essentially a graph. It just depends on what shape it has.
The tools will change, what you work on will change, but your ability to problem solve will travel with you no matter what domain you're working in.