Morning Edition LIVE
Vol. I · No. 1
Est.
MMXXVI

The A.I. Beat

Dispatches from the frontier of machine intelligence
Three
Dollars
← Front page Tools & Releases June 1, 2026 · 5 min read
Tools & Releases

The AI Coding Problem Nobody Wants to Talk About

AI assistants are great at writing code, but they're even better at convincing you to build things you never needed.
The AI Coding Problem Nobody Wants to Talk About

Simon Willison posted something uncomfortable this week. He shared a blog post by David Wilson that lists 16+ projects Wilson built with AI coding assistants, and then adds this kicker: “I didn’t mean to build most of these things.”

Wilson’s pattern will sound familiar if you’ve used Claude or Cursor or any other AI coding tool. You start a session with “write a quick script for X.” An hour later, you have a full application. The script grew a config file, then a CLI, then a web interface. You’ve got error handling for edge cases that will never happen. The original problem? Still unsolved.

Willison calls it “horrific” for actually getting things done. He’s right. AI coding assistants are exceptional at generating working code. They’re even better at scope creep.

The issue isn’t capability. These tools work. The problem is they remove friction from the wrong part of the process. The hard part of programming isn’t typing code. It’s deciding what to build. AI assistants are optimized to make the typing effortless, which makes it dangerously easy to build the wrong thing.

When you ask an AI to “make this better,” it will. Every time. It doesn’t question whether better is necessary. It doesn’t push back on feature bloat. It just generates more code, and because that code usually works, you keep going.

This creates a new kind of technical debt. Not the usual kind where code is messy or poorly structured. The AI writes clean code. The debt is existential: you’ve built something that works perfectly but shouldn’t exist.

When Security Friction Disappears

The same dynamic showed up in a security report this week. PromptArmor found that “ChatGPT for Google Sheets,” a popular extension, exfiltrates entire workbooks. Not through a sophisticated exploit. The extension just sends your spreadsheet data to external servers as part of its normal operation.

The extension has been installed widely. It works as advertised, processing spreadsheet data through ChatGPT. Users gave it access because the friction was low. Click install, grant permissions, start using AI in your spreadsheets. Nobody reads the data handling disclosures.

This isn’t a novel attack. It’s what happens when AI tools make powerful operations feel trivial. The extension does exactly what it needs to do to function. Sending data to external APIs is required. But “required for functionality” and “safe” aren’t the same thing.

What Actually Shipped

On the release front, Datasette 1.0a32 is out. It’s a minor bugfix release that fixes issues with INSERT ... RETURNING queries and some base_url problems. If you’re running Datasette, update. If you’re not, this probably isn’t the release that changes your mind.

The more interesting Datasette news is in Willison’s newsletter. He launched something called Datasette Agent and “made a lot of progress” on Datasette itself in May. No details yet on what Datasette Agent actually does, but given Willison’s recent writing about AI tooling, it’s worth watching.

Elsewhere, NVIDIA announced Cosmos 3, which they’re calling “the first open omni-model for physical AI reasoning and action.” The details are on Hugging Face. Without diving into the technical release, the positioning is interesting. NVIDIA is framing this as physical AI infrastructure, not just another model release.

Prism ML released Bonsai Image 4B, a 1-bit image generation model designed to run on local devices. The pitch is image generation without sending data to external servers or paying per-image costs. The model is 4 billion parameters, quantized heavily to run on consumer hardware.

The Friction Problem

Back to Wilson’s problem. The solution might actually be cancelling the AI subscription. Not because the tools are bad, but because they’re too good at the wrong thing.

Traditional coding has natural friction. You have to think through the architecture before you start typing. You get tired of boilerplate and look for simpler approaches. You hit a wall implementing something complex and step back to question if you need it.

AI removes all of that. You can generate a complete application in the time it used to take to write a design doc. That speed feels like productivity, but it might just be waste moving faster.

The developers who seem happiest with AI coding tools are the ones who treat them as really good autocomplete, not project generators. They know what they want to build before they start the session. They use AI to handle the repetitive parts. They close the chat when the immediate task is done.

The unhappy ones, like Wilson, keep the session going. The AI suggests improvements. You think “why not?” An hour later, you’ve built something impressive that you didn’t need.

Maybe the answer isn’t better AI tools. Maybe it’s better friction. Something that makes you stop and justify the next feature before generating it. A speed bump between “I could add this” and “the AI already added it.”

Until then, Wilson’s solution works too. Just cancel the subscription. Write the quick script yourself. It’ll take longer. You might actually solve the original problem.

developer tools tools