One acquisition landed September 14. LocalStack acquired WonderTwin AI. The company famous for faking AWS and Snowflake now owns the SaaS side: local emulators for 20-plus outside apps including GitHub, Stripe, HubSpot, and PostHog.

The WonderTwin founder line hits hard. "SaaS testing was always limited. AI agents broke it completely. Emulation was the only fix." Meaning what? Once agents directly operate Slack, CRM, payments, and cloud APIs, touching real systems during tests is itself the risk.

Why fakes: a speed and scale problem

Old integration tests ran human-written code against shared sandboxes. Slow was fine because humans waited.

Human era: 1 shared sandbox, sequential tests, a person stops mistakes
Agent era:  n agents, parallel tests, no instinct to stop
→ Shared sandboxes cannot take the scale and concurrency

As DevOps.com notes, AI coding agents may slip around guardrails into sensitive data. If the test rig is a live API, testing is the incident. Traditional software's mock and sandbox thinking is now moving into agent testing for real.

What merges: both branches of the graph

The joining post has a good metaphor. Software touches two branches of the dependency graph.

Dependency graph:
|- infra branch: AWS, Snowflake → LocalStack grounded it for years
+- app branch: payments, comms, commerce, dev tools → WonderTwin emulates

Combined: agentic full-stack emulation
→ everything your code and agents touch, local, as a real stateful
   model of how the dependency behaves, not a static spec

"Stateful" is the key. Not a static description but a fake that behaves like the real thing. Then agents can move fast without guessing. LocalStack customers reportedly see about 10x productivity from grounding just the infra layer. The claim: that number previews, not caps.

In practice: place fakes in 3 steps

Set the rule first.

Agent integration tests must not call production APIs directly.

Step 1, fake APIs (starting today):
- intercept outside calls with canned responses first
- block writes, payments, and sends first

Step 2, local emulators (this quarter):
- LocalStack-style cloud plus WonderTwin-style app emulation
- single-tenant sandbox per agent (no sharing)

Step 3, disposable sandboxes (settled):
- throwaway environments per test run
- CI runs automatically against emulators

It matches layer 3 isolation from the four-layer security post. Runtime isolation extends into test isolation. The MCP comparison said open MCP tools read-only first. Tests follow the same order.

CodeBridge Mini Lab: audit your agent's outside calls

1. List everything outside your agent calls:
   - SaaS APIs (Slack, CRM, payments, issues)
   - cloud APIs (deploy, storage, DB)
   - shared sandboxes (who else uses them)

2. Tag each call:
   [ ] Read or write
   [ ] Do tests hit the real thing
   [ ] Do failures and retries have side effects (double charges, spam)

3. Fake the riskiest one first:
   - write plus live calls plus side effects → top priority
   - run all related tests through 1 fake
   - manage alongside never-rerun marks from the
     [checkpoint post](/en/blog/pi-durable-execution-checkpoint-resume/)

It connects to the orchestration cost feel from the Qwen delegation post. Failures in fake environments cost nothing; one failure in the real one costs money. Practice in fakes first, and run the real thing through fakes first too.

Conclusion: so speed stops being risk

Back to the founder sentence. Ground all of it, continuously, and speed stops being risk.

The faster agents get, the earlier fake environments come.

One task for today: find 1 place where your agent calls the real thing and swap in a fake. That one spot changes test safety and speed together. Agent-era mock thinking starts there, not in some grand platform.

Further reading

References

Go deeper with a course

To practice running agents in isolated environments with verification, this course builds CLAUDE.md, skills, hooks, subagents, and MCP in real projects, exactly like the sandbox story here.