What’s harder: teaching a business person to code, or teaching a developer to think in business terms?

The answer is surprisingly clear. Teaching a business person to code with AI is easier today. And that fact is quietly overturning the organizational logic companies have relied on for decades.

Not long ago, the boundary between business and development was well defined. Business set the requirements. IT delivered them. Long refinements, endless iterations, waiting. Then large language models arrived — and this model stopped working.

The sudden switch

Business people who start working with AI coding tools experience a specific moment. Call it the switch. They suddenly find themselves in an environment where everyone around them seems smarter and more experienced. They see code, don’t understand the conventions, deliver something functional — but architecturally messy. And they have to answer a question: do I belong here or not?

This moment is critical. Not because it’s uncomfortable — but because everyone who takes this path has to consciously push through it. And those who do bring something to the development environment that is otherwise missing: deep knowledge of the business, the context, and the people the solution is actually being built for.

The overlooked change management challenge

A lot is said about convincing business people to adopt AI. Less is said about what happens on the other side.

A developer who has spent years building clean code suddenly has to accept a solution that emerged from vibe coding. They see duplicate functions, suboptimal structure, code they would never have written themselves. And they have the urge to fix it — even when the output is functional and delivers the required value.

This switch is exceptionally demanding for experienced developers. And they are precisely the people who decide whether a business person gets to stay in the development environment or not. Companies where developers can accept this shift — defining the right tools, frameworks and governance — dramatically shorten delivery time. Companies where they can’t remain where they were.

Courage as the critical factor

Technology alone isn’t enough. What matters is courage.

The courage of a leader to say: we’ll try this, even without a guaranteed business case. The courage of a developer to let someone into their space who doesn’t write code by established conventions. The courage of a business person to stay in an environment where they feel out of their depth — and deliver anyway.

In companies where this courage exists, things happen fast. In companies that wait for a perfect brief, a complete plan and guaranteed results, the pace of adoption slows dramatically. AI cannot be successfully deployed through standard approval processes designed for a different world.

The wow moment as the foundation of adoption

The most effective path to genuine AI adoption isn’t training. It’s the personal experience of a result.

When a business person assembles their first working application on their own — a simple form, a calculation tool, something they had long needed at work — and that output actually goes into use, something essential shifts. They stop seeing AI as an abstract topic and start seeing it as their own tool.

From this moment, their approach changes. They start asking: where else in my work is a solution missing? What could be automated? What would this process look like without my manual involvement? And with each iteration, they move further.

Who am I now?

Traditional roles are blurring. The developer who starts thinking about business processes. The business person who starts delivering working code. Both groups are moving toward the centre.

The question “am I a developer or a business person?” no longer has a clear answer. And perhaps that’s a good thing. Being purely a developer — without understanding who a solution is being built for, and why — was attractive in the era when technology separated those who controlled it from those who needed it. That era is ending.

Today, the more valuable person is someone who understands the problem, can design a solution, and is capable of building it themselves. Not perfectly. But functionally, quickly, and with the context that a purely technical person struggles to acquire.

What this means for companies

Organizations that close themselves off to this shift — through tool restrictions, rigid processes, or an unwillingness to let business people into the development space — will see their delivery speed fall further and further behind those that remove this boundary.

Companies that enable it face a different problem: people working with AI are significantly more productive and generate more ideas, prototypes and initiatives than before. Capacity can’t keep up with everything that suddenly becomes possible.

That’s a good problem. But it’s still a problem that requires management.

The result? Business stops specifying requirements and waiting. It starts designing, building and delivering. Development stops implementing other people’s requests. It starts co-creating and managing the frameworks within which others can safely work. And in the overlap between these two worlds, a role is emerging that didn’t exist a few years ago — and is today one of the most valuable in any organization that takes AI seriously.

FD