Stack Underflow: Losing the Craft of Coding — The New Atlantis

Essay

Summer 2026

Stack Underflow: Losing the Craft of Coding

Software engineers are now Claude Code managers. But how can I manage what I’m forgetting how to do myself?

Jarett Malouf

Subscriber Only

Sign in<br>or Subscribe Now for audio version

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...