AI coding is the prime example of HITL
How Hooman in the Loop provides ground truth to make AI coding works...
Let’s discuss an elephant in the IDE: the bizarre contradiction of AI in software development…
If you’ve spent any time pair-programming with modern LLMs, you’ve noticed the paradox... AI is terrifyingly good at writing that first draft of a script. It is equally brilliant at fixing the script when you paste the error logs back into the chat. So, the million-dollar question is: Why doesn’t it just write it flawlessly in the first place? Why can’t we just tell the AI, “Write this app, and keep iterating internally until you fix all the dead code and regressions, then give me the final product”?
It feels like the ultimate example of Hooman-In-The-Loop (HITL), but to understand why we are stuck in this loop, we need to look under the hood. It boils down to a mix of token mechanics, architectural blindspots, and the fundamental nature of how these models “think”…
1. The Probabilistic Trap
First, we have to remember what an LLM actually is. It is not a compiler. It is not a deterministic logic engine. It is a highly advanced, probabilistic text predictor. When it generates code, it isn’t “building” a mental map of your software architecture; it is guessing the next most likely sequence of tokens based on its training data…
When you ask it for a complex feature, it plots a statistical path. But code requires 100,0% deterministic accuracy. A single missed semicolon or a misaligned variable scope ruins the whole execution. The AI can guess right 99,9% of the time, but that 0,1% margin of error is where your application crashes. It can’t catch it beforehand because it doesn’t run the code before outputting it…
2. The Context Window and “Attention Dilution”
You might think, “Well, just give it a bigger context window!” Modern models can hold upwards of 1.000.000 or even 2.000.000 tokens. That sounds like enough to grasp the “big picture,” right?
Not exactly. Even with massive context windows, models suffer from attention dilution. They are great at understanding the immediate syntax of the function they are writing right now, but they start to forget the intricate downstream dependencies of a module they wrote 500 lines ago.
When you ask an AI to iterate on its own without hooman intervention, it easily gets lost in the weeds. It will fix one regression, but in doing so, it statistically drifts away from the original architectural constraints, creating two new bugs somewhere else. It simply cannot hold the entire “big picture” in crisp, absolute focus the way a strict static analyzer does…
3. The Lack of a Ground Truth
Why does the AI suddenly become a genius again when you point out the error?
Because you are providing the Ground Truth. You are the runtime environment.
When you run the code, compile it, and get an error stack trace, you are introducing hard, deterministic facts back into the AI’s probabilistic brain. You are essentially saying, “Your statistical guess failed at line 42 with this exact memory leak.” The AI then uses that highly specific constraint to recalculate a new probability path, which is usually right on the money.
If you tell an AI to “keep iterating until it works,” it has no way to verify if it works. It would have to write its own test suites, but because it is generating the tests using the same probabilistic logic it used to write the code, the tests will likely validate the flawed logic. It becomes a hallucination loop…
The Ultimate HITL
So, yes, AI coding is the prime example of HITL, and it probably will be for the foreseeable future. We are not just prompt engineers; we are the deterministic anchors for probabilistic engines. We provide the compilation, the architectural vision, and the boundary conditions. The AI provides the raw, brute-force syntax generation.
It’s a solid partnership, honestly. We get to skip the tedious boilerplate, and the AI gets a safety net so it doesn’t accidentally delete the production database while trying to center a div… ;-).
How are you currently managing your AI workflow, do you write your own tests before feeding them to the AI, or do you let the AI write the tests and just act as the hooman compiler yourself? ….