The Moat Was Never the Code

I have spent a long career in technology, as an executive inside public companies and building my own businesses. Getting it right and managing risk were part of the job. Throughout, the constraint stayed consistent. The hard part was rarely writing the software. It was knowing enough about the business to know what the software was supposed to do. You could find people who could code. The understanding of how a thing behaves once it leaves the demo and meets the real world was harder to come by.

Applied AI has sharply reduced the time and cost of turning an idea into working software. My work is to understand business needs and goals and translate them into functional, valuable, secure software. Having a domain expert on the team fortifies that work. Their experience sharpens the requirements, exposes assumptions, and helps us recognize what a good result actually looks like. It also helps us understand what the system must protect and what is at stake if those protections fail.

Two examples from my own work.

The first is a product in financial services. I built something capable. My domain knowledge there is reasonable rather than deep, but a career spent reading business requirements, pricing risk, and looking for the failure nobody named in the meeting turns out to travel well across industries. The product works. Deeper domain expertise would fortify that work further, sharpening the requirements and bringing the nuances of daily practice into how we evaluate the result. In financial services, that includes understanding who should be able to see or change a record and what evidence must remain when a decision is questioned.

The second is a product in law, built for expert witnesses. It is capable and close to elegant. Its strength comes from combining my ability to translate business needs into software with the experience of a domain expert who has spent thirty-five years as an expert witness, including in cases that set precedent. When my output is wrong, he often knows within a minute. He cannot read the code and does not need to. He recognizes a right answer because he has produced thousands of them. The product gets better quickly because that depth of experience is part of the development process. That same knowledge helps define how sensitive case materials should be handled and who should have access to them.

That combination is more or less the whole point.

The familiar version of this story says senior engineers come out ahead because they bring judgment, and that is true as far as it goes. What I think it misses is that engineering judgment and domain judgment are not the same thing. AI has made producing code cheaper. It has not made either kind of judgment dispensable.

A more capable developer does not, by themselves, close this gap. A faster and more elegant builder with no experience in the domain can also produce wrong answers more efficiently. The model can write a billing rule, a compliance check, a valuation step that compiles, passes the tests they knew to write, and is quietly, expensively off. The mistake can be hard to see when no one in the room knows what right looks like.

The room is filling up. AI has invited a lot of capable people to step straight into industries they have never worked in, because the tool lowers the technical barrier to getting started. Much of that is healthy. It is also where I would look for trouble.

Two risks seem worth naming.

The first is security, where I spent a portion of my career. A system can do exactly what a user wants and still expose a client’s data or allow an unauthorized action. Understanding the business includes knowing which information is sensitive, who is entitled to use it, and what happens if it is lost, altered, or disclosed. Domain expertise brings those requirements into focus. My job is to translate them into design and implementation, and to test the protections that result. AI can help with that work, but generated code is no assurance that a system is secure. Security belongs in the work from the first requirement through deployment and ongoing review.

The second is correctness, which can hide in a result that looks entirely reasonable. Software that appears to work but produces plausible wrong answers can be more dangerous than software that simply falls over. A crash announces itself. A plausible wrong number in a financial filing or a legal exhibit may sit there unnoticed until it has cost someone real money or real liberty.

So if I had to name the bet, as someone spending their own time deep in applied AI, it would be this. Keep business needs, domain knowledge, and security close to the work, from the first requirement through evaluation of the finished system. That understanding shapes what gets built, how we judge whether it delivers, and what it must protect.

Sometimes that domain expert is me. When it isn’t, the value of having that person beside me becomes unmistakable. AI has made producing software faster. The depth of understanding behind it remains the advantage. The moat was never the code.