Graph engineering

The feature the video calls the heart of a graph met its trigger condition once, across 52 of my runs. It is a fourteen-minute concept lecture that lays out a lineage of LLM techniques — prompt → context → loop → graph — and explains the last stage. The framing is clean, but counting its eight elements against my test-case pipeline, seven were already in the code, and the one I lacked — parallel execution — was the only real gain: re-analysing the logs of eight actual runs gave a median of 9.9 minutes per run.

What the video says

It is a pure concept lecture. Zero lines of code, zero live demos, zero framework names. Its spine is one hypothetical task — planning a market study — solved twice: (a) thrown whole at a single agent, and (b) split into a graph.

The part about the single agent’s limit is accurate. When planning, searching, interpreting and verifying sit in one box, all you learn is that the result was wrong — not where. That is where the case for splitting comes from.

It asks for a quantified completion condition on every node. At least ten competitors, market size must cite a source, at least twenty user comments. And it separates who decides by the nature of the decision — competitors ≥ 10 goes to code, “which market is more attractive” goes to the model or a person.

Pulling out a “don’t use this” slide is unusual. Don’t build a graph for something two tool calls would finish — structural complexity, debugging surface and cost all go up, and “tokens just melt.” Concept lectures rarely state the conditions under which their own subject shouldn’t be used.

What broke

It is not a new trend. Composing work from nodes, edges, conditional edges and state is the decades-old workflow-engine model, unchanged. The video itself concedes late on that “this pattern has always lived alongside developers” — but the title and opening sell it as a new buzzword.

The lineage story contradicts itself. The opening narration says each stage is a superset of the last; a later slide draws the opposite — concentric circles. The later one is right: a graph with bad prompts is still bad. Read only the opening and you get “prompts don’t matter now”, which is a misreading.

The loop/graph distinction isn’t an engineering one. The only support offered is naming — “something that keeps going round” vs “nodes and edges.” A loop is a graph with one backward edge, so the contrast doesn’t hold. The difference it was reaching for is whether control flow is implicit inside the agent’s head or explicit outside it — and that sentence never arrives.

The cost claim is self-contradictory. “Use less AI and save money” and “more agents means tokens just melt” land a minute apart. Both can be true, but it never says under which conditions, so the cost discussion goes nowhere.

And the failure modes of graphs are missing entirely. One line about “more places to debug” is all there is. Infinite retries, state bloat, partial failure and idempotency, and the fact that rolling back doesn’t refund what you already spent — none of the things that actually bite you while operating a graph.

Zero verifiable claims. No sources, no code, no runs. The only numeric assertion on screen is 5 AI nodes · $2.40 per run, with no model name, no token counts and no definition of “a run.” It is closer to an animation prop and cannot be cited as evidence.

Held against my own setup

Node splitting, state passing and per-node code rules were already there in a different shape. State isn’t one object, it is a file contract — thirty kinds of json accumulate in the work folder and the next node reads only those. Per-node rules are four gates called eight times in a run. That is exactly the spot where the video says “competitors ≥ 10 goes to code.”

Generate ↔ evaluate is busiest on my side. Chunk retries, column-violation corrections, one gate-correction round, lens-output verification retries — 36 of 52 runs actually fired one.

But the thing the video calls the heart of a graph, I don’t use. “Write into the graph, in advance, which node to return to when verification fails” — in my logs that condition fired once in 52 runs. The reason is plain: my pipeline corrects in place instead of going back. Go back and everything the earlier nodes already spent is gone — which is precisely the failure mode the video never covers.

The one left over was parallel execution, and I measured it. The adversarial review stage was running three lenses in sequence; re-analysing eight real runs shows switching to parallel saves a median of 9.9 minutes per run. That is 8–9% of total run time.

Verdict

What	Verdict
Parallel execution	adopt. The only net gain with measured evidence — 9.9 minutes a run
Node split · state passing · per-node code rules	already have it. Different shape, same place
Generate ↔ evaluate	already have it. Busier on my side
Human approval gate	already have it
Conditional jump-back edge	rejected. Fired once in 52 runs. Going back throws away what was already spent
Router · single state object	rejected. The file contract already occupies that slot
Citing the video as evidence	⛔ don’t. No sources, no code, no runs, one number with nothing behind it

The lesson I paid for here: a concept being right and a concept being worth something to me are different questions. All eight elements were conceptually sound. But seven were already there, the one it emphasised most was dead in my logs, and the actual gain sat in the one it mentioned in passing.

And that difference is never visible at the level of concepts. It only appears when you re-read 52 runs of logs. Had I read someone’s tidy summary and stopped at “we should do this too”, I would have spent time building a feature that fires once and missed the one worth 9.9 minutes.