The Plumber Always Has a Job: Why Deep Knowledge Still Wins in the Age of AI

There's a question making the rounds in every engineering Slack, every tech subreddit, every conference hallway: are coding jobs dead?

The answer, if you spend enough time thinking honestly about it, is no. But the more interesting answer is: it depends on what kind of engineer you are.

The Credential Trap

A lot of engineers right now are scrambling. Contributing to open source not because they care about the project but because it looks good on a promotion rubric. Taking courses not because they're curious but because someone told them they should be. Chasing the identity of a "serious engineer" without interrogating what that actually means for them specifically.

This is understandable. The industry is loud about what a good engineer looks like. OSS contributions. Side projects. Deep systems knowledge. A GitHub profile that bleeds green.

But there's a difference between wanting to be a certain kind of engineer and wanting to want to be that kind of engineer. That distance — two layers removed from actual desire — is where a lot of people are living right now. And no amount of courses or pull requests fixes a motivation problem dressed up as a skills gap.

What AI Actually Changes

Here's the honest picture of what AI tools like Claude, GitHub Copilot, and others actually do to software engineering: they compress the middle.

Boilerplate is cheaper. CRUD applications are faster to ship. The engineer who knew exactly one framework and applied it the same way every time is genuinely more replaceable than before.

But the engineer who understands why the system is slow, why the database query degrades at scale, why the memory usage spikes at 3am — that engineer is not more replaceable. They're less replaceable, because AI tools make the surface layer cheap and the deep layer relatively more valuable.

The Plumbing of Modern Systems

Consider what happens when you use something like Claude Code — an AI agent that reads, writes, and executes code on your behalf. On the surface it feels like magic. Underneath it is a set of deeply human engineering problems.

• There is an agent loop: a continuous cycle of sending context to an API, receiving a response, parsing whether the model wants to use a tool, executing that tool, feeding results back, and repeating. Managing the latency and cost of that loop efficiently is not a solved problem.
• There is context management: every message to a language model has a token limit, and deciding what to include — which files, which history, which results — without bloating the prompt is a genuine systems challenge involving chunking, summarization, and retrieval.
• There is sandboxed execution: the agent runs bash commands, reads files, spawns processes. Someone built the security layer that decides what it can and cannot touch. Someone debugs it when it breaks.
• There is streaming and reliability: responses arrive token by token over a network that drops packets, times out, and has bad days. The code that handles this gracefully, retries intelligently, and fails safely was written by an engineer who understood the system below the abstraction.

None of this is going away. If anything, as AI systems become more capable and more embedded in infrastructure, the demand for engineers who understand what's happening underneath them will increase. The AI raises the floor. It does not lower the ceiling.

Depth Comes From Friction, Not Curriculum

Here is the uncomfortable truth about becoming a deep engineer: there is no shortcut, and most shortcuts are actually detours.

You do not become a systems engineer by completing a Coursera specialization, though good courses help. You do not become one by contributing to a popular OSS project, though that experience has value. You become one by encountering a problem you cannot solve with the tools you have, refusing to accept the surface explanation, and pulling on the thread until you understand what is actually happening.

The engineers who know internals deeply are not smarter than everyone else. They accumulated hours in discomfort. They debugged things that made no sense for days. They read source code not because it was fun but because the alternative was not understanding. And then, somewhere in that process, it became interesting — because understanding is intrinsically rewarding once you get a taste of it.

The question is not "how do I learn internals." The question is "what problem do I care enough about to be frustrated by." That frustration is the curriculum. Everything else is just material.

What to Actually Study

If you want to develop genuine systems depth, the path is less exotic than it sounds.

Start with how computers actually work. Nand to Tetris — a course available free online from Hebrew University — builds a complete computer from logic gates up through a programming language. Most working engineers have never done this. The ones who have think differently about every layer above it.

Then study operating systems. Not to become a kernel developer, but because the OS is the contract between software and hardware. Understanding processes, memory management, scheduling, and file systems means you can look at a performance problem and reason about where it could possibly be coming from.

Then pick a real problem in your actual work. Slow queries. Memory leaks. Mysterious latency spikes. Follow those problems down as far as they go. Use profiling tools — perf, flamegraphs, strace. Read the source of the tools you use when they behave unexpectedly. Instrument everything.

The knowledge compounds. Each layer you understand makes the next layer faster to learn.

The Identity Question Underneath All of This

There is a version of the "deep knowledge" conversation that is really about something else: wanting to feel like a serious engineer. Wanting to belong to a certain kind of professional identity. Wanting the respect that comes from being the person others bring hard problems to.

That is a legitimate want. But it is worth being honest that it is an identity question, not just a skills question. Because identity questions do not get resolved by learning the right things. They get resolved by doing meaningful work and having that work recognized.

If you are already excelling at your job, innovating, winning internal competitions, and shipping things that matter — you may already be deeper than you think. The gap between your current self and the engineer you want to become might be smaller than the tech industry's narrative makes it feel.

The Bottom Line

Coding jobs are not dead. The engineers who are safest are not the ones who know the most frameworks. They are the ones who understand what is happening underneath the frameworks — who can look at a black box and reason about its internals, who are not helpless when the abstraction leaks, who know which questions to ask when no one else knows what is wrong.

That kind of knowledge is not built in a weekend. It is built through genuine curiosity, sustained frustration, and the habit of never fully accepting "it just works" as an answer.

The plumber always has a job. The question is whether you are willing to learn the pipes.

This article was developed from a conversation about OSS contributions, career growth, systems engineering, and what it actually means to go deep in your craft.