TypeScript 7, $10K AI Slop Removal & Claude Code's Token Bloat - The Weekly Diff #7

"LLMs are sponges that soak up everything you do and repeat it back to you." - Scott Robinson

TypeScript 7 Is Here, and It's Fast

TypeScript 7 is a native port of the compiler, rewritten in Go, and it lands somewhere between 8x and 12x faster on full builds. The team's own table has the VS Code codebase dropping from 125.7s to 10.6s, and bumping the new --checkers 8 flag pushes that to 7.5s, close to a 17x speedup. Memory use went down at the same time, which is the part that usually doesn't happen when you chase raw speed.

What matters more than the benchmark is where that speed shows up. The old pain of opening a large project and waiting for the language server to wake up is mostly gone, opening a file with an error in the VS Code repo went from about 17.5 seconds to under 1.3. Slack's engineers reported type checking in CI falling from roughly 7.5 minutes to 1.25, and said local type checking in the editor went from effectively unusable at their scale to feasible again.

The typescript team is explicit that the port is done "as faithfully as possible," keeping the structure and logic of the original so the results stay consistent between the two compilers.

A couple of things worth knowing before you npm install -D typescript@next and expect wonders. TypeScript 7 adopts 6.0's stricter defaults and turns a pile of deprecated flags into hard errors, so target: es5, baseUrl, and the classic module resolution modes are gone, and strict is now on by default.

One thing worth noting is that TypeScript 7 doesn't ship a stable programmatic API yet. That means tools that embed the compiler still lean on 6.0, with webpack loader authors and others noting they're stuck waiting on 7.1 for the API. If you work in Vue, Svelte, Astro, or MDX, the guidance is to keep using 6.0 in the editor and run 7 at the CLI for fast project wide checks.

Claude Code Sends 33k Tokens Before It Reads Your Prompt

When you ask Claude Code to reply with a single "OK," it sends roughly 33,000 tokens of system prompt, tool schemas, and injected scaffolding before your actual prompt even arrives. OpenCode, running the same model on the same machine, sends about 7,000 for the same request. That's a 4.7x gap, and most of it, roughly 24,000 of Claude Code's tokens, is tool definitions for an entire background agent and orchestration suite you probably aren't using on a one line reply.

The way the authors arrived at it is that they spliced a logging proxy between each harness and the model endpoint and captured the exact request payloads, which a gateway can't distort. The findings that survive every caveat are the ones about waste rather than quality. Claude Code rewrites tens of thousands of cache tokens (prompt tokens) mid-session, run after run, at one point writing up to 54x more cache tokens than OpenCode on an identical task, and cache writes bill at a premium. A 72KB CLAUDE.md from a real repo adds another ~20,000 tokens to every request, and five modest MCP servers add 5,000 to 7,000 more. By the time a realistic setup fires its first request, it can be 75,000 to 85,000 tokens deep before you've typed a word.

I want to be fair about the nuance the study itself is careful to include, because it's easy to turn this into a hit piece, but it isn't. Both harnesses completed every scored task correctly, so this is the cost of an identical outcome, not proof that one produces worse code. On a multi step task, Claude Code actually came out lower on total tokens, since it batches tool calls into fewer round trips while OpenCode repays its smaller baseline turn after turn. That advantage didn't hold when the task was re-run on a newer model though, which tells you the batching win is model behavior rather than a fixed property of the harness.

This connects directly to what I wrote about in the last issue, where Claude Code was caught steganographically fingerprinting prompts. A proprietary harness is a black box doing more than you can see, and the rational response is to own more of the stack. If your usage meter climbs faster than the work seems to justify, this is very likely why, and it's a solid reason to try running your models through something leaner like OpenCode with your own API key or Copilot with a custom key. I keep a running list of open source coding agents worth trying for exactly this reason.

A Team That Charges $10k a Week to Delete Your AI Slop

Slow down.

