Your Best Software Engineers Don't Work in Engineering
The people who understand your operations best aren't in the engineering org—they're in finance, ops, and support. The companies that let them build their own tools pull ahead.
The person who understands your reconciliation process best is not on your engineering team. They’re in finance, they’ve done it four hundred times, and they know exactly where it breaks. The person who knows what your support team needs to see on one screen is a support lead, not a backend developer. In most companies, these people have spent years describing what they need to a queue of engineers who don’t share their context—and waiting. The organizations pulling ahead in the AI era have noticed something: their deepest reservoir of software-building talent has been sitting outside the engineering org the whole time, blocked only by the fact that building required code.
That reservoir is now reachable. And the companies that tap it operate at a speed the request-and-wait companies can’t match.
TL;DR
- The people who understand a workflow best—in finance, ops, support, RevOps—are the right people to build the software for it, because they hold the context engineers have to be briefed on.
- Most orgs waste this capacity by routing every tool request through a central engineering queue, where domain context gets lost in translation and the backlog swallows anything that isn’t a top priority.
- The result is a long tail of needed-but-never-built tools: the work that’s too small to justify a sprint but too important to do well in a spreadsheet.
- This isn’t an argument for individual productivity hacks. It’s an operating-model change: the org that distributes building moves faster than the one that concentrates it.
- The old objection—“non-engineers can’t build real software”—was true until recently and is the reason past low-code waves underdelivered.
- What changed is that describing an application in plain language can now produce a real, deployed app, not a toy, which removes the skill barrier that kept this capacity locked up.
- The competitive gap opens because building capacity stops being capped by headcount in one department and starts scaling with the number of people who understand your problems.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
Why are the people closest to the problem the right builders?
Software is encoded understanding. A good internal tool is just someone’s knowledge of how the work should go, written down in a form a computer can execute. The hard part was never the typing—it was the understanding. And the understanding lives with the people who do the work every day, not with the engineers who get a ticket describing it secondhand.
When a finance analyst hands a spec to an engineer, the first thing that happens is loss. The analyst knows the seventeen edge cases that matter; the ticket captures three. The engineer builds what the ticket says, ships it, and discovers the other fourteen during a month of back-and-forth. The tool that finally works is the one where the analyst’s full context made it into the build—and the fastest path to that is for the context-holder to build it directly, not to play telephone through a queue.
This is why the org that distributes building wins on quality, not just speed. The tool built by the person who understands the problem is simply a better tool. It has fewer wrong assumptions baked in, because there was no translation step to introduce them.
What does the request-and-wait model actually cost?
Most leaders underestimate the cost because the expensive part is invisible. The visible cost is the engineering backlog. The invisible cost is everything that never gets requested at all—because everyone knows the queue is six months deep, so they don’t bother. They route around it with a spreadsheet, a manual process, or a workaround that quietly becomes load-bearing.
Consider what each department is currently not building because it isn’t worth a sprint:
| Team | The tool they need | What they do instead |
|---|---|---|
| Finance | A vendor approval tracker with real status | A shared spreadsheet nobody trusts |
| Operations | A dashboard that joins three systems | Manual exports, copy-pasted weekly |
| Support | One screen with the full customer context | Five browser tabs and tribal knowledge |
| RevOps | A lead-routing tool tuned to their rules | A SaaS product configured 70% of the way |
| HR | An onboarding checklist app | A doc, an email, and good intentions |
None of these justify pulling an engineer off the roadmap. All of them cost real money in slow, error-prone, manual work—and buying a SaaS product rarely closes the gap, because generic SaaS is built for the average company, not for how your team actually works. This is the long tail of internal software—too small to build the old way, too important to keep faking. In the request-and-wait org, the entire tail goes unbuilt. In the org that distributes building, the tail gets built by the people who feel the pain, and the aggregate productivity gain is enormous precisely because there’s so much of it. Finance is the clearest example—see the apps finance teams can build with AI, from approval trackers to reconciliation tools, none of which used to be worth an engineering sprint.
Isn’t this just shadow IT with extra steps?
It would be, if these tools landed as a hundred disconnected islands—the failure mode that sank previous “let everyone build” waves. The answer isn’t to ban distributed building; it’s to make sure what people build lands on a governed foundation leadership can see. Distributed building and central visibility aren’t opposites, which is the larger argument in what the winning org looks like. The point here is narrower: the building capacity exists, it’s stranded outside engineering, and the orgs that reach it pull ahead.
What changed to make this possible?
For decades, the objection to all of this was correct: people who don’t write code can’t build real software. Low-code platforms tried to close the gap and mostly produced brittle, limited apps that hit a wall the moment a workflow got real. The skill barrier was genuine. Describing what you wanted was easy; turning that description into a working application with a real backend, a database, and authentication was the part that required an engineer.
Most organizations assume AI already erased that barrier, so their first move is to hand everyone an AI coding assistant—Claude Code, Cursor, GitHub Copilot—and wait for the building to start. It mostly doesn’t. Those tools are remarkable in the hands of an engineer, but they work at the code layer: they assume you can read a diff, run a repository, wire up a database, and ship a deploy. Put one in front of a finance analyst and the skill barrier hasn’t moved—it’s only changed shape, from “write the code” to “understand and operate the code the AI just wrote.” The real bottleneck was never coding skill; the AI skills gap is a description gap—and clearly describing a workflow is exactly what the domain expert is best at. The org rolls out the licenses, the non-engineers bounce off them, and leadership quietly concludes that building belongs back in engineering after all. That conclusion is wrong; the tool was just aimed at the wrong layer.
A product agent removes the barrier instead of relocating it. This newer category of AI tool takes a plain-language description of an application and compiles it into a real, deployed full-stack app: backend, database, authentication, frontend, and deployment, with a live URL. Not a prototype, not a screen. Today the most advanced one is Remy. The finance analyst describes the vendor approval tracker they’ve wanted for two years; the agent drafts a plain-language plan; they read it, adjust it in plain English, and it compiles into a working app with real server-side roles—approvers approve, viewers view—running at a real URL. A typical full-stack build runs about $30–40 in compute. The plan stays the source of truth, so when the process changes, they edit the plan and recompile instead of filing a ticket.
That’s the move that converts your latent building capacity into actual output. Engineering stops being the single channel through which all software flows. The finance analyst, the ops lead, the support manager—the people who were always your best-positioned builders—can finally build, because the part that required an engineer is now done by the agent. The honest caveat: this is open alpha, and it’s aimed at the internal-tools and workflow apps where most of that stranded long tail lives—not yet at every enterprise-grade need. But that long tail is exactly where the request-and-wait model was bleeding the most.
FAQ
Who are the “best engineers” outside engineering? The employees who hold deep, daily context about a workflow—finance analysts, operations leads, support managers, RevOps specialists. They understand the problems that software should solve better than anyone, which is the hard part of building good tools.
Doesn’t distributed building reduce software quality? Often it improves it. The biggest source of defects in internal tools is lost context between the person who understands the problem and the person who builds it. Removing that translation step removes a whole class of wrong assumptions.
What kinds of tools should non-engineers build? The long tail of internal software: trackers, dashboards, approval workflows, lightweight CRMs, onboarding apps—work that’s too small to justify an engineering sprint but too important to keep doing manually.
How is this different from low-code platforms? Low-code still required people to assemble logic inside a constrained builder, and the apps hit limits fast. Describing an app in plain language and getting a real full-stack application removes both the assembly skill and the capability ceiling.
What does it cost to build an internal tool this way? With a product agent, a typical full-stack build runs roughly $30–40 in compute—a fraction of the cost of an engineering sprint, which is what makes the long tail of small tools finally worth building.
Will this replace the engineering team? No. It frees engineering to work on the core product and the hard systems, while the long tail of internal tools gets built by the people who understand those workflows directly.
The bottom line
Your company already employs the people best positioned to build most of its internal software. They’re in finance, ops, and support, and for years the only thing stopping them was that building required code. That barrier is gone. The orgs that recognize this and let their domain experts build—on a foundation leadership can still see—convert a huge reserve of stranded capacity into shipped tools, while the request-and-wait companies keep waiting.
If you want to see what your teams could build by describing it, explore Remy →. For the bigger operating-model picture, read what the winning org looks like.
