Stack Underflow: Losing the Craft of Coding

As a software engineer at a big tech company, I accomplish a non-trivial portion of my work with ⌘+C, ⌘+V — plugging the contents into my AI agent and letting it do all the thinking and execution for me. I’ll even use agents for technical conversations where I’m out of my depth. A fellow engineer will message me a question and I’ll paste the conversation directly into the agent. Sometimes in meetings, I’ll transcribe a question in real time to my agent so I can reply intelligently without missing a beat.

Much of my work at this point is that of a stenographer and a puppet. My contribution, laughably, is re-humanizing the AI output — tweaking responses in my own language and editing AI-generated documents for readability. It sounds lazy, and it is. But the truth is, this workflow is not specific to me. We are all, to some extent, stepping away from the work and handing it off wholesale.

More and more, as engineers adapt to the new vibe-coding paradigm and gain literacies across AI development workflows, we lose the hard skills that have been abstracted away.

I was affronted with this realization when I took a coding test last week, half for fun and half to see whether I could still do it. I found myself stumped almost immediately. Not stumped on the problem per se; the problem was simple, and I could describe — even teach — the solution conceptually. But when it got down to the implementation, it felt like coding on a typewriter. I gave up and shut the laptop.

The high-level architectural know-how was still there, but the muscles of execution had withered. It was jarring to reckon with this. I’ve been coding for over a decade, I now work a job where I am constantly building and maintaining complex code repositories, and suddenly I can’t build a tree in Java.

We are in the midst of a de-skilling epidemic. For big and small tech companies alike, AI’s supersonic growth and ubiquitous adoption now raises the existential question: Will AI’s capacity to write and debug code grow fast enough to make up for the de-skilling of engineers? The answer will determine our salaries and jobs. It may also determine the survival of the companies themselves.

The past three decades painted an illustrious image of software engineering: glimmeringly intelligent minds collaborating on difficult problems to solve real-world issues, sculpting innovative technologies to furnish the future of our wildest dreams. From website designers to system architects, it was a class of bona fide brainiacs with skills, wits, and intuitions forged in the fire of years of painstaking mental labor and marathon debug sessions.

The 2010s of computer engineering selected its enterprising cohort for their mastery of computer science fundamentals, and for their patience, experience, and wherewithal in designing elegant UIs and complex architectures. Coding was still manual: to build something from scratch, engineers would create new files in a directory, toggle between them, type out lines of code one character at a time, run the code, and debug until they reached the desired result, typically over the course of hours, days, or weeks.

Hard skills were the gatekeepers to mouth-watering entry-level “FAANG” jobs — that is, jobs at Facebook, Amazon, Apple, Netflix, or Google. Junior engineers earned their shot by performing well on “coding challenges” — live programming tests designed to assess whether they could, for example, build a directed acyclic graph or architect a dynamic front-end interface. Coding was an obstacle course, and the better you were at surmounting the obstacles, the better you were at the job.

The speed with which these long-held markers of engineering capacity have lately fallen into disuse has produced incredulous, industry-wide whiplash. The labor of an engineer used to be that of a draftsman, bricklayer, cement pourer, mason, woodworker, steel cutter, electrician, plumber, and project supervisor, all wrapped up in one. Now the labor of an engineer is that of a mere commandant. The advent of LLMs, and of multi-agent orchestration tools, has birthed a sort of “middle class” of software engineers, who function in a supervisory or managerial capacity.

But how good will we be at our AI-supervision jobs if we lose the skills AI replaces? As every engineer knows, the quality of a manager’s work is largely limited by their own technical expertise. A trope in the software engineering world is that of the overly ambitious, borderline antagonistic manager who knows nothing about what he’s asking the engineers to do and expects it done in a miraculous timeline.

There’s an argument to be made — a bet, more so — that the hard skills we were once required to master are now and forever obsolete, and thus that the withering away of low-level competencies is unproblematic. But I would venture that what has always been true in software engineering will remain true: he who understands the layer beneath will thrive.

