The invention of the chainsaw didn't make the knowledge of how to fell a tree obsolete, but it sure made the process a whole lot faster.
If you're writing software and not using LLMs, you're working at a fraction of the pace of those that do. While it's not going to create some world-changing algo today, it completely eliminates most of the boiler plate you need to type out, makes implementing tests much, much faster. At least that has been my experience in Golang at work.
> At least that has been my experience in Golang at work.
Maybe so for you, but you might want to think about why your work involved so much boilerplate and routine content in the first place. If so much of it is easily completed by an LLM already, was your employer really paying you some large share of your 5-6 digits of compensation for every year? Do you think most of your value to the company has just been in typing boilerplate and mindlessly generating tests until now?
Personally, I'd feel pretty insecure in my career and underdeveloped in my trade if I could answer yes to that.
If it does apply to you (or others reading this), hopefully you can exploit this brief window of gained personal productivity to develop more valuable skills and get your tasked to more valuable roles asap. Software engineering as a profession isn't going anywhere, but the people most helped by today's fairly primitive LLM coding assistants are the ones that are actually vulnerable to be squeezed out of the trade because it means they're the not actually contributing very much specific expertise.
The productivity change you've experienced should be taken as a bright red warning flag that you've unwittingly settled into a role as an technician getting paid highly because of ephemeral demand bubble rather than the valuable engineer you might imagine yourself to be.
I just want to add that many desk jobs do the equivalent of writing boilerplate code. Copying from calendar A to calendar B is a real 70k/yr job I’ve seen. And from what I can tell, being a human shell script + representing that function (responsible face and name) characterizes lower tier white collar jobs.
So the mere existence of “worthless” churn in your job isn’t evidence that you aren’t solving business problems that are worthy of pay.
To put it another way. Most jobs exist to make a problem go away for an executive.
I understand you are also getting at the ethos of good engineering and encouraging this person to take pride in their work.
> you've unwittingly settled into a role as an technician getting paid highly because of ephemeral demand bubble rather than the valuable engineer you might imagine yourself to be.
I have not seen this put so succinctly and this cannot be repeated enough.
Most of what I do at work is not necessarily the same thing as the value that I add. I solve business problems with software. A very good portion of that is just boiler plate and lines of code that anyone can write. Someone has to write the main.go, read in the cli args, the environment args, define and initialize the API clients, define the server api spec, and then finally, you write the business logic. Then you write the tests to validate the business logic.
Many of those tasks can be completed via normal copy and paste. It's much faster to have the LLM do it. When you're initializing a client for a database in go, you can refer to the library on how to do it, or you can just let the LLM do it.
Maybe you have a photographic memory and you don't need to reference docs for other people's libraries, I don't have that ability. But the LLMs do, so I use them.
If you're writing software and not using LLMs, you're working at a fraction of the pace of those that do. While it's not going to create some world-changing algo today, it completely eliminates most of the boiler plate you need to type out, makes implementing tests much, much faster. At least that has been my experience in Golang at work.