Your Processes Change Faster Than Your Software Can
In most orgs, the business learns faster than its tools can be rebuilt, so understanding outpaces software and the company slows to the speed of its backlog.
Most organizations don’t run at the speed of their understanding—they run at the speed of their software backlog. A business learns constantly: a process changes, a regulation shifts, a customer segment behaves in a new way, and the people running the work understand the new reality within days. But the software that encodes how the work gets done can’t keep up. Changing it means filing a request, waiting in a queue, and shipping a fix long after the understanding that prompted it. So the org’s tools calcify into a snapshot of how things worked last quarter, and the company adapts no faster than its slowest code can be rebuilt. The winning org inverts this: it makes software as easy to change as its understanding is to update, so the tools keep pace with the learning instead of dragging behind it.
This is a different problem from building the first tool quickly, and from capturing knowledge before it fades. It’s about what happens after the software exists—whether it stays in step with a business that never stops moving, or freezes the day it ships and slowly drifts out of date.
TL;DR
- Most orgs adapt at the speed of their software backlog, not their understanding—the business learns in days but rebuilds its tools in quarters, so the tools always lag reality.
- Software calcifies the moment it ships: it encodes a snapshot of how the work ran then, and every change after that is expensive, queued, and slow, so the snapshot ages.
- The cost isn’t a slow project—it’s a ceiling on how fast the whole company can change, because every shift in how the business works waits on a code change someone has to schedule.
- Hand-maintained code is the root cause: the intent lives in someone’s head, the code is the only record, and changing it means re-deriving the intent and editing by hand—which gets riskier as the codebase ages.
- The fix is to make a plain-language spec the source of truth—the readable plan the software is built from—so changing the software means editing the plan and recompiling, not hand-patching code.
- When the spec drives the software, the cost to adapt collapses and the person closest to the change can make it, so software changes as fast as the org’s understanding does.
- The org that runs this way becomes a learning system whose tools keep pace: understanding updates, the spec updates, the software recompiles, and nothing freezes a quarter behind reality.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
Why does software calcify the moment it ships?
Because the day a tool goes live, it stops being a description of how the work runs and becomes a fixed artifact that has to be changed to keep up. While it was being built, intent and code moved together—someone understood the process and the software reflected it. After it ships, the two drift. The business keeps learning. The code does not. Every new understanding now has to be translated back into edits to a codebase that’s already in production, and that translation is expensive, risky, and slow.
The expense compounds with age. A fresh codebase is easy to change; the people who wrote it remember why. A year later, the original engineers have moved on, the reasoning behind a given function lives in no one’s head, and a small business change—a new approval step, a different tax rule, an extra status field—turns into an archaeology project. Nobody wants to touch the part that works, so changes get batched, deferred, or refused. The software hardens into something the org maintains rather than evolves.
The result is a quiet inversion of who’s in charge. The business is supposed to drive the software; instead the software starts driving the business. Teams shape their processes around what the tool can already do, because changing the tool is harder than bending the work. That’s calcification: the tool stops serving the current understanding and starts enforcing an old one.
What does this cost an organization?
It costs the org its change velocity—the rate at which it can turn new understanding into new behavior. That’s not a project-level cost; it’s a company-level ceiling. Every shift in how the business works, from a pricing change to a compliance update to a reorganized workflow, eventually routes through a software change. If software changes slowly, the whole company changes slowly, no matter how fast its people learn.
The delivery-research world has measured the mechanics of this for years. The DORA program tracks lead time for changes—how long it takes a change to go from committed to running in production—as one of its core indicators of software-delivery performance, and finds an order-of-magnitude gap between the fastest and slowest organizations (Google Cloud). The org-level version of that clock starts even earlier—the moment someone understands that the process needs to change—and includes all the queue time before an engineer ever touches the code.
The maintenance burden makes it worse over time. Industry estimates have long held that the majority of a system’s total cost arrives after its first release, in the ongoing work of changing and fixing it (NIST). An org doesn’t pay for software once. It pays, again and again, every time reality moves and the code has to be dragged along behind it. The slower that dragging, the further behind reality the org runs.
Why does hand-maintained code lock the org in?
One coffee. One working app.
You bring the idea. Remy manages the project.
Because when the running code is the only record of intent, every change has to start by reverse-engineering what the code was supposed to do before anyone can safely change what it does. The reasoning that produced a system—why this rule, why that exception, why the edge case is handled this particular way—isn’t stored anywhere durable. It lived in the heads of the people who built it, and it leaks out as they move on. What’s left is the code: precise about what happens, silent about why.
So a change that’s simple to describe in business terms—“approvals over $50k now need a second sign-off”—becomes a careful operation in a system nobody fully understands anymore. An engineer has to locate the right code, infer the surrounding intent, make the change without breaking the three things that quietly depend on it, and verify the result. The gap between the simplicity of the understanding and the difficulty of the edit is the whole problem. The understanding changed in a sentence; the software changes in a sprint.
This is also why “just hire more engineers” doesn’t lift the ceiling. More engineers widen the queue but don’t change the unit economics of a single edit. Each change still routes through a central team, still requires re-deriving intent from code, and still waits its turn. The org gets more throughput on the same slow, lossy process—not a faster path from understanding to working software. The higher-leverage move is the opposite: point your best engineers at architecting the substrate everyone builds on, not at hand-editing every change in the queue.
Don’t AI coding assistants fix this?
They help with one part and leave the binding constraint untouched. Tools like Cursor, Claude Code, and GitHub Copilot make engineers genuinely faster at reading and writing code, which shortens the edit step. For an engineering team maintaining a codebase, that’s a real gain. But the edit step was rarely the long part of the org-level loop. The long parts are everything around it: the change reaching an engineer at all, entering the queue, and waiting behind other work.
The deeper limit is one of layer and fit. Coding assistants operate at the code layer and assume engineering skill—they’re built for the people who already own the codebase, and they’re excellent for them. Point one at the finance lead or ops manager who actually understands what needs to change, and the barrier hasn’t moved; it’s just been relocated to “now learn to operate a code editor and a project.” The person with the understanding still can’t make the change. It still has to travel to an engineer, re-enter the queue, and get re-derived from code. The org gets faster edits and the same slow loop—because the source of truth is still hand-maintained code that only engineers can safely touch.
So the change velocity barely improves. Faster typing doesn’t help when the bottleneck is that understanding and software live in two different places, maintained by two different groups, kept in sync by hand.
Code as the source of truth vs. the spec as the source of truth
The difference between an org whose software calcifies and one whose software keeps pace isn’t talent or budget. It’s what the software is built from—where the intent lives and how a change happens. The two models behave nothing alike once the tool is in production.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
A quick definition first, because the whole argument rests on three terms. The source of truth is the canonical artifact a change is made against—the thing you edit when you want the software to behave differently. A spec is a planning document for your app, in plain language—no code—the brief you’d hand a developer, except an AI compiler builds the working software from it. To recompile is to rebuild that working software from the updated spec, the way a build tool turns source into a running program.
| Code as the source of truth | Spec as the source of truth | |
|---|---|---|
| How a change happens | Find the code, infer the intent, hand-edit, test, ship | Edit the plain-language plan; recompile the app |
| Cost to adapt | Rises as the codebase ages and authors leave | Stays low—you change a description, not a system |
| Where intent lives | In the code (the what) and people’s heads (the why) | In the spec—readable, the why and the what together |
| Who can change it | Engineers who can safely modify production code | The person closest to the problem, in plain language |
| When the business shifts | A backlog item; the tool lags until it’s scheduled | The plan is edited and recompiled; the tool keeps pace |
| The tool’s trajectory | Calcifies—drifts from reality, gets maintained | Stays current—evolves as understanding evolves |
The right-hand column isn’t a faster version of the same process. It moves the source of truth from an artifact only engineers can safely change to one anyone who understands the business can read and revise. That single move is what decouples the org’s change velocity from its engineering queue.
How does an org make software change at the speed of understanding?
By inverting what’s authoritative. Instead of treating code as the thing you maintain and a document as the thing that describes it, you make a plain-language plan the source of truth and treat the working software as something compiled from that plan on demand. When the understanding changes, you change the plan and rebuild. The software follows the understanding instead of lagging it, because the understanding is the source.
This needs two conditions to hold. First, the source of truth has to be readable and editable by the people who actually hold the understanding—not a syntax that puts you back in the engineering queue. The person who knows the approval rule changed should be able to express that change in the same plain language they’d use to explain it to a colleague. Second, rebuilding from the changed plan has to be cheap and fast enough to do whenever understanding shifts—not a quarterly event. A learning system isn’t one that builds the right tool once; it’s one that keeps rewriting the tool as the work evolves, at the cost of editing a paragraph.
When both hold, calcification stops. The tool can’t drift a quarter behind reality, because the act of keeping the plan current is the act of keeping the software current—they’re the same artifact. The intent stops leaking out as people leave, because it’s written down in the plan rather than trapped in code. And the change velocity of the whole org rises to the speed at which its people understand their own work, which is the only ceiling that should ever apply.
The turn: what makes software keep pace
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
Everything above describes what an org needs to stop its software from calcifying: a plain-language plan as the source of truth, editable by the people who hold the understanding, cheap enough to rebuild from whenever the work changes. The question is what makes that practical instead of aspirational. For most of computing history it wasn’t—because turning a plain-language description into real, running software still required engineers to write and maintain code, which put the source of truth right back into the artifact only they could safely change. The plan was always a document beside the software, never the thing the software was built from.
The recent reflex is to hand non-engineers an AI coding assistant—Cursor, Claude Code, Copilot—and call it adaptability. But those tools are built for the code layer and assume engineering skill; they’re excellent for engineers and a poor fit for the ops lead who actually knows what needs to change. Pointing them at a non-engineer relocates the barrier instead of removing it, and the source of truth is still hand-maintained code. The change still has to travel back to an engineer, and the software still lags the understanding.
A different category resolves it. A product agent lets someone describe an application in plain language and get back a real, deployed full-stack app—backend, database, auth, frontend, and deployment—not a prototype. Today the most advanced one is Remy. You describe what you need; it drafts a plain-language plan; you read and refine that plan in plain language; and it compiles into a working app with real server-side auth, real data, and a live URL—you hit Publish and it’s deployed. A typical full-stack build runs about $30–40 in inference. It’s open alpha today, and enterprise pieces like SSO/SAML aren’t shipped yet—but the thing it changes is exactly the adaptation problem.
The reason this keeps software at the speed of understanding is that the spec is the source of truth. The plain-language plan isn’t documentation sitting beside the code—it’s the artifact the software is compiled from. So when the business changes, you don’t file a ticket against a codebase and wait for it to clear the queue; you edit the plan and recompile. The intent lives in the plan, in plain language, where the person who understands the change can revise it—not buried in code only engineers can safely touch. Unlike coding agents like Cursor and Claude Code, which edit code inside a project an engineer already owns, a product agent operates at the product layer: the person closest to the change describes it and gets a rebuilt app, with no relay through the engineering queue. That’s the difference between a tool that calcifies a quarter behind reality and one that adapts as fast as the org understands.
For the deeper mechanics, see what spec-driven development is and what a product agent is. For how this collapses the first build, see from problem to tool in days; for why captured understanding stops decaying, see process knowledge has a half-life; and for the broader operating-model picture, what the winning org looks like.
FAQ
Why does software calcify after it ships? Because once a tool is live, the business keeps learning while the code stays fixed, so the two drift apart. Every change now has to be translated back into edits to a production codebase, and that gets more expensive as the original authors leave and the reasoning behind the code fades. The tool hardens into a snapshot of how the work ran when it was built.
What is change velocity and why does it matter? Change velocity is the rate at which an organization can turn new understanding into changed behavior—and since most behavior is encoded in software, it’s gated by how fast software can change. It matters because it acts as a company-wide ceiling: a business can only adapt as fast as its slowest-to-change tools, no matter how quickly its people learn.
Don’t AI coding assistants make software easier to change? They make engineers faster at editing code, which shortens one step. But the bottleneck in the org-level loop is rarely the edit itself—it’s the change reaching an engineer, entering the queue, and being re-derived from code that only engineers can safely modify. The source of truth is still hand-maintained code, so the change velocity for the whole org barely improves.
What does “the spec is the source of truth” mean? It means the plain-language plan describing what an app should do is the artifact the working software is built from—not a separate document kept beside the code. To change the software, you edit the plan and recompile, rather than hand-editing code, so the software stays in sync with the org’s current understanding by construction.
What does it mean to “recompile” an app from a spec? It means rebuilding the working software from the updated plain-language plan, the way a build tool turns source code into a running program. When understanding changes, you revise the plan and recompile, and the new app reflects the change—no manual code surgery required.
How is this different from just hiring more engineers? More engineers widen the queue but don’t change the cost of a single change, which still requires re-deriving intent from code and routing through a central team. Making the plain-language plan the source of truth lowers the per-change cost and lets the person closest to the problem make the change directly, which is what actually raises the org’s change velocity.
The bottom line
The organizations that keep pace in the AI era won’t be the ones that build the most software—they’ll be the ones whose software changes as fast as their understanding does. In most orgs it doesn’t: the business learns in days and rebuilds its tools in quarters, so the software calcifies into a snapshot of last quarter’s reality and the whole company slows to the speed of its backlog. The cause is hand-maintained code as the source of truth—an artifact only engineers can safely change, where intent leaks out as people leave. Make a plain-language plan the source of truth instead, cheap to edit and recompile, and the ceiling lifts: the org becomes a learning system whose tools keep pace, adapting at the speed it understands its own work.
If you want to see what software that keeps pace with understanding looks like in practice, explore Remy →.
