AI can generate code – experience determines whether that code should exist

In many ways, AI behaves like an incredibly productive junior developer. It works fast, always has an answer, and often sounds convincing. The problem is that convincing and correct are not the same thing. And just like a junior developer, the value isn’t having it work independently, it’s in knowing when to trust it, when to challenge it, and when to ignore it entirely.

In my daily work creating, discussing, and reviewing code, I see more and more developers use AI as part of their workflow - and for a good reason. It’s excellent for debugging, explaining unfamiliar code, generating boilerplate code, and tackling simple to moderately complex tasks. The problems usually start when AI stops being a tool and becomes a source of truth.

AI tends to solve the user’s problems quite well, very well in fact, but it solves them in an AI-way which can both be dangerous without the proper knowledge of the domain and the code it tries to change. Often you get a well written persuasive text explaining your new shiny changes, but if you stop for a second and actually review what the AI generated you may either be amazed at how good it is, or extremely puzzled by why it solved it in that particular way.

What makes the former particularly dangerous is that AI is usually wrong in a very convincing way. Since it never tells you it doesn’t know, and rarely pushes back on questionable assumptions, it confidently produces an answer, wraps it in a well structured explanation, and presents it as if it was the best solution ever. That makes it incredibly easy to stop thinking and treat the AI as a source of truth.

Over the past few years I’ve seen many developers get caught by this false sense of security - myself included. With AI being so persuasive the mindset quickly becomes: AI knows best, and therefore it must be correct. This is especially noticeable during discussing and reviewing code. Whether it’s in Slack or on Github, I frequently encounter AI generated responses that sound polished and confident, yet completely miss the point of the original question or concern. The issue isn’t that AI was used. The issue is when the response is posted without understanding, challenging, or validating it first. At that point, AI stops being a tool for communication and becomes a substitute for understanding. As developers, we’re responsible for the long-term health of our codebases. That requires us to understand the problems we’re solving, defend our decisions, and explain our reasoning. AI can absolutely be part of that process, but it shouldn’t become the source of our judgement.

The same principle applies when writing code, and is where experience, knowledge, and healthy scepticism come into play. Because being able to understand the problem and envision a solution before involving AI in the process can be a crucial factor - not only for the end result, but also for saving time. If you haven’t taken the time to understand the problem beforehand or the direction you’re aiming for, how can you expect AI to do it for you? Typically, what starts out as a productivity boost can quickly become a trap. You begin with a vague prompt, get a partially useful answer, refine the prompt, get another partial answer, and repeat the cycle until both you and the AI are stuck chasing a solution neither of you fully understands, and eventually you give up and decide to just start over. I think the following graph captures this scenario perfectly.

But in all seriousness, none of this means we should stop using AI. AI is a great tool, and when used correctly it can be incredibly powerful. The key is to avoid treating it as a replacement for understanding and judgement. As developers, we still need to take ownership of our code and be willing to sign our name to it with pride - not only because we want to keep our jobs, but because we need to understand the systems we build, make good architectural decisions, evaluate and understand trade-offs, and ultimately take responsibility for the software we deliver to the end user.

At the end of the day it’s still the developer who decides what gets merged into the codebase. AI can suggest, generate, and explain, and can even be right most of the time - but it cannot own the outcome. That responsibility still belongs to the developer, and is exactly why experience matters more than ever.

Claes Gill is a Senior Software Engineer at Witted.