When I started building my Kubernetes Operator, I wasn't a Go developer.
I had deep Kubernetes expertise. Deep database expertise. Seven years of enterprise platform work. But Go? I was learning it as I went, reading documentation, studying patterns, understanding idiomatic practices for the first time.
The operator shipped in two weeks anyway.
Not because AI replaced the expertise I didn't have. Because the expertise I did have (knowing exactly what the system needed to do, understanding the Kubernetes internals, seeing the database behavior clearly) was the hard part. AI helped me express that expertise in a language I was still learning.
That distinction is everything.
The popular framing right now is that AI replaces developers. Tasks get automated, roles compress, headcount comes down.
I think the framing misses the more important shift.
The layers of the job that AI has eaten so far are the layers that look like translation. Retrieval and synthesis (finding the relevant information and condensing it) got eaten last cycle. Code generation from a known spec is largely solved. Even parts of judgment, the rubric-based review of whether a design covers its failure modes and respects existing conventions, are being distributed across panels of models.
What hasn't been eaten is the upstream question. What should the system do. For whom. Under what constraints. With what failure modes that matter. That question still requires a human who has actually been close enough to the problem to know the answer.
That's expertise. And expertise is the layer that compounds with AI rather than being replaced by it.
The shape of the trade is simple.
The scarce resource was never the code. It was always the knowledge of what to build, for whom, and why. For decades, the cost of translating that knowledge into working software was high enough that most domain experts could not afford the translation, and most engineers were spending their time on the translation rather than the knowledge.
That cost is collapsing.
Which means the people whose advantage is real understanding of a domain (finance, logistics, healthcare, energy, agriculture, anything where the rules are subtle and the stakes are concrete) are about to find themselves with a lot more leverage than they had a year ago. Not because they will become engineers. Because the engineering cost of expressing their expertise just dropped by an order of magnitude.
There is a discipline cost on the other side.
Knowing which models to use for which tasks. Understanding where they fail and why. Building the workflow that separates real productivity gains from impressive demos followed by weeks of cleanup. None of that is automatic, and the gap between "this looks like it works" and "this actually ships and stays shipped" is where most teams underestimate the work.
But the discipline is learnable. And once it's in place, the multiplier on existing expertise is real.
My own journey is a small proof of concept for a much larger argument.
Domain expertise plus AI-assisted development plus the discipline to use both well: that combination can ship production systems faster than anyone expects, in languages you are still learning, solving problems that previously required teams and months.
Retrieval got commoditized. Judgment is becoming commoditized. Expertise is the layer where the human stays in the loop, and the layer where AI works for you instead of around you.
If you have spent years getting close to a real problem, the next decade is going to reward you in ways the last one didn't.
What's a problem you understand deeply that you've never built for because the engineering cost was too high? I'd like to hear what people are about to start building.
Top comments (0)