AI-assisted coding has a slot machine problem

AI-assisted coding changed the feedback loop.

You write a prompt. Press Enter. Code appears.

Sometimes it's good. Sometimes it's almost good. Sometimes it compiles, looks reasonable, and hides three bad decisions under a clean interface.

And that's where the problem starts.

Not because AI writes bad code. Humans write bad code too.

The problem is that AI can make coding feel like a slot machine.

Press Enter.
Get output.
Press Enter again.
Maybe this time it works.

The dangerous part is not generation

Generating code is not the dangerous part.

The dangerous part is when generation replaces understanding.

I've seen this pattern more than once — and honestly, I catch myself in it too. We ask AI for help, get an answer, copy it, and move on before fully reading what was generated.

Sometimes it's a code change.
Sometimes it's a review comment.
Sometimes it's an explanation of a bug.

The shape changes. The failure mode is the same.

AI produced something that looked useful, so we treated it as done.

The faster the tool gets, the easier it becomes to confuse movement with progress.

The tool is fast, confident, and usually close enough to feel helpful. It removes friction from the first 80% of the task.

But the last 20% is where engineering happens.

"AI wrote it" is not a review strategy

One uncomfortable thing about AI tools is that they can make low-effort work look high-effort.

A generated comment can sound thoughtful.
A generated refactor can look clean.
A generated component can match the design visually.

From the outside, everything looks fine.

But software is not judged only by what appears on the screen.

A feature can look finished and still be full of unnecessary state, duplicated logic, weak boundaries, overcomplicated abstractions, and copy-pasted boilerplate. The UI can be beautiful while the internals are quietly turning into spaghetti.

The demo works.
The screen looks right.
The PR is green.

But it is easy to miss the question that matters most: is the code maintainable?

Vibe coding has a time and place

There's a narrative that has been gaining traction: if the UI works, the engineering behind it matters less. Just prompt your way to a working product.

I get the appeal. The demos look great.

And for prototypes, experiments, and throwaway ideas, that speed is genuinely useful.

The problem starts when a prototype workflow becomes a production workflow.

Here's what those demos don't show: the codebase six months later.

Vibe coding optimizes for the moment when something appears to work. Real engineering optimizes for the moment when somebody has to change it six months later.

Those are not the same moment.

The first one asks: "Does it work now?"
The second one asks: "Will the next person understand why it works?"

When we accept code without understanding what the model generated underneath, the feature may be working — but the team has inherited a liability.

If nobody can explain why it works or safely change it later, the productivity gain is mostly an illusion.

That's not a new way to build maintainable software.

That's spaghetti with a clean UI on top.

Reading is the new bottleneck

Before AI, writing code was often the bottleneck.

Now reading is.

The code appears faster than we can properly evaluate it. The comment appears before we have fully understood the issue. The refactor appears before we have checked whether the abstraction already exists somewhere else in the codebase.

This changes our responsibility.

The job is no longer just to produce code. The job is to validate output.

• Is this solving the right problem?
• Does this match our architecture?
• Would I be comfortable explaining this in code review?

If the answer is "I don't know, AI generated it," then the work is not done.

AI does not remove accountability

This is the part I think teams need to say out loud:

AI can write the first draft.
It cannot take ownership of the result.

The ownership stays with us.

If I paste generated code into a codebase, it's my code now. If I paste a generated review comment, it's my review comment now. If I accept a generated refactor, I own the complexity it introduces.

"AI gave me this" explains the process. It doesn't replace the review.

The same applies to code review. If an AI reviewer catches something useful, great. If it misses something obvious, that doesn't mean human review disappears from the process.

AI can reduce review load, but it should not replace engineering judgment.

At least not in the kind of codebase people have to maintain for years.

The real skill is calibration

This is why I keep coming back to calibration.

Good AI usage is not about pressing Enter until something works. It's about knowing what kind of output you are asking for, what quality bar it needs to meet, and where the model is likely to fail.

For throwaway code, maybe "works" is enough.

For production code, it isn't.

For a small internal script, maybe generated boilerplate is acceptable.

For a shared component used across the application, it deserves more scrutiny.

For a review comment, sounding smart is not enough. It has to be correct, relevant, and actually read by the person posting it.

The tool can generate. We have to calibrate.

What I try to do differently

When I use AI for coding, I try to slow down at exactly the moment the tool wants me to speed up.

After it generates code, I read it line by line.

Not because I don't trust AI. Because I don't trust any code I haven't understood yet.

I ask:

• What did it assume?
• What did it ignore?
• Would I write it this way without AI?

That last question is useful.

Because if the answer is no, I need a very good reason to merge it.

The standard I want

I don't want developers to stop using AI. That would be absurd.

I want the opposite: use it more deliberately.

Use it to explore.
Use it to draft.
Use it to compare approaches.
Use it to challenge your assumptions.
Use it to find edge cases you missed.

But don't outsource your judgment.

The moment AI output enters the codebase, it stops being AI's output.

It becomes ours.

And that means we have to read it.