A sales rep at one of our clients recently built a working tool for a doctor he works with. He has no coding experience. It took one afternoon.
That afternoon changed how I think about who builds software. The hard part was never typing code. It was understanding the problem well enough to describe the right solution, and he understood this one better than any developer could.
This article walks through what happened, why it is a pattern rather than an outlier, what engineers still own, and how leaders can let their experts build without creating a mess.
What Happened in One Afternoon
The doctor was drowning in paperwork. Every new patient arrives with years of medical history spread across dozens of documents: lab results, referral letters, specialist reports, discharge summaries. All of it lands in the practice software with no structure. By the doctor's own account, piecing together what had happened to one person could take 45 minutes.
Our client is not a developer. But he hears about this problem from doctors every week, so he understood it in detail. We sat down together and tried something simple.
We opened ChatGPT in voice mode and just talked. He described what the doctor needed, what the documents look like and how the output should be structured. I asked questions. From that conversation, the AI generated a specification document.
Then we fed the specification into a coding agent. It built a working prototype: upload patient documents, get a structured summary with diagnosis history, a medication timeline and lab value trends. We put it online the same afternoon, ready for the doctor to try.
From a doctor swearing about paperwork to a working test version in one session. The person who made it happen was not a developer. He was the person who sits across from frustrated doctors every day.
The old path runs from the expert through a specification and a development queue. The new path runs from a conversation through a coding agent to a test version, with an engineer reviewing.
This Is a Pattern, Not an Outlier
I see the same shift in other professions. Lawyers at the law firm Debevoise built an interactive compliance training game without a programming background. Accountants are automating reconciliation workflows. Sales teams are building their own internal tools.
The industry data points the same way. Forrester reports that 89% of development executives are now implementing citizen developer strategies, meaning programmes in which people outside IT build their own applications. And Collins Dictionary chose "vibe coding", building software by describing it to an AI, as its Word of the Year 2025.
None of these people became programmers. They stayed lawyers, accountants and sales reps. What changed is that their knowledge can now become software without passing through a long translation chain.
The Bottleneck Moved: From Syntax to Understanding the Problem
For decades the bottleneck in software was translation. Can someone turn this idea into working code? That required developers, developer time was scarce and expensive, and so every idea waited in a queue.
Now the question is different: does someone understand the problem well enough to describe the right solution? That is a completely different skill, and millions of people already have it.
Lawyers understand compliance better than any developer. Accountants understand reconciliation. Sales reps who work with doctors understand what doctors actually need. That domain knowledge was always the hard part. The translation layer was just expensive and slow. Now the translation layer is a conversation.
Writing the code is no longer the narrow point. The scarce step is understanding the problem, and that is where your experts sit.
The next wave of internal tools will be built by the people who actually understand the problems.
What Engineers Still Own
This is not a story about developers becoming unnecessary. A test version that works for one person is not a system a company can rely on. Engineers remain essential, and their role becomes more focused.
Architecture: how a tool fits into existing systems, and whether it should be built at all or should extend something you already have.
Security and data protection: who can access what, where data is stored, and what must never leave your environment.
Scale and reliability: what happens when many people use it instead of one, and who fixes it when it breaks.
Review: reading what the coding agent produced and deciding whether it is fit to go further.
The best setup pairs the two. The expert defines what the tool must do and judges whether the output is right. The engineer makes sure it is safe, maintainable and connected to the right systems.
How to Set This Up Safely in Your Team
Letting experts build is a leadership decision, not only a tooling decision. Without a few ground rules you end up with a zoo of unmaintained tools. With them, your best people solve their own problems. Four rules make the difference.
Name a technical owner early
Before anything leaves the test stage, agree who in your organisation is responsible for it technically. If nobody can own it, it stays a test version.
Build in review
An expert checks whether the output is correct. An engineer checks the code and the data flows. Neither review replaces the other.
Set clear data rules
Decide which data may be used in which tools before people start building. In a healthcare setting like the example above, where the tool runs and where documents are processed has to be settled before any real patient data goes in.
Treat the first version as a test
A working prototype answers one question: is this worth pursuing? It is not yet a product. Decide deliberately what it takes to move from a test version to something the team relies on every day.
This is also how we run our engagements: we build the first improvement together with your experts and agree the technical owner early. Read more about how we work .
Your Experts Already Have the Hard Skill
Engineers are not going anywhere. Architecture, security and scale still need deep technical skill. But much of the next wave of internal software will not start in the IT department. It will start with the people who understand the problems.
So the question for leaders is not whether your team can code. It is: which of your experts understands a problem so well that they could describe the solution tomorrow, and what would it take to let them?
Frequently Asked Questions
- What is a citizen developer?
- A citizen developer is someone outside the IT department who builds applications for their own work, usually a domain expert such as an accountant, lawyer or salesperson. With AI coding agents, they can describe what they need in plain language and get a working prototype, while IT keeps responsibility for security, architecture and operation.
- Can people without coding experience really build software with AI?
- They can build working prototypes and simple internal tools, as the example in this article shows. What they bring is an understanding of the problem. Turning a prototype into something a company relies on still needs an engineer for review, security and integration.
- What is vibe coding?
- Vibe coding means building software by describing what you want to an AI in natural language instead of writing the code yourself. Collins Dictionary named it Word of the Year 2025. It works best for prototypes and small tools, with proper review before anything goes into daily use.
- How do we avoid a chaos of unmaintained tools?
- Set a few rules before people start: a named technical owner for anything beyond a test, review by both the expert and an engineer, clear rules on which data may be used where, and a deliberate decision on when a test version becomes a tool the team relies on.
How we work · Work · Insights