AI Isn’t Just for Engineers

A strange thing happens in many AI workshops. We tell an audience of business leaders that AI will transform their work, then teach the material as if everyone wants to become a software engineer.

I understand why. Engineers helped build these tools, and technical fluency remains important. But I think we risk missing the larger opportunity.

The people closest to a business problem often know more about what needs to happen than the people asked to build the solution. A sales leader understands the friction in a pipeline. An operations manager knows where handoffs fail. A finance leader knows which reconciliation is consuming every Friday afternoon.

Historically, turning that understanding into working software required a translation chain: explain the need, document requirements, prioritize the backlog, build, test, and discover what everyone misunderstood. Each handoff introduced time and distortion.

AI can shorten that chain. A domain expert can now explore an idea, prototype a workflow, examine data, and demonstrate a useful first version without waiting for a full development cycle. That does not make every domain expert a production engineer. It gives them a new way to express and test what they know.

This is the asymmetric advantage I care about.

Imagine a transportation operations leader who can prototype a better dispatch exception workflow during a working session. Or a commercial leader who can turn a customer hierarchy problem into a demonstrable matching process before a formal project begins. The first version might be imperfect. But everyone is now reacting to something real rather than debating an abstract requirements document.

The professional engineer still matters enormously. Security, architecture, reliability, performance, integration, and maintainability do not disappear because a prototype looks convincing. In fact, the ease of producing software makes those disciplines more valuable. Someone must decide what is safe to deploy, how it should be governed, and who owns it when it breaks.

What changes is the relationship. Instead of business people handing requirements over a wall, domain experts and engineers can iterate together at a much higher frequency. The domain expert contributes context and priorities. The engineer contributes systems judgment. AI reduces the cost of testing ideas between them.

I believe training should reflect that reality. Less emphasis on memorizing the mechanics of a particular tool. More emphasis on problem framing, process mapping, data literacy, verification, security, and measuring whether a solution actually helps.

The question I want executives to ask is not, 'How many employees have used a chatbot?' It is, 'How many employees can identify a costly problem, test a better approach, and responsibly move that improvement into the business?'

That is a much higher bar. It is also where the return begins.

AI isn't eliminating the need for engineers. It is expanding who gets to participate in building.