There is a distinct, quiet disquiet settling over the software engineering landscape today. You can feel it in LinkedIn post threads, in hushed conversations over coffee with senior colleagues, and in the background noise of tech news cycles. On one side of the coin, we are navigating an unprecedented era of tech layoffs, budget contractions, and corporate belt-tightening. On the other side, artificial intelligence is advancing at a dizzying, almost relentless speed. Coding agents write entire pull requests, generate complex unit tests, and spin up functional microservices in seconds.
It is almost impossible, even for the most seasoned engineer, not to feel a creeping sense of existential dread.
Will things go sideways for my career? And even if things do go well in terms of employment, will the job change so fundamentally that what I originally fell in love with simply isn't there anymore? Are we being demoted from architects and problem-solvers to glorified code reviewers, wading through mountains of syntactically correct but emotionally hollow machine output?
To understand what we risk losing, we have to look back at why most of us entered this discipline in the first place.
Every programmer remembers the first time they made a machine speak. They remember seeing Hello, World!
appear on a dark terminal screen.
The older you are—or the lower down the stack you started—the more magical that moment felt. Writing Hello, World!
in x86 assembly or C, manually managing registers or pointers and coaxing the operating system into outputting a handful of bytes to stdout
, released an entirely different tier of dopamine than executing console.log("Hello, World!")
in a browser console or getting a chat model to generate a full-stack dashboard.
section .data
msg db 'Hello, World!', 0xA
len equ $ - msg
section .text
global _start
_start:
mov eax, 4 ; sys_write
mov ebx, 1 ; stdout
mov ecx, msg ; bytes to write
mov edx, len ; message length
int 0x80 ; call kernel
mov eax, 1 ; sys_exit
xor ebx, ebx ; exit code 0
int 0x80
Why did that simple assembly snippet feel so profound? Because of the friction.
The dopamine didn't come from the text on the screen; it came from overcoming the hurdles along the way. It came from fighting linker errors, deciphering cryptic compiler messages, understanding memory alignment, and fixing segmentation faults. The core joy of programming was never the raw output—it was the cognitive struggle of solving the puzzle and the deep, permanent learning that occurred during that struggle.
With AI coding agents, the value proposition has inverted. The new pitch is speed and pure ideation: you dream up a concept, and the agent builds it. You act as the product director and code reviewer. But in stripping away all the friction, we have also stripped away the source of satisfaction. Reviewing machine-generated boilerplate simply does not ignite the same psychological spark as wrestling a complex algorithm into submission with your own brain.
The new joy—if we can call it that—is fast, efficient, and useful. But it isn't satisfying in the way old-school engineering was.
Faced with this shift, I have made a conscious decision: I am stepping off the fast train to a certain extent.
This is not a Luddite rejection of modern technology. I am practical. If a task is repetitive, mechanical, or inherently boring—writing standard boilerplate, generating repetitive schema migrations, or setting up mundane configuration files—I will happily hand it off to an AI agent. There is no honor in manual labor for tasks that carry zero educational or architectural value.
However, when a problem is complex, critical, and intellectually interesting, I deliberately choose to step in and solve it myself. I choose to embrace the friction.
More importantly, I am doubling down on fundamental Computer Science principles over transient AI tooling.
Every few months, a new framework emerges promising to orchestrate agentic workflows, chain LLM prompts, or automate software development lifecycle tasks. Learning the API of a hyped AI framework might give you a short-term productivity bump today, but that framework will likely be obsolete in two years when the underlying models evolve.
I would much rather spend my time building an HTTP server from scratch in Rust, implementing a key-value store, writing a custom memory allocator, or understanding OS kernel internals.
Understanding protocols, concurrency models, memory layouts, and data structures creates knowledge that compounds over decades. Tooling fades; core principles endure.
If you look at the broader software industry today, we are witnessing a visible surge of enshittification, low-quality code slop, and short-term corporate greed.
Driven by aggressive sales targets and quarterly earnings pressures, tech giants and enterprise platforms are rushing unfinished AI features and half-baked infrastructure to market. Look at massive cloud ecosystems like AWS or Microsoft Azure: under constant commercial pressure to beat competitors to market, vast swathes of services suffer from bloated configurations, inconsistent APIs, and brittle integrations. Features are pushed out fast, but the underlying engineering discipline is frayed.
Yet, even within these corporate giants, pockets of pure engineering excellence still manage to thrive. Take the TypeScript compiler team at Microsoft as a prime example. Why does TypeScript remain such an extraordinary piece of software? Because the team behind it operates with a relentless commitment to correctness, language semantics, and long-term stability, relatively isolated from raw feature-rush sales targets.
And when you look at the industry with a 10- or 20-year horizon, the real winners—the foundational technologies that power our global economy—are almost exclusively the projects that refused to sacrifice engineering excellence:
These systems weren't built by rushing slop to market to hit a quarterly target. They were built by engineers who cared deeply about the craft.
In his famous autobiographical book, Just for Fun: The Story of an Accidental Revolutionary, Linus Torvalds articulated a philosophy that defined the open-source movement: the greatest technical achievements don't come from market pressure, but from human curiosity and the sheer enjoyment of solving hard problems.
That ethos is the path forward for software engineers in the age of AI.
Consider the historical parallel of the samurai sword master. When modern industrial metallurgy and firearms arrived, traditional sword crafting lost its practical utility as a weapon of war. By purely economic metrics, samurai sword makers should have vanished entirely.
Yet, centuries later, master blacksmiths still forge katana using traditional methods. Why? Because their absolute dedication to excellence, discipline, and craftsmanship elevated their work from a utility tool into an enduring art form. They survived because people recognized that human mastery possesses an intrinsic value that mass manufacturing can never replicate.
AI will automate immense amounts of software generation. But it will never take over true engineering excellence. The engineers who treat software as a craft—who build with deep understanding and care—will endure, just as the master craftsmen did.