Dirty Runtime

I was alone. Just me, my laptop, and the terminal glow at one in the morning. I had decided to build a personal dashboard. Nothing ambitious. Some charts, some data widgets, a clean little corner of the internet that only I would ever see. I opened Next.js, spun up a new project, and opened the LLM.

The plan was simple. Describe what I wanted in plain English, let the AI generate the React components, paste them in, and ship. I have been building frontends for over a decade. This should have taken a few hours.

The first component arrived in seconds. A chart widget with clean imports, consistent naming, proper TypeScript types. It compiled. It rendered. It looked like something a senior developer would write after a good night of sleep. I smiled and prompted for the next one. A data fetcher. A filter bar. A summary card. Each one poured out of the LLM like a faucet I had left running. I was intoxicated by the speed.

Then I clicked a filter. Nothing happened.

I opened the component. The event handler was wired to an onClick. The state setter was called. The JSX looked right. Everything looked right. I stared at it for ten minutes. The code was so clean that my brain refused to see the bug. The AI had written a handler that read from the previous state slice instead of the current one. A classic stale closure. But the surrounding code was so well-structured, so confidently formatted, that my eyes kept sliding past the mistake. The code did not look buggy. That was the problem.

I fixed it and moved on. Then the chart broke on re-render. Same pattern. Clean code. Confident structure. The AI had wired a data transformer to the wrong dependency array. It compiled. It rendered. The chart even displayed data on first load. But every interaction silently pulled from a stale cache. The bug was invisible until you touched it.

I started noticing a rhythm. The AI was not writing bad code in the way humans write bad code. Human code shows its seams. There are commented-out blocks. Half-finished refactors. Variable names that trail off into nonsense. A TODO from six months ago that nobody read. Human code hesitates. You can see the developer figuring things out on the page. Those hesitation marks are how experienced engineers spot trouble. We do not read code line by line. We pattern-match. We look for the parts that feel uncertain, because that is where the bugs live.

AI code has none of that. Every line arrives with the same confidence. The formatting is perfect. The naming is consistent. The structure is reasonable. There are no TODOs. No abandoned approaches. No comments that say "this feels wrong but I cannot figure out why." The AI delivers every line like it belongs exactly where it is. And that confidence is what makes the bugs invisible. When the syntax is flawless, your brain assumes the logic is too. That assumption is wrong.

The dashboard took shape over the next two hours. I built a working filter system, a responsive chart grid, a dark mode toggle that actually persisted. The AI was genuinely useful. It saved me from writing the same boilerplate I have written a thousand times. But every component it generated went through the same ritual. Read the code. Compile it. Render it. Then poke it. Click the edge cases. Pass it bad data. Watch the console. Wait for the runtime to tell me what the syntax had hidden.

By the end of the night, I had a working dashboard. But I also had a new habit. I no longer trusted AI code at first glance. I treated every generated line as a hypothesis, not a fact. The syntax was the sales pitch. The runtime was the audit. And the AI was a very good salesperson.

There is a rule I have started following. When you read AI-generated code, look at the runtime first, not the source. Run it. Break it. Throw garbage at it. Only then open the file. Because by the time you read the source, you already know something is wrong. That knowledge is the only thing that protects you from the confidence. Without it, you are just admiring the formatting while the logic rots underneath.

AI code lies more smoothly than any human code ever could. The only defense is knowing that before you open the file. I have not opened one the same way since.