The Structural Unease: AI Finished Your Feature. Why Are You Still Uneasy?
Tedium Is Stability · Part 1
Series｜Tedium Is Stability: building with AI agents, treating your unwritten rules as code.
You know the feeling.
You hand a requirement to an AI. Seconds later it hands back working code. It compiles, the tests are green, the demo runs clean. You should be relieved, but a small voice won't quit: something feels missing.
It's not that the AI isn't smart. Today's models can spin up a whole module in seconds, and the quality is genuinely impressive. The unease runs deeper. It isn't about whether the work is good; it's about whether the work is complete. I call it structural unease: you sense that something hasn't been taken care of, but you can't point to it, so you can't check it either.
This series is about naming that unease, and then dismantling it, one step at a time. And it leads somewhere that sounds backwards at first, which is also the spine of everything that follows: the very checks that make you uneasy, the tedious ones, turn out to be your single biggest source of stability when you build alongside an AI agent. Tedium is stability. Hold that thought; we'll get there.
One scoping note: this isn't about weekend toy apps. It's about the kind of mature system whose rules are so many that only the veterans remember them all. The simpler the feature, the fainter this unease; the more mature the system, the more lethal it gets.
A "Working Feature" Is Just the Tip Above the Water
Let's see the problem clearly. Say you ask the AI, "add an API that exports orders into a report." What it gives you is the part above the waterline: an endpoint, some service logic, a set of passing tests. Clean and reassuring. But a feature is never just that running code. Below the surface, it drags a long string of things nobody spelled out, yet all have to be done.
Did it record who exported what, and when, so you can answer for it later? Does this action need approval first? Who is allowed to run it, and has this customer's plan even paid for the feature? Does the report leak national ID numbers or other sensitive fields that should be masked? If it sends a notification email, did that outbound call leave a trace? When two servers run in production, will it fire twice? And did changing this quietly break something else?
You saw one feature. Underneath were eight things. They're mostly not in the ticket; they live in a senior engineer's instinct and in some unremarkable corner of the codebase. Your unease comes from exactly here: you can feel them, but you can't name them.
It's Not That the AI Is Dim; Nobody Told It "Also Check These"
There's a cruel asymmetry here.
The AI nails the visible part: endpoint, tests, clean naming, even a tidy execution record. But the invisible string? It quietly skips it. Not out of laziness, but because from start to finish, nobody told it: this kind of task, besides working, also has to check these.
The worst part is that this kind of miss doesn't error out on the spot. The feature ships, runs, everything looks calm. The real bill arrives three months later. A customer asks "who exported this data?" and you search the whole system and find nothing, because that audit line was never written. Or one day you notice the report shipped raw personal data. Or those two production servers each sent the same notification. None of it shows up when you run a single instance on your laptop.
POG Added a Layer. This Series Adds One More.
If you know POG, you know its thesis: treat tasks and prompts like code. Stop letting that carefully honed prompt, and the logic of how the AI broke the task down, vanish the moment you close the chat. Write them into Git, keep an execution record, let experience accumulate and be traced back. That filled a crucial gap: it answers "what did the AI actually do."
What this series is after sits one layer higher.
It answers not "what did the AI do" but "did the AI do it all." Same spirit: if a task can be code, then "which obligations a task must satisfy" can be code too. We can take that submerged string of invisible rules, itemize them, write them down, and turn them into a checklist every task grows on its own, so the AI knows, before it starts, which fronts this kind of task has to cover; and so you, at the finish line, hold something real and tickable instead of a hunch you can't put into words.
Naming that unease is where the whole journey starts.
Next, we haul the whole iceberg up: what, exactly, is a feature made of? You'll find it's far more traceable than you feared.
Top comments (0)