From Backlog to Pull Request: Building a React App With Agent22
Revy is a fictional app, used here to illustrate how Agent22 works in practice. The setup is realistic. The stack, the workflow, the ticket types — all of it reflects how real teams are using Agent22 today.
Revy is a ski resort review platform. Users search resorts, read reviews, filter by conditions, and leave their own ratings. The stack is what you’d expect: React with TypeScript, Vite, a component library, and a REST API on the backend. Nothing exotic. The kind of codebase most teams have three or four of in various states of completion.
What’s different is how the work got done.
We connected Agent22 to Revy’s Jira board and GitHub repo, pointed it at the backlog, and let it run. The agent picked up tickets, implemented changes, and opened pull requests. Nobody wrote the code. Engineers reviewed it.
Here’s what that actually looked like in practice.
The Setup
Configuration is done through the Agent22 Hub. You connect your GitHub repo, connect your Jira project, and configure a filter that tells the agent which tickets to pick up. For Revy, we scoped it to a specific label on the board.
That filter matters more than it sounds. The agent will pick up whatever you point it at. If your backlog is full of vague tickets with three-line descriptions and no acceptance criteria, you will get vague PRs back. Garbage in, garbage out applies here exactly the same as it does when you hand work to a junior engineer.
The tickets we assigned were specific. Component scope was clear. Acceptance criteria existed. That turned out to be the biggest factor in output quality.
What the Agent Actually Did
Each ticket went through the same cycle. The agent checked out the repo, read the codebase, implemented the change described in the ticket, and opened a pull request against main. The PR description included which ticket it was working on, what it changed and why, any assumptions it made, and a note on test coverage.
For Revy, that looked like:
- Adding a star rating component to the resort detail page
- Updating the search results handler when the API returned no matching resorts
- Fixing a layout regression on the resort listing page on mobile that had been sitting in the backlog for two weeks
- Wiring up the conditions filter to the API query parameters — the UI existed, but the filter was not actually connected to anything
None of these were technically complex. That is exactly the point. Most backlogs are full of tickets that are not technically complex. They are just waiting for someone to have the bandwidth to do them.
What Landed in Review
The PRs were reviewable. Not always perfect, but reviewable. Engineers looked at the diff, understood what had changed, left comments where something needed adjustment. The agent does not auto-merge. That is intentional. The agent ships code to review, not code to production.
A few patterns showed up quickly in the review process.
When the ticket was specific, the PR was tight. When the ticket was vague, the agent made assumptions and documented them in the PR description. Sometimes the assumption was right. Sometimes it prompted a conversation about what the ticket actually meant, which is a useful forcing function.
The agent did not touch tests. That was expected. Tests are the team’s responsibility. The agent’s job is to implement the feature; the team’s job is to verify it behaves correctly. This is not a limitation, it is the right separation of concerns.
What This Changed About the Workflow
The backlog moved faster. Not because the work was being done carelessly, but because the work was actually being done. Tickets that would have sat for two sprints because nobody had capacity got picked up and came back as PRs within hours.
The engineering team spent more time in review and less time in implementation for this class of ticket. Whether that is a good trade depends on your team. For Revy, where the bottleneck was implementation bandwidth rather than review capacity, it worked well.
One thing that shifted: ticket quality improved. When engineers knew the agent was going to act on what was written, they wrote better tickets. Acceptance criteria got more specific. Edge cases got documented. That is a side effect worth noting.
Where It Fits
Agent22 is not the right tool for the parts of your backlog that require architectural decisions, deep domain knowledge, or careful judgment about tradeoffs. Those need an engineer thinking through the problem.
It is the right tool for the parts of your backlog that are clear, bounded, and waiting for someone to have time. That is a larger fraction of most backlogs than teams usually admit.
Revy’s board had a realistic mix. The agent handled a lot of the queue. Engineers handled the rest. The combination was faster than either alone.
Agent22 supports Jira and GitHub out of the box. Configuration takes less than an hour. If you have a backlog and a React codebase in the same state Revy’s was in, it is worth a conversation.