How AI Could Replace Your Job as a Software Developer
At a recent Live!360 tech conference I attended in Florida the keynote speaker, Marcel de Vries, the CTO of Xebia Microsoft Services, said cautiously, “I think [in the future] we will not be programming in C#; I do not think we will be programming in JavaScript; I think we will not be doing Java, anymore — because we will be programming in natural language. We’ll just describe what we need and the AI will take care of it in us just putting in the natural language and it spitting out the executable.“ As a software developer, surrounded by hundreds of other tech professionals who probably felt about the same, it didn’t exactly make me feel all warm and fuzzy inside. Ever since then, as I continue to adopt more AI into my daily work, it has me thinking a lot about how AI could replace your job as a software developer.
My Reluctance to Adopt GitHub Copilot
My first exposure to GitHub Copilot was in November of 2022. I had installed it in VS Code and had been wanting to try it out. I’d heard a lot about it, both good and bad, and had been reluctant to adopt it for quite some time. Once I’d had it installed I of course started with the basics: I tried making some simple HTML files, a little JavaScript and I’d also given it a go in Visual Studio with some C# code. After a couple of hours of playing around with it, I realized I pretty much hated it. It was slow, it made many errors and sometimes didn’t even come close to doing what I’d asked it to do. So, with little care for trying it any longer I deleted it and moved on with my work.
Roughly 16 months after that, around February of 2024, I found myself at a new job, with an opportunity to join the GitHub Copilot Community of Practice (CoP) within my new organization. It sounded like fun and I was willing to give it another try. But this time, using Copilot just felt different. I started to realize what had actually happened that first time I tried using it back in 2022 (apart from it being horrible and seemingly useless). This time around I was forced to face those same initial emotions I’d had before but that I stuffed way down deep. And I realized that it was less about the crappiness of the tool and more about what I was scared of - the risk to my career as a developer and to my own livelihood, ultimately - change.
How Other Software Developers React to Using Copilot
I’m not shy when it comes to my opinion of Copilot, or GitHub for that matter. In the past year I had a very difficult time working with GitHub when they suspended a new account I’d made for a bookmark extension I’ve been working on. I had intended to make it open source and so I chose GitHub as my platform, since it’s the de-facto platform for that type of project. So, it’s a bit ironic that I’m back to using Copilot given my scathing review of what I think of GitHub. But sometimes you just have to swallow your pride and move on. Anyway, back to my point…I’ve experienced a mixed-bag of reactions from other developers so far, both in person and online, when it comes to using AI to code. And the main concern I hear come up time and time again, is the same thing I told myself when I first tried using it. “But, what about code quality? You still have to know what the code is doing if you rely on Copilot to generate it.” Which is a perfectly valid argument and one that I don’t think anyone would disagree with.
What I’ve deduced from this sentiment is that I think that most, not all, but most developers who are trying AI code tools for the first time have a very similar gut feeling — this seems like a potential threat to my job. When you pick apart the meaning behind the comment and apply it to our existing world as software developers (assuming a world without AI) the same idea of having to know what the code is doing, can and should be said about the code we write, today. Anyone writing code knows that you don’t simply go to Stack Overflow, copy it and then paste it back in your program and call it a day. You have to have the tacit knowledge to determine which code snippet is likely going to work, or that is most appropriate. And then you copy and paste it in to your code, tweak and rework it to get it to function properly. Where you source the code you’re going to use also doesn’t only ever come from Stack Overflow. This could be code that is created and written in documentation right from Microsoft that you’re trying to add to your project. And all of this requires at least some basic understanding of how to program in the first place. This process also comes with a responsibility to know what your code is ultimately doing. If things break in the future and you can’t fix it because you don’t understand it, that’s not going to fly.
So, my response to both myself, and anyone who says that you still need to know what the code is doing is just that - of course you do. But that is actually where one of the most powerful features of Copilot starts to shine; one that you simply cannot get when you’re sourcing your code suggestions from Stack Overflow, from the Microsoft docs, or anywhere else on the internet. The ability to contextually drill-down into the code suggestions it’s providing to you. One of the main things I like to say about Copilot, now that I use it every day in my career, is that it’s like having hundreds of talented and experienced developers right at my fingertips, ready to have a conversation about my code. And that is what’s changed my mind about using it, and what continues to make it so impossible to live without as a software developer, today.
Leveraging Copilot for Deeper Learning and Efficient Coding
One of the sessions I went to at the Live!360 conference was from a software developer named, Chris Klug. In his session titled, “Stop Using Entity Framework as Just a DTO Provider!” he made a comment that really stuck with me. It went something like, “How many times do any of us developers go dig in the documentation, take word-for-word what we find in there, get it working in our code, and then move on? Never to even think really beyond what was shown initially to us in the documentation?” I’ll speak for myself on that one and say, I am absolutely guilty of this. There are times where, months later I’ll start to dig into things a bit more, and learn a thing or two. But more often than not, due to time constraints, deadlines, meetings and life outside of work, we simply don’t have the luxury of going really deep into things like we’d probably like to. This is where Copilot excels and one of the main features that I’ve been taking advantage of with it all year long.
The primary way in which I use Copilot is not for its code suggestions, it’s for learning concepts and supplementing my knowledge specifically, and contextually around my own code. Yes, it can be used to speed run writing unit tests or for quickly making a website for you (see video below). And yes, I do use it to speed run developing things outside of work. But that’s because the last thing I want to be doing is wasting a single minute of time outside of work on fumbling through code. I just want things to work and to be done with it. So that’s to say that I think that the main advantage it gives me as a developer is to be able to tell it to spit some code out, get it roughly 80% of way to the goal line and then I come in and finish fitting everything in to place. Just like we’ve already been doing by relying on internet resources since forever (except for when you had to read from a physical manual if you had the privilege to learn on a Commodore 64 - I sadly did not get this opportunity 😔).
And once I get things to this state I don’t stop there. I’ll then highlight a piece of code, something I’ve maybe never seen before or simply want to know more about, and I will ask it to give me more information around it. This is something that, at least in my career so far, has never been possible. You can paste your snippets into Google all you want, but you’re going to have to determine, through clicking through link after link, what thing is most relevant, and then start reading - most of the time only to find out it’s garbage, and you start the process all over again. The alternative, which I will admit I have been very fortunate thus far in my career, is to have the benefit of working alongside very talented developers and to have them mentor you on things along the way. But, even in this scenario you can’t be messaging your coworker every five seconds and bothering them with trivial questions while you are trying to cement a concept in your brain.
So in a way, programming with Copilot has actually made me a much more knowledgeable developer. I’m not asking questions to Google that I don’t even know the words I should be Googling, let alone knowing that I’m on the correct bit of documentation for it. And I’m also not having to sort through comment after shitty comment on Stack Overflow about how the OPs question is off-topic, or that it’s stupid, or that the second reply should be the suggested answer. All of this noise is draining when you’re trying to get code written, and Copilot not only keeps you contextually within the IDE, it trims all of that noise out for you in its responses. And as a result I get to focus more on writing code and have less context switching, less accidental side quests while Googling, and less strain on my brain while I’m trying to figure something out.
A Thought Experiment for Myself and for Other Developers
There is, however, a big, hairy elephant in the room with all of this. And something that does still have me a bit uneasy, because it poses an existential threat to my profession, and yours as well. This idea that programming the way it’s always been done is headed for extinction. The idea is that we won’t be programming in C#, or JavaScript or Java, anymore. That we’ll be having so-called “conversations” with our computers; telling them what to do and how to create a program by using our natural language. And then it takes that natural language and it converts it into our program. He bolsters this idea by asking, “[When] was the last time you checked if your compiler created the right assembler?” To which, apart from maybe doing a decompile on a dll back into C# or copying dll files for manual inclusion in a project, I can say that I have never verified the output of the compiled code. The reason he asks this question is to challenge this idea that so far, AI generating code has not been high quality enough, or that it will be riddled with errors. And this is a big concern I currently have. And it’s also been my experience so far when using Copilot to generate code for me.
So, ultimately the reason I say this is a thought experiment for myself and for other’s is that this is a concept I personally have yet to truly stomach and accept. But when you compare it to the fundamental concept of what it is to write programs, it actually makes perfect sense. All written programming languages are simply abstractions that sit atop other abstractions. I’ll always remember a former colleague of mine teaching me the concept of code design and patterns being “turtles, all the way down.” And if you apply that to this next iteration of using AI to write code, it fits perfectly. What we will say with words, in our natural spoken language, will simply be one more abstraction atop our existing layers of code that will then be compiled into something that gets closer to the computer code. Creating programs will become a conversation, which ultimately means that creating programs will become more accessible and approachable than ever.
Summary
I think overall we have a long way to go before AI starts creating entire large, complex programs on its own. Marcel goes on to talk about “self-healing” applications, which I’ve tried experimenting with myself with little success. So far, by simply using Copilot at least, it doesn’t have the ability to create, review and modify an entire program that lives inside a directory. One time I’d intentionally forced a barebones application to fail and I fed the log files back into Copilot and asked it to go fix the broken code and update any necessary files. It was simply too much for it to handle, and it failed. But, I have no doubt that this is where things are headed.
In much the same way as we’ve seen other industries impacted by technology, we’re now seeing those same changes take place at our front door. Take construction for example, where there used to be a need for say 10 people to drive all the machinery and manage a worksite, there are now companies providing autonomous conversion kits for massive multi-ton pieces of equipment. So, what used to take 10 people now takes 1 person watching computer screens in a little room nearby monitoring the workflow.
Where I used to be reluctant and in denial over adopting the use of AI as a software developer, I’ve now flipped my view of it all as being open and adapting to a changing tech landscape. Because at the end of the day what we do really isn’t about the code itself. We’re programmers, but more importantly we’re problem solvers. And so long as there are problems to be solved, there will always be a need for people like us. Nobody truly knows what the future will look like, but by accepting that change is happening and getting on board early enough in that transition, we can at least ensure that either way this works we’re not left behind because we were being sticks in the mud. Ideally, we set ourselves up well enough and can be lucky enough to be that one person in a little room managing the work it used to take 10 people to do.
Notes:
I highly recommend watching Marcel de Vries presentation. It’s a pretty big eye-opener, but I think that most people in our industry would benefit from giving it a listen.
