From PR to Production: Why We’re Building Forge

Part 1 in the series on building Forge, an agentic SDLC that runs a ticket from a business request all the way to production.

Today’s coding agents all stop in the same place: at the proposal. The agent writes the code, opens a pull request, and hands the baton back to a human exactly where the rest of the work begins — review, merge, deploy, watching the dashboards afterwards. Forge asks the harder question: what would have to be true for an agent to safely go further? This series is the design record of an agentic SDLC — one that closes the loop through merge, staging, and production.

Forge is an agent orchestrator that attaches to someone else’s monorepo through configuration — it doesn’t live inside it — and drives a ticket from the business request to the deployment. A few conventions apply from day one, because we already know their absence hurts: interrupt() always sits in a dedicated node with no side effects, webhook dedup uses INSERT ... ON CONFLICT as a lock, and guardrails and risk scoring are pure functions with unit tests.

The goal that is easy to wreck: the developer does as little as possible

The business files the ticket. The developer’s only role in a normal run is to review the requirements when the agent itself signals that it doesn’t know something. Planning, implementation, tests, verification, PR, release, post-deploy observation — the system does all of it.

A goal stated that way has a well-known failure mode: you can hit it trivially by merging everything without looking. The time metric then looks superb while technical debt piles up unnoticed for months. So the metrics are hierarchical, not parallel:

• Quality is the condition (the gate): the share of changes reverted or hotfixed within 7 days of deployment, the share of PRs needing corrections after review, and security misses.
• Time is the goal: median developer time per ticket and the share of tickets that pass with no human intervention — maximised only while the condition holds.

If any quality indicator degrades, autonomy thresholds tighten automatically, even at the cost of time. Never the other way around.

Trade-off: a hierarchy instead of a balance means we may end up with a slow, working system — developer time not dropping, quality high. We accept that deliberately: a slow working system is an optimisation problem, whereas a fast debt generator is a project to stop. The distinction between those two states is written into the plan explicitly.

Scepticism toward AI-written code isn’t our quirk — it’s the state of the industry. Trust in the accuracy of AI code fell to 29% in the Stack Overflow Developer Survey 2025, and 66% of developers spend more time fixing “almost-right” AI code than that code saved them (survey write-up). Any system that wants to take the human out of the loop has to answer what replaces that distrust. Forge’s answer is evidence, not assurances — the subject of post #3.

Buy vs build: what an agentic SDLC actually adds

Forge went through the market confrontation before the first line of the plan — the question “isn’t this just product X for $N a month?” has to be asked before the build, not after. And it has to be asked honestly, because the market moved a long way through 2025 and 2026. Browser verification is no longer a gap: the Copilot coding agent has had its own browser via Playwright MCP, on by default, since July 2025, Devin drives a browser over CDP, Jules renders UI and attaches screenshots. Nor is asking clarifying questions: Google Jules has asked them before coding since August 2025, Atlassian Rovo Dev does it on Jira issues, and both Copilot and Cursor ship planning modes that ask.

Subtract what already exists and exactly three things are left — and if any of them turned out to be unnecessary, the honest answer would be to buy:

1. Closing the loop through to production. This is the one differentiator no vendor ships in mid-2026: everyone stops at a human gate around merge, nobody carries a change through staging, canary and an observation window. Off-the-shelf tools end where the developer’s remaining work starts.
2. Requirements clarification as a mandatory gate in a durable ticket thread. Not “we ask questions” — others do that. The difference is that the question is a gate rather than an optional mode, that it targets business requirements, and that one thread carries the whole cycle through to release consent. Off-the-shelf agents abandon the issue thread once they pick up the work.
3. Evidence of working software instead of assurances — verification artefacts (gate results, a recording of the click-through, a staging smoke run) as a condition of promotion, not as an attachment.

Trade-off: file editing, branching and PRs are a commodity — we don’t write our own coding loop; we call a ready-made agent behind a CodingAgent interface. The price: a dependency on someone else’s product in the middle of the system, and its pace of change. The alternative — our own prompt plus patch application — is a lot of work for a worse result, and it’s the fastest-ageing part of the whole thing. The interface lets us swap providers without touching the graph.

The strategic risk is named in the plan without anaesthetic: we might build a worse version of an existing coding agent. The exit criterion is explicit — if developer time doesn’t drop at sustained quality by milestone M5, we go back to buying.

The hard assumption from day one

The business writes the ticket, and its text reaches an agent with access to a repository and a shell. We treat the target repo and the generated code as an untrusted execution environment, with the consequences — sandbox, network allow-list, forbidden paths — developed in post #3. Prompt injection through ticket text is not an exotic scenario here; it’s threat number one on the OWASP Top 10 for LLM Applications.

What’s next

If the goal is minimum developer work, the key question follows immediately: who decides when the system asks and when it acts alone? The answer — a pure function, not an LLM — is the subject of post #2.

Bibliography

• Stack Overflow Developer Survey 2025 — trust in AI code accuracy at 29% (write-up)
• GitHub — Copilot coding agent gets its own browser and coding agent docs — browser verification as a commodity; the issue thread is abandoned after handoff
• Google Jules changelog — clarifying questions GA since August 2025
• OWASP Top 10 for LLM Applications — prompt injection as risk number one