Much has been made about AI generated code slop in the last year. It’s easy to point at as a reason to reject AI use. Of course we said the same about the PC, the internet, the smartphone, the cloud. All had (and often still have) their problems.
Why AI Is Not an Easy Button
From my own experience, I can offer the following analogy. Many people seem to think of AI as an easy button. You want something, you describe it, press a button, and go get a cup of coffee. Indeed, when you come back, it appears you have what you wished for. You then make your next wish, rinse and repeat. This process continues until you think you have a solid solution, but you start to encounter bugs or worse, security issues. You then have to spend time debugging code you didn’t author, probably the least favorite task of any software engineer. Wait! There’s an easy button! So you tell the AI to fix its own problems while you scroll through your social feeds. When it thinks it’s done you go back to making wishes. Or you start making demanding prompts as if multiple exclamation points will provide better outcomes. Does this sound familiar?
You could argue that the quality of the code is in question if bugs are introduced so easily. I disagree. Perhaps that argument may have been true a year ago, but I can tell you from decades of engineering experience, that that is no longer the case and it’s improving on a nearly daily basis. It is not perfect and I often have to say “why not just do it like this…”, but it’s no worse than a pull request comment at this stage.
How to Use AI as a Fast-Forward Tool
What I have found is that it’s not an easy button. Instead it’s a fast forward button. It allows you to skip through the tedious steps of writing the code and instead focus on the overarching logic and architecture of the solution. Let’s pause for a moment and revisit that sentence. It allows YOU to focus on these things. If you abdicate that responsibility to the AI, it will happily do its best. However, the final result is often not what you expect and can carry a lot of design decisions you disagree with.
In the Adam Sandler movie Click, he is given a magical remote control that allows him to fast forward through his life to achieve his desired goals. And it works, but in the process he has jumped over years of his life. His actions and decisions while on auto-pilot during those years have huge repercussions on his family and social life. In the end he learns the lesson that he must pay more attention and throws the remote away.
So is the right approach to throw AI away and do it “the old-fashioned way”?
Of course not, but it does mean that you have to pay attention to the design decisions as they are added to your project. A small decision that is missed can have huge repercussions as you keep moving forward. If Adam had instead only fast-forwarded a day at a time, he could have achieved his goal in a shorter amount of time and have kept his family life from becoming a mess.
The best approach I have found is to use a solid workflow and either watch changes as they are applied or review them carefully before merge (or both). Even then, it takes a nuanced eye and experience to spot issues. This is why I think the role of AI taking over human knowledge roles is a bit overblown.
With that said, if you don’t have the knowledge or experience, it will be a struggle for you to identify these issues. I, for example, wouldn’t be able to spot a contract loophole generated by AI any better than a lawyer could spot a security loophole when vibe coding. But if you are the type of engineer (or lawyer) who churns out the same type of code (or contracts) over and over, your role is definitely in jeopardy.
What This Means for Engineers
The future dynamic of AI and human interactions is unfolding as we watch. I’ve already had my “come to Jesus” moment. I’m still the same engineer with all the same experience, however I look at project work differently. Gone are the days of poor requirements. You get what you ask for. If you ask for a house and didn’t specify what kind you are just as likely to end up with a bird or dog house. Gone too are the days when there is not enough time to do it right. Unit test coverage, architectural diagrams, documentation and more are just there for the asking. Gone are the days of ignoring technical debt because it’s “too much” effort. A time will come when productivity is measured in minutes and these will slide back down the priority scale. Thankfully that is not for a while.
The true challenge is to achieve your goals with the right approach so that bugs and rework are kept to a minimum. This includes all the things we know we should do as engineers, but never seemed to have the time.
Good luck and best wishes!