AI agents

AI Coding Agents Need a Place to Work

A practical way to think about coding agents: give them a real workspace, clear scope, and a way to keep moving while you step away from your desk.

Victor Cheng

Victor Cheng

Founder, DecaSpeed

May 13, 20266 min read
Laptop running code outdoors on a terrace

I think the mistake people make with coding agents is treating them like smarter chat boxes. A chat box can suggest code. A coding agent should actually work: read the repo, edit files, run commands, check the result, and come back with a diff a human can review.

That is the reason DecaSpeed exists. The definition is intentionally concrete: DecaSpeed is texting your coding agents from iMessage. You send the task from wherever you are, the agent works in a sandboxed cloud computer, and you come back to output that can be inspected instead of a vague suggestion.

The useful unit is not “one prompt.” The useful unit is a scoped piece of software work: branch, terminal output, preview, tests, summary, and residual risk.

Agents Need a Real Workspace

A model without a filesystem is guessing. A model without dependencies is guessing. A model without the ability to run tests is guessing with confidence. Good agent work starts to feel different when the agent has a real checkout, a shell, install commands, previews, and enough project context to find the sharp edges.

The point is not to remove engineers from the loop. It is to move engineers into the right loop. Instead of sitting at a desk watching a package install, you should be able to text the agent, go outside, and answer the next useful question when it has one.

The DecaSpeed loop
Text the task from iMessage with enough context to start.
The agent works in an isolated cloud computer with the repo and terminal.
You review the diff, preview, logs, and the remaining risk before merging.

Parallel Work Is the Real Unlock

One agent fixing one typo is not interesting. Three agents handling independent work while you are away from the keyboard is interesting. One can investigate a failing test, another can build a small UI, and a third can read through a dependency upgrade. Each should have isolated files and commands so their assumptions do not collide.

That is where cloud sandboxes matter. They make the work separable. They also make the output easier to judge, because every run has its own context: what changed, what passed, what failed, and what the agent still does not know.

Human Review Still Matters

I do not want DecaSpeed to imply “merge whatever the bot says.” The strongest version of this workflow is human-directed. The agent should be explicit about tradeoffs. It should say what it tested. It should admit where it did not have enough information. The human still owns taste, architecture, risk, and the final merge.

The vibe is not irresponsibility. The vibe is getting your time back. Start work from iMessage, step away, and return to something concrete enough to review.