Pressing enter to accept model suggestions now takes less effort than scrolling past it. One keystroke, and the code is yours. Reading it, understanding it, deciding if it's actually right, that part hasn't gotten any faster.
That gap, between how fast we can accept code and how fast we can actually understand it, is where things start to go wrong.
The new shape of technical debt
We used to know where technical debt came from. Tight deadline, cut corner, # TODO: comment that nobody ever revisits. Rushing was the cause, and we could at least point to it.
Now you can build up the same kind of debt on a calm Tuesday afternoon, no deadline in sight, just six suggestions in a row accepted because they looked fine and the flow felt good. Nobody rushed you, and the code still ended up just as unexamined.
Same debt, just a different excuse.
"It works" is not the same as "I understand why it works"
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
— Brian Kernighan, 1974
Fifty years later, the gap got wider. Kernighan was talking about code you wrote. At least you understood it once.
A suggestion that compiles, passes the linter, survives code review and even comes with passing tests can still be standing on a wrong assumption that nobody caught, because nobody was reading it as code. They were reading it as output, and output that makes sense tends to get approved.
Compiling is a low bar. Passing tests is a slightly higher one, depending on whether you wrote the tests, or its suggestion shaped or created those too. If it's the second, it's like grading its homework with its own answers.
None of it tells you the logic is sound, that the edge cases are covered, or that it does what you actually needed, something we already learned every time we trusted code we didn't write. Somehow it's easy to forget it the moment the code appears inline, in our own editor, in our own style.
Where this actually bites you
A few ways this shows up in practice.
You debug code you never really read. Something breaks three weeks later, you open the file, and you're starting from zero, because the first time around, you accepted instead of reading.
Edge cases that look right but aren't. A suggestion handles the happy path convincingly. The null check is there. The structure looks careful. But the one case your domain actually cares about, the one that would've come up in two minutes if a teammate had glanced at it, was never on the model's radar, and it wasn't on yours either, because you didn't ask the question.
You can't defend half your own PR. Someone asks "why did you do it this way?" in review, and you genuinely don't have an answer, because you didn't make that decision. You just didn't reject it.
This isn't an anti-AI post
To be clear, none of this means the tools are bad. I use them constantly, and they're genuinely useful for exploring a codebase I haven't touched before, for discussing different alternatives to tackle an issue, or creating an implementation plan for a big new feature.
The problem isn't the assistance. It's the posture. Treating every suggestion as something to glance at and accept, instead of something to read and decide on, even the good ones above still need that second look once they turn into actual code.
Where it's low stakes, generated boilerplate, a quick script, a throwaway prototype, speed wins and it's fine. Where it isn't, business logic, anything touching security, anything you'll be paged for at 2am, the posture needs to change. Read it like you're about to own it, because you are.
Habits that keep you in the loop
Nothing groundbreaking here, just things worth doing on purpose:
- If you will work on a big feature, discuss your own take with the model and when you agree on a solution, request an implementation plan and review it
- Read the diff like you wrote it and you'll have to defend it in review, because eventually you will
- Ask the tool to explain its own reasoning before you accept, not after something breaks
- Treat suggestions like a junior dev's PR: often useful, never ground truth
- Slow down specifically on the lines that surprised you. Surprise is usually a signal worth paying attention to
Wrapping up
The keystroke got cheaper. The responsibility didn't.
Speed is fine. Speed without understanding is just debt with a faster checkout line.
Top comments (0)