AI Coding Tools After the Hype: Where They Help and Where Judgement Still Wins

The conversation around AI coding tools has been through the usual cycle now.

First came the demos. A prompt becomes an app. A test suite appears. A bug gets explained. A developer who has never touched a framework before suddenly has something running locally.

Then came the backlash. The code is wrong. The abstraction is strange. The tests prove very little. The tool invents an API that does not exist. The demo looked good, but the production reality was messier.

I think both reactions miss the more useful point.

AI is changing the tools we use to do software engineering. It is changing the speed of certain tasks. It is changing the shape of the workflow. But I do not think it changes the work itself as much as people want to believe.

The work is still understanding the problem. Drawing the right boundaries. Making trade-offs. Sequencing delivery. Managing risk. Keeping systems understandable. Building teams that can make good decisions without constant escalation.

If anything, people are more critical than ever.

My view is simple: AI coding tools amplify judgement. They do not substitute for it.

That matters because these tools are no longer just a personal preference. They are becoming a team decision, a hiring decision, a productivity decision, and eventually a policy decision. Leaders need a better answer than "everyone should use them" or "serious engineers do not need them."

The real question is where they help, where they quietly make things worse, and what kind of engineering culture makes them net-positive.

They help when the intent is clear

The best use of AI coding tools is not asking them to think for you. It is asking them to move quickly once you already know what you are trying to do.

They are genuinely useful for boilerplate. They are good at producing glue code around unfamiliar APIs. They can generate a reasonable first pass at test scaffolding. They help with mechanical refactors when the direction is clear. They are useful for spike work, where the goal is to explore a path rather than ship the first output. They can also be very good at explaining unfamiliar code, especially when you are trying to get your bearings in a codebase you did not write.

That is real productivity.

On a team, these moments add up. Less time staring at syntax. Less time hunting for the exact shape of a library call. Less time writing the dull first version of something you already understand.

But the condition is important: the engineer still needs to understand the intent.

The tool is not deciding the boundary. It is not deciding what the system should mean. It is not deciding which trade-off is acceptable. It is not carrying the operational consequences of the code six months later.

It is a fast typist for clear intent.

That is the framing I keep coming back to. When I know what I want, the tool can help me get there faster. When I am vague, it gives me something vague back, just dressed up as working code.

Vague intent in, plausible-but-wrong out.

Judgement still wins where being wrong is expensive

There are areas where I still want human judgement firmly in the lead.

Architecture and boundaries are the obvious ones. Where should this responsibility live? What should this service know about? Is this abstraction buying us clarity, or just hiding coupling behind a nicer interface? Those are not typing problems. They are judgement problems.

Naming is similar. Good naming is not cosmetic. It is a compression of the model. It tells the next engineer what the system believes. AI tools can suggest names, but they do not reliably know which distinctions matter inside your domain.

Debugging subtle correctness issues is another area where judgement still wins. These tools can be very convincing while missing the thing that matters. They can explain the common version of a bug while your actual bug lives in an edge case, a race condition, a data contract, or a bad assumption between systems.

Security-sensitive code deserves even more care. Authentication, authorisation, input handling, infrastructure permissions, secrets, data access — generated code gets no special trust there. In fact, I tend to apply more scrutiny, because the code can look ordinary enough to slip through review while carrying a weak assumption.

The failure mode is not usually ridiculous code.

It is plausible code.

Plausible code is dangerous because it lowers your guard. It compiles. It fits the local style. It may even pass the first test you asked for. But it can still be wrong in the way that matters.

That is why I do not like treating AI-generated code as a separate category. The authorship question is less important than the accountability question.

If you merge it, you own it.

It does not matter whether you typed every character, accepted a completion, pasted in a generated function, or asked a tool to rewrite a module. The standard is the same. The review is the same. The responsibility is the same.

Generated code gets no free pass.

The junior engineer problem is real

The most uncomfortable part of this discussion is what it means for junior engineers.

I do not think the answer is to ban juniors from using AI tools. That feels clean, but unrealistic. These tools are part of the environment now, and pretending otherwise does not prepare people for the work they are actually going to do.

But I do think there is a real skill-atrophy risk.

The danger is not that a junior engineer uses AI to move faster. The danger is that they outsource the thinking before they have built the judgement to evaluate the answer.

A senior engineer can often look at generated code and feel that something is off. They can see when the abstraction is too broad, when an error path is missing, when the test is coupled to the implementation, when a boundary has been crossed, or when the tool has solved a nearby problem instead of the actual one.

That instinct was not gifted to them. It was built by doing the work.

If juniors skip too much of that struggle, they may become faster at producing code without becoming better at understanding systems.

That is not a moral failing. It is a leadership problem.

The job is to protect the fundamentals while still capturing the speed. That means setting expectations around AI use, but more importantly setting expectations around explanation.

Why this design? Why this boundary? What happens on failure? What assumptions does this code make? What did you verify? What would make this unsafe? What trade-off did you reject?

Those questions matter more now, not less.

For junior engineers, I want AI used as a tutor, pair, and accelerant — not as an answer machine. "Explain this code path" is useful. "Show me three approaches and the trade-offs" is useful. "Generate the whole thing and I will skim it" is risky.

The goal is not to preserve suffering. The goal is to preserve learning.

The work did not disappear

This is the part I think gets lost in the hype.

AI changes how some work gets done. It does not remove the need for the work.

A compiler changed how we write software. Frameworks changed how we build applications. Cloud platforms changed how we operate systems. None of those removed the need for engineers who understand trade-offs, failure modes, architecture, delivery, security, and people.

AI is another shift in the tooling layer. A powerful one, but still a tooling-layer shift.

The mistake is assuming that because the tool can produce code, the hard part was producing code.

It was not.

The hard part was knowing what should exist, why it should exist, where it belongs, how it fails, how it changes, who maintains it, and what risks it introduces.

That is people work. Engineering judgement work. Leadership work.

And that is why I think people become more important, not less.

Measure value honestly

The other trap is measuring the wrong thing.

Lines of code are not value. Number of commits is not value. A dashboard showing that engineers accepted thousands of completions may tell you something about usage, but it does not tell you whether the team is better.

The useful questions are closer to the outcomes we already cared about.

Did cycle time improve? Did review quality hold? Did defect rates move? Are incidents going down, staying flat, or quietly getting worse? Are engineers spending less time on mechanical work and more time on design, validation, and customer problems? Are we reducing toil, or just producing more code for the same amount of understanding?

A tool can make a team feel faster while increasing downstream cost. It can also remove genuine friction and give good engineers more room to think.

You only know which one is happening if you look past the demo.

I am optimistic about AI coding tools. Not because I think they replace engineers, but because in the hands of thoughtful engineers, they remove drag.

That is worth taking seriously.

But the leadership job is not to chase the tool. It is to build the judgement that makes the tool safe and valuable.

Invest in people who can reason clearly, review carefully, name things well, draw good boundaries, debug patiently, and understand the systems they are changing. Then give them better tools.

The tools will compound what is already there.

If the judgement is missing, the tools will hide that for a while.

Then the bill comes due.

Tools amplify judgement. They do not substitute for it.

That is the principle I would build around.