AI assistants build exactly what you ask for, and nobody asks for the ability to diagnose a feature six months from now. That gap between code that runs and code you can actually operate shows up the first time something breaks quietly in production.
The Details:
- The root cause is a specification gap, not a model limitation. When a prompt says build a payment handler, the assistant optimizes for that request alone. No log line, metric, or trace span appears unless someone names it, so tests pass and the feature ships with zero breadcrumbs for the person who gets paged.
- Bolting observability on after deployment costs more and works worse than building it in at the point of writing. The developer who wrote the code is the only one who knows what abnormal actually looks like for that specific path; a platform team reconstructing that context later is guessing.
- A short persistent guidance file, the kind an assistant reads on every request, changes the default without anyone remembering to ask each time. Three or four rules work, such as logging entry and exit with a correlation ID on every I/O boundary. Guidance files that balloon into thirty competing rules stop getting followed and start getting negotiated with.
- The labor split that works best runs against intuition. Let the assistant handle mechanical breadth, wrapping every external call and every handler with structured logging, since that tedious pattern work is exactly what bored humans skip. Reserve human judgment for picking which three metrics actually signal health and for catching logs placed everywhere except the hot loop where traffic actually flows.
Bottom Line: The fix costs an afternoon: write four lines of guidance, change one code review question, and feed every incident back into the file the day it happens."
