We’re Coding Faster, but Are We Still Engineers?
I’ve been watching our velocity charts lately, and honestly? They look amazing. We’re shipping features at a pace that would have seemed like science fiction a few years ago, and most of that is thanks to the AI sitting in our IDEs. But if we’re being honest with ourselves, there’s a quiet, creeping cost to all this speed. We’re starting to trade the actual “craft” of engineering for the convenience of a generated snippet, and that trade-off is more dangerous than it looks on a dashboard.
The “Looks Good to Me” Trap
The biggest issue right now is the breakdown of the code review. When you spend two hours fighting with a logic problem, you know that code inside and out. When an AI spits out a solution in two seconds, you’re just a spectator. It’s incredibly tempting to skim an AI-generated PR, see that the tests passed, and hit “merge” without actually understanding the “why” behind the logic. This “validation gap” is where the most annoying bugs hide, the kind that don’t break a unit test but absolutely wreck a production environment because of some subtle, unintended behavior the AI couldn’t have predicted.
Security and the Frankenstein Codebase
Then there’s the security side of things. LLMs are basically the world’s best copy-pasters, but they don’t actually care about our specific security protocols. They’ll happily suggest an outdated library or a vulnerable auth pattern just because it was common in their training data. If we aren’t manually auditing every line, we’re basically leaving the keys under the mat.
Get Yassine Beldi’s stories in your inbox
Join Medium for free to get updates from this writer.
On top of that, we’re seeing a real fragmentation in how we write. If three different devs are using three different AI agents with three different prompting styles, the codebase starts to look like a patchwork quilt. Without a unified standard, the architecture becomes brittle and a nightmare for whoever has to maintain it six months from now.
The 18-Month Wall: When Speed Becomes Stagnant
There is a pattern emerging in teams that lean too heavily on AI: the first three months feel like a superpower, with features flying out the door. But around the 18-month mark, many of these same teams hit a wall. They realize they’ve accumulated what experts call “Comprehension Debt.” Because the developers were essentially “directing” the AI rather than deeply building the logic themselves, they lost the shared mental model of how the system actually fits together. When a complex bug inevitably appears, no one on the team can explain why certain architectural choices were made. As noted in the AI Technical Debt Crisis, the “instant” code of last year quickly becomes the unfixable legacy code of today.
Reclaiming the Driver’s Seat
To keep from losing our “engineering muscle,” we have to find a better balance. AI should be the intern that handles the boring, repetitive boilerplate — not the architect making the big decisions. We need to make sure we’re still spending time coding manually and digging into the documentation, or we’re going to wake up in three years and realize we don’t actually know how our own systems work.
Implementing rigorous peer reviews and holding ourselves to a standard where we never merge something we couldn’t explain on a whiteboard is the only way to stay in control. Speed is great, but it’s worthless if we’re just building a house of cards.
Final Thoughts
Ultimately, AI is a tool, not a replacement for the curiosity that brought most of us into engineering in the first place. It’s okay to let it handle the grunt work, but we can’t let it do our thinking for us. At the end of the day, our value isn’t measured by how many lines of code we can generate in a minute; it’s measured by our ability to understand, question, and actually care about what we’re building.
Let’s make sure that when we look back at our projects a year from now, we see a reflection of our own expertise and craftsmanship, not just a collection of successful prompts. Speed is a nice bonus, but building something that lasts — and knowing exactly why it works — is what makes us engineers.
