LLMs
Why ChatGPT Won’t Replace Me as a (Human) Developer
Nina Holm-Jensen
Senior Data Scientist
The year was 2024. The future had arrived wearing the name ChatGPT, and everyone was raving. I was a senior software developer who had been called into a sales meeting to answer the customer’s more technical questions.
We made smalltalk over our afternoon coffee. And then they started asking questions. A few questions about data integrations. Some about our estimates. And then I was asked: “How can you estimate so much time, when I can ask ChatGPT to make it in five minutes?”
At the time, I was astonished – and, to be entirely honest, a little bit angry. I spent an embarrassingly long time ranting to my colleagues at the coffee machine afterwards.
But in the year since, I still hear the question asked. Not always as blatantly. But it is permeating the entire field of coding at this point.
So let’s explore it.
Everyone can code now
Everyone and their grandma has tried vibe coding their own app at this point. A friend of mine texted me excitedly the other day to tell me how he has vibe coded his own app to send love letters to his girlfriend. Last week, my project manager told me how he used Cursor to fix an issue in an old application, happy that he didn’t have to bother the developer who wrote it.
Romantic use cases aside, this development is exciting. On my end, as an “old” programmer, it is fun to get new tools to make my work faster. On a societal level, it is amazing how code is getting democratized. A lot of grunt work is being lifted off my shoulders.
But it is incredibly important that we understand what kinds of work ChatGPT can lift. And what kinds of work it cannot.
Consider my project manager who solved a coding issue with Cursor. If we envision an IT system as an elaborate birthday cake, then Cursor basically told him to get the blue sprinkles from the cupboard and to put them on the cake. That is impressive, for sure. But who made the cake itself? Who layered on the frosting? Who went and bought the blue sprinkles and put them in the cupboard? Not Cursor.
The “invisible” work I do
Let’s say I am asked to develop a new feature. What do I need to master in order to turn this feature request into actual value?
The first and foremost thing is to know the broader IT landscape. I need to know which tools are out there, what kind of problems they can solve, what is just new and shiny, and what is feasible.
It is knowing and understanding the IT landscape of my particular organization or project. It is knowing all the legacy code, which code repos are actually deployed where, the infrastructure, and which external systems we depend upon.
It is remembering the decisions we have made and why. This is especially important for the counterintuitive decisions we made ten sprints ago. Sometimes a database configuration is insane because it has to accommodate the legacy code once written by the founder’s teenage nephew.
It is knowing the requirements, both technical and non-technical, and keeping them in mind when analysing solutions. It is knowing which requirements are half-baked or inaccurately described (because life happens, and nothing is ever perfectly documented), either because I have been told, or because I have seen similar things before.
It is knowing all the things that are not written down but often discussed in meetings, like expectations for scalability, security demands, or cost limits. Often, I will be expected to prepare the system for a grand new feature before the feature is described – and often, working towards this fuzzily-described idea will save us much time in the long run.
It is constantly questioning whether we are solving the right problem in the right way.
It is building an actual, architecturally solid codebase which Cursor can read and act upon. Code must always be clean and extendable, meaning we can add more features with minimal pain. Clean code is an art and a discipline, and it is crucial for preserving our lead time.
It is reading and understanding the code before accepting Cursor’s proposed changes to my codebase. Metaphorically, Cursor might ask me to sprinkle chili flakes on my birthday cake, and I have to know whether it is the right thing to do.
Why can only a human do it?
Because humans are imperfect, social creatures. We are creatures of emotion, of connection, of politics. All these things are incredibly important when gathering the knowledge I need to turn code into value.
This is why the coffee machine is the most important place in any organization. I go there, and I overhear my colleagues talking, and I realize that someone on another team has just solved the problem I’m agonizing over, saving me days of further work.
As a human, I can hear the hesitation in the product manager’s voice when she describes a new feature request, clocking that she isn’t entirely confident in its value.
I understand that other work is done by other humans. I send the email asking our devops guy to set up data backups in our system. I send that email again. I then bring him a coffee and a smile, shamelessly bribing him to solve my problem during a clearly overworked day/week/month/worklife.
Because empathy and connection is something only another human can offer.
ChatGPT does not drink coffee
And now we come full circle. ChatGPT is amazing and will revolutionize the field of IT (as it will revolutionise so many other fields). It is already changing the way I work, the way I talk to my project manager, the way I interact with new knowledge.
ChatGPT is an amazing assistant, which I can direct according to the needs of myself and my customers. It is a great tool which I can wield. But it is only a tool, and it needs competent human oversight.
ChatGPT does not drink coffee. That is its largest shortcoming.
I do. That’s my greatest strength.