I've always preached that having domain knowledge is far more valuable than knowing how to invert a binary tree or remembering an obscure language feature no one uses.

I pushed heavily for this during interview reviews with questions like, "why are we not interviewing engineers for domain understanding along with technical fundamentals?"

Anyone can Google an implementation or ask an LLM for code, but deep domain expertise is what delivers real value to customers.

This gap is why we end up with code full of classes named "handler" and "orchestrator" instead of names that reflect the actual business. Without domain grounding, engineers create abstractions about their code rather than the customer’s reality, and the result is software that works but is meaningless to the business and hard to evolve.

Engineers then have to mentally translate real domain concepts into generic code terms just to understand the system.

I used to teach the engineers I would mentor that a better approach is to design code that mirrors the domain. When the domain changes, you immediately know where to update the code because its structure follows the business itself.

Now, many engineers are starting to realize the real value of our work was never the code itself. Code is just an artifact. The real goal has always been delivering value to the customer. And with AI able to generate huge amounts of code on demand that truth is impossible to ignore.

For decades we obsessed over standards, tooling, frameworks, and language debates. We treated code as the product instead of the vehicle. Worse, many engineers avoided domain knowledge because it felt less "pure" than writing technical abstractions.

But that lack of understanding is now a real liability. When AI can write code faster than we can argue about it the only durable advantage left is understanding the customer, their problem, and the value being delivered.

We lost sight of that and now we're paying the price.

The other side of the coin is having product owners who refuse to deeply understand the problems they're trying to solve. They know that X needs to happen but that's where they stop. Instead of designing a domain level solution they leave it up to the engineers to figure out how to solve these challenges.

Again, we end up with code that's hard to change, communication issues between product and engineering, and "domain experts" that are only experts at delegating the real work to others.

The future of engineering and product will merge into a single role: someone who has deep domain expertise but is also technically proficient. These Technical Domain Experts will use AI to do the heavy lifting of writing code, wiring up configurations, and fixing bugs. But they'll also be responsible for reviewing the work AI produces, designing efficient technical solutions, and deciding what to build next.

The most important skill this role will require is being able to communicate what the product should do with enough detail to remove unnecessary ambiguity. This has always been the Achilles' heel of product owners which was often covered up by human engineers making educated guesses and using experience to fill in the gaps. Without another human to rely on, Technical Domain Experts will need to develop better design documents and requirements.

Often we've seen roles merge after technological breakthroughs and LLMs are no exception. We're already seeing companies cut back on engineers who only wrote code but never contributed to the product conversation. Product roles are also being eliminated for those who don't know how to integrate AI into their workflows.

There will definitely be jobs in the future because as most companies reach a level playing field regarding the capabilities of AI they will need humans to build the next generation of innovative products. But these jobs will change into some synthesis of product owner and software engineer.