Rillet Uses AI Agents to Auto-Write PRs: New Features Ship in 2 Hours, Merged PRs Triple

While most teams are still debating whether AI coding assistants can be "reliable," some engineering teams have already handed the entire pipeline from customer request to production deployment over to AI Agents. According to information shared on Twitter, RilletHQ engineers run eve agents on Vercel to convert customer requirements directly into PRs—new features reach production in just 2 hours, and merged PR volume has tripled. Behind these numbers is a software delivery process being fundamentally redefined.

From Customer Request to PR: A Compressed Delivery Pipeline

In the traditional workflow, a customer request goes through product manager triage, engineer scheduling, coding, review, testing, and merging before it goes live. RilletHQ's approach hands the "requirement understanding—code generation—PR submission" segment to eve agents running on Vercel. When a customer request enters the system, the Agent generates the corresponding code changes and opens a PR, while human engineers shift to review and gatekeeping roles.

The value of this model isn't about letting AI "write code"—it's about driving the conversion cost between requirement and code down to nearly zero. For highly repetitive, clearly patterned feature requests, the Agent can immediately produce reviewable changes, freeing engineers from context switching and boilerplate code.

PR (Pull Request) is a standard mechanism on code collaboration platforms like Git/GitHub: after completing changes on a separate branch, a developer submits a merge request to the main branch, which goes through code review, automated testing, and other gatekeeping before being merged into the mainline. A PR simultaneously serves three roles—the carrier of changes, the venue for review, and a traceable audit record. "Agent opens a PR" means the AI generates not just a code snippet, but a complete change unit with commit messages, change descriptions, and direct entry into the review process. This also explains why the quality of review infrastructure directly determines the success of this model.

What 2-Hour Deployment and Tripled PRs Mean

"New features in production within 2 hours" and "merged PRs tripled" need to be examined together. The former shows delivery cycles significantly shortened; the latter shows substantial throughput improvement—not working faster at lower quality, but more changes actually being merged into the mainline.

Tripled PR volume typically has two explanations: either more requirements exist, or the cost of landing each requirement has decreased—small changes previously shelved due to scheduling are now worth doing. Given the context of Agent-generated PRs, the latter is more likely: when the marginal cost of opening a PR is extremely low, teams are more willing to quickly land small customer feedback items, creating a denser iteration rhythm.

You might not have noticed that increased PR merges don't automatically equal improved engineering quality. Whether review processes are strengthened in tandem, whether test coverage keeps up, and whether Agent-generated code conforms to team standards—these questions determine whether this model can sustain long-term.

How Agent-Driven Delivery Differs from Traditional AI Coding Assistants

Most AI coding tools on the market position themselves as "co-pilots" in the IDE, helping engineers complete code, explain errors, and generate unit tests—with humans driving every action. RilletHQ's model is closer to "Agent-driven": the Agent receives a business goal (customer request) and autonomously completes the loop from understanding to PR submission, with humans intervening at the PR stage.

This difference determines the scope of automation. The co-pilot model optimizes the efficiency of the act of writing code; the Agent model optimizes the entire pipeline from requirement to change. The latter has a higher ceiling but also demands more from Agent reliability, codebase context understanding, and team review infrastructure.

AI Agents differ fundamentally in architecture from traditional code completion tools. Completion tools are essentially "single-step predictors": given context, predict the next code segment, with humans deciding when to invoke and how to verify. An Agent is a system with goal decomposition, tool invocation, and feedback loops—it can read requirements, search codebases, edit files, run tests, and retry based on failure results until a deliverable change is produced. Implementing these capabilities typically requires integration with code repositories, CI systems, documentation retrieval, and other external tools, along with long-context understanding and multi-turn autonomous decision-making. Precisely because of this, Agents have higher capability ceilings but also more "complete" errors—they may confidently submit a PR that looks reasonable on the surface but actually violates standards, which is why human review cannot be omitted.

Vercel's Role as the Agent Runtime Foundation

RilletHQ's choice to run eve agents on Vercel indicates that such Agent workflows have specific requirements for deployment and runtime environments: they need to respond quickly to events, integrate with code repositories and collaboration tools, and scale lightly. Vercel's product positioning covers exactly the deployment scenarios for event-driven applications, allowing Agents to run as persistent services rather than being tied to an individual engineer's local environment.

From an architectural perspective, placing Agents on a cloud deployment platform means their behavior can be uniformly observed and managed—essential for engineering teams that need to audit the source of every code change.

Event-driven applications refer to services triggered by external events (such as a new ticket, a webhook callback, or a customer message) rather than continuously waiting for user requests. Agent workflows are naturally event-driven: a customer request arriving triggers a "understand—code—submit PR" execution pipeline, then returns to idle. Such workloads are bursty and intermittent, suited for platforms with on-demand scaling and fast cold starts. "Vercel's" product positioning is exactly deployment for frontend and event-driven services, supporting integration with Git repositories, Webhooks, and other ecosystems, enabling Agents to run as persistent services rather than being tied to an individual engineer's local environment, with every execution uniformly observable and auditable.

Who This Model Suits—and Who It Doesn't

The suitable scenarios are fairly clear: teams with stable requirement patterns, well-structured codebases, and mature testing and review processes. Such teams can have Agents produce high-quality PRs within established boundaries, with humans focusing on review and architectural decisions.

The unsuitable scenarios are equally obvious: teams with heavily coupled codebases, highly ambiguous requirements, or lacking automated testing as a safety net. In these environments, Agent-generated PRs would pile up in the review stage, actually increasing engineers' burden. RilletHQ's case doesn't offer a directly copyable solution—it's a signal that when review and testing infrastructure is strong enough, Agents can take on far more responsibility than "code completion."

Where the Human Engineer's Role Is Heading

If the path from requirement to PR is taken over by Agents, engineers' core work will concentrate at two ends: one is decomposing vague business problems into clear goals that Agents can understand; the other is rigorously gatekeeping generated changes. Coding itself still exists, but its share will decline.

This raises new requirements for team capability structure: review skills, overall command of the codebase, and the ability to design Agent work boundaries will matter more than raw coding speed. RilletHQ's practice shows that someone is already walking this path—and achieving quantifiable results.