AI Coding Assistants Aren't the Risk. Your Engineering Practices Might Be

“The real risk of AI coding assistants isn’t bad code — it’s not realising the risk isn’t the AI.”

The Conversation That Keeps Happening

A year ago, if you had asked me what my most common conversation at work was, it wouldn’t have been about AI coding assistants. It definitely wouldn’t have been about rollout strategies, risk models, or the difference between a Copilot and a Claude (spoiler: that’s not even a valid question).

But now it’s almost every conversation. Across clients, engineering teams, and leadership discussions, the topic keeps coming up. The wording changes, but the fear doesn’t. And in almost every one of those conversations, I find myself coming back to the same thought: we’re focusing on the wrong thing.

The Fear Everyone Starts With

Most conversations start in a familiar place, usually framed as a concern about quality and control. People worry that AI will fill their codebase with garbage, that standards will slip, or that they’ll lose the ability to properly review what’s being written. Alongside that sits a slightly different concern about learning; particularly for junior engineers. If someone can prompt their way to a working system, are they actually developing the skills they need, or just assembling something they don’t fully understand?

These aren’t unreasonable fears. In fact, they tend to come from experienced engineers who have spent years dealing with the consequences of poor code and weak engineering discipline. They care about quality, and they’re right to. But while the concerns sound sensible, they’re also slightly misdirected.

The Uncomfortable Truth

The uncomfortable truth is that humans already write bad code, and they always have. No team is shipping perfect software today, and none ever have. The way we deal with that isn’t by expecting perfection from individuals, but by building systems that assume imperfection and catch it before it causes damage.

That’s why we rely on code reviews, CI pipelines, automated testing, and static and dynamic analysis. These aren’t optional safety nets; they are the foundation of how modern engineering teams operate. They exist precisely because we don’t trust individual contributors, however experienced, to get everything right first time.

Which makes the reaction to AI-generated code slightly strange. The same engineers who trust these systems to manage human-written code suddenly question whether they’ll work when the author isn’t human. But the reality is that nothing about those safeguards changes. If you enforce test coverage thresholds, they still apply. If you run SAST or DAST scans, they still run. If your CI pipeline blocks unsafe changes, it will continue to do so.

The real difference isn’t capability. It’s speed.

What I’ve Actually Seen

This isn’t theoretical for me, it’s what I see happening day to day. As I’m writing this, I’ve got GitHub Copilot’s CLI running in the background, working through a set of tickets I assigned earlier. It’s using an agentic “squad” model, with different roles handling frontend, backend, testing, and coordination, and even a scribe keeping track of progress and changes.

When that work completes, it raises a pull request which goes through exactly the same process any human-generated change would. CI/CD pipelines run, code review tooling kicks in, static analysis scans execute, and the solution is deployed to an integration environment where tests are run before being torn down again. The difference is that the loop happens quickly, and some of the feedback cycles are handled automatically before a human even looks at it.

What’s interesting isn’t just the speed, it’s the behavioural change it unlocks. When engineers are freed from repetitive work and boilerplate, they start to explore more. Ideas that would normally get dropped during refinement because “we don’t have time to figure that out” suddenly become viable. You start to see quick proof-of-concepts, alternative approaches explored earlier, and refactoring that would previously have been deferred.

The impact on junior engineers has been particularly noticeable. One of my team started using Copilot not to generate code, but to understand it; asking questions about how different parts of the system interacted, or what specific pieces of logic were doing. Instead of waiting for time with a senior engineer, she could work through problems independently, reducing how often she was blocked. Over time, that translated into more confidence and less hesitation. Imposter syndrome is real, and having a tool that allows you to ask questions without judgement changes how people engage with learning.

There are also more subtle effects. Engineers tend to default to familiar solutions, either out of habit or because it’s efficient. AI introduces a second perspective, which can challenge that default thinking. As a senior engineer, I’ve often relied on explaining ideas to others just to clarify my own thinking, effectively using someone else as a sounding board. A strong model can play a similar role, offering alternative approaches or highlighting considerations you might have missed. That doesn’t replace collaboration, but it does change how and when it happens.

The Risks You’re Missing

If you’re worried about risk (and you should be) it’s worth looking in the right place. The failure modes I’ve actually seen aren’t about AI producing obviously bad code. They’re more subtle, and they tend to stem from how teams adapt (or fail to adapt) their practices.

One of the first issues is what I think of as PR blindness. As generation becomes faster, the size of changes tends to increase. Not intentionally, but gradually. At some point, pull requests become large enough that they are no longer meaningfully reviewable. Engineers scroll, skim, look for obvious issues, and approve. We’ve all done it. The uncomfortable question is whether we would have properly reviewed the same change if it had been written by a human. If the answer is no, then the problem isn’t the AI; it’s that our review practices haven’t evolved to match the new reality.

A related issue is workflow mismatch. Many teams initially treat AI coding assistants as a more powerful form of autocomplete, slotting them into existing habits without changing how work is structured. That approach tends to encourage generating large chunks of code in one go, skipping natural checkpoints and collapsing multiple logical steps into a single change. Used well, these tools support a more iterative, collaborative style of working, where changes are broken down, validated, and refined in smaller increments. Used poorly, they amplify the tendency to do too much at once and tidy it up later.

The final risk is cultural. Organisations often introduce the tools, perhaps run a demonstration, and then assume engineers will work out how to use them effectively. Some do, but many don’t. The result is inconsistent usage, quiet frustration, and sometimes misuse that reinforces the original concerns. Without a shared understanding of when to use these tools, how to use them, and what good looks like, adoption becomes fragmented and difficult to manage.

None of these are AI problems. They’re engineering discipline problems.

The Reframe

AI coding assistants don’t remove the need for good engineering practices—they make their importance more visible. In strong teams, where changes are small, review is meaningful, and systems are in place to catch issues early, these tools act as an accelerator. They allow engineers to spend less time on repetition and more time on design, intent, and problem solving.

In weaker environments, where large changes are common, review is treated as a formality, and discipline is inconsistent, the opposite happens. The same behaviours are amplified, and the risks people were concerned about begin to materialise—not because the tool is inherently unsafe, but because it reflects and scales the existing way of working.

That’s the real risk. Not that AI will suddenly degrade the quality of your codebase, but that it will expose where your practices aren’t as strong as you thought they were.

What Comes Next

The conversation around AI coding assistants is still focused in the wrong place. We’re debating whether the code they produce is good or bad, when we should be asking whether our teams, processes, and culture are ready to use them effectively.

Because at its core, nothing fundamental has changed. Software engineering is still about managing complexity, validating behaviour, and working collaboratively to build reliable systems. AI doesn’t remove those responsibilities—it accelerates them.

In the next posts, I’ll dig into what this looks like in practice:

• How to introduce AICAs without breaking your team
• The real impact on junior engineers
• What good usage looks like day to day

Thank you to Matt Taylor and Brett Jordan on Unsplash for the photos in this post.