Due Diligence Programming: The Source of Individual Output Disparity in the Age of AI Coding

For over a year now, AI coding has shifted from a trendy new way of programming into the default approach. Everyone is using nearly identical models, similar setups, and similar agents. In theory, the quality of code produced by everyone should also be comparable. But if you have worked on the front lines, you will find that reality is quite the opposite—the variance in everyone's code output is actually larger than ever before. This is quite a fascinating topic, yet I have noticed that very few people discuss it on the internet.

Why is there such a massive gap in output quality when everyone is clearly using the same programming methods? Especially when I reflect on my daily conversations with AI: I don't feel there is any technical sophistication involved. I have no magical prompts, nor do I install any flashy skills. I simply treat AI as a partner to collaborate with on getting the work done. I believe everyone else works this way too, so why do these individual differences still exist?

After pondering this question for a long time, I believe I have found a working methodology that is rarely discussed, yet in my view forms the core essence of AI coding. I call it "Due Diligence Programming," or to put it more colloquially, "being dependable."

If you have dealt extensively with HR, property management, government agencies, and other bureaucratic personnel, you know how hard it is in this society to get them to help you accomplish a task. Yet I believe everyone has that one highly capable person in their social circle who is exceptionally good at getting things done. In ancient times, they went by other titles, such as local gentry or private advisors (shiye). Their job boiled down to just two words: "getting things done." It is worth noting that these people often do not possess specific technical expertise themselves, and they rarely execute the tasks personally, but they have the uncanny ability to get others to accomplish things smoothly and cheerfully.

In my view, AI coding requires precisely this capability. In this era, because programming speed has drastically increased, the granularity of task allocation has also become much coarser. In the previous era, the task assigned to you might have just been writing a specific module or even a single function; you didn't need to care about what the final aggregated work of everyone actually accomplished. Today, however, you are more often asked to make an entire outcome happen. Making an initiative succeed might break down into a hundred sub-tasks. AI has the capability to finish every single sub-task, but AI lacks the ability to decide which hundred sub-tasks need to be done. That context might reside in your conversations with your manager, in your accumulated past work experience, in common sense, or even in projecting future developments. AI has no way of grasping so much contextual information from just a few sentences in a chat window.

At my previous company, I encountered what I considered the most terrifying kind of person—to the point where I briefly wanted to request that the company ban him from writing code. He would let the AI decide which hundred tasks needed to be done to accomplish a goal, and then let the AI complete all of them blindly. This brings us to today's topic: "Due Diligence Programming." In my view, his biggest mistake was failing to exercise "due diligence." Frankly, when AI makes autonomous decisions, its accuracy rate isn't actually low, but it is certainly nowhere near 100%. If you tell AI to build an article editing feature without providing additional context, AI will autonomously decide whether to use auto-save or a save button, and whether the text box has a fixed size or expands dynamically with content. Yet AI will still miss certain nuances, such as what happens with concurrent multi-user editing. Because your prompt is only a few characters, it will simply treat it as a straightforward requirement to check off. Moreover, if the AI overthinks, it risks over-engineering. At this stage, it heavily relies on human critical thinking, challenging the AI, and more importantly—even though you didn't write the code yourself, you must be able to answer any questions raised by others during technical reviews. This is what I consider meeting the standard of "Due Diligence Programming."

If the goal were merely to implement requirements, I feel that since the advent of the AI coding era, I would only need to work two hours a day. But the rest of my time is usually spent on "understanding the AI's design." I understand the code generated by AI not by reading the raw code itself, but by having AI draw architecture diagrams and draft design documents. I even have a foolproof "magic prompt" where I ask the AI to write a "product manager-facing" document. This way, I can understand the AI's design without even having to parse tedious technical jargon, and I can also hand this document over to product managers so others can understand the system implementation as well.

However, "due diligence" is a subjective behavior with no definitive end. What kind of requirement warrants what degree of diligence is entirely up to individual discretion. For instance, for a system I recently built to evaluate Agent quality, I didn't perform much "due diligence" because its code was non-core and easily discarded and rewritten. But if you are writing the core codebase of an Agent, due diligence is endless. It requires not only reviews before submitting code, but also recurring "regression due diligence" on the system over time as the code continuously evolves, just to maintain an up-to-date mental model. None of this work produces visible, tangible output; whether to do it or not rests entirely on the individual, and doing it doesn't necessarily yield immediate results. Not every company can accommodate this way of working, especially within teams run by non-technical middle managers at large corporations.

Even so, there are ways to inject objective tooling into the AI coding workflow to encourage this "spirit of due diligence" to flourish across an organization. For example, I recently added a Codex-based automated code review plugin to our main repository. Note that this is not the superficial kind of plugin found online that scans a few lines of code and comments on trivialities. Instead, it clones the entire repository, analyzes all side effects generated by the change in the context of the codebase, and then provides review feedback. Furthermore, its Agent context is entirely independent of the user's AI Coding Agent context, making its evaluations exceptionally objective. If you insist on mutating data inside a GET endpoint, Claude Code might comply and accommodate you because of your direct instruction, but the Review Agent—unaware of your stubbornness—will still flag it and forbid it. Since review comments are generated on every commit, you are forced through multiple rounds of revisions, or you must explicitly state why you disagree with the review. Moreover, your "due diligence" process is fully visible on GitHub, so whoever reviews your code is essentially reviewing your due diligence process. This transforms subjective decision-making into an objectively visible effort. In my experience, perhaps due to its prompt setup, this Review Agent has evolved a bit into a harsh code-review critic, but in an era where everyone is constantly flattered by AI, a harsh critic is precisely what we need.

When I discovered this phenomenon of diverging individual outputs despite using identical tools, I felt a slight sense of relief, to be honest—at least in the short term, AI won't easily replace my job. The difference between us and AI is that we want to actually get things done, whereas AI merely wants to complete the conversation. And the ability to get things done has always been a rare commodity throughout history, never once replaced by the advancement of tools.