"Is using AI to write code cheating?"
That's the question I asked myself when I first started dabbling with LLMs to generate code. Quite frankly: it felt dirty.
My first impression wasn't a good one. I used ChatGPT (I think it was v2 or v3) to help me generate some code and the results were...blah.
It kind of worked, but I noticed some issues. Bad formatting, weird coding patterns, and of course, the occasional hallucination.
But as I started to get better with prompting, my opinion changed.
Things that used to take me hours—if not days—to code 100% from scratch were taking a few minutes. If I were to rough estimate how much faster I was moving, it was easily 50-100%.
The real turning point was realizing that the LLM, if given proper context, could write code more or less like I wrote code. Once I got things fine-tuned, I had the "aha" moment.
"This is like having a pair programmer by my side," I thought.
Over the past few months, I've warmed up to using AI for programming. In terms of productivity, it's truly an evolutionary step.
That's both good and bad. It's good in the sense that, if you're an experienced developer, it can help you to write code and ship products at warp speed. If you're new, however, that benefit becomes a liability.
Years before I started Parrot, I made my living teaching other developers. I was fortunate enough to work with developers who had a wide range of skill sets. Beginners. Intermediate. Advanced. Everything.
When it came to AI, it gave me a deep understanding of how developers think and how such a tool might fit into one of those developer's day-to-day process.
For the intermediate-to-advanced developers (the one's who had experience writing a fair amount of code by hand), I wasn't concerned.
But for the beginners? It gave me shivers.
The reason why is that, with experience, you have an awareness of when and why something isn't quite right. Sure, the code may run as expected, but a trained eye really knows the difference between something that works and something that's right.
"Make it work, make it right, make it fast."
You've likely heard that quote by Kent Beck. And it's really good. I've used it for years as a measuring stick for the code that I'm writing (and my approach to iteration and refactoring).
When I first started coding, I only cared about #1: make it work. As I shipped more and more code, the other two steps started to creep in. My concern for making it right and making it fast grew, organically, as a result of experience.
In the post-AI era of writing code, for beginners, this all changes.
Because you're essentially getting the answer for cheap if not free (the cost being the time invested to find a solution), you're not likely to be concerned about making something right or fast (or even know that you should care about those things).
As a beginner, AI has, in a way, robbed you of the opportunity to understand the need for those things and truly learn how to achieve them.
I see this as posing two possible problems:
- Over time, we're less certain of the code being shipped. For small, non-critical B2B and B2C apps, this is mostly a trivial concern. For mission-critical apps, it's heart attack inducing.
- The quality of the average programmer declines sharply. Assuming we're just blindly trusting what the AI spits out, faced with a serious issue that requires an experienced developer to fix, businesses are either left to spend gobs of money to fix a problem, or even worse, be derailed straight into bankruptcy.
These concerns may seem extreme today, but as more and more programmers enter the industry with the added advantage of AI to help them write code, it's an all but certain future.
This brings me back to my earlier question: "is using AI to write code cheating?"
Yes and no. For a developer who already has several years of experience, I'd lean towards no as an answer as they've already spent their time in the trenches. But for a beginner, my answer is 100% yes. It's not cheating in the sense that you're doing something wrong, but rather, that you're cheating yourself out of the deep knowledge required to form expertise.
Pretty weird for a guy building an AI-driven business to say, eh?
It's because I feel responsible. I've been building things on the web for 17+ years and for the majority of that was forced to learn how all of this stuff works the hard way. Sure, I would have loved to go faster, but I really cherish the skill set I have today. It's what allowed me to ship Parrot in < 1 month of work.
Had I not "gone through hell," I wouldn't have made certain decisions that allowed me to save time and ship a high quality product. The app would likely—even with the advantage of AI—been riddled with bugs. It just wouldn't have been right.
Those are my thoughts. If you're new to coding and using Parrot, keep the above in mind as you work. Even if you can prompt your way to a shortcut, challenge yourself to do the opposite. A few tips:
- Instead of writing a prompt first, do some digging on Google. See what some of the different opinions are on solving your problem and try to understand the how/what/why of the solutions you find.
- Try writing a version of the code yourself. Assume that it won't work quite right, but realize the advantage of getting your hands dirty and really understanding what's happening when things go wrong.
- Use the generated code as a guideline/baseline against your own, hand-written code. Take it line by line, getting one thing to work at a time and figure out why it's working the way it is.
Beyond this, contemplate your long-term value as a developer. It's scary to see how "easy" it's getting to ship code, but understand that if you make a point to sweat it out, you'll be one of those rare, highly-valuable developers who can help to fix the mistakes of the less-experienced, corner-cutting developers that are actively flooding the market.
From one developer to another: I wish you the best of luck and hope the path you choose is one that's both lucrative and rewarding. I only ask that you keep the above in mind and think about how, one day, you might be the "grey beard" developer who's responsible for teaching younger generations how to make it work, make it right, and make it fast.
