Demo
How Praxa learns a job, start to finish.
Praxa takes one real person's last 90 days of work and builds an AI employee for that job. Here's one example, a code reviewer, step by step — the real result of each step, nothing made up for the demo.
No signup, nothing to set up. You land in a look-only workspace with four AI employees and the real record of their work — click around all you like; nothing you do changes a thing.
60-second overview · sound on for the full effect
01 · Pick a person
A senior backend engineer on a payments team
Praxa looks at the last 90 days of their work.
github·eng@acme— Senior reviewer
02 · Watch their work
247 things it looked at.
Praxa goes through everything this person did over those 90 days. Here's what it found, grouped by type:
Code reviews
92
Changes written
31
Comments left
88
Saves to the code
36
Patterns it picked up
- On any change to the money records, asks "will this slow things down for live users?"
- Pushes back when a payment feature talks to an outside service with no safety net if it fails
- When a change can save money, asks how it avoids charging someone twice
03 · Learn the job
What does this person do?
Reviews changes to the payments code, with a sharp eye for getting the money right, not slowing down live users, and never charging someone twice. Style is short and asks questions first. Will hold up a change that's missing tests — but is fine when there's already a test that covers the same ground.
What they spend time on
- Review changes to the payments codeoften
- Sort through new bug reports about the money recordssometimes
- Write up what went wrong after a money bugrarely
The rules it learned
- A change that would slow things down for live users: hold it, and suggest a safer way to do it.
- A new call to an outside service with no backup plan if it fails: hold it.
- A change that touches money but could charge someone twice: hold it.
- Missing tests: only a small concern if another test already covers the same path.
How they write
Plain and to the point. One clear question per concern. Short bullets, never long paragraphs.
04 · Pick the role
Best fit: Code reviewer91% match
Most of this person's work is reviewing code changes, and the rules they follow line up cleanly with a code-reviewer role. Two other roles were considered and ruled out: a bug sorter (only a small slice of the work) and an error investigator (no sign of that work at all).
05 · Build the employee
Here's its setup
Praxa turns everything it learned into a working employee: a name, when it kicks in, exactly what it's allowed to do, and how well it has to score before it's allowed to start.
Name: Code Reviewer · Payments
Kicks in: When someone opens a new code change
Allowed to:
- · Read the code change
- · Read what exactly changed
- · Read the history behind it
- · Leave a comment on the change
- · Ask for changes before it goes in
Tests it must pass: 38
Score it has to hit: 90%
06 · Test it
Tests it has to pass (5 of 38 shown)
Each test comes from one of the rules it learned by watching the real person. It has to pass enough of them before it's allowed to start any real work.
- A change that slows things down for live userspassed
Checks that it catches the slowdown and suggests a safer way to make the change.
- A new outside call with no backup planpassed
Checks that it asks for changes when a new call to an outside service has no safety net.
- A money change that could double-chargepassed
Checks that it flags a change that touches money but could charge someone twice.
- Missing test, but already coveredpassed
Checks that it does NOT hold up a change for a missing test when another test already covers the same thing.
- A docs-only changepassed
Checks that it is confident enough to approve a docs-only change on its own.
What you just saw
Six steps, and you never wrote a single instruction. The same steps run on your team's own work when you sign up — and the employee that comes out is locked to one job, shows you the tests it passed, and keeps a record you can always check.