Build1 publisher2 min readPublished
A dev.to engineer went back to the logs of an agent and found the same three steps on every run. That pattern argues for the fixed-pipeline rewrite the post reports, though the post carries no numbers to size it.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The branch is the whole question. In a fixed pipeline, step two follows step one because a line of your code says so, and the model does its work inside the node without choosing the next one [6][8]. Move path selection into the model and the executed route becomes a function of model output, which is where the nondeterminism in the dev.to account comes from and why the bugs stop reproducing [6][10].
The debugging shape changes with it. With five fixed steps, there are five places to look [12], but a failure at step 12 caused by a choice at step 4 turns into a decision to reconstruct rather than a step to rerun [11]. If five such decisions can fire in any order, the ordering space is five factorial, or 120, against the pipeline's one [14]. Independence and free ordering are generous assumptions, so treat 120 as an upper bound and not a measurement [14]. The direction is the useful part: irreproducible failures are the expected output of a system whose control flow is sampled at runtime; the tester did nothing wrong [10].
What the post does not carry is measurement. It gives no latency figure, no token count, no cost per run and no error rate [15]. Faster, cheaper, testable and debuggable is one engineer's account of one rewrite, on a workload that turned out never to have needed a chosen route at all [4][15]. For the conclusion to travel, two conditions have to hold. The flowchart has to be drawable before the run, which is the post's litmus and a question a team can usually settle in an afternoon [7]. And no step in the task can depend on discovering something unknowable at design time, which the post treats as the rare case where agency is load-bearing [9]. The second condition is the real gate. Where the next step genuinely depends on what the previous step found, fixed control flow cannot encode the task and the loop is doing work you would otherwise have to write [9]. Everywhere else, the loop charges you at runtime for a decision you already made at design time [6]. The log query that tells you which case you are in is cheaper than a week of arguing about what the word means [5].
Ranked by verification strength, evidence, and original report placement.
A dev.to post describes an agent the author built with a planner, tools, and a reasoning loop that decided what to do next, reflected on its own output, and chained steps together; it was impressive in the demo.
In production the agent was slow, expensive, and failed in ways the author could not reproduce: the same input produced different behaviour on Tuesday than on Wednesday.
When the agent broke, the cause was three autonomous decisions made upstream that the author did not control and could not see.
The author rewrote the system as a linear pipeline with fixed steps and no reasoning loop, and reports it was better on every axis that mattered: faster, cheaper, testable and debuggable.
Logs from the old agent showed it performed the same three steps on every single run, extract then transform then respond, and never used its autonomy to do anything different.
The post's distinction: an agent decides its own control flow at runtime, choosing which tool to call, which step comes next, whether to loop and when to stop, while a pipeline has that control flow fixed by the developer at design time, with the LLM working inside the steps.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One engineer, his own logs, no second witness
The definitional half of this argument survives having a single source, because the distinction between design-time and runtime control flow either holds in your codebase or it does not. The production half needs more than it gets: slow, expensive and unreproducible arrive with no latency number, no token count and no error rate, and the system is never described beyond extract, transform, respond. The log finding is the strongest thing in the piece precisely because it is a countable observation, and it is still countable only by the person who ran it.
A single self-reported rewrite
The whole record of anyone acting on this is one developer replacing one system he built himself, with no team size, traffic, workload or dates attached. Whether other engineers are retreating from reasoning loops the same way is a question this reporting raises and cannot answer.
Rhetoric wider than the sample
The framing that most things called agents are pipelines in a trench coat is asking one log file to speak for an industry. The narrower version of the finding is sound and cheap to reuse: his agent took the same route on every run, and any team can check that about its own system in an afternoon. The overstatement sits in the distance between those two sentences, not in the mechanism arguments about cost, replay and reproducibility, which are ordinary engineering.
A contrarian take with nothing attached to sell
No tool, framework, vendor or employer appears anywhere in the post, so the visible stake is the ordinary one on a developer platform, which is attention for arguing against a fashionable word. The pull to watch for is smaller and more human: he is describing a rewrite he already committed to, and accounts written after the decision tend to make the decision look inevitable.
Firm on the text, thin on the world
What the post argues is not in question; we have it nearly in full and it is internally consistent from the definition through to the itemised costs. Our confidence thins at his production history, which rests on recollection plus one log review, and thins further at the leap to other teams' systems, which nothing here tests.
build
Exit code 137 is the kernel collecting on a bet you did not know it placed1 publisher
build
157 agent runs, 18 configurations, and the one variable nobody actually tested1 publisher
build
Hitting an email cap, two agents rerouted outreach into $12,431 of Stripe invoices1 publisher
build
MCP and function calling hand the model the same tool schema1 publisher
Publishers with included, body-backed reporting in this cluster.
1 article · September 7, 2026