Photo: Tech. Sgt. Lauren Gleason, U.S. Air Force, public domain.
The State of Things
Within the corporate world of coding, LLMs are, at least in my sphere, ubiquitous. In some ways, this is fantastic. To all those who complain about slop code and hallucinations, I can assure you that both of those things were happening in astonishing quantities even before LLMs arrived on the scene. So, to some degree, this is a welcome tooling improvement and possibly even an increase in median code quality inside a lot of companies.
But I’m worried. In the old world, you could not help but learn. When you had to go spelunking in some old legacy codebase, you probably picked up a few new tricks and maybe even learned about a build system against your will. We complained about it at the time, but that slow accretion of new ideas and skills was really meaningful. And that’s not even counting the occasional nerd sniping or the rabbit holes you’d go down while yak shaving, only to decide that YOU were the person who was going to fix this particular annoying
None of that happens anymore. We don’t run into the friction because the LLM smooths it out for us. We don’t see the different ways things are done because the harnesses don’t even show us the code as they work anymore.
Instead, we probably have three to five projects going at once and are just cycling through them as the agents come back for their next prompt. We really are all suffering from being promoted to managers, and our technical skills are atrophying.
What can we do, then?
$work is not going to want us coding at 2 mph when we could be doing 30 mph with agents. I think we have to take a page from other industries that have gone through the heavy shift from manual to automated technical work, specifically aviation, where manual flight hours are required in order to maintain qualifications, even though autopilot is capable of doing a large amount of the flying. In order to remain competent and have any hope of actually improving our skills, it’s going to take dedicated effort. And until $work figures this out, it’s going to have to happen on our own time.
What should that look like?
Do things by hand at home. Suffer through the friction of setting up a project on your own. Learn a new language. Go read Knuth. Basically, all the same advice from the before times applies. Possibly even more now than ever, having a broad base of knowledge is an advantage. Learn things one layer below the current level of abstraction at which you work.
Read, write, code, and avoid LLMs when off the clock. If you haven’t already, go write a coding harness BY HAND and see how it all works.
I would go so far as to say that those who avoid LLM usage the longest at $work will be at an advantage. These tools are trivially easy to pick up and don’t require any special skill to master. If you had missed out on the last year of the LLM explosion and just jumped in today, you would probably have a sharper set of technical skills, and you’d have fewer preconceived notions about what models can do. You’d also be less likely to underestimate what you can ask of the latest-generation models.
Closing
There are always exceptions. Some people have the discipline to work on one project at a time, never press the easy button, keep the LLM in check, read all the code, maintain the mental model, etc. But it is generally better not to assume you are the exception and to just put in the work instead.
AI Disclosure
An AI spellchecked this. The words and thoughts are my own.