From TODO to TOKNOW

Developers told Stack Overflow two things this year that do not fit together. 84% of us use or plan to use AI to write code. Only 3% say we highly trust what those tools produce, and among the most experienced developers that number falls to 2.6%. Active distrust of AI output climbed to 46%, up from 31% a year earlier.

Sit with that. We have adopted, at industry scale, a way of producing software that most of us openly say we do not believe. This is not recklessness. We ship anyway because it is fast, and we file the disbelief under "deal with it later."

That gap between using and trusting is the real story, and it has a cost nobody has named yet. For most of my career, technical debt had a shape I could see. It looked like a comment. // TODO: handle the null case. The work was deferred on purpose, and the understanding stayed intact.

AI changed which half you defer. It writes the code in minutes and generates the tests and the docs alongside it, so the things we used to postpone now come for free. What gets postponed instead is comprehension. The defining comment of this era is not the TODO. It is the TOKNOW.

Understanding never used to be a task of its own. It was a side effect, forced on you at four points in the work whether you wanted it or not. You understood the problem because you had to decide what to build. You understood the design because you defended it at a whiteboard against someone who disagreed. You understood the implementation because you wrote it and hit every wall in person. Then you understood it once more when a reviewer made you justify it.

The code was the residue of all that comprehension. AI removed the friction at each of those points, and that is the part people rightly celebrate. But the friction was quietly doing a second job nobody put on the invoice. It was forcing the thinking. Take away the struggle of producing the code and you also remove the thing that used to guarantee you understood it. Comprehension does not arrive for free just because the code compiled.

Here is what makes this debt so easy to take on: you cannot feel yourself accruing it. In 2025, METR ran a careful randomized study of experienced open-source developers working on their own repositories. With AI tools allowed, they took about 19% longer to finish their tasks. They had expected AI to speed them up by 24%, and even after living through the slowdown they still believed it had sped them up by around 20%.

I want to be fair to that study, because it has a sequel. METR later cautioned that its follow-up data was distorted by selection effects, that the developers who gain most from AI kept opting out of the no-AI condition, and that it had probably underestimated how much current tools help. Fair enough. I would not bet a roadmap on the slowdown number.

The finding that survives all of that is the one I care about. These developers were wrong about their own productivity, in the optimistic direction, by roughly forty points. If we cannot feel a swing that large in our own speed, we certainly cannot feel the comprehension we skipped along the way. The velocity is loud and immediate. The debt is silent and deferred. We calibrate on the loud signal and miss the quiet one.

You do not have to take the perception argument on faith, because the debt is starting to surface in the code itself. GitClear analyzed 211 million lines of code changed between 2020 and 2024 across repositories at Google, Microsoft and other large companies. Two trends move in step with AI adoption.

This is what comprehension debt looks like from orbit. Refactoring requires understanding the thing you are reshaping. Pasting does not. When the share of refactoring collapses while duplication climbs past it for the first time on record, that is a workforce assembling more and understanding less.

I will be honest about the limits. This is correlation, the timing simply lines up with the spread of AI assistants, and GitClear sells tools in this market, so weigh it with that in mind. But the direction is hard to wave away, and duplicated code is independently associated with 15 to 50% more defects in prior research.

Bad code is not the real threat. Bad code tends to announce itself. It throws an error, fails a test, or falls over in the demo. The threat is plausible code, the kind that compiles and passes its tests and reads cleanly, then turns out to be quietly wrong in a way nobody thought to question.

A Stanford team led by Dan Boneh put numbers on this in 2023. Across 47 participants writing security-sensitive code, the group with an AI assistant wrote measurably less secure code than the group without one. The part that should worry you is the second half: the people using the assistant were also more confident their code was secure. Less safe, and more sure.

That inversion is the engine of the whole problem. The tool raises your confidence faster than it raises your correctness. The danger was never that AI writes bad code. It is that AI writes convincing code, and convincing code does not get the second look that ugly code earns for free.

Here is the analogy I keep returning to. Imagine telling your employer to stop paying your salary into your own account, and to send it straight to a financial advisor you have never met. Let them understand your goals and move the money for you. You just get a dashboard that says things are going well.

Nobody sane agrees to that, and not only out of fear of fraud. We want the money in our own hands because the friction of managing it is how we ever learn to manage it. The struggle is what builds the judgment.

In software we are signing up for that exact deal and calling it productivity. We hand the agent the one asset that actually compounds, our grasp of how the system works, in exchange for the speed of getting features out the door. The dashboard looks great. And quietly, the only entity that understands the codebase becomes the one we rent by the token.

It would be easy to land this as an anti-AI piece, and it would be wrong. The best evidence we have says the tool is not the villain. It is a multiplier.

Google's DORA program has the longest-running data on this. In 2024 it found that a 25% increase in AI adoption came with an estimated 7.2% drop in delivery stability and a smaller dip in throughput. The mechanism was not "AI writes garbage." It was batch size. AI makes it trivial to produce more change at once, and bigger changesets have always carried more risk.

By 2025, with AI adoption near 90%, the picture matured. Throughput actually turned positive, so teams really do ship more now. But the negative relationship with stability held. DORA's reading is that AI amplifies whatever your organization already is. Teams with strong testing and fast feedback turn it into real gains. Teams with fragmented process and shallow understanding get their weaknesses magnified. The comprehension gap is the pre-existing condition. AI just turns up the volume on it.

None of this argues for slowing down or hand-writing code out of nostalgia. I want the velocity. The fix is to stop letting the agent be the only thing that holds the understanding. Four habits I keep, each pointed at one of the failure modes above:

There is a career implication buried in all of this. For twenty years the prized engineer was the one who could produce. Type faster, know more libraries, ship more volume. Generation was the bottleneck, so generation was the prize.

Generation is no longer the bottleneck. It is close to free and close to infinite. When supply runs to infinity, value moves to whatever is now scarce, and what is scarce is the judgment to decide whether a given thousand lines should exist at all. The valuable engineer now is not the fastest typist. It is the person who can read what the model produced and tell you which fifty lines are load-bearing and which are confidently wrong.

AI did not abolish technical debt. It changed its denomination. The old debt was unfinished implementation and you could see it. The new debt is unfinished understanding, and it hides behind a green test suite and a confident tone.

I wrote once about moral surrender, losing the why and not just the how. TOKNOW is what that surrender looks like inside a codebase. Every generated function nobody has reasoned about is a quiet bet that later will come, and that someone will understand it before it matters. The data says later does not arrive on its own.

So I have started asking one question before anything ships. If this breaks, and the only thing that ever understood it is the model that wrote it, who fixes it? If the answer is nobody, you did not ship a feature. You filed a TOKNOW and called it done. The TODO was a promise to do the work. Make the TOKNOW the one promise you refuse to write.