Introducing Critique Builder: where English compiles

Today we are introducing Critique Builder, a browser-first cloud agent surface for delegating real software work and getting back a readable execution trail instead of an IDE cosplay.

Software teams are not short on tools. They are short on one room where a clear sentence turns into motion without the interface shouting over the work.

Critique Builder is that room: a full-screen cloud execution surface built around conversation, tuned to the same dark, quiet, editorial rhythm you already know, then sharpened for one kind of work: start a serious coding run, watch it land, and leave with receipts.

That positioning matters. Builder is not our answer to v0 or ManusAI. Those products are excellent at turning prompts into app scaffolds, UI experiments, and first drafts. Builder aims at a different emotional center: less “make me a demo,” more “help my team update real software.”

The joke that stopped being a joke

For years, engineers have said the quiet part out loud: the hardest part is no longer memorizing syntax. It is naming the outcome precisely enough that a serious system can execute it with discipline—environment, repo context, model choice, validation, and a thread you can read without feeling like you opened a server closet.

Builder takes that idea seriously. English is not a party trick here. It is the primary interface—treated with the same respect we give real engineering: history you can revisit, status you can scan, outputs you can inspect, and a composer that stays the hero so intent never gets lost in chrome.

The difference between a toy prompt box and a production tool is what happens after the sentence. Does the system have the repo? Can it inspect the code on its own? Can it validate? Can it continue from prior work? Can it run from your phone, an iPad, a borrowed laptop, or a thin browser tab on the train? Builder is designed around yes.

Researching the strongest cloud-agent launches made that distinction even clearer. The best launches do not just say “AI can code.” They define the operating model: background execution, isolated environments, parallel work, and a clean handoff back to a human review loop. That is the category Builder belongs to.

Why now

The center of gravity in software has shifted. Local-first coding is no longer the only serious default. The best teams now bounce between chat, code search, review agents, repair agents, CI, and browser-based orchestration. Once that happens, a cloud agent surface stops feeling optional. It becomes the missing coordination layer.

That is why browser-based delegation suddenly matters. You should be able to hand off a task from anywhere, let the agent work inside managed infrastructure, and come back to a result that is inspectable enough to trust. That is the cloud agent promise. Not later. Now.

Why we built it this way

Most agent products import the wrong metaphor. They stack panes until your attention fractures—logs here, files there, tabs everywhere—each one insisting it is the main event.

Builder starts from Critique Chat: a fixed canvas, a generous composer, a thread that reads like dialogue. The difference is purpose. Chat is for exploration through GitHub APIs and model reasoning. Builder is for execution: a prompt, a repository, a model, a sandbox clone, and a straight line from “here is what I want” to “here is what changed.”

You still get proof—files touched, validations, branch and PR workflows as the product matures—but those details sit beside the conversation, not on top of it.

The design target is closer to the best parts of Cursor background agents than to browser IDE theater. Tell the system what outcome you want, let the cloud agent run, come back to a readable thread. The important distinction is that Builder is explicitly device-agnostic. Your local machine is not the runtime and does not need to be.

That is also the thread running through the launch messaging of the best cloud agents. GitHub Copilot talks about an agent working like a teammate in the background. OpenAI’s Codex stresses isolated cloud sandboxes and multiple tasks in parallel. Claude Code on the web frames browser-based delegation on managed infrastructure. Kiro frames itself as going beyond vibe coding toward production discipline. Builder belongs in that family, but with a stronger bias toward one thing: getting actual work done inside Critique’s world.

What you will recognize

If you have lived in Critique, Builder will feel familiar the moment it opens.

The left rail is your history: recent runs, status at a glance, the repo each task breathed in. The center is the live thread—your instructions first, then compact beats of thinking, tool use, and steps written for humans, not log parsers. The composer stays impossible to miss. That is where work begins.

We did not invent a second aesthetic. Same off-black canvas, same warm type, same acid accent used like a highlighter instead of a neon sign. The goal is legibility under pressure: the feeling that someone competent is in the room, and the interface is not auditioning for your attention.

That continuity is intentional because Builder is not a side quest. It belongs to the same product logic as Critique Chat. One surface is lighter-weight and API-driven. The other is heavier-weight and sandbox-driven. Same house, different room, same standards for calm, scanability, and proof.

