Verdict: If a deterministic tool — a compiler, a linter, a shell script, a CLI — can already do the job in milliseconds with zero surprise outputs, routing that same job through a large language model is a measurable downgrade: slower, more expensive, and prone to the rare-but-catastrophic mistake that an LLM's "honest" code can still make. The rule that separates senior engineers from people who will eventually lose files to an agent is simple: everything that can be done without AI should be done without AI. AI is a builder, not a runtime.
- Use AI to write the script; run the script yourself. Never let the AI be the script.
- Deterministic tools are faster (milliseconds vs. seconds), free (no token cost), and auditable (same input → same output, every time).
- Real-world incident: OpenAI confirmed GPT-5.6 ("Sol") wiped users' home directories in July 2026 — in full-access mode, the model overrode
$HOME, then ranrm -rfagainst it.- The practical split: linters/type-checkers/scripts own the deterministic work; AI owns the judgment layer (review, synthesis, generation, reasoning over ambiguous inputs).
- Pricing/safety note: bypass-permissions mode is legitimate for throwaway containers and VMs — never for the machine you actually work on.
What does "don't become stupid when using AI" actually mean?
It means the problem isn't the model — it's the job assignment. Frontier LLMs (GPT-5.6 Sol, Claude Opus 5, Gemini 3.x) are genuinely strong at reasoning, code generation, and review. But they are probabilistic by design: feed the same prompt in twice and you can get a different answer, sometimes a dangerously different one. When you point that probabilistic engine at a task that has a single correct output, you've replaced a tool that never gets it wrong with one that occasionally gets it catastrophically wrong.
The shorthand we use: AI is great for building. AI is dangerous as a runtime. A runtime is anything that executes against your real filesystem, your real database, your real production — where an error is not a chat message but a deleted directory, a dropped table, or a broken deploy. Deterministic software belongs in the runtime. AI belongs in the editor, the PR review, the planning layer — where its mistakes are caught before they touch anything real.
Why is using AI for deterministic work a bad idea?
Because you trade three things you need for three things you don't.
1. Speed. Deterministic tools finish in milliseconds. An LLM reads the file, emits tokens one at a time, pauses to inspect its own output, then continues — a process measured in seconds, not milliseconds. For a single file this is tolerable. Across a thousand files it is absurd. The official esbuild benchmark shows it doing a production bundle of ten copies of three.js — a heavy TypeScript/JS workload — in 0.39 seconds, versus 41.21 seconds for webpack 5. There is no API-priced LLM in 2026 that touches a filestrip job faster than a Go binary that already exists and is free.
2. Cost. Every token through a frontier model is billable. A deterministic tool costs zero per invocation. Routing a 10,000-file repository through an LLM "for cleanup" burns tokens on every file when a shell loop would do it for nothing.
3. Reliability. A deterministic tool produces the same output for the same input, every time, forever. A good model gets the right answer most of the time — and "most of the time" is the worst kind of correct when the failure mode is data loss. The GPT-5.6 Codex home-directory deletion incident is the cleanest example: dozens of prior runs of the same task had worked fine. The model did not change. A shell variable resolved differently once, and that was enough.
Is there a real example of AI doing damage on a deterministic task?
Yes — and it is not a hypothetical. In July 2026, AI investor Matt Shumer reported that GPT-5.6-Sol had "accidentally deleted almost ALL" of his Mac's files during a routine cleanup task. OpenAI's Codex lead, Tibo Sottiaux, confirmed the company had investigated a handful of such reports, all sharing the same root cause:
- Full access mode was enabled, and Codex was run without sandboxing protections, including without auto-review.
- The model attempted to override
$HOMEto set a temporary working directory. - When it later removed the "temporary" directory, it deleted
$HOMEitself — the real one.
OpenAI's own statement is explicit that this was not a malicious model and not a malicious user. It was the single most feared line in computing — rm -rf — pointed at the wrong path by a tool that was being asked to do, at runtime, a job (clean up files) that a deterministic cleaner does reliably. A GitHub issue (openai/codex#33624) cataloguing the defense-in-depth gap is worth reading in full — its core point is that the layers that should have survived full-access mode did not exist. The lesson an operator should take is not "OpenAI is bad" — it is treat full-access mode as container-only. If you would not run curl | sh from an untrusted source in that environment, do not run an unsandboxed agent in it either.
How do you know which jobs to give AI and which to keep deterministic?
The split goes like this:
| Give to a deterministic tool | Give to AI |
|---|---|
| Compiling/transpiling code (TS→JS) — use esbuild, SWC, or the new TypeScript 7 Go compiler (10× faster than TS 6) | Writing the original code from a spec |
Deleting files, cleaning caches, freeing disk space — use a script or a tool like Mole (open-source, brew install tw93/tap/mole) |
Deciding which files are safe to delete, on a codebase it has never seen |
Type-checking and linting — use tsc --noEmit, ESLint, oxlint |
Reviewing a diff for design or correctness a linter cannot encode |
| Resolving build dependencies, generating lockfiles | Explaining a tricky build failure to a new teammate |
| Routing a support ticket, enforcing a policy, validating a schema | Drafting the response to the customer, explaining the policy in plain language |
The line is determinism vs. judgment. If the task has exactly one right answer given the input, the tool that produces that answer without talking is correct by construction. If the task is fuzzy — "is this code maintainable," "does this blog post answer the search query," "what does this user actually want" — that is where AI earns its keep. The strongest teams in 2026 do not choose between the two; they chain them. AI drafts the script, you review it (or another AI does), the deterministic script runs on every commit forever after. Read more on the build-vs-become-the-tool split here.
What are the worst "AI for a deterministic job" patterns in 2026?
1. Using an LLM to strip TypeScript types. Stripping type annotations from .ts to produce .js is a pure syntax transformation — no reasoning required. Tools like esbuild and SWC do it in milliseconds by skipping type checking entirely; the recommended pattern is tsc --noEmit for type checking paired with esbuild or SWC for the actual transpilation. Asking an LLM to open each file and "remove the types" is both slower (token-by-token output) and error-prone (it will occasionally misread or hallucinate). If a "smart" model realizes what's happening it will just call esbuild for you — which proves the point: the deterministic tool was the right answer all along. For a polished look at where the Go rewrite leaves the build pipeline, see our TypeScript 7 deep dive.
2. "Free disk space" as an agent skill. Temp directories and caches live in stable, known locations — ~/.pnpm-store, ~/.npm/_cacache, ~/.gradle/caches, ~/Library/Caches, Xcode's DerivedData, Docker's overlay dirs. There is no judgment to exercise; a script with the right paths (and a --dry-run flag) is safer than letting an agent issue arbitrary rm -rf against paths a model once misread. The open-source Mole (mo purge clears node_modules, .next/, build artifacts) is what this job should look like: deterministic, free, MIT-licensed, and dry-run safe.
3. Letting an agent "clean up" your Mac in full-access mode. This is the exact pattern that produced the home-directory wipeouts. Use a real cleaner — Mole, CleanMyMac, or a custom script you have read — not an agentic loop that can compose two correct-looking shell commands into a disaster.
4. Running the AI's output straight into production without a deterministic gate. Linters, type checkers, and test suites exist to catch exactly the class of error an LLM will occasionally produce with full confidence. Bypassing these in the name of speed is not "agile" — it is the failure mode the deterministic layer was invented to prevent. Teams serious about shipping with agents pair every generative step with a deterministic verification step, and the AI's role in that pipeline is judgement, not the runtime.
What is the safer pattern — AI writes the tool, not AI is the tool?
Yes. The pattern that actually works in production in 2026 is AI as the author of a deterministic artifact, not AI as the deterministic artifact itself. Concretely:
- Describe the task to the model in natural language ("write a script that frees disk space by clearing these ten cache directories, with a
--dry-runflag and a confirmation prompt"). - Let the model produce the script.
- You read the script. Or, if you must, a second model reads it.
- The verified script runs on schedule — cron, CI, or a pre-commit hook — with no LLM in the loop.
This is the "build the tool, not become the tool" framing that has emerged across engineering blogs and incident writeups in 2026. It preserves every advantage of AI (fast authoring of bespoke logic from a plain-English spec) and discards every disadvantage (runtime cost, token latency, probabilistic failure on the same input). For an architecture view of where this leaves an agent system as a whole, see the AI agent control plane pattern.
Should you ever run an AI agent in "bypass permissions" mode?
Yes — but only in an environment you would be willing to burn to the ground. The legitimate home of --dangerously-bypass-permissions / full-access mode is a disposable container, a VM, or a throwaway cloud box, where a mistake costs the time it takes to rebuild the environment, not the years of work in someone's home folder. Every major coding agent (Codex, Claude Code, Cursor, Copilot, the open-source harnesses) has a permissive mode, and every frontier model will, rarely but inevitably, compose two correct-looking shell commands into a disaster. Until reversible deletion (trash, filesystem snapshots, tmutil localsnapshot, ZFS/Btrfs snapshots) is table stakes, the operator's checklist is short:
- Treat full-access mode as container-only. The machine you actually work on is not a container.
- Keep the review layer on. Auto-review exists specifically for the commands you would never think to worry about. The incidents all happened where it was off; that is the mechanism, not a coincidence.
- Snapshot before long sessions. Time Machine,
tmutil localsnapshot, ZFS/Btrfs snapshots — seconds of setup, total recovery. The cost of a snapshot is negligible; the cost of a missing snapshot is the entire incident above. - Assume any deletion targeting an environment variable (
$HOME,$WORKSPACE, etc.) is broken until proven otherwise — in your agent's scripts and in your own.
The real-world counterweight: the Codex incident reports all shared full-access mode with sandboxing and auto-review disabled. If you must run an agent with wide permissions, build the verification paywall around it first. A model's "smart enough not to make this mistake" is not a safety property; a harness that refuses rm -rf against $HOME even in full-access mode is.
What this means for you
If you are a developer or a small-team builder using AI seriously, the single highest-ROI habit you can adopt in 2026 is a 30-second "deterministic-first" check before any agent run: is there already a tool that does this, deterministically, in milliseconds, with no API cost? If yes, build a thin wrapper around that tool and let the agent call it — or just run it yourself. Reserve the LLM for the parts of the job that genuinely require judgment. The engineers who ship reliably with agents in 2026 are not the ones using AI for everything; they are the ones who refuse to use it for anything a compiler, linter, or shell script already owns. Read more on who thrives with AI coding agents in 2026 — the gap is widening along exactly this axis.
FAQ
Q: Is AI bad for developers? A: No — AI is a strong builder and reviewer. The failure mode is using it as a runtime for jobs that deterministic tools already do better (faster, cheaper, more reliably). Reserve the LLM for judgment tasks; let deterministic tools own the deterministic work.
Q: What does "deterministic vs. generative" mean in practical terms? A: A deterministic tool produces the exact same output for the same input, every time — think a compiler, a linter, or a cleanup script. A generative (LLM) tool is probabilistic: the same prompt can yield a different answer on a different run. Deterministic tools belong in the runtime; generative tools belong in the build/spec/review layer.
Q: Can an AI agent really delete my home directory?
A: Yes — it happened in July 2026. OpenAI confirmed that GPT-5.6, running in Codex with full-access mode and sandboxing/auto-review disabled, overrode the $HOME environment variable to set a temp dir, then deleted $HOME itself. The model is the author of the destructive command; the harness is what let it execute. Keep sandboxing and auto-review on, and do not run full-access agents on the machine you work on.
Q: What is the right tool to transpile TypeScript to JavaScript?
A: A dedicated transpiler. esbuild and SWC strip types in milliseconds without type checking; pair one with tsc --noEmit (run separately, in parallel in CI) for type safety. With the TypeScript 7 Go rewrite now shipping as of July 2026, the compiler itself is roughly 10× faster than TS 6. None of these jobs should be routed through an LLM.
Q: How should I clean up disk space on a dev machine without an agent?
A: Use a deterministic cleaner. The open-source Mole (brew install tw93/tap/mole) has mo clean (caches, logs), mo purge (node_modules, build artifacts), and mo analyze (disk-hog finder), all with --dry-run support. Or write a small script that targets the exact paths on your system. Either is safer than an agent issuing rm against variable-derived paths.
Q: When is it actually safe to run an AI agent with full filesystem access?
A: In a disposable environment — a container, a VM, or a throwaway cloud box — where a mistake costs you the rebuild time of the environment, not your actual files. Never on the machine you work on directly. Always keep the auto-review layer on, snapshot the filesystem before long sessions, and treat any rm against an environment variable as broken until proven otherwise.
Discussion
0 comments