Three months of debugging after AI "finished" SENU

AI wrote SENU in roughly seven days. SSH client, encrypted chat, log viewer, file browser — the lot. The demo worked. Connections opened, messages sent, files listed. I shipped a build and almost wrote a blog post about how fast the future got.

Then I tried to use it.

What actually broke

The SSH session died on every reconnect. Looked fine in the logs, looked fine in the code. The root cause was that we were caching the channel object across reconnects, and the new TCP socket got a stale ChannelId. Nothing in the AI's generated tests covered "what happens when you suspend your laptop for 20 minutes."

The X25519 + AES-GCM chat occasionally scrambled message order during rapid send. Three messages in 80ms and the third would arrive before the second. The handler used a single mutex on the deserialisation step but had no ordering guarantee at the network layer. AI patched it twice and twice it came back. I fixed it by making the sequence number part of the encrypted payload and dropping anything that arrived out of order.

The log viewer kept the whole file in RAM. A 700MB nginx access log brought the process to 4GB resident. The fix was a windowed reader streaming through a ring buffer, but to write that correctly you have to know what "back-pressure" means, and the AI confidently does not.

What I actually learned

AI doesn't see what's broken. It sees what you tell it is broken. The work is not "ask AI to write a terminal" — the work is saying no, that's not it two hundred times and knowing exactly why each time.

The leverage is real. I would not have shipped a Tauri + Rust app in seven days without it. But the leverage compounds on top of judgement. Without the judgement, you ship a beautiful demo that crashes when a real user opens it.

You can't outsource taste. You can outsource typing.

SENU is in beta now and I trust it on my own server. That sentence took three months past the "AI is done" mark.