Start where it matters and the risk is small.
The teams that get value quickly do not pick the most impressive task. They pick work that genuinely needs doing, that a person would otherwise do, where a mistake costs a rejected pull request rather than an incident.
Backlog and maintenance
Bugs, dependency upgrades, flaky tests, deprecation warnings. The work that genuinely needs doing and never makes it into a sprint.
Read →Code review
A reviewer on every pull request that has read the codebase, run the tests, and can point at the caller it would break.
Read →Browser QA
Run the changed journey in a real browser and return structured checks, screenshots and evidence alongside the pull request.
Read →Work, rules and proof stay together.
Each use case starts with assigned work, runs in a real engineering environment and ends with evidence your team can review.
Repository work can proceed within the limits you set. Actions in connected services follow the same rules, where Nova can proceed, ask the right person or remain blocked.
That gives a pilot an honest scorecard: tickets completed, reviewer corrections, AI and environment usage, and evidence quality rather than a collection of impressive demos.
See Nova run on your own code.
A working session rather than a slide deck. Bring a repository and a ticket you would otherwise assign to someone, and watch it go from the ticket to a pull request you approve.