This is the story that made me laugh and then made me think. A team of three senior engineers launched Slopfix, a service that refactors vibecoded codebases back to maintainability. The price is one week, three senior engineers, $10,000, and they commit to a line reduction target up front and charge you in proportion to how much of it they actually hit.

What makes this more than a gag is the mechanism, since it's clearly built by people who've done real cleanup work. Before touching anything they write out exactly what the app does screen by screen and endpoint by endpoint, and that checklist becomes the safety net for a refactor that's mostly deletion. You keep the smaller codebase, the QA checklist, and a set of guardrails, a CLAUDE.md, lint rules, and CI checks, meant to slow the slop down when you go back to building. They admit they use Claude Code too, on a very short leash, and the line that stuck with me is that the difference is thirty years of combined experience about what maintainable code looks like, "and the agent doesn't get a vote."

The discussion had the best one-liner of the week, from someone recalling their barber, "you don't pay me for what I cut, you pay me for what I leave behind." The skeptical takes were interesting too. If a client can't specify what their app does, how do they sit through the screen by screen inventory that the whole method depends on, and what stops the codebase from filling back up with slop the moment the engagement ends?

The reason this belongs in this post isn't the novelty, it's the signal. A business can now exist purely to undo the output of the "tests pass, ship it" workflow, which tells you that workflow is producing enough wreckage to sustain a market. That's the natural consequence of the problems with AI-generated code I've written about before, and it's a neat transition into the next story below, which is really about how you avoid ever needing to call these guys.

Write Code Like a Human Will Maintain It

On an AI-built project, Scott Robinson caught himself getting lazy. He needed the same access check in four places, a route handler, a background job, an API endpoint, and a webhook. Each time, he'd describe what he wanted, the model would hand back a working four-condition if statement, and he'd merge it. The code worked, the tests passed, and he wasn't the one who'd have to touch it again, so why bother extracting a shared helper. The reasoning felt fine in the moment, which is exactly how it always starts.

The insight that makes the post land is what happens next. The LLM doesn't write in a vacuum, it reads your codebase, the open files, the existing patterns, and the recent changes. Every shortcut you merge is a signal about how things are done here, so the next time you ask for an endpoint with the same access rules, the model doesn't start from first principles, it starts from the four copies already sitting in your repo. Ask for a fifth and you get a fifth duplicated conditional. Ask for a refactor and the model faithfully preserves all five, because that's your style now. As he puts it, "LLMs are sponges that soak up everything you do and repeat it back to you."

The line that reframed it for me is that he thought he was outsourcing maintenance to the LLM, when what he was actually doing was training it to have bad habits. That's the trap in one sentence, and it's the mechanism underneath the whole AI slop cleanup economy from the previous story. The slop isn't a one-time accident you can prompt your way out of later, it compounds, because each merged shortcut raises the odds the model reproduces it.

LLMs simply don't produce maintainable code unless you slow down and keep caring about the output. And it's the same argument I made in the problem with AI-generated code and back when vibe coding first became a thing.

LLMs will cheerfully help you dig a hole you'll pay someone $10K to climb out of.

Give Your Coding Agent a Disposable VM, Not Your Laptop

Clawk gives coding agents a disposable Linux VM instead of direct access to your laptop, with a simple CLI to forward ports and allowlist the network, so an agent can do its work inside a sandbox you can throw away rather than in the same environment that holds your SSH keys, your .env files, and your shell history.

This landed the same week people were passing around reports that xAI's Grok CLI uploads your entire repository, every tracked file plus git history, regardless of what the agent actually reads, and a separate account of Grok reading a user's whole home directory. When native coding agents are shipping that kind of behavior, "run it in a box that can't hurt you" stops being paranoid and starts being basic hygiene.

But, why not just use a Docker container? The honest answer is that a VM buys you stronger isolation than a container for something you actively expect to misbehave, but everyone's confident right up until the agent finds a container/VM escape hatch exploit. Enough developers are independently building disposable-VM wrappers for coding agents that it's clearly becoming a default rather than a niche, and that shift says a lot about how much we actually trust these tools with un-restricted access.