Live preview
Open the change running, with seeded sample data, on its own address behind your sign-in. It stops when nobody’s looking. Laravel projects, for now.
An AI teammate for your backlog, held to your own checks.
nightlab takes a ticket, writes the change in a sandbox, and runs your project’s own static analysis and tests on it. A second model reviews it. You get a draft pull request, and a person merges.
Invite-only for now. Works with Jira, GitHub and GitLab.
Ticket in, draft pull request out
Five steps, in order, and it shows its work at each one. Start one run by hand, a batch from a filtered list, or let an event in your tracker start it under rules you set.
Scope
Reads the ticket and the code it touches, and checks the feature isn’t already there. Then it writes down what done means.
SHOP-1430Customers can download past invoicesJira
“Customers keep emailing support for old invoices. Let them get them from their account.”Sam Roe, Support. Story, priority High.
It reads this, and the code it touches: the Order history page, the Invoice model and its controller.
It compared the ticket with what the code already does
It exports a list of orders, not one invoice, and only admins can run it.
It emails an invoice again; the customer still can’t get one themselves.
New feature. Nothing close enough to call it a duplicate, so it goes on.
The spec it posted back
- A customer downloads a paid invoice as a PDF
- The link sits beside each order in Order history
- An unpaid invoice answers 403
- Each case has a feature test
Posted to SHOP-1430 as a comment, so the ticket says what will be built and why.
Code
Writes the change in a sandbox, on its own agent/ branch. Your branches stay yours.
agent/SHOP-1430Sandbox3 files
12 public function download(Invoice $invoice)13 {14+ abort_unless($invoice->isPaid(), 403);15+ $this->authorize('view', $invoice);16+17+ return Pdf::loadView('invoices.show', compact('invoice'))18+ ->download("invoice-{$invoice->number}.pdf");19 }
28Route::middleware('auth')->group(function () {29 Route::get('/orders', [OrderController::class, 'index']);30+ Route::get('/invoices/{invoice}/download',31+ [InvoiceController::class, 'download'])32+ ->name('invoices.download');33});
1+it('downloads a paid invoice as a PDF', function () {2+ $invoice = Invoice::factory()->paid()->create();3+ actingAs($invoice->customer)4+ ->get(route('invoices.download', $invoice))5+ ->assertOk()->assertDownload();6+});7+8+it('answers 403 for an unpaid invoice', function () {
Written in a container with no route to nightlab’s own credentials. It pushes only to agent/ branches.
Gates
Your static analysis and tests, on the base branch and again on the change. They’re compared by message, not by line, so old warnings and moved code don’t count. Only a new failure does, and it goes back to the code step: no pull request opens until it’s gone.
Base branch main
With the change agent/SHOP-1430
Gates for Laravel, Node.js and TypeScript, Python, Go, Flutter and .NET, in containers.
Review
A second model, not the one that wrote it, reads the diff. Advice only: it never approves or merges.
AI pre-screenAdvisory
0 blockers0 warnings1 nit
17 return Pdf::loadView('invoices.show', compact('invoice'))18+ ->download("invoice-{$invoice->number}.pdf");
Customers search their downloads by date. Consider the date in the file name too.
Written by one model, reviewed by another
Its findings travel with the run and the PR. A person decides what they’re worth.
Draft PR
Opened on your git host, with what changed and why. On GitHub it also names a reviewer: whoever owns or last changed those files. It merges only when you say so: today, a person merges.
Draft#322GitHub
SHOP-1430: customers can download past invoices
main has 3 errors and the change has the same 3, compared by message: none of them is new.
0 newly failing. Attempt 1 failed one test; the code step fixed it.
Name the PDF with the date too. Advice only: it doesn’t block the merge.
Review it on your git host and merge it there, or send a review basket back.
Where it waits for you
A run goes from ticket to draft PR on its own. Turn a round on for a project, and runs stop there for a person, and only there. Switch a few on to see what you’d get.
Beyond the ticket
A run ends at a draft PR. These go beyond it: before the merge, on your team’s own pull requests, between tickets, and when a version ships.
Reviews of your team’s PRs
The same second model reviews the pull requests your people open, as a comment review with a “nightlab review” check. It never approves.
Project Health
Scheduled scans of each repository in eight categories. The worst findings become suggested tickets, filed only when you approve one.
Releases
Create and release your Jira versions from nightlab, with each merged change’s fix version suggested, or set. When a version is released, it drafts two notes from what shipped, one for your team and one for your clients. A person approves each one, then copies it.
All of it inside limits you set
Each limit is a setting you can see in the portal, not a promise on a web page.
It writes only once you turn writes on
Writes to your repository
Off. Every run is a dry run.A new workspace starts here: no pull request, comment or push until you turn writes on.
It merges only when you say so
Draft #322Merge: a person
It opens draft pull requests. Today, that means a person merges, on your git host.
It pushes only to its own branches
agent/*Writes here
main, your branchesNot touched
Everything it writes goes to agent/ branches, and reaches yours only through a pull request.
Each person sees only what they can see
Issues in SHOPAs your tracker account sees them
In your tracker, each person sees, and starts runs on, only the issues their own account can see.
It stops at your budget
Close to this workspace’s monthly limit. See budgets
This workspace’s monthly limit is used up; runs start again on 1 Nov, or when an admin raises it.
Admins set a monthly limit and each project’s share. Near it, a note says so; at it, new runs pause.
It works in a sandbox
SandboxNo route to nightlab’s credentials
Model providerCode and tickets, to do the work
The agent, the gates and live previews run in containers.
Worth knowing
Your checks set the bar.
nightlab’s work is as good as the gates you give it. Your tests and analysis catch what they catch, and your team reviews the rest.
Code goes to your workspace’s model provider.
To do the work, code and tickets are sent to the model provider your workspace uses, under that provider’s terms. The agent works in a sandbox, apart from nightlab’s own credentials. How your data is kept
Works with
nightlab sits between your tracker and your repository, and uses your checks, your tools and your model on the way.
Tickets come from
Your tracker
Where your team files the work.
- Jira
What nightlab does here
- Reads the ticket, and posts the spec back as a comment.
- Starts runs by hand, from a filtered list, or on an event, under rules you set.
- Triages new issues, once you turn it on: which it can take, and what the rest are missing.
- Manages versions and fix versions, and drafts release notes when a version is released.
The work happens in
nightlab
Where the change is written and checked.
What nightlab does here
- Writes the change in a sandbox, on its own agent/ branch.
- Runs your checks on the base branch and on the change. Only a new failure counts.
- Has a second model review the diff, as advice.
- Your checksStatic analysis and tests, in containers, for Laravel and PHP, Node.js and TypeScript, Python, Go, Flutter and Dart, and .NET
- Your toolsMCP servers you connect to a project, for the agent to use
- Your modelAny model behind the Anthropic or OpenAI APIs, or your own endpoint (vLLM and others). Billed by nightlab, or bring your own key.
- Claude
- OpenAI
- OpenRouter
- Your endpoint
Draft PRs go to
Your repository
Where your code lives, and a person merges.
- GitHub
- GitLab
What nightlab does here
- Pushes only to agent/ branches. Yours stay yours.
- Opens a draft pull request with the spec, the gates and the review.
- Reviews your team’s own PRs, and scans each repository for Project Health.
Using something else? Say so in your request.
Request access
nightlab is invite-only for now. Tell us about your team and the first tickets you’d hand it.
What happens next
- We review your requestWe look at your stack and the work you described, to see where nightlab fits.
- We set up your workspaceYou get an invite from hello@nightlab.io, with any questions we have first.
- You start with dry runsSetup takes you through four required steps: your code, your tracker, a project, and how runs are paid for and approved. Then run real tickets. Nothing is written to your repository until you turn writes on.
Have a question first? Write to hello@nightlab.io.
Thanks, . Your request reached us.
We’ll answer at . Nothing else to do for now.
Your request didn’t send.
Your answers are still in the form. Try again in a minute, or email them to hello@nightlab.io.