When You Unleash Domain Experts to Be Builders, Everything Changes

There are 36 million software developers in the world. There are hundreds of millions of domain experts who have always known exactly what should be built. The barrier between them just disappeared. The question is whether organisations are structured to take advantage of it.

I took a little bit of a break over the break and the amount of headlines haven’t slowed down at all. New models were released and OpenAI has raised a massive $122m for the next generation of AI. What does that mean for us though.

Replit raised $400 million at a $9 billion valuation. That number tripled in six months. A $9 billion valuation for a development platform tells you something important: the market is screaming for an AI operating system that is enterprise ready. Their new Agent 4 product lets anyone, not just developers, describe what they want and watch it get built in real time. The platform does not care whether you have a computer science degree. It cares whether you know what needs to exist.

In the same week, Atlassian cut 1,600 jobs. More than 900 of them were in research and development. The CTO is gone. The company framed it as “self-funding its AI pivot.” Read that again. They’re cutting the people who build in order to fund the technology that lets other people build.

One company is enabling domain experts to create software. The other is dismantling its engineering function. These are not unrelated events. They are two sides of the same structural shift, and it is happening faster than most organisations are prepared for.

And the pressure is not just coming from AI-native startups. There are private equity firms investing heavily in SaaS businesses on the back of existing operating models. The thesis looks solid on paper until you realise what is coming. Those businesses will face relentless pressure to lower their price point as AI drops the cost of building competing products. To retain value, they have to do three things simultaneously: lower the cost to serve, increase the offering, and expand into new markets. All three require building faster with fewer people. All three require domain experts who understand the customer, the market, and the problem to be directly involved in building, not waiting in a queue for engineering capacity.

Meanwhile, AI providers are in an open price war. Costs dropped 30 to 70 percent across the major platforms in a single week. The cost of building software has never been lower. The cost of compliance, of testing, of documentation, of security scanning, has never been lower either. And 72 percent of Global 2000 companies are now running agentic AI in production. Not piloting. Running.

So which is it? Is this the democratisation of building, or the destruction of engineering as we know it?

I think the answer is both. And the tension between those two things is going to determine which companies accelerate and which ones stall.

Where we are in the series

If you have been following this series, I have been building an argument piece by piece. I started with the economics: AI-native companies generating revenue-per-employee multiples that make traditional SaaS look like a different industry. Then the operating model: you have to change how you work before the technology matters. Then the org structure: smaller, flatter, autonomous units. Then judgment: the one skill that survives when execution cost drops to near zero. Last week, the compounding gap: why the distance between leaders and laggards is widening at an accelerating rate.

This week is the question that follows naturally from all five of those arguments. If the economics have changed, and the model has to change, and the structure has to change, and judgment is what matters, and the gap is compounding, then the obvious next question is: who builds in this new world?

The answer is domain experts. The people who have always known what should be built but never had the tools to build it themselves.

But there is a structural problem. And it is not where most people are looking.

The translation layer is dissolving

For thirty years, professional software development has operated on a fundamental assumption: the people who know what to build and the people who know how to build it are different people. Entire industries exist to bridge that gap. Requirements documents. User stories. Acceptance criteria. Empathy maps. Journey maps. Wireframes. Sprint planning. Backlog grooming. All of it is translation infrastructure. A $7.3 billion low-code market growing at 28 percent per year, all of it trying to make the gap between “I know what we need” and “here is a working product” narrower.

Nate B Jones, whose daily AI strategy briefings I follow closely, frames it through what he calls the Six Unlocks. His argument is that the execution premium, the professional value built on the ability to write the code, is evaporating. “For thirty years or more, professional value has been built on execution skills,” he says. “Can you write the code? Can you ship the product? That execution premium is just evaporating now. What stays valuable is human judgment, clear direction, and excellent workflow tools.”

When the expert becomes both user and developer, a merged identity that mirrors the convergence that made open source successful, something fundamental shifts. The translation layer does not just get thinner. It disappears.

The numbers tell the story. Deloitte projects growth from 30 million professional developers to more than 100 million citizen developers by 2028. Business-user developers are expected to outnumber professional developers four to one. Forrester found that low-code development is up to ten times faster than traditional programming. Domain-specific AI solutions deliver 85 percent greater commercial impact than generic tools.

