---
title: "Due-Diligence Programming: If You Submit It, You Own It"
author: "Shawn Jiang"
lang: en
date: 2026-09-16
canonical: https://tplog.dev/en/essay/due-diligence-programming/
translations:
  ja: https://tplog.dev/ja/essay/due-diligence-programming/
  zh: https://tplog.dev/zh/essay/due-diligence-programming/
---

# Due-Diligence Programming: If You Submit It, You Own It

AI has lowered the cost of writing code. It has not lowered the cost of being responsible for that code.

Due-diligence programming means that whoever submits the code owns the result.

Even when AI generates the code, the person submitting it remains responsible—and should not pass costs they ought to bear on to someone else.

This is not a moral slogan. It is a boundary of responsibility.

## Who Owns the Code That Enters Main?

Much of the conversation about AI coding concerns speed: writing code faster, changing it faster, and reaching the point where it “looks like it runs” faster. Due-diligence programming asks a different question: once that code enters the shared main branch, who owns it?

AI can generate code, modify it, and run checks. None of that changes what enters the repository and begins affecting other people: executable code, not the record of your conversation with a model.

Due-diligence programming therefore does not mean “write prompts more carefully,” nor does it mean using less AI. It sets one rule: whoever submits the code is responsible for the result. Responsibility cannot be outsourced to a model.

## What It Opposes: Automating the Blame Shift

“I only generate the code; quality is the tool's responsibility” may sound modern, but it merely hides responsibility inside an automated process.

The model will not go on call. It will not repair an interface it broke for someone else, nor will it defend the design in a review meeting. Those costs eventually fall downstream: on the reviewer, the person integrating the change, or anyone blocked by it.

Doing due diligence means absorbing one round of those costs before you submit. The code does not have to be perfect, but you should be able to say: I have read it, I understand its boundaries, and if it breaks, come to me.

## As Code Gets Cheaper, Ownership Becomes Scarcer

As code gets cheaper, the gap between people's output may widen. The difference is not necessarily who writes better prompts. It is who still owns the result and who merely completes the conversation.

Given the same hour, one person delivers something that “looks about right”; another delivers something they can defend in review. The first consumes the team's capacity to collaborate. The second preserves it.

Due-diligence programming is therefore more than personal discipline. It is both an ethic of collaboration and a matter of engineering efficiency. Any checking, judgment, or repair you leave undone has to be picked up by someone else.

## Automation Does Not Mean Nobody Is Responsible

Automation works when the intent is clear and the execution path can be constrained. It can help you ship; it cannot relieve you of responsibility.

You may let AI write ninety percent of the code, or even all of it. But as long as that code enters a shared space and can affect other people, the submitter's responsibility remains. Fully automated generation does not mean responsibility disappears.

Otherwise, what you have is not complete automation but a semi-automated production line that leaves the team's decision debt and incident debt unpaid.

If you submit it, you own it. Take responsibility for your impact on others instead of passing your costs on to them.

AI can be the pen, the hand, or the checker. It cannot be the scapegoat.

Getting the job done has always been rarer than finishing the conversation. And getting it done includes something unfashionable: being willing to put your name on the result.