Graph engineering

A 14-minute lecture on the latest way to give AI work. The feature it calls the heart of the method fired exactly once across 52 real runs of mine.

The four stages it describes

The lecture lays out how using AI has evolved.

Stage	What
1. Asking well	Thinking about how to phrase the request
2. Attaching material	Handing over the documents the question needs
3. Looping	Having the AI check and correct itself
4. Splitting the work into a layout	The subject of the lecture

The example for stage 4 is good. It gives “write me a market research brief” two ways.

• Throw it whole: one sentence, write me a market research brief
• Split into a layout: find competitors, research each, collate, review, and loop back if thin

Why the second is better shows up when something goes wrong. Thrown whole, a bad result gives you no idea where it went wrong. Split up, you can see which box failed.

But this is not a new trend

The title and opening sell it as a new buzzword. It is not.

Splitting work into boxes and routing between them on conditions is decades old. Only the name is new.

The entertaining part: the lecture admits this in its second half. It calls it a pattern that has always lived with developers. Sold as new at the front, conceded at the back.

Held against mine — seven of eight were already there

I pulled out the eight elements it names and matched them one by one against my own pipeline.

Seven were already in code. They just looked different.

For instance the lecture says put the information passing between boxes into one state object. Mine is not an object, it is files. Results accumulate in a working folder and the next box reads only those.

Same job, different shape. So counting it as absent would be wrong.

The feature it stressed most was dead in my logs

The lecture calls “loop back to an earlier stage when a condition fails” the heart of it. Conceptually it is fine.

I opened 52 real runs of mine and counted how often that condition fired. Once.

So I rejected it. Two reasons.

1. It almost never fires — once in 52
2. Looping back throws away the cost already spent — you redo work already done

“Conceptually correct” and “worth it to me” turned out to be different questions.

The real gain was in something the lecture mentioned in passing

There was exactly one thing I did not have: run unrelated work at the same time.

The lecture does not dwell on it. Re-analysing eight of my own runs, it came to a median of 9.9 minutes saved per run.

	Emphasis in the lecture	Measured gain for me
Looping back	Called the heart of it	Fired once in 52 runs
Running in parallel	Mentioned in passing	9.9 minutes per run

Exactly inverted.

I do not cite this lecture as a source

That is not to say the content is wrong. It is simply not a citable source.

• Zero sources — never says where any of it comes from
• Zero lines of code — never shows how you would build it
• Zero live demonstrations
• One number, with no basis

Good for getting the concepts arranged in your head, useless as grounds for a claim. Those are different jobs.

What this piece cost me

“The concept is right” and “this benefits me” are different questions.

All eight elements were conceptually sound. And yet seven were already there, the one it stressed most was dead in my logs, and the real gain sat in the one it mentioned in passing.

That verdict is unreachable without opening 52 run logs. Watching the lecture and saying sounds good, let’s adopt all of it would have meant building machinery for something that never happens.

The detailed record starts here

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.