There are 36 million software developers in the world. There are hundreds of millions of domain experts: doctors who know exactly which patient pathway is broken, logistics managers who can see the bottleneck no dashboard captures, teachers who know what assessment actually measures understanding, financial advisers who know which compliance checks matter and which are theatre.

For thirty years, every one of those people has had to describe what they need to someone else and hope it comes back right. Usually it does not. Usually it takes months. Usually by the time it ships, the requirements have changed.

That era is ending. Replit at $9 billion is not a coding tool. It is a signal that the barrier between knowing and building has collapsed.

The power that gets unleashed

When domain experts can build, the economics change in ways that most boardrooms have not yet grasped.

I wrote last week about the compounding gap. The same maths apply here, but in the other direction. When the cost of building drops by an order of magnitude, the CFO calculus flips on experiments. The $10 million niche market that was not worth serving when execution cost $3 million a year becomes viable overnight. The product that needed fifty people to ship can be shipped by five. The feature your customers have been requesting for three years, the one that never makes it past the backlog, can be prototyped in a week by the person who actually understands the problem.

Look at what is already happening. Cursor generates $500 million in annual revenue with fewer than twenty people. Midjourney does $500 million with forty people and zero external funding. These companies are not more efficient versions of the old model. They are structurally different. They are what happens when the people with domain knowledge have direct access to the tools of creation.

Gong found that sales teams using domain-specific AI generate 77 percent more revenue per rep than those using generic tools. The difference is not the AI. The difference is that domain-specific solutions encode the judgment and knowledge of people who actually understand the work. When experts build for themselves, the output is inherently better because the translation loss is zero.

Here is the calculation I keep running for the organisations I work with. If AI tools deliver even half the productivity gains the research suggests, then the conservative case is this: same outcome, half the cost. The same output your engineering team produces today, for roughly 50 percent of the current spend. But that is the unambitious version. The ambitious version: same cost base, at least five times the outcome. Redirect the saved execution capacity into new products, new markets, new capabilities. The data supports both. Forrester says ten times faster. Deloitte says 50 to 70 percent faster development cycles. CrewAI says enterprises have already automated 31 percent of their workflows.

But here is the critical qualifier. None of those multipliers unlock unless you change the structure. Layer AI on top of the same agile process, the same sprint rituals, the same manual review pipeline, and you capture maybe 10 to 15 percent efficiency. That is the turbocharger on the horse I wrote about two weeks ago. The multiplier only comes from structural change.

So what is stopping them?

If the tools exist, and the economics work, and the domain experts are ready, then why is this not happening faster?

The answer, in most organisations, is structural. The entire delivery model was designed for a world where building required specialised skills. Every process, every governance layer, every approval chain assumes that the people who know the problem and the people who can build the solution are different people. That assumption no longer holds, but the structures built around it are still running.

Agile gave engineering teams autonomy. That was the right call for twenty years. Autonomous, cross-functional teams that own their delivery pipeline and make their own technical decisions. It worked. It produced better software, faster, with fewer dependencies.

But that autonomy has calcified into something else. Process orthodoxy that is now creating a structural mismatch with the speed at which things can be built. Teams optimised for process rather than outcome. Sprint rituals that consume 30 percent of available time. Velocity measured in story points rather than business value delivered. Governance designed for a world that moved more slowly.

This is not anyone’s fault. These processes were built for good reasons. But when an AI agent or a domain expert with Replit produces functional code in hours, a process that takes weeks to evaluate it creates a bottleneck that did not used to exist.

There is also the “not my code” dynamic, and it is as old as software engineering itself. Engineers have always preferred working on code they wrote or understand deeply. The first instinct when inheriting a codebase is to re-engineer it so you can trust it. Every engineering leader knows this. It is one of the biggest sources of wasted effort in the industry.

With AI-generated code, the comfort level drops further. So the instinct to rework is even greater. Teams spend weeks reworking functional AI output not because it fails, but because the process was not designed for code that arrives this way.

And the quality concerns are real.

The rigour question

The data on AI code quality is real and it matters. AI-generated code has 1.7 times more issues per pull request than human-written code. Logic errors are 75 percent more frequent. Security vulnerabilities appear 1.5 to 2 times more often. Performance issues are nearly eight times more common. Only 55 percent of AI-generated code was found to be secure across a study of 80 coding tasks. Pull request review times increased 91 percent for high-AI-adoption teams.

These are not trivial numbers. The engineers who raise quality concerns are raising real concerns.

But here is where the conversation goes wrong.