Ultimately, engineers debug and build; that’s the job. Of course, a modern-day AI-fluent engineer can point an agent to a problem and say “fix this,” and it might accurately debug the problem, though at other times it will flounder. It will dive deep down misguided avenues and spit out useless code that tangles the web beyond its own capacity to disentangle it. This is when the AI-fluent, code-poor engineer hits his ceiling. And then what, nuke the project and start over? This might work at a startup, but not at a tech giant with a codebase comprising billions of lines, where a single deployment failure could cost the company millions of dollars.

At big tech companies, managers now explicitly instruct their engineers to familiarize themselves with AI tooling and integrate it into their workflows. Underlying these instructions is an earnest human-to-human plea: “If you want to keep your job, don’t fall behind on this stuff.” From an organizational top-down perspective, this sort of messaging makes sense: optimize productivity by encouraging AI fluency, then prune a bloated workforce of all those who can’t keep up.

At the same time, I wonder if a more violent pruning will take place — if the pendulum will swing back to reprioritize antiquated skillsets and fossilized intuitions. If a company wanted to drastically reduce its headcount and every engineer was equally fluent in AI, the most valuable ones to retain would be those with the most seniority, the most native instincts.

Code-rich engineers, with a decade or more of industry experience, have an indomitable edge — they are the least immune to de-skilling, even with an increasing reliance on AI and a sharp decline in manual code production. It’s hard to shake off such well-formed and deeply reinforced intuitions.

On the other side of the spectrum, college students who delegate their computer science assignments to Claude are doomed. Coding, quite literally, is a linguistic exercise, and as anyone who “hasn’t spoken Spanish since high school” knows, such fluencies atrophy over time.

What’s puzzling about this modern interregnum in software engineering is that, in some respects, the engineers working in big tech understand that the job security is the opposite of what it used to be. The era of “you can always find a job if you know how to code,” during which software engineering was the safe post-grad path, is history. The current class of junior and mid-level engineers now coast along a dying career path, mere years away from mass extinction, either scheming an outright pivot or clinging to the AI vanguard in hopes of surviving the job-pocalypse.

Soon, junior and mid-level positions will be abstracted away entirely. An agent will be deployed with contexts across all of the applications an engineer has access to, so it can autonomously complete the work in their stead. The funny thing is, engineers themselves are hastening this dystopian reality.

It seems, at this point, that AI-generated code will continue to improve at a rate that renders mass de-skilling a non-issue. Computer science has seen a number of paradigm shifts over the last forty years, and as new layers of abstraction have been introduced to separate the engineers from the work, they have adopted new skillsets and shed those of their predecessors. By the time engineers were working in Python, the lessons of assembly code were safely obsolete. Even so, as the majority of the de-skilled workforce focuses myopically on leveraging AI, the very best will continue to understand, question, and improve what’s underneath.

But this shift is unique to all those prior. For an engineer, shedding the fundamental skill of writing and analyzing code is decapitating. It dulls a sharp technical mind into a formless mass, ill-equipped to debug even the simplest problems because of its distance from the underlying implementation.

Is fear warranted? Is it really so bad, in other words, if we do de-skill? It wasn’t a requirement to know ancient programming languages in the era of modern programming. Will it be a requirement to know how to code at all in the era of AI?

What we can say now is that, without the executive skillset of a programmer, the work becomes flimsy and superficial. Engineers have transitioned, essentially, from being foreign language specialists to mooching off of translators. Not only do we not write code anymore, we hardly even look at it. There is such little doubt in AI’s capacity to produce clean code that engineers often just tell the AI to write something, then test what it’s written and demonstrate that it’s working. Debugging workflows now take the form of prompts like, “If it’s working, great, push the code; if not, fix it and tell me how you did it.”

This is no longer a “layer” of abstraction; it’s a tectonic plate. And for those who identify as engineers, it leaves little ground to stand on.