AI can write code. That stopped being the question some time ago. The harder question — the one that determines whether organisations actually adopt AI-assisted development at scale — is whether anyone can explain what a proposed change will do to the rest of the system before it happens.
Today, the answer is usually no. And that gap is where regressions live.
The quick fix problem
Every codebase of meaningful size has a property that makes it dangerous to change casually: hidden dependencies. A function that looks isolated calls another function that sets a state that triggers a side effect three files away. A type definition shared across twelve components. A database column referenced by an API route, a validation layer, and a reporting dashboard that nobody remembers building.
When a human developer makes a change, they carry a mental model of these dependencies — incomplete, decaying, but real. They know which files are fragile. They know which module was written by someone who left two years ago and is best left alone. That institutional knowledge is what makes experienced developers expensive and valuable.
AI has no such model. It sees the files you show it. It modifies what you ask it to modify. And it does so confidently, cleanly, and quickly — which makes the result feel safe when it might not be. The code compiles. The tests pass. And three days later, a customer reports that invoices are rounding differently because a shared utility function was quietly refactored.
This is not an argument against AI writing code. It is an argument for understanding the blast radius before executing the change.
Show me what it touches
Orch Edit is built on a single principle: the system maps every file, dependency, and downstream effect of a proposed change before anything is modified.
The workflow is deliberately simple. You describe what you want to change in plain language — "update the pricing calculation to include the new tax rate" or "add a last-modified timestamp to the client list." The system analyses the codebase, identifies every file the change would touch, maps the dependency chain, and presents it as an interactive graph. You see the blast radius before approving anything.
If the change is contained — two files, no shared dependencies, low risk — you approve and it executes. If the change fans out across the codebase in ways you did not expect, you see that too, and you can adjust the scope or escalate to a full governed build.
The point is not that the system prevents you from making changes. The point is that you never make a change without knowing what it will affect.
Left: plain-language intent and generated DO/DO NOT instruction. Right: interactive dependency graph with risk classification.
Click any node to expand its connections.
The dependency tree grows as you explore. Every connection is a real import relationship.
Constraints over instructions
There is a design choice in Orch Edit that may seem counterintuitive. When the system generates a technical instruction from your plain-language description, that instruction is dominated by constraints — not actions. A typical instruction might contain two or three things the change should do, and ten to fifteen things it must not do.
This is deliberate. In a complex codebase, what you don't change matters more than what you do. "Update the price field" is one line of work. "Do not modify the audit trail. Do not change the currency formatter. Do not alter the tax calculation shared by three other modules. Do not remove the null check on line 247" — those constraints are what prevent the one-line change from breaking four other systems.
Experienced developers do this instinctively. They carry a mental list of "don't touch" zones. Orch Edit makes that list explicit, complete, and enforced.
Three surfaces, graduated risk
Orch Edit sits between two existing systems in the platform.
Orch Reasoning is the thinking layer. Zero risk — nothing is modified, nothing is executed. You explore ideas, analyse decisions, and build understanding. The context accumulates over days.
Orch Edit is the surgical layer. Low risk — scoped, analysed, reversible. You describe a change, review its impact, approve or adjust, and execute with full knowledge of what will be affected. For changes that are too large or too interconnected, the system refuses the surgical approach and offers to convert the request into a governed build.
Orch Build is the full pipeline. The governed autonomous build with multi-agent planning, parallel execution, quality gates, and grading. For new systems, major features, and anything that requires architectural decisions.
The graduation matters. Most changes to production software are small — a field update, a new column, a calculation adjustment. Running a full build pipeline for a two-file change is overkill. But making that two-file change without understanding its dependencies is reckless. Orch Edit occupies the space between those two failure modes.
Why this matters for enterprise adoption
The conversation about AI in enterprise software has, until now, centred on generation — can AI write the code? The answer is yes, and has been for some time. The conversation that actually determines adoption is about control.
A CISO does not want to hear that AI can write code faster. A CISO wants to hear: "Before any AI-assisted change executes, the system maps every affected file, classifies the risk, presents the dependency graph for human review, and refuses to proceed on changes that exceed the safety threshold."
That is a different value proposition. It is not about speed. It is about legibility — making the consequences of a change visible and reviewable before they become consequences.
"Show me what this change touches before it touches anything." That sentence, more than any benchmark or demo, is what gets AI-assisted code changes approved in organisations that take their codebase seriously.
Oscar is the founder of orch.build, a governed autonomous development platform.
Contact: oscar@interstice-advisory.com