Doing the Right Things Properly: My Defense Against Answer Addiction
I found a security hole during my pre-deployment audit for O9X. That is the part that shamed me.
I had three CLI agents running simultaneously. One reviewed my product requirements document and built the database schema. One worked from the same document to design the application’s route layout. One identified features missing from the requirements for the next phase. I shifted between all three, moving fast, feeling productive.
The schema agent produced over 500 lines. I reviewed about 50, found nothing obviously wrong, and approved the full output. Row Level Security (mechanism that controls which user can access which data) was in the lines I did not read.
I knew about RLS before that session. I had been compiling a list of common AI security errors since the first day of the build. I had read enough stories about basic mistakes in AI-generated code to know that a final deployment audit was not optional. I knew the risk and had built infrastructure to catch it. I still missed it. Not because I did not know. Because I was context-switching across three independent sessions when the foundational decision was being made.
The deployment audit caught the hole. What followed was not two weeks fixing one bug. It was two weeks reviewing every file I had built during that period, with the attention I should have given it the first time. The fast work had not created one problem. It had created the condition where any number of problems could exist undetected, and I had to verify all of it from scratch.
There is a name for the state I was in: Answer Addiction. It is accepting the AI’s first output as the solution (when I am tired or impatient to question it further), when it should only ever be the starting point. The AI’s answer is not the end. It is the material you interrogate.
I have never written a line of code in my life. I use AI to build the systems my business needs. For someone like me, there is no fallback. I cannot sight-read code. I cannot spot a missing RLS policy the way a trained developer can. My only tool for closing the gap between what the AI built and what the business actually needs is my own judgment. And judgment requires attention that cannot be split three ways.
I call this the Judgment Gap. It is the distance between an AI’s logical correctness and my business reality. It is a diagnostic concept, not a decision rule. The AI builds what it was trained to build. The operator knows what the field actually requires. The gap between those two things does not close itself.
The Judgment Gap widens every time I approve an output that I did not read fully read. Every time I switch context before a decision is made. Every time a parallel session runs work, my attention cannot hold across multiple sessions with same focus.
Knowing the gap exists is not enough. I needed a rule for when to stop.
Trigger: A second independent CLI session opens where each session requires design judgment i.e., schema decisions, architecture choices, logic that affects other parts of the system.
Mandated action: Limit myself to just one session. Finish the current session to a log checkpoint before opening the next independent workstream.
Known exception: I use multiple CLI sessions for parallel execution of pre-decided, non-overlapping fixes such as lint errors, isolated bug lists, where the decisions are already made and sessions are not making judgment calls that affect each other.
The distinction matters. Ten sub-agents executing a brief I have already stress-tested can be fine. Two independent CLI sessions making design decisions simultaneously is the same as human multitasking. I already know I cannot multitask. I had just convinced myself that AI workflows were different.
They are not different. That was the mistake.
I started building O9X in November 2025. Within the first few weeks I had watched experienced developers, people who code for a living, talk about running multi-agent workflows. I assumed the workflow was the transferable variable. My hypothesis is that experienced developers hold enough of the system in their heads to context-switch safely across sessions. I cannot verify this from the outside. What I can say is that I did not have that capacity, and the method failed in my hands in ways I did not see coming.
This looks like a Halo Effect. One strong impression (skilled developers endorsing multi-agent builds) distorted how I evaluated whether their method applied to my situation. The mechanism does not change the decision rule. I am an newbie who is learning how to develop code, not a developer who learned to operate. The mental models are not the same and the workflow cannot be the same either.
My father had a simple saying:
Do the right things properly. Don’t aim to do things rightly.
Doing things rightly is about execution. The AI handles that better than any operator. It will produce a logically consistent schema, a clean route layout, a thorough feature list. All correctly built according to what it was trained on. Doing the right things is about context. It is knowing that the schema it built needs every associate to have a permanent shift timing, and that in my operations, shift changes every two weeks. Shipping that logic would force 25 field staff through a change-request process every fortnight.
I had not asked. Before approving that schema, I should have asked the agent what assumptions it was making about shift scheduling. My belief is that the question would have surfaced the mismatch, but I did not ask, so I cannot be certain. What I know is that the question cost nothing and I skipped it. The fixed shift model would have costed me considerably more.
Two stories, same structure. The AI produced something logically correct. The gap between its logic and the operational reality is the thing that breaks my business. In one case the deployment audit caught it after the fact. In the other, a single question would likely have caught it before anything was built. The difference is not the AI. It is whether I am moving at a pace that ensures I don’t miss such errors.
After the two-week audit, I rebuilt the workflow from the ground up.
Planning now happens in the Web UI, before any CLI session opens. I bring three inputs:
- The specific goal for the session
- The existing schema
- The PRD.
Then I instruct the AI to interrogate me and not build . I use a structured Socratic prompt, which produces a brief for the CLI agent. The thinking and the building happen in separate environments, by design.
Every CLI session ends with a session log. Four fields:
- Date
- What was built
- Key decisions made
- Which files were created or edited and why.
A key decision is any choice the next session cannot reverse by editing a single file. A long session can run to hundreds of exchanges. The log compresses that into a hundred or two hundred words. It captures the reasoning, not just the output.
The next session inherits the thinking, not just the code. Without it, the code exists but the logic behind it does not, and that is the condition that might produces another major security error.
The deployment audit checklist still runs before any code goes live. It worked exactly as intended. Its job is to catch what the process missed. It is not a substitute for the process.
The Judgment Gap does not announce itself. It widens gradually, one approved output at a time, one context switch at a time, until a deployment audit or a field conversation surfaces what the fast work buried. Reading about the risk would not have saved me. However, developing a better catch infrastructure can save me. The audit is the last line.
My father’s principle is not an argument for slowness. It is an argument for knowing which kind of work I am doing. The AI handles execution. I handle context. The moment those two roles collapse into one fast-moving session, I am not building faster. I am scheduling a two-week audit for a future date, at a higher cost, with less to show for it.
Do the right things properly. The business you build with enough attention to understand it will outlast the one you shipped at ten times the speed.