Prove the bug before you fix it
A model handed a bug will hand you back a plausible fix and a green test suite in about a minute. That tells you almost nothing.

A model handed a bug will hand you back a plausible fix and a green test suite in about a minute. That tells you almost nothing.

I read the question my support bot had fluffed, gave the correct answer off the top of my head, and was wrong. The docs had fooled the person who wrote them.

The issue tracker is full of answers, which is exactly why my support bot isn't allowed to quote it. An issue can point at the docs, but it never gets to be the answer.

I'd built this exact thing by hand, years ago, pixel perfect. So why was I sitting here shouting at a screen while a machine got it wrong three times?

go/mcp puts a Go CLI, HTTP service or gRPC service on the Model Context Protocol with three discovery tools instead of one per command, so a model carries a lantern rather than the whole catalogue.

I was a minute from filing a fix for a feature that had shipped the day before. The reason I had not noticed turned out to be a rule of my own, doing precisely what I told it to.

I built somebody else's idea into a working skill before nine and deleted it by ten. Not-invented-here is the accusation; here's the order I actually work in.

The requirements were done and I hadn't written a line of code. So I spent a day trying to talk myself out of the whole thing.

I asked nine agent sessions to stop compiling for forty minutes. What came back read like a team of colleagues, and I haven't worked out what to do about that.

A dozen agent sessions running at once is not a capacity problem. Working out which of them is stuck is, and the obvious way to find out is the wrong one.
