You don't have a skills gap. You have a description gap.
Most orgs think AI adoption is blocked by too few people who can code. The real bottleneck is turning what your experts already understand into working software.
Most organizations have decided their AI problem is a skills gap—not enough people who can code, prompt, or wrangle a model—and the fix is to train everyone up. That diagnosis is wrong, and it’s expensive to get wrong. The thing actually blocking AI adoption in most companies isn’t a shortage of technical skill. It’s a description gap: the people who understand a process precisely have no way to turn that understanding into working software without handing it to someone who codes. Close the description gap and the skills gap mostly stops mattering—because the constraint moves from “who can build” to “who can describe what’s needed clearly,” and your org already has those people.
That reframing changes where leadership should spend. You don’t need to mint a thousand junior developers. You need a way for the analyst, the ops lead, and the support manager to convert what they already know into a real application.
TL;DR
- Surveys keep finding that leaders blame a lack of AI skills for stalled adoption, and the standard response—upskill everyone to code—treats the wrong bottleneck.
- The real constraint is a description gap: your domain experts understand their processes precisely but can’t turn that understanding into software without a coder in the middle.
- Handing non-engineers an AI coding assistant doesn’t close the gap because those tools operate at the code layer, where the barrier they were meant to remove still sits.
- The people who know exactly how a workflow should behave are the analysts, ops leads, and managers running it—not the engineering team, and they’re the ones currently blocked.
- When the unit of work becomes a clear description instead of code, the scarce resource becomes clarity of thought, which orgs have far more of than coding capacity.
- This is why AI budgets and bootcamps underperform: they fund the wrong layer, while the idea-to-tool loop still routes through engineering the way it always did.
- The orgs pulling ahead aren’t the ones with the biggest AI spend—they’re the ones that let people closest to a problem describe and ship the fix directly.
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
Why does “we have a skills gap” feel so obviously true?
Because the surveys say so, loudly. Deloitte’s enterprise AI research names the AI skills gap as the biggest barrier to integration. McKinsey finds 46% of leaders cite skill gaps as a major barrier to adoption. So leadership reaches the natural conclusion: if we had more people who could build, we’d ship more AI-era software. Fund the bootcamps, buy the licenses, run the trainings.
The conclusion doesn’t survive contact with how internal software actually gets requested. Walk into any finance team and you’ll find someone who can describe their reconciliation process to the decimal—every edge case, every exception, every rule that exists because of one bad quarter in 2019. They understand the problem with a precision no engineer ever will, and there’s a long list of apps a finance team could build if description were the only thing standing between them and a working tool. What they lack isn’t understanding. It’s a path from understanding to a working tool that doesn’t require learning a profession.
That’s the tell. When the person who knows the problem best is also the person least able to build the solution, the gap isn’t skill. It’s translation. And translation is exactly what software development has always been: turning a domain expert’s knowledge into something a computer runs, with one or more engineers acting as the translation layer.
What is the description gap, exactly?
The description gap is the distance between knowing precisely what a tool should do and having that tool exist. In most orgs that distance is filled by people—you describe what you need to an engineer, the engineer interprets it, builds it, and hands something back that’s usually 80% right. Then you describe the other 20%, wait again, and iterate through a queue.
Define it plainly: the description gap is the cost, delay, and fidelity loss of moving an idea from the head of the person who has it into running software. Every internal-tools backlog is a measure of it. Every “we faked it in a spreadsheet because IT couldn’t get to us” is the gap winning.
Notice what the gap is not. It’s not that the analyst can’t think clearly about their process—they think about it more clearly than anyone. It’s not that they lack requirements—they have them in exhausting detail. The missing piece is purely the conversion step. And a conversion step is a much more tractable thing to fix than “everyone must learn to code.”
Why doesn’t “upskill everyone to code” close the gap?
Two responses dominate when an org decides the problem is skills, and both miss.
The first is bootcamps: train the workforce to write code. Set aside that this takes years to produce competent builders—even when it works, it’s solving for the wrong scarcity. You don’t have a shortage of people who understand the problems. You have a shortage of conversion, and turning a finance analyst into a part-time React developer is a slow, lossy way to buy conversion. Most of them won’t get good enough to ship production software, and the ones who do you’ve quietly removed from the finance work you actually needed them for.
The second response is more current: hand non-engineers an AI coding assistant—Cursor, Claude Code, GitHub Copilot—and expect them to build. These are genuinely excellent tools. But they’re excellent for engineers. They operate at the code layer: they assume you can read what they emit, judge whether it’s right, structure a project, wire up a backend, manage a database, and deploy the result. Pointing them at someone who can’t do those things doesn’t remove the barrier—it relocates it. The analyst is now staring at TypeScript they can’t evaluate instead of waiting in a ticket queue. The wall moved; it didn’t fall.
That’s a layer mismatch, not a failure of the tools. A coding agent is the right instrument for someone who already builds software. Using it to close a description gap is like handing someone a better chisel when what they needed was to not have to carve at all.
Who actually has the understanding—and why aren’t they building?
The understanding lives outside engineering. It’s distributed across every team that runs a process:
| Layer | Skills-gap framing | Description-gap framing |
|---|---|---|
| What’s scarce | People who can code | A way to turn clear descriptions into apps |
| Where the bottleneck sits | The workforce’s technical ability | The conversion step between knowing and building |
| Who’s blocked | ”Non-technical” employees | The domain experts who understand the problem best |
| The proposed fix | Bootcamps; AI coding assistants for everyone | Let people describe what they need and compile it |
| What the fix optimizes | Headcount that can write code | Clarity of the description |
| Why it stalls when wrong | Years to train; code layer still excludes non-coders | — (the gap is closed when description compiles) |
Read the right-hand column top to bottom and a different operating model falls out. The people who should be building are the ones who own the workflow—a support manager who knows exactly which tickets should escalate and when, an ops lead who can recite the approval chain in their sleep. They aren’t building today because the only on-ramp runs through code, and code isn’t their job. Move the on-ramp to description, and the same people become your most productive builders, because they were never short on understanding—only on a way to express it that a computer accepts.
This is also why throwing AI budget at the problem so often disappoints. The spend funds models and licenses and training, but the idea-to-tool loop still routes through the same engineering chokepoint it always did. You can buy every employee a chatbot and change nothing about who’s allowed to turn an idea into a running tool.
What changes when description becomes the unit of work?
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
The scarce resource flips. In a skills-gap world, the limiter is coding capacity, and you ration software accordingly: only the highest-priority requests survive the backlog. In a description-gap world—where a clear description compiles into a working app—the limiter becomes the clarity of the description itself. And clarity is something an org can cultivate broadly, cheaply, and fast, because it lives in the people already doing the work.
This is the quiet reason some companies are pulling ahead on AI while others light money on fire. The MIT NANDA initiative’s 2025 study found that about 95% of generative AI pilots stall before delivering measurable impact—a pilot-to-production gap that has less to do with model quality than with who can actually ship the tool. The companies succeeding weren’t the ones with the most ambitious central AI labs, but the ones empowering the people on the line to drive adoption. That’s the description gap closing in real terms: software gets made by whoever understands the problem, not by whoever can clear the engineering queue.
The winning org doesn’t ask, “How do we get everyone coding?” It asks, “How do we let everyone who understands a problem describe its solution into existence?” Those are completely different transformations, and only one of them is achievable in the timeframe leadership actually has.
How an org closes the description gap
Everything above describes what an org needs: a way for the people who understand a process to turn that understanding directly into working software—skipping the code layer entirely, not relocating the barrier to it. Here is what makes that real.
A new category of AI tool, the product agent, operates at the product layer instead of the code layer. You describe the application you need in plain language. The agent drafts a plain-language plan—what the app does, its data, its rules, who can see what—and you read and refine that plan in the same plain language, no syntax to author. The plan then compiles into a real, deployed full-stack app: backend, database, authentication, frontend, and a live URL. Today the most advanced product agent is Remy.
The layer is the whole point. Unlike coding agents like Cursor or Claude Code—which edit code in a project you already own and assume you can read it—a product agent never asks the description-gap person to operate at the code layer at all. The plan is the source of truth, written in language the domain expert already speaks. When the process changes, you edit the plan and recompile; you don’t hand-maintain code you couldn’t have written. The conversion step that used to require an engineer becomes the act of describing clearly—which is the one thing your analysts and ops leads were always able to do.
This is early and worth saying plainly: product agents are in open alpha, enterprise needs like SSO aren’t there yet, and a typical full-stack build runs around $30–40 in inference. But the shape of the fix is already clear, and it’s not “teach everyone to code.” It’s “let the people who understand the problem describe the solution, and let the description become the software.”
FAQ
What is the difference between a skills gap and a description gap? A skills gap is a shortage of people who can build software—write code, manage a backend, deploy an app. A description gap is the inability to turn what your domain experts already understand into working software without routing it through someone who codes. Most orgs misdiagnose the second as the first.
Why doesn’t training everyone to code fix AI adoption? Because the scarce resource was never understanding—it was conversion. Your finance and ops teams already understand their processes in detail; turning them into part-time developers is a slow, lossy way to buy the conversion step, and it pulls them away from the work you needed them for.
Aren’t AI coding assistants enough to close the gap? Coding assistants like Cursor, Claude Code, and GitHub Copilot are excellent for engineers because they operate at the code layer—they assume you can read, judge, and structure code. Pointing them at non-engineers relocates the barrier instead of removing it.
Who should be building software in an AI-era org? The people closest to each problem: the analyst who knows the reconciliation rules, the ops lead who owns the approval chain, the support manager who knows which tickets escalate. They have the understanding; what they’ve lacked is a path from understanding to a working tool.
Does buying more AI tools or budget close the description gap? No. AI budget funds models, licenses, and training, but the idea-to-tool loop still routes through the same engineering bottleneck. Buying everyone a chatbot changes nothing about who is allowed to turn an idea into a running application.
What does it mean to “describe” an app instead of code it? You explain what the app should do in plain language—its data, its rules, who can access what—and refine a plain-language plan. A product agent compiles that plan into a real full-stack app. The description, not the code, is the source of truth.
Is describe-and-compile production-ready today? Product agents are in open alpha. They compile real apps with server-side auth and real data, but enterprise features like SSO/SAML aren’t shipped yet. The fit today is internal tools and prototypes for teams that want to stop waiting on a backlog.
The bottom line
The companies stuck on AI keep funding the wrong layer—bootcamps and code-layer tools aimed at a skills gap that was never the real constraint. The constraint is the description gap: the distance between the people who understand a problem and software that solves it. Close that gap and the scarce resource becomes clarity of thought, which your org has in abundance and your competitors are still trying to hire.
If you want to see what closing the description gap looks like in practice, explore Remy →. For the operating model this makes possible, read what the winning org looks like and why your best engineers don’t work in engineering.
