Domain expertise has always been the real moat

> The mechanical skill you sweated for, turning a clear idea into clean code, has gotten dramatically less valuable.

But that was never the hard part!

Come now.

After twenty plus years as a professional software developer I can name two hard problems, not more. One is related to the article, the other is not:

1. Getting that clear idea out of a stakeholder's brain. Traditionally this would be a specification but doesn't need to be that formal. Remember, remember the first panel of https://i.redd.it/i2aeyrivmjoz.jpg An LLM doesn't help here because it doesn't push back. It'll do whatever you tell it to do even if it's not what you really wanted. The software developer here operates very similarly as a translator and it always has been true a translator who speaks both sides well will be able to do the highest quality work. This is not at all new. It always has been the advice that if you know things like, say, logistics and software or any such pair then you'll be well off financially either because you can do this translation well or because you realize what's missing and can do a product for it.

2. The other problem, of course, is debugging. Since LLMs fundamentally work from a training set any debugging problem not blatantly obvious to a sr developer is hopeless for them.

There's just no way this can be true. Every project I've committed to has been a bet made with incomplete information. Sometimes it pans out, sometimes it doesn't. Every time I've made one of those bets, I've had to shoulder the opportunity cost of 2-3 other 1/8th-finished but promising projects I could have driven to completion instead. Not having that opportunity cost anymore wildly changes the dynamics of what I build.

This weekend I'm playing with a SwiftUI MusicKit player (everything I'm doing lately has been Swift/SwiftUI, itself a radical change from just a couple months ago when everything was a TUI, and then a few months back from that and all the way back to 1993, when everything was a CLI) with a Responses API hookup that turns the player into an agent, with tool calls to let the model see what I've been playing. "Keep a continuous queue of music playing while I'm working in the wood shop".

Worked a treat. I'm genuinely interested in where I can take this. I have a real problem, one that's been annoying me since ~2000, which is that I "own" a lot of music but find myself stuck in an epicycle of the same 200 songs. Problem solved-ish. I never, ever, in a million years, would have built anything like this before.

It's really hard to sell me on the idea that nothing profound has changed here in terms of the projects we now pick up. Go build an operating system. I'm serious! Claude will practically one-shot it. Mine has smoltcp hooked up to a Rust virtio-net driver Claude pulled out of its butt.

In my own experience this is 180 degrees from reality. As a generalist, feeling out the depths of a single domain (something I've been forced to do at least 50 times in my career, to the point that I'm probably a global expert in at least 2-3 things I don't actually care about, but are poorly documented and not especially lucrative on their own) is something that's basically a bunch of Google searches, reading source code, and writing/running tests manually, none of which I really care about short of getting to "the right solution."

Meanwhile, as a generalist who has a basic understanding of general things, everything from how to design efficient network protocols, to how cache lines affect the performance of sorting algorithms, without being a real expert in any of those things, I act as a constant course correction for AI agents doing work on my behalf, in a way that LLM context windows simply cannot replicate.

To give a concrete example, I recently used agents to build a specialized sync protocol that broadly resembles Dropbox. It's nowhere near as efficient in terms of how blocks are synced (because it entirely happens on a LAN and the cost difference is minimal), but I constantly had to make objectively more valuable course corrections on how the sync actually traversed the participating nodes. If I'd just let the LLM drive, it would have come up with a reasonably efficient algorithm (better than I probably would have done on my first try in the same timeframe) that would have had an obvious (to me) single bottleneck.

> In the past, an engineer who deeply understood the internals of a DB and how memory management worked in Java would be indispensable.

That engineer still is indispensable. Any organization foolish enough to replace such a person with an LLM is going to find itself in deep water when the pile of hallucinations becomes too much to endure.

Your dad owning the company?