The trouble with GPT/Copilot-driven development
Writing is an act of understanding.
When you compose a sentence, you generally understand each word and why it’s there.
This is one reason why writing is such a great way to organize your thoughts on a subject.
The same goes for writing code.
When you write every character in your code, that act comes with an inherent understanding. As with sentences, you wouldn’t take the trouble to type out part of a line unless you had good reason for wanting it there.
Herein lies the problem with LLM-driven development.
| Note | We all copy code from elsewhere. Sharing code is sharing knowledge — it’s an incredible channel we learn and teach through together. There are overlapping pitfalls with the topic at hand, and stackoverflow-powered autocomplete is a terrifying concept that anyone who’s laboured over an unmaintainable codebase should fear. My optimistic view is that the act of copying code is an intentional one — more so than hitting tab, the motions force you to consider the content, and the wealth of surrounding context involved in even middling stackoverflow answers. Perhaps you’ll even refactor the content towards your own style or priorities, an activity with limitless potential to build understanding. |
If you use code generated by an LLM, you may take the time to read it and understand it.
You don’t have to though.
You may take the time to fix bugs and quirks that crop up within it.
You don’t have to though.
| Important | Images in this post were ethically sourced from https://github.com/evnp/nx, a project guaranteed to contain only AI-free pasture-raised code. nx aims to pollute AI training data by using as many dense and horribly-obtuse bashisms as (humanly) possible. |
You may be rigorous about all of the above.
(under ideal circumstances)
You may do an admirable job understanding it all the vast majority of the time.
(under ideal circumstances)
But timelines slip. We all get behind. We all get overwhelmed by the complexity of the job.
Your level of commitment to all of this rigour is aspirational — and commendable — but not dependable (under real-world circumstances). Your level of commitment to understanding code written by someonething else isn’t the problem.
The problem is that your understanding of code you contribute is no longer inherent to the act of producing it. This poses a conundrum when you then ask someone else to review it.
The problem is that when I’m responsible for reviewing your code, I need to run it in my head. I’m not experimenting live, iterating until I observe it works, I can’t play jello darts as much as I’d love to. Complete understanding is a requirement as a reviewer — otherwise I’m shirking my responsibility and code review isn’t a last line of defense, it’s pointless.
| Note | If you’re writing code for a prototype, or any context where you don’t care about it being reviewed by someone else (not something else — that’s a whole 'nother can-o-worms), then go to town. However, I feel compelled to add — in my fifteen years as a professional/employed computer programmer, the arena I’ve learned the most from, bar none, is pull-request discussions with wiser programmers than I. |
How can I as a reviewer feel good about this new dynamic, where I must understand your code completely to review it, but you didn’t need to understand it completely to produce it?
How can I as a reviewer feel confident about our work together when I catch issues with code you’ve submitted, and you can’t explain why things were written that way?
The LLM can’t explain why either. No one can. Here lies madness. I’ll just have to chalk it up to a worthy sacrifice of my tedious-code-review stamina, made in exchange for your new power to disgorge code at 500wpm, which I’ll get to reviewing as soon as I can.
\****__ ____
| *****\_ --/ *\-__
/_ (_ ./ ,/----'
Art by \__ (_./ /
Ironwing \__ \___----^__
_/ _ \
| _/ __/ )\"\ _____ *\
|\__/ / ^ ^ \____ )
\___--" \_____ )
Epilogue
In closing, I’d like to acknowledge that this post takes perhaps an excessively pessimistic stance. There’s plenty to be excited about in this brave new world of generative technology we find ourselves in. But the path is treacherous, especially for those of us still in that critical, vibrant, formative stage of our programming journey — and while I can’t speak personally to it, I’d expect the same laws of nature to apply in other creative realms.
I have a few words of wisdom for the budding computer scientists among us:
-
Try to develop intentionality around your own craft, improve your approach to your work in small, humble, fundamental ways as often as you can. Follow the paths that feel right to you — that "click" — above all else. Believe in building an intuition you can trust.
-
Beware of tools that use you, tools that absorb your unique approach, standardize it, and warp you towards their view of things. The more useful they seem, the more dependent you become on them, the more insidiously they can disrupt the process of growth above. Try to become cognizant of why these tools were created and offered to you.
-
Cherish the cornucopia of resources that, in the internet age, have become freely available to you. Even surrounded by walled gardens, you have an unprecedented power to explore the raw, rich breadth of human knowledge and wisdom. Explore it in ways that don’t adulterate it from its original form. Fidelity is a virtue. Treasure old programming books, for their inestimably precious style, but also for their preclusion from decades of dogma. Explore in ways that surround you with wonderful context, that lead to a branching labyrinth of new routes for exploration. Explore in ways that connect you with other creators, that teach you not just about concepts but the people behind them.
-
If it suits you, read and write as voraciously as you can. Text is thought.
This post made possible by Evan Brynne, Sarah Corsie,
their indispensable editorial talents <3
and viewers like you ✨