What happens in practice is that AI-generated code receives disproportionately greater scrutiny than human-written code in the same environment. It is not just held to the same standard. It is held to a higher one. Every output is treated as suspect. Every function is audited as if it is going straight to production without any automated checks. The natural response is to rebuild from scratch, with human hands, because that is what feels safe. But the better response is to build systems that catch the problems automatically.

Senior engineers spend 4.3 minutes reviewing AI suggestions compared to 1.2 minutes for human code. Thirty-eight percent of developers say reviewing AI code requires more effort than reviewing a colleague’s code. And the METR study found something remarkable: when sixteen experienced developers were tracked across 246 tasks, they expected AI to speed them up by 24 percent. The actual result was a 19 percent slowdown. But after the experiment, they still believed AI had sped them up by 20 percent.

Both sides of this debate think they are right. And that perception gap is why the conversation is so difficult.

The compliance argument has flipped

Here is the point that most engineering leaders are missing.

Yes, AI-generated code needs more rigor. I am not disputing that. The data is clear. But the argument “we need to slow down for quality and compliance” no longer holds in the way it used to, because the cost of compliance has also dropped dramatically.

Never before has the cost of delivery reduced so much. But also, never before has the cost of compliance reduced so much.

To develop artefacts that support ISO 27001 on the back of an AI-generated workflow has never been easier. The same tools that generate the code can generate the test suites, the documentation, the audit trails, the compliance evidence. Automated security scanning catches vulnerabilities faster than any human review. Architectural fitness functions validate structural integrity continuously. CI/CD pipelines enforce standards without a single person standing at a gate.

The answer to “AI code has more bugs” is not “therefore we rebuild everything with human code.” The answer is “therefore we build better automated systems for catching bugs.” The answer is to invest in the guardrails, the blueprints, the architecture, not in manual line-by-line review of every function.

This is where engineers should be spending their time. Three places, specifically.

First, building systems to review rather than manually reviewing. Automated quality gates, linting, security scanning, architectural fitness functions. If the blueprint and the architecture are right, you spend far less time in manual review.

Second, the blueprint itself. Architecture, standards, patterns. Get the foundations right and everything built on top of them is inherently more trustworthy, whether a human or an AI wrote it.

Third, prototyping new ideas. New ways of doing things. New products. New capabilities. This is where engineering creativity should live. Not in line-by-line code review of functional output.

The gap between vibe coding and production is smaller than engineers think

This is the part that will be uncomfortable for many engineers to hear, but it needs saying directly.

The gap between how vibe coders and even autonomous AI agents get something to production does not deviate from good architectural and engineering practices. Software engineering fundamentals still hold. Data engineering fundamentals still hold. The architecture matters. The security standards matter. The non-functional requirements matter.

What has changed is the execution layer. If the blueprint is right, if the architecture is sound, if the guardrails are in place, then the question of who wrote the code becomes dramatically less important. A senior engineer, a junior developer, an AI agent, a domain expert with Replit. If the product works, if it is performant, if it meets the architectural standards and the NFRs, then the code style is not the conversation we should be having.

The product is the thing. The outcome is the thing. The process of how the code got written is not the thing.

Engineers need to move closer to the product. Understand the why and the what, not just the how. What business outcome is this serving? Who is the user? What does success look like? The skill is shifting from how we build to why we build and what we build. Does what we build achieve the business outcome we are looking for?

Teams need to be optimised for outcome, not process. And the engineers who thrive in this new world will be the ones who embrace that shift, from code-centric to product-centric, from process-driven to outcome-driven.

The agile trap

I realise I am saying something that will be controversial in engineering circles. Agile has been the dominant methodology for two decades. It has genuine strengths. But in an AI-native world, it has become a trap.

Sprint rituals that consume a third of available working time. Story points that measure effort rather than value. Backlogs that grow faster than they shrink. Standup meetings where the most common answer is “still working on the same thing.” Retrospectives that identify the same problems quarter after quarter.

All of this was designed for a world where the bottleneck was execution. When it took six months to build something, process discipline was essential. When the cost of failure was high, careful planning was the right instinct.

But what happens when the bottleneck shifts? When execution drops to near-zero cost? When the cost of building a prototype goes from six months and half a million pounds to a weekend and a Replit subscription?

