Keeping Technical Skills in the Age of the LLM
the end of the era and new one beginning
I’ve seen this topic arise a few times, sometimes shouted from a Substack, other times running as a strong undercurrent among some unhappy technologist. Either way, it boils down to the same problem that an entire generation of software engineers and other technical folk are wrestling with ... It’s even taken on the hues of a life-and-death struggle between two factions.
To LLM or not to LLM, that is the question.
Being a person myself who was and is a self-taught programmer, having never taken a CS class in my life, I find the choice between the red and blue pill an incredibly difficult one, depending on the day. God knows what the right answer is; I don’t know. Most likely it doesn’t matter, and I will be long gone to the sky or retirement home before the die that has been cast is actually settled. To better help you understand the epic struggle I find myself battling inside myself every day when I open the terminal to do some work or exploration, and in that single split second decide whether I will type “Claude” or something of my own choosing, let me take you back to young me.
The early years.
I come from a family of tinkerers, first mechanical and then digital. Growing up in the heart of the Midwest, beaten beneath that unforgiving sun, or frozen stiff in the cold north winds of the winter; it would not be uncommon circa 1998 to be found in two distinct places on a Saturday morning.
{ BTW. I write about those experiences on a separate Substack. }
First …
More often than not, I would find myself amusing myself amidst a vast pile of old and decaying cars piled to the sky, otherwise known as a junkyard. Often we would be on the search for a specific make and model, whos general vicinity was hand waved by some mysterious old man with a cigarette hanging out of his mouth standing next a burn barrel spewing forth the blackest smoke. Unless my skinny arms and young fingers were needed to wrench on some hidden corner of an engine, I would happily collect the spare change from the cigarette trays of 100 old cars. Then we would leave.
Second …
Many a time we would end up at my uncle’s farm, a lonely spot on the undulating prairie of the North, whose vocation as a shop teacher held many delights for a young boy. He was a most unusual shop teacher for his time; not only could he explain and tear into anything mechanical with delight and knowledge, but he also had a love for computers. It turned out to be a bug that affected a fair number of others, cousins, brothers ... and the like.
Today’s sponsor is Estuary. Without them, this content isn’t possible. The best way to support this Substack is to click the links below and give Estuary a try.
Pipelines built by an agent, orchestrated by you
Estuary Agent Skills lets your AI assistant draft production-grade data pipelines from a plain-language description, right inside Claude Code, Cursor, or the tool you already use. The output is config in your repo, not a black box. You review the diff, approve it, version it, and roll it back like any other infrastructure. Same runtime as every other Estuary pipeline. No separate “agent mode.”
I caught that bug young. Sitting in front of his Mac II, or later in front of Netscape, I felt that dial-up tone do something to my heart and mind I cannot explain. If you know, you know. What followed in the years before and after was an ever-increasing obsession with computers and all that they could do.
Sure, I would leave his house and drive the dirty gravel roads another five miles to my grandmother’s farm, where I would promptly seat myself on the top of the D17 Allis Chalmers (a tractor 🚜) with either a shotgun or fishing pole cradled in my lap, depending on the season. This was my experience growing up, and still is to some extent today.
I spent hours, nay, days, playing Myst, Doom, Yahoo Pool, chatting on MSN Messenger trying to find a girlfriend, World of Warcraft, later Battlefield 1942, and Halo, Limewire, while at the same time perfectly content to roam the woods and waters looking for the next meal.
Early on, I learned about Perl from a cousin I worshipped and became enamored with the terminal. From an older brother, I learned of something called PHP. The rest, as they say, is history. I spent my high school and college years working with the LAMP stack, picking up Objective-C, Droomla, hand-rolling servers, MySQL, CSS, HTML, PHP, and my beloved Perl. Mostly as a hobby, one of many, but I never thought of it as a career.
How do we save our souls from the Agentic Devil(s)?
So, with that long-winded and highly short view to the past, from the days before we even had StackOverflow to tell us we were absolute idiots not worthy to touch the keyboard for asking a question; we come to the crux of the position programmers find ourselves in. In some respects I envy the new breed of developers who come of age when Claudius Maximus reigns supreme; they don’t know what they don’t know; those little buggers probably sleep like logs.
Not me.
The existential crisis we find ourselves in, much like Neo, is: do we accept what we don't like, or do we fight back against the Machine? Like Cypher do we sell our birthright for a bowl of porridge, or in his case, a nice juicy steak?
Chew on that AI goodness, that sloppy code spewed out, just close your eyes and tab your way to a PR.
Look, we programmers have to eat. That’s what the luddites and witch hunters of old who refuse to dain to bend the knee to the AI gods are missing. It’s the context that matters. Some of us are gainfully employed by companies who, fully within their rights, have decided that the use of Agents in coding is the way forward and the future. If you refuse to drink from the cup, you are sealing your own fate. We can’t simply bite the hand that feeds us. We don’t have that luxury. We have mortgage payments, kids, cars, gas, healthcare, Big Slurps from the corner store; ya know, we don’t want to live in a van down by the river. At least not yet.
We do what we are paid to do. If we are inside a culture that encourages and tells you to use Agents for all aspects of the Software Lifecycle … then we do what we are told.
You can’t put the cat back in the bag. Indeed, at least in the short term, there are many aspects of the Software Lifecycle that benefit greatly with the use of LLMs.
Infra as Code
Documentation
Testing
Research
Finding edge cases
Exploring architectures and options
Generating boilerplate
Projecting planning
Even for those people that hate LLMs for coding can’t reasonably deny the use of Agents in these basic concepts. An LLM paired with a Senior+ Engineer is a sight to behold; the speed of what can be researched, planned, and built… is amazing. Yet, the very elixer we drink can posion us.
Yes, of course, with a few decades of experience and Claude, I can single-handedly output unthinkable amounts of code, features, research, plans, etc. But I do think all is as it seems. We have known, collectively, for some time that software solutions are more than just code. Software involves end users, engineers, product-market fit, cost, infra, on-call, alerts, monitoring, data, analytics, teams, inter-team communication, stakeholders, and the list goes on
The core issue(s) with The Vibes.
There is a time to vibe, and a time not to vibe. We have to be realistic about the business we operate in and the Vibes that call out to us from the terminal. A person/team can get into serious trouble without strong boundaries and leadership in the age of The Agent. You can very quickly vibe yourself into a corner that is hard to get out of. All of a sudden, those sweet tokens that were once an offering of incense sent up to Saint Anthropic will become a bitter pill.
Here are some extermely obvious gotchas.
In a codebase with lots of Vibes … no one really understands what’s happening and why.
Over time, The Vibes will erode the skills of those you depend on to keep “things running.”
The Vibes will cause you to move faster than you should. Solutions will come before thoughts.
Less code means fewer bugs and a better overall experience; The Vibes will have the opposite effect.
It isn’t possible to review the amount of Vibes that are produced.
The Vibes can become a serious lynchpin and breaking point. (think something breaks and Claude is down)
You're one bad Vibe away from production destruction or security breach.
The problem is that Agentic Coding is a new frontier, pun intended; we don’t know, and won’t know the full effects until years from now. We know that it’s not going anywhere; businesses everywhere are scrambling to get on the Agentic Bandwagon without much thought for the unintended side effects … if there are some.
I can feel the change in my bones, can you?
After weeks of the Vibes planning a new project, researching, MVPs, spewing out code that works, understanding what went wrong, trying to tweak a complicated piece I never wrote, incorporating more business logic … I can FEEL the difference. I can feel the difference in the solution; I can also feel the difference inside myself when I start on the next project.
I’m not as sharp. My mind is overcrowded, foggy, dull.
Maybe it’s the speed at which we are now required to attempt to comprehend complex solutions and their various impacts on the business, people, and projects. Technical and non-technical processes that took days and weeks collapsed down into ten minutes of tokens. How can you really understand the impacts of what is happening, the side effects, the best choice? Talk to the relevant stakeholders and read between the lines of what they need and want. You can’t.
How to not lose your technical skills when Vibing.
There is a time to vibe, and a time not to vibe. We have to be realistic about the business we operate in and the vibes that are expected of us. We have to pay The Piper that pays us; do what they want. But you do have skin in the game. You have your technical skills and abilities hanging in the balance. One must remember that most of us are just little pawns acting within a cosmic game of chess. You should be wise and understand that your technical skills gleaned over years and decades are what make you … you. They are what make you valuable in the marketplace, set you apart.
Do you really want to walk away from all actions that caused you to learn and grow, just so you can meet a token budget and get the Vibes out 6 hours faster than your coworker? That is short term thinking that will bit you in the !@#$ later.
Say what you want, if you write no code yourself, and simply review code, barely, for weeks, months … a year; will you still be the same programmer a year later? No, you will not. It’s not magic. Practice makes perfect; if you don’t practice, you will lose the skill(s) over time. All that research, talking to stakeholders, writing the minutiae of code, thinking about tradeoffs, MVPs, POCs; when you put your hand to the plow, you get calluses that help you the next time around.
So, getting down to brass tacks, how can we not lose technical skills in the Age of AI?
5 steps to keep your skills sharp.
Remember, you are your own best investment; putting time into you will give the best ROI. No one else is sitting around thinking about the you that will exist 10 years from now, what your professional life and skills will look like. Will you be stronger, or atrophy into oblivion?
Here is what I do to keep my technical skills sharp.
No rocket science involved, or double backflips; just the simple exercises of your skills and mind that will keep it sharp and on point. Not dulled down by King Claude after handing over some of the most valuable skills you have. We learn through experience, through struggle … Agents will steal this from you if you are not careful. You will hand over your critical thinking skills, research skills, desire and willingness to learn new languages and concepts, and communication with others. Stop doing things at your own peril. You will truly become a mindless tab engineer, no matter how pretty your prompts are, if you stop learning and growing. Don’t let the LLM learn for you.
1. Write some code by hand.
Take the time to write some code by hand, even if it is on the weekend. It will force you to think, read, fail, try again, and remember the fundamentals. Things you forget about when you no longer write code.
2. Read and consume good technical materials.
I know there is a lot of “AI Slop” out there, some good, some bad; either way, reading and consuming material about other problems people are working on and solving is something that pays back in spades later on down the road. All of the information is like money in the bank that you can draw on later. I read a lot, but a few Substacks like these will keep you informed about what is going on in the greater data and software community.
Ananth Packkildurai and the Data Engineering Weekly is a must.
The Gergely Orosz and The Pragmatic Engineer is gold.
Of course there are many more; I wrote this article on other blogs I follow if you want some more ideas.
It’s fair to say that you can’t read enough, and that is the truth. It expands your horizons, opens you up to new technologies and solutions, and what other people are working on; it gets you out of the box that you work inside.
3. Learn new tools and languages. Anything new.
When I mean anything, I mean anything. The reason it’s important to learn new things is that there is usually a fair amount of struggle and work involved. You can’t ask for a better teacher than something hard that you have to earn. It could be a whole new programming language, maybe a new package you haven’t tried; sometimes the simple act of solving a “new-to-you problem”, even in a caveman-like way, is going to keep your wits sharp.
The worst place youd could possibily be is waking up 1 year from now, with a wonderful Agentic workflow, using the same old prompts and same old tools. Realizing you … I mean YOU … haven’t hard to struggle to learn a new concept or tool once.
Fight against that tendency to be lazy; push yourself to be uncomfortable; find yourself in a position where you don’t know what you are doing or what the right answer is. This is the best place you could possibly be. Others will be growing lazy and overfed on their generous allowance of tokens, unable to program their own way out of a box within a short time.
4. High-level project planning + critical thinking.
The other important part of software projects that is only quasi-technical but core to the way we can deliver good solutions, on time, on budget, that meet our end-users' needs … is project planning … and the closely tied skill of critical thinking. Project planning in software requires not only technical know-how, but a wide array of soft skills that reach far into other areas and groups inside whatever business you find yourself in.
Understanding and obtaining user requirements and desires.
Understanding the C-Suite and how to play their games.
Thinking about the best solution that can be delivered and how to say no.
How to communicate with others, how to lead by example, and how to bring others along.
Making critical tradeoffs in technical areas and business areas, weighing options and making decisions.
The list goes on.
I have used Claude many times to help me plan and suss out the details of many large-scale projects involving multiple people. Sure, it feels good at first; you feel like you’re getting somewhere without much effort … the only problem being YOU didn’t put the time or effort in to think through the options and plan yourself, so you get to watch it slowly unravel, show cracks, and generally feel ill-prepared for the future ahead or answering questions and solving problems that inevitably come.
5. Write and communicate with LLMs.
I want to let you in on a little secret. Shhh … don’t tell anyone; it’s a superpower. Did you know that when trying to communicate an idea or message yourself, when you actually write it out yourself or speak it, you actually have to understand it at a deeper level than if an LLM does the work for you?
Shocker, I know.
For example, when I wrote to you about Cloudflare as a Data Platform, I knew exactly what you did beforehand. Nothing. Zilch. Nada. You know what I knew when I finished? More than I did when I started. Also, alot more than some talking head on Reddit who’s never actually DONE ANYTHING without Cloudflare. Suprise.
If you’re writing a Slack message to a co-worker or boss, and you have to explain why you did something the way you did … it makes you stop, think, consider. Does this communicate what I want? How will they take it? Do I need to do something else to make this clearer? There are few people more valuable in the marketplace than those who can communicate clearly and are good at it from practice.
At the end of the day.
Do what you want at the end of the day; you are your own boss, and you get what you put in. We must just learn to ride the winds and waves of popular opinion in the world of CTOs and do what we are told like good little hobbits. But we must remember that if we turn over the minutiae of how we go about our work day to day, we might wake up and find ourselves worse for wear. I suspect in a year or two, many a once mighty Senior Engineer will find themselves slipped back into the Slough of Despond to wrestle and battle with the Juniors.
This will not be the fault of Claude or Anthropic, or your boss. It’s your fault.
You are smart; you know how you learned and gained experience to land where you are today; it’s not a secret. You are the one who did it after all. Consider those things. Remember your first love. Code. Read. Learn. Grow.