20-50x Faster Shipping: What One Engineer's AI Workflow Reveals About Editor-Free Agent Orchestration

A developer reports 20-50x productivity gains by moving AI out of the editor and into a two-agent browser workflow, where one agent builds and another reviews, operating on full file context. The approach, which uses manual diff handoffs and a human approval gate, highlights tradeoffs such as context overflow and partial application, and is best suited for solo developers or small teams.

A developer posted a 270-point HN thread claiming 20-50x productivity gains by moving AI out of the editor and into a two-agent browser workflow. The claim is bold, but the architecture is simple: one agent builds, one agent reviews, and both operate on full file context instead of cursor snippets. The interesting part is not the speed number. It is the orchestration shape and what it reveals about context boundaries, diff handoffs, and failure modes when you separate reasoning from the IDE. The workflow uses two browser tabs ChatGPT, Claude, or similar and a terminal. No plugins, no LSP integration, no inline completions. Agent 1: Builder Agent 2: Reviewer The developer pastes code into the builder, gets a diff, pastes the diff into the reviewer, and manually applies changes. No file watchers, no automatic writes, no shared state between agents. Editor-integrated AI tools Copilot, Cursor, Cody operate inside a single file or a narrow window. They see the current buffer, maybe a few imports, and whatever the LSP can index. They optimize for low-latency completions, not cross-stack reasoning. Moving AI into the browser lets you paste: The tradeoff: you lose automatic context. You have to manually select what the agent sees. If you forget a dependency or a caller, the agent will not catch it. The builder agent does not write files. It returns a diff or a rewritten block. The developer copies that into the editor and applies it manually. This introduces a human approval gate, but it also creates a failure mode: if the diff is large or touches many files, manual application becomes error-prone. The developer has to track which changes were applied and which were skipped. The reviewer agent mitigates this by checking the final diff, but it only sees what you paste. If you apply half the changes and forget to paste the rest, the reviewer will not know. The biggest win is cross-boundary work. When a change spans Swift, Objective-C, and JavaScript, editor tools struggle because they do not share context across language servers. The browser-based agent sees all three at once. Example flow: This works because the agent has full context. It breaks if the codebase is large enough that you cannot paste all relevant files into a single prompt most models cap at 128k-200k tokens . | Failure Mode | Cause | Mitigation | |---|---|---| | Missed callers | Agent does not see all files that import the changed function | Paste all known callers or use grep to find them before prompting | | Partial application | Developer applies some changes but not others, reviewer only sees partial diff | Always paste the full intended diff into the reviewer, not just what was applied | | Context overflow | Codebase too large to fit in a single prompt | Break into smaller tasks or use a retrieval layer vector DB, file chunker | | Stale diffs | Agent generates a diff, developer edits files, then applies the diff on top of new changes | Apply diffs immediately or regenerate them after manual edits. Use git stash before applying diffs to avoid conflicts. | | No rollback | Manual application means no automatic undo if the change breaks tests | Use Git branches and commit after each agent-generated change | The developer mentions "surgical edits" as a guardrail: instead of letting the agent rewrite entire files, ask for exact line numbers and changes. This keeps diffs small and reviewable, but it requires the developer to know the codebase well enough to guide the agent. There is no observability layer. The developer does not log prompts, track token usage, or measure agent accuracy. The workflow is entirely manual. This simplicity is intentional: fewer moving parts means fewer failure modes. The developer relies on manual review and testing instead of automated metrics. If something breaks: This works for solo developers or small teams, but it does not scale. There is no audit trail, no way to replay a session, and no way to measure which agent builder or reviewer introduced a bug. For production use, you would want: The deployment is a developer's local machine. No servers, no APIs, no orchestration framework. The "infrastructure" is: This is the simplest possible agent orchestration: stateless, synchronous, human-in-the-loop. It works because the developer is the orchestrator. If you wanted to automate this, you would need: At that point, you are building Cursor or Copilot Workspace. The developer does not share code, but the workflow implies something like this: python builder agent.py import anthropic client = anthropic.Anthropic api key="..." def get diff files: dict str, str , instruction: str - str: """Send multiple files to builder agent, get back a diff. Warning: This will consume tokens proportional to total file size. For large codebases, you may hit context limits 128k-200k tokens . Consider chunking or using a retrieval layer for production use. """ context = "\n\n".join f"// {name}\n{content}" for name, content in files.items prompt = f"{context}\n\nTask: {instruction}\n\nReturn a unified diff." try: response = client.messages.create model="claude-3-5-sonnet-20241022", max tokens=8000, messages= {"role": "user", "content": prompt} return response.content 0 .text except anthropic.APIError as e: Handle rate limits, context overflow, or API failures print f"API error: {e}" return "" def review diff diff: str - str: """Send diff to reviewer agent, get back a critique.""" prompt = f"Review this diff for regressions, missing updates, or subtle bugs:\n\n{diff}" try: response = client.messages.create model="claude-3-5-sonnet-20241022", max tokens=4000, messages= {"role": "user", "content": prompt} return response.content 0 .text except anthropic.APIError as e: print f"API error: {e}" return "" Usage files = { "api.swift": open "api.swift" .read , "bridge.m": open "bridge.m" .read , "client.js": open "client.js" .read , } diff = get diff files, "Add a 'timeout' parameter to the API call" print diff critique = review diff diff print critique Developer manually applies diff and commits No automation, no file writes, no state persistence. The developer is the glue. The workflow has no explicit security boundaries. The developer pastes code into a third-party LLM OpenAI, Anthropic, etc. , which means: This is the primary security risk. Every paste operation is a potential data exfiltration event. If you work on proprietary code, customer data, or anything covered by an NDA, this workflow violates most security policies. For production use, you would need: The developer does not mention any of this, which suggests the workflow is used for side projects or non-sensitive code. If you handle production systems, customer data, or regulated environments, you cannot use this workflow without adding a security layer. Additional risks: Use this workflow when: Avoid this workflow when: Best for: Solo full-stack engineers working across multiple languages on non-sensitive projects. Not suitable for teams requiring audit trails, compliance, or security isolation. The 20-50x claim is hard to verify, but the architecture is sound for a specific use case: a developer who knows the codebase well, works across multiple languages, and prefers explicit control over automatic tooling. If you want to scale this, you are building an orchestration layer. At that point, evaluate whether Cursor, Copilot Workspace, or a custom MCP server fits better than two browser tabs.