The bottleneck is no longer execution. It is imagination. It is knowing what to build and having the judgment to evaluate whether it is working. And the people with the most imagination about what should exist in their specific domain are not, for the most part, the engineers. They are the domain experts.

The companies that recognise this will move significantly faster. The companies trapped in agile process orthodoxy, where engineering teams control the pipeline and every piece of code goes through the same review process regardless of its purpose, will be slower. Not because their engineers are bad. Because their structure is wrong for the moment.

What to do about it

I said at the start of this series that I did not want to write articles that define problems without offering solutions. So here is the “so what.”

If you are a CEO or on a board: audit how long your current engineering pipeline takes to move an idea from concept to production. If the answer is measured in quarters, you have a structural problem. Create parallel tracks: production engineering for quality, security, and architecture, and domain-expert prototyping for speed, experimentation, and market testing. These are not the same pipeline and should not share the same governance. Set a 90-day target: identify three domain experts in your organisation who know exactly what should be built. Give them AI tools, a sandbox, and engineering support rather than engineering gatekeeping. Measure what they produce. And start measuring your engineering function on outcomes enabled, not code produced.

If you are an engineering leader: your highest-value work is now architecture, standards, and automated guardrails. Invest in the systems that make AI output trustworthy at speed: CI/CD pipelines, automated security scanning, architectural fitness functions, compliance automation. Accept that AI-generated code needs more rigor. That is fair. But build systems for that rigor rather than applying it manually. The cost of compliance tooling has dropped as much as the cost of code generation. Challenge your teams honestly: are you spending more time recoding AI output from scratch, or building the systems that make AI output trustworthy? If it is the former, you are solving yesterday’s problem.

If you are a domain expert: start building. This week. Not next quarter. Pick a tool: Replit, Cursor, Claude, Copilot, Lovable. The barrier has never been lower. Prototype the thing you have been describing in meetings for years. The dashboard you sketched on a whiteboard. The workflow you explained to IT six times. The feature your customers keep asking for. Build a working version this week. A working prototype changes conversations faster than a slide deck. Show what is possible, then bring engineering in to harden it.

If you are an engineer: your skills are not obsolete. Architecture, systems thinking, security, quality standards are more important than ever. But the form those skills take is changing. Move closer to the product. Understand the why and the what, not just the how. Evaluate code on outcomes and NFRs rather than on style. Does it work? Is it performant? Is it secure? Does it meet architectural standards? If the answer to all four is yes, then the question of whether a human or an AI wrote it is the wrong question. The engineers who thrive will be the ones who make it easier for others to build safely. Enablers, not gatekeepers. The ones who build the guardrails, not the ones who stand at the gate.

The cost maths for everyone: if your organisation is spending the same amount on engineering and getting the same output as two years ago, you are falling behind. The conservative case: same outcome, half the cost. The ambitious case: same cost, five times the outcome. Both are supported by the data. Neither happens without structural change. Neither happens while your engineering team is spending a year on something that should take three months.

The skills that matter now

The individuals who will thrive in this shift are those with systematic thinking, the ability to see the whole system rather than just their piece of it. Those who can go wide, who connect domain knowledge to technology to business outcomes. Those with deep domain knowledge, who know what good looks like in their specific field.

Not prompt engineering. Not knowing which AI tool is flavour of the month. Systematic thinking, breadth, and domain depth. These are the skills to hone.

AI can generate code. It cannot generate twenty years of knowing what actually matters in logistics, in healthcare, in finance, in education. That knowledge, your knowledge, is the irreducible input. The execution gap was the only thing standing between that knowledge and working software. That gap just closed.

What is coming next

I am going to explore something in the coming weeks that follows directly from this argument. If the execution premium is evaporating, if domain experts are becoming builders, if the skill shifts from how to why and what, then certain roles are going to converge. The technical business analyst, the technical product manager, the engineer who understands the domain: these boundaries are dissolving. I think we are entering the era of the generalist, and that has implications for every hiring decision, every team structure, and every career plan in every organisation.

More on that soon.

Let us talk about what this means for you

If you are a leadership team watching your engineering pipeline take quarters to ship what should take weeks, I want to hear from you. If you are a domain expert who has been told “it is on the backlog” for the third year running, I want to hear from you. If you are an engineer trying to figure out what your role looks like in two years, I want to hear from you.

These conversations are happening every week now. Connect with me on LinkedIn or drop me a DM. The people navigating this well are not doing it alone.

First published on LinkedIn, 14 April 2026.