Posts about AI coding tools mostly say one of two things. Either it is amazing and changes everything, or it is overrated and produces garbage.
Both are boring, because both are positions rather than observations. The interesting material is in the specifics of what actually happened.
The shape that works
Goal, attempt, judgment, correction, result.
I gave the agent a twenty line task. It wrote the feature in about a minute.
Then I spent two hours fixing assumptions it had made about the workflow. Not bugs. The code ran. It had built the wrong thing correctly, because I had not told it that exports are per-account rather than global, and there was nothing in the codebase that said so.
The interesting part of AI coding is not the typing. It is that "correct" turned out to be a thing I had never written down.
That has a real observation in it. Someone else can recognise their own experience in it, and it did not require a position on whether AI is good.
What to avoid
"AI is changing software development." True and useless. Everyone has heard it.
Raw productivity claims. "Built this in a day with AI." Without detail, unfalsifiable and unmemorable.
The hero narrative. The agent as a collaborator with opinions. It makes the post about the tool rather than the work.
Pure dismissal. "It generated garbage" is as uninformative as the opposite. What kind of garbage, and why?
The most reliable angle
The consistently interesting question: what did you know that the model did not, and how did you find out you knew it?
That is where the actual content is. Agents fail on product context, on constraints that were never written down, on the definition of done. Those failures are specific, surprising, and say something about your system rather than about the tool.
The percentage observation
A common and genuine experience: the agent gets most of the way in minutes and the remainder takes longer than the whole thing would have taken manually.
That is worth writing about, but only with the specifics. The general version has been posted a thousand times. The useful version says which part was the remainder and why.
The last part was not difficult code. It was that the agent did not know exports are per-account, which is not written anywhere. It is in three people's heads and one four year old ticket.
Now the post is about undocumented domain knowledge, which is a real problem that predates AI and that AI made visible.
What we built in
Noomachy DevTracker has a specific prompt layer for this, added only when the story involves AI tooling:
The interesting story is the loop: goal given to the agent, what the agent produced, where human judgment was needed, what got corrected, what the result was. The useful insight is usually about defining what "correct" means, not about code generation being fast.
Only use this framing if the evidence actually supports it. Do not invent a correction the agent needed.
That second paragraph matters as much as the first. The framing is good, which makes it tempting to apply whether or not it happened. An invented struggle with an AI agent is exactly the kind of plausible, unfalsifiable detail that erodes trust in everything else you write.