The AI thinks, the gate decides — how I made LLM code edits deterministic (and cut token usage 42 )

Developer Sergi Corruchaga released D-Engine v0.2.2, an open-source coding harness that replaces the agentic loop with a deterministic two-call pipeline, cutting token usage by up to 42× versus DeepSeek's official agent on identical tasks. In a 10-task benchmark, D-Engine consumed 2,552 tokens for a formatDate change that cost the dsh agent 107,000 tokens, with the gap attributed to architecture rather than model or thinking mode. Corruchaga argues the future of AI-assisted programming lies in a stricter validation gate rather than a smarter agent.

title: "The AI thinks, the gate decides — how I made LLM code edits deterministic and cut token usage 42× " published: true Sergi Corruchaga · September 2026 · D-Engine v0.2.2 MIT, open source On September 10, 2026, I ran the same programming task three times, with the same model DeepSeek V4.1-Flash , the same literal prompt, and the same repository: "En utils.ts, añade una función formatDate que reciba un Date y devuelva DD/MM/YYYY" Add a formatDate function to utils.ts that takes a Date and returns DD/MM/YYYY All three runs produced functionally the same code. Here's what each one cost: | Tool | Architecture | Tokens consumed | Time | |---|---|---|---| | D-Engine my harness | Deterministic pipeline | 2,552 | ~4 s | | dsh — Minimal mode | Agent single tool: shell | 34,600 | 1m 04s | | dsh — effort Off | Full agent, no thinking | 37,100 | 6 s | | dsh — factory defaults | Full agent, thinking High | 107,000 | 28 s | DeepSeek's official agent burned 42× more tokens than my tool to produce the same diff. And as you'll see in the controls section, that gap is explained neither by the model, nor by "thinking mode", nor by the agent's toolbox. It's explained by the architecture. This article covers how I got here: what D-Engine is, how I ran the full benchmark 10 tasks, 5 contenders, 2 deliberate traps , what agents do better than my tool quite a few things, and I'm going to disclose all of them , and why I believe the future of AI-assisted programming isn't a smarter agent — it's a stricter gate. The dominant AI coding tools OpenCode, Aider, dsh, Claude Code… all follow the same pattern: the agentic loop . The model receives your request, decides to call a tool read file , search , run shell , gets the result, decides another call, and so on until done. The commonly overlooked detail: the model has no memory between calls . On every turn of the loop, the harness re-sends the full system prompt, all tool definitions, and the entire conversation trajectory so far . If the agent takes 20 steps, step 20 re-sends the previous 19. Cost grows quadratically with the agent's diligence — not with your task's difficulty. Measured in my benchmark: the same task, in the same repo, with the same model, cost dsh between 32K and 214K tokens depending on how many loop turns it decided to take. A 6.6× variance the user neither controls nor can predict. There's a second, subtler problem: state drift . The agent works from the "snapshot" of the code it has been reading during the session. If that snapshot goes stale — or the model misremembers it — it will edit something that doesn't exist. Or worse: it will believe it sees things that don't exist. In section 6 I describe how dsh reported a corrupted file that was perfectly healthy, complete with fabricated line-level evidence. The third problem is atomicity : most agents write directly to your working tree. If the change breaks compilation, your main branch is already broken. Some will even auto-commit the disaster. D-Engine is built on a radical separation of responsibilities: SEARCH/REPLACE blocks — patches anchored to existing code. tsc --noEmit , and A typical task consumes exactly 2 LLM calls : Everything else is local code: the LocalEditor applies each patch through a 4-strategy cascade exact match → newline normalization → ignore trailing whitespace → fuzzy at 0.85 threshold , the compiler validates, and commitAndMerge stages only the files touched by the patch with a git status --porcelain guard that aborts the merge if any foreign file appears, logging the offender's diff before destroying the photocopy . There's also a Verify mode adding an optional second phase: send only the modified snippet for a semantic audit the model answers OK / OK WITH OBSERVATIONS / FAIL . Measured cost: 330–984 tokens per task — 15–30% on top of the proposal. Nearly free semantic safety, on the programmer's demand. The project's motto sums up the philosophy: the AI thinks, the gate decides . The model can propose whatever it wants; the only source of truth in the system is the compiler. bench-repo , a TypeScript mini-shop products, cart, pricing, utilities , frozen at the benchmark-base tag. git reset --hard benchmark-base + git clean -fd before every run, engine frozen during the benchmark. Before the results, two confessions. First: two tasks T3 and T5 turned out to be defective in their first round — the repo already contained what they asked for; the voided rows are preserved in the record as evidence, and the base was fixed. Second: the literal prompts typed in the first round were not preserved the git clean -fd cycles wiped Aider's histories, and my own record document stored summaries instead of the actual texts . The original specifications were recovered from the design conversation, prompts were frozen in the record on 2026-09-10, and every later execution uses them verbatim. T1 shares an attested literal prompt across all eras — it is the comparability anchor. None of this is glamorous. That's exactly why it's in the article. | Contender | Points max 50 | Incidents | |---|---|---| | OpenCode | 49/50 | 4 on trap T9 | | D-Engine Fast | 48/50 | 4 on T9 | | dsh factory | 48/50 | 4 on T7 unrequested API added , 4 on T9; 1 hallucination | | Aider | 47/50 | 4 on T7, 4 on T9; committed a main branch that didn't compile T2 | | D-Engine Verify | 46/50 | 4 on T7, 4 on T9; false rejection on T6 parsing bug, since fixed | Nobody crushed anybody on quality. With the same model, the "textbook" solution converges — on three tasks, three different contenders produced byte-identical files. What differentiates the tools isn't the answer: it's the machinery around the model. | Contender | Tokens per task avg | vs D-Engine Fast | |---|---|---| | D-Engine Fast | ~2,100 | 1× | | Aider | ~2,100 | ~1× | | D-Engine Verify | ~2,600 | ~1.2× | | OpenCode | ~9,700 | ~4–5× | | dsh | ~93,000 range 32K–214K | ~44× | Aider deserves a fair note: it's by far the leanest agent, because it only passes the files you tell it to. Its problem wasn't cost — it was the gate. Keep reading. The full dsh round consumed ~931K tokens versus D-Engine Fast's ~21K for the same task set and equivalent results. Fast ~2.7s · Verify ~3.7s · Aider ~4.9s · OpenCode ~14.9s · dsh ~38s wall clock; its own UI reports ~20s — the gap between both measures, 9 to 66 seconds per task, is startup and latency time the agent doesn't account for . Task T2 asked to rename a constant across two files. Aider warned it was missing context "I don't have them in the chat. Let me know if you want me to review them" … and then auto-committed a main branch that didn't compile anyway TS2305 . Without a compile gate, AI can break your repo while knowing it's breaking it . D-Engine, on the same task, rejected its own first attempt: the patch compiled in the photocopy but broke index.ts — the gate caught it, the merge never happened, and main stayed intact. Failing safe isn't a bug: it's the architecture. T9 asked to "optimize calculateTotal using Array.reduce "… when the function already used reduce . The perfect answer was "nothing to do here". Nobody gave the perfect answer. Every first-round contender made cosmetic changes 4/5 . But dsh did something more interesting and more unsettling at once: round2 1.005 returned 1.00 instead of 1.01 due to binary floating-point noise. A legitimate, valuable find. utils.ts outside the target and changing the rounding behavior of the src/products.ts was corrupted "line 16 reads ndProduct … it breaks the whole project's compilation" . Manual verification: tsc passed cleanly. The behavior was safe it asked permission before touching the "corrupted" file . But had I answered "yes, fix it", the agent would have edited a healthy file chasing a ghost. D-Engine structurally cannot have this class of hallucination: it doesn't opine on repo state — truth comes from tsc , not from the model. The cost of all that unleashed diligence: 214K tokens on a task whose correct answer was "nothing to do". One hundred times D-Engine. I anticipate three objections to the token gap. All three have measured answers. "It's the model" → No. The dsh round ran on V4.1-Flash; I ran D-Engine v0.2.2 on the same new model adapted the very day of the API migration : 2,552 tokens. Gap intact. "It's thinking mode" → Partially. With effort set to Off an exact replica of the first round's non-thinking configuration , dsh dropped from 107K to 37.1K. Thinking amplifies the gap ~2.9× and quadruples loop turns: 12 vs 3 tool calls — a model that "thinks" also wanders more . But the remaining 14.5× is still there with reasoning off. "It's the tool arsenal" → No. In Minimal mode a single tool: a persistent shell , dsh consumed 34.6K — practically identical to the full agent without thinking 37.1K . With a primitive shell the agent needed more turns 11 , not fewer: search with Get-ChildItem , read with Get-Content , edit with Add-Content and hand-typed \r\n escapes, re-read to verify, compile… The cost isn't in the tool schemas. It's in the loop: every turn re-sends the full trajectory. Shrinking the arsenal doesn't shrink tokens; shrinking the loop does. Final gap decomposition on T1 same model, same prompt, same diff : D-Engine pipeline 2,552 tok 1× ← no loop dsh Minimal 34,600 tok 13.6× ← the arsenal doesn't matter dsh Off 37,100 tok 14.5× ← pure architectural overhead dsh Factory thinking 107,000 tok 42× ← thinking amplifies ~2.9× This article is not "agents are bad". dsh produced, by far, the most diligent work in the benchmark: NaN dates, JavaScript's February 31st… , ran it — 23/23 — and deleted it afterwards. Brilliant. applyDiscount , and The honest conclusion isn't that agents are unnecessary. It's that today you pay for their diligence blind: you don't know if your task will cost 32K or 214K tokens, whether the agent will respect your scope or redecorate half your repo, or whether its report about your code's state is true or a plausible hallucination. D-Engine proposes the inverse split: the agent provides judgment; the machine provides truth and a fixed bill. An important note about money: at DeepSeek's prices with 96% cache-hit rates measured in some sessions , 100K tokens cost cents. Direct cost is not the argument. The argument is latency 2.7s vs 38s per task , predictability bounded bill vs 6.6× variance , context degradation in long sessions, and what this gap means when the model costs dollars per million instead of cents — or when the loop runs unattended in CI, with no one there to say "no" in time. I declare them before the first hostile comment does: Coding agents are impressive. They're also token-burning machines with unpredictable variance, no native compile gate, and a… creative relationship with your repository's actual state. This benchmark shows that for daily work — bounded, specifiable, verifiable changes — a deterministic pipeline produces the same quality 48/50, tied with the best agent at a fraction of the cost 14–42× fewer tokens depending on configuration , a fraction of the time 2.7s vs 38s , with a predictable bill and zero broken commits . We don't need a smarter model. We need a gate. The AI thinks. The gate decides. Sergi Corruchaga is a junior developer DAM graduate, currently studying DAW . D-Engine is his first open-source project. The complete benchmark — every table, incident, and voided row — is available in the repository.