Codezen: From a Repository to a Pull Request
A walkthrough of the Codezen app: pick a GitHub repository, follow the run step by step, and get a pull request that carries its test results.
Yantra Team3 min read
On this page
A coding agent is only as useful as what it hands back. Codezen runs on your GitHub repository on a cloud machine and hands back a pull request, with the evidence a reviewer needs already in it.
Open it and pick a repository
Pick Codezen in the apps launcher, or open /c/<chat-id>/codezen. Codezen owns the chat while it is open, and it is available from a brand-new chat. Connect GitHub, pick a repository, and describe the change in plain words: a feature, a bug fix, a refactor.
Nothing runs on your laptop. Codezen clones the repository onto a cloud machine, installs the dependencies and works there.
Follow the run
A run is a series of named steps you can watch, such as Install dependencies, Review project, Implement change and Create pull request. Depending on the harness the session uses, a run can add Draft implementation plan before any code is written, and Debug failing tests for one more fixing pass when the suite ends red.
Ask for a plan first when the change is large. "Plan a migration of our API client to v2 in the acme/backend repo" gives you the plan to read before any code is touched.
What lands in the pull request
Before the pull request opens, Codezen runs the repository's own checks. The result goes into the pull request whether it passed or failed. A red suite is a fact the reviewer should see, not something to hide. For changes that render, it captures screenshots so the reviewer can judge by looking. The pull request title is written from the diff that actually landed, not from the original request.
Follow up, then merge
Ask for a change on a pull request an earlier task opened, and Codezen works on top of that branch. The open pull request gains a commit instead of a sibling. When it is ready, Codezen reads the pull request's real state and merges it from the session, so you do not have to go to GitHub to finish.
Prepared machines and scheduled sessions
A prepared machine keeps the clone and the installed dependencies, so the next session on the same repository starts from there instead of from zero. You can open an IDE, a terminal or a desktop on the machine when you want to look for yourself.
Scheduled coding sessions run an agent task on a cadence: a cron expression in your timezone, a single run at a set time, a window with a start and an end, or a maximum number of runs. An existing schedule can be paused, resumed or deleted.
Reviews and issue sweeps
Codezen also works on pull requests and issues you already have. It can review a pull request and give it a risk score, review open pull requests automatically, fix a GitHub issue, or sweep the issues carrying a label.
From a design
A design made in Design Studio can be published with Use in code, which gives Codezen a link to build from. The Demo video action in Design, Canvas and Web Builder opens Codezen with a prefilled form for a demo video of that design. Nothing runs until you confirm it there.
From chat
- "Connect my repo and fix the failing login test, then open a PR."
- "Plan a migration of our API client to v2 in the acme/backend repo."
- "Have the coding agent add dark mode support to my Next.js project."
- "Clone my repository and fix the failing test."
What it is not
Conceptual programming questions, explaining a pasted snippet and small scripts with no repository are answered in chat. Learning GitHub or a language as a subject is a study plan in Notebook. Designing a website visually is Web Builder or Design Studio. Build pipelines and deployments are CI, and the databases your code talks to come from Workspaces, covered in Spin up a database from a chat message. Tracking the work for a team is Issue Ticket.