What is new

Builder is a major feature because it closes the loop between intent and execution inside Critique’s world.

Under the hood, Builder rides the same execution spine the rest of Critique trusts: isolated environments, OpenCode on E2B, and the operational habits we hardened for reviews and remedies. New room. Same foundation.

Concretely, a Builder job writes the task into the sandbox, clones the repository into `/workspace`, boots OpenCode in that environment, and asks the model to work there rather than on your device. That architectural choice is the whole point. The model can read files, run checks, inspect state, and write a real execution summary from inside the repo it is changing.

Builder also supports chained follow-ups. A later run can continue from the prior job’s output instead of forcing you to restate everything from scratch. That starts to look less like a single prompt and more like directing a compact software team that already remembers the assignment.

Why OpenCode

Builder is built on OpenCode because we think OpenCode is the best open-source framework for serious agentic coding work right now. That is not a slogan about ideology. It is a practical judgment about execution quality, model routing flexibility, and how much of the agent loop you can actually inspect and shape.

Open-source matters here because the agent runtime is not a side detail. It is the thing deciding how tools are called, how prompts are structured, how models are delegated, and how the whole run behaves under pressure. We would rather build on a framework we can understand, improve, and trust than treat the execution layer as a black box we rent by the month.

OpenCode also fits the way Critique thinks. Reviews, remedies, and builder jobs all benefit from a runtime that is comfortable with explicit instructions, structured tools, and specialist handoffs instead of pretending one monolithic model should do everything equally well.

The launch posts we studied also reinforced something important: the runtime story matters as much as the model story. The strongest products explain where the work runs, what the agent can touch, and how the result gets handed back. Builder should be understood the same way. OpenCode is not an implementation footnote. It is the execution substrate that makes the product legible.

Subagents are not garnish

We are opinionated about subagents because a real engineering task is rarely one lane. Updating software means someone should inspect the API contract, someone should check the tests, someone should trace the affected files, and someone should keep the whole run pointed at the outcome. Builder inherits that worldview.

The useful mental model is not “one super-bot did a thing.” It is “I just directed a small cloud software team.” One worker can research. Another can patch. Another can validate. The lead agent decides what to do next based on the evolving state of the repo. That is closer to how good engineering work actually gets done.

That is also why Builder feels different from app generators. v0 and ManusAI are usually evaluated on first-draft impressiveness. Builder should be evaluated on whether it helps you move a repository forward with less friction, more continuity, and better remote execution.

Who it is for

Builder is for anyone who has written a careful paragraph in Slack, then copied it into three tools to get a branch.

For maintainers who want a clean handoff: do this, with a paper trail. For builders who want speed without abandoning taste. For teams who want one premium surface instead of a patchwork of experiments.

It is also for people who do not want their local machine to be the bottleneck. If the software team is partly synthetic now, it should not live only on the laptop that happens to be open. Builder lets that team work in the cloud, on demand, from any device that can open a browser.

How to think about it

Critique Builder is not an app builder in the narrow sense. It is not a dashboard report, not a benchmark playground, and not a browser IDE wearing a product-marketing trench coat. It is a cloud agent surface: chat-first, status-aware, honest about complexity, and unwilling to waste your eyeballs on decoration.

The cleanest summary is this: Chat helps you think with the codebase. PR Review helps you judge code heading toward merge. Remedy helps you repair code that already has a review artifact. Builder helps you get work done in the first place.

We ship Builder in chapters, because the right surface for cloud coding should earn its complexity. Shell and composer first. Better live activity next. Deeper results, continuations, and richer execution loops after that. When you open it from the dashboard, you are not jumping to a different company. You are walking into the same house through a different door.

Critique Builder is where a clear sentence meets a serious run, where OpenCode does the heavy lifting in a real sandbox, and where the interface finally acts like it believes software work should be calm, remote, and actually shippable.

What we believe

We think the software stack is reorganizing around delegation. Humans still set goals, judge tradeoffs, approve outcomes, and own the product. But more of the implementation work can happen in managed environments, with specialized cloud agents doing parallel research and execution in the background. Builder is our expression of that future.

Not because terminals are dead. Not because local tools stop mattering. But because serious teams need both: direct control when they want it, and a cloud execution room when they want to offload work without offloading judgment.