Programming Before ChatGPT Era?
Someone recently asked me:
“Are you a better coder with ChatGPT?”
That’s the wrong question. In fact, the entire premise is wrong.
What did it mean to be a good programmer before ChatGPT? It was based entirely on how well you could ideate, build, debug errors, Google answers, and iterate.
A non-trivial part of the process is learning what to do when you’re faced with an error. There’s two kinds of errors: the scary-red-lines type and the more subtle logic and implementation errors. When faced with the first, a novice programmer will grapple with common pitfalls (off-by-one errors), or the quirks of the language (pointers vs. direct values, object manipulation). When faced with these issues, you learn how to interpret the errors, Google answers and how to read and write in that specific programming language.
Subtle logic and implementation errors are harder. Maybe your algorithm works perfectly most of the time. Or your app is too slow when retrieving from the database. Or you’re burning through API credits and have to make your system more efficient. When faced with these kinds of issues, you learn how to problem-solve. You learn how to recognise if a problem even exists.
You learn how to use debugging tools like breakpoints (*cough* print statements *cough*). You learn how to diagram a “better” solution, how to design more performant systems, how to organise and structure your code and much, much more.
Notably, this all takes time. The timeline for idea product is “slowed down” by all of the learning done1.
Before ChatGPT, it was difficult and inefficient to build something novel while simultaneously skipping these learning steps.
Programming After ChatGPT Era:
Today (December, ‘24), the programming landscape looks different. If you want to build something, a potential process could look like:
- Ideate
- Craft a prompt describing what code you want.
- Take the generated code, run it and note any errors / improvements.
- Craft another prompt to iterate over.
While this exact process will likely be dated soon, the key idea remains: Programming skill is increasingly about how well you can ideate and “prompt” in new improvements2. You no longer need to learn how to interpret errors and traditionally problem solve to build something3.
This Isn’t New:
Building a technological product has always had a prohibitive barrier to entry, but it’s steadily fallen over time. In the early 1970s, programming often meant manually manipulating computer memory. Resources were limited, so every instruction mattered.
Languages like C abstracted some of this complexity, and Python built on this by eliminating memory management altogether. Simply declare a variable and the language would take care of the rest. The barrier to entry continuously fell4.
The specifics of how memory works under-the-hood are increasingly abstracted, making it easier for developers to focus on what they want to build rather than on how to build it. AI tools like ChatGPT represent the next step in this progression.
After all, the hottest new programming language is English 😉 5.
The Near-Term Future of Programmers
For Programmers in Large Corporate Environments:
The vast majority of people in “Software Engineering” positions are creating micro-products constantly. They’re given a “ticket” that details exactly what’s expected of them and a time-frame to complete it. They’re often asked to build (or more often - change) a tiny component in a much larger system, admittedly a non-trivial task.
These programmers, in the near-term, will be able to complete many more tickets in the same amount of time6. And it will be a lot harder to fire these programmers than just giving them more work.
So tickets-completed-per-man-hour will rise7 (this won’t necessarily coincide with hiring rate changes). But will the supply of tickets in these big corporations rise correspondingly?
and then handed another whenever they’re finished.
The field of computer science is currently undergoing a hiring crisis. Tech companies systemically over-hired for years after 2018. Now, undergraduates are finding it comparatively harder to get jobs.
Society has always valued people who build things other people want. But building technology has always had a prohibitive barrier to entry. As AI makes building more accessible, builders without traditional coding skills will still create.
TODO:
- Make this all not read like utter crap
- Explain the difference between coders + builders
- Explain the value coders will (likely) have over builders
- Becoming a combinatorial system that overcomes either as an individual.
- The long-term future.
Footnotes
-
These learnings eventually pay dividends. More on that later. ↩
-
Prompting and iterating with a language model is not a trivial task. To get the most performance out of a model, you should learn how to write prompts they best respond to (i.e. prompt engineer). Albeit you don’t need to learn this to build a product; à la “vibe coding”. But your ceiling of ability is heavily constrained… for now… (December ‘24). ↩
-
Cursor (an AI-first code-editor) has a dedicated button(!) to feed a given error into a language model and get a potential solution. Or the “Chat” functionality is just a short-cut away - simply ask a LM to change something in the product and it will. Minimal (and increasingly less) debugging from you is required. ↩
-
My very first foray into coding was Scratch - a simple visual coding language built on “blocks”. The ceiling I could build with it was incredibly low, but I (maybe) wouldn’t have built anything if BASIC was the only option available. ↩
-
This is contingent on companies adopting these technologies. Many (most?) large companies have implemented some privacy-protecting version of ChatGPT (source: trust me bro). But many were only after 12 months.
It’s a much rarer sight that you see a large corporate (insert any financial institution here) providing their engineers with Cursor licenses. ↩
-
A programmer could (hypothetically) spend 8 hours to complete 1 ticket. Now, with Cursor, it may take them 4. Therefore, ↩