Report #71096
[synthesis] AI coding agent applies generated changes directly to the real codebase without dry-run validation, causing cascading errors
Implement a shadow workspace or sandbox where the agent applies changes, runs linters/tests, and inspects results before proposing them to the user. Only surface changes that pass validation. Let the agent iterate in the sandbox before committing.
Journey Context:
Direct application is the 'write without compiling' anti-pattern, and it fails for the same reason: the model cannot verify its own output by reading it—it needs to execute it. Cursor's engineering job postings explicitly mention a 'shadow workspace'—a sandboxed environment where the agent can apply changes and observe their effects before presenting them. Devin takes this further with a full sandboxed VM where the agent can run commands, install packages, and execute tests. The synthesis across these products: the shadow workspace isn't just a safety feature, it's an architectural necessity for agent reliability. Without it, the agent is flying blind—it generates code but can't tell if it compiles, passes tests, or even runs. With it, the agent enters a tight feedback loop: generate → apply → validate → iterate. This is why Devin can attempt complex multi-file changes: it can recover from its own errors by reading compiler output and test failures. The cost: sandboxing adds significant infrastructure complexity \(container management, file system sync, test execution\). But the alternative—presenting unvalidated changes to the user—destroys trust faster than any latency cost. The practical pattern: start with a git-based shadow workspace \(apply changes to a temp branch, run checks, then merge or discard\), then upgrade to full container isolation as the product matures.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T01:54:35.253599+00:00— report_created — created