The One Who Keeps Pressing Enter

There's one on nearly every team now. The ticket lands, they open the AI, and from that point it's Enter, Enter, accept, yes, allow, yes. Forty suggestions before lunch. They read maybe four of them properly.

And nothing looks wrong. The feature works. The demo goes fine. Tickets close faster than they used to, so from where you sit this person looks like your best hire of the year. That's what makes it hard to catch until the bill turns up.

Debt used to build up slowly

A few years ago a developer typed every line themselves. That was slow, and slow had a side effect nobody appreciated at the time. To write it, you had to hold it in your head. You knew what was in there because you put it there.

Bad decisions still got made. Plenty of them. But they got made at human speed, one at a time, by someone who at least knew they were making a call. A module took months to get messy. A system took years to get scary. You usually had a rebuild conversation somewhere around year three, and by then the business had got real value out of the thing.

That slow build-up was doing quiet work for you. It gave people time to spot the problem before it got expensive.

Now it lands in months

The same developer who used to write two hundred lines on a good day can now ship two thousand. Everyone celebrates the first number. Nobody thinks about the second one, which is that the mess grew by the same multiple.

Volume is the whole story here. More code per week means more decisions per week, and a decision that nobody actually made is exactly what technical debt is. Push ten times the code through a team with the same amount of attention, and the pile that used to take three years to build up gets there before your second release.

None of that breaks anything today. It all breaks in six months, when you ask for a change and the answer comes back much bigger than you expected. We wrote about the shape of this output in AI slop, which is the same problem seen from the code side.

Pressing Enter is not the problem

We use AI every day here. It's a good tool and we're not going to pretend otherwise. The damage isn't in the tool, it's in the gap between accepting something and understanding it.

Every suggestion you accept is a decision about your business. What happens when the payment succeeds but the order fails. Whether a deleted customer is really gone or just hidden. How long the system waits before giving up. Who is allowed to see the numbers. Press Enter and that decision still gets made. It just gets made by something that has never met your business and never will.

Why it surfaces so much faster

Speed alone would be bad enough. Three other things stack on top of it.

Nobody remembers anything. The old system had one thing going for it. When something broke at 2am, some developer somewhere could say "ah, that's like that because of the SST change in 2022". That memory was worth a fortune and it never appeared on a payslip. Now you ask why the code is like that and the honest answer is that the AI wrote it that way and it looked fine.

It all looks senior. Generated code comes with clean names, neat structure, tidy comments. It reads like something a good engineer wrote on a good day, so it moves through review much faster than the same mess would have if a junior had typed it. Confidence is the disguise. That's also why it got harder to spot a good engineer in the first place.

It runs. It compiles, the screen loads, the button works, so everyone treats that as proof. Working today and being right are different claims, and only one of them gets checked. We went into that in it looks like it works, so they commit.

What it looks like from your chair

You won't see any of this in the code, so here's how it shows up on your side of the business.

That last one is the tell. If output doubled and delivery got slower, the extra output is going somewhere, and it's going into work that has to be undone later. The money side of that is in technical debt: the silent tax on your business.

The test that sorts it out

There's one question that separates a developer using AI well from one who is just accepting things. Point at a piece of the system and ask why it was built that way.

Someone who used the tool properly will tell you straight away. We store it twice because your finance team needs the old value after a correction. We retry three times because the bank's API drops about one call in a thousand. We didn't use the fancy version because you'll want to change this rule every quarter and the simple one is easier to change.

Someone who pressed Enter will tell you it's the standard way of doing it. Or that it's what the AI suggested and it worked. Same code, same speed, completely different thing to own for the next five years.

What good teams actually do

The fix isn't to ban the tool. Teams that ban it just fall behind and end up with the same debt, only slower. The fix is to put the effort back at the accept step instead of the typing step.

You'll notice none of that slows the tool down much. It slows down the moment of saying yes, which is the only moment that was ever doing any work.

Three questions to ask your team

You don't need to read code to check for this. Ask these in your next update and listen to how they land.

Good teams answer these in about ten seconds and they enjoy answering them. If the room goes quiet, that silence is the finding.

The honest version

AI didn't create technical debt. Companies were drowning in it long before any of this. What AI removed was the delay between making a bad decision and living in it. The three-year rot now takes about eight months, and the rebuild conversation arrives while the system still feels new to you.

The person pressing Enter all day isn't lazy or bad at their job. They're doing what the tool encourages, and getting praised for it, because the cost of it doesn't show up in the same quarter as the speed. Somebody senior has to care about the second half of that trade, and it usually has to be someone with a reason to still be around in two years.

So ask why the system is built the way it is. If the team can answer, you're fine, whatever tools they use. If nobody can, the tools are not your problem.