For Product Hunt and Hacker News. Tyler drives a real repo on screen. No marketing language, no voice-over selling. The product does the work, and the talk track just describes what is happening.
Hyrax connects to your GitHub, finds real problems across the whole codebase, and fixes them as pull requests you approve. Every fix is verified against your own tests before you see it. It handles more than bugs, and nothing ships without you.
By the end, the viewer understands the loop and trusts it. It proves a problem is real before fixing, verifies the fix against their own suite, and the human still merges. This is not a coding agent you babysit, and not a scanner that hands you a backlog.
The talk track under each frame is direction, not a script. It tells you what that moment needs to land, in the voice you would use explaining this to another engineer. Keep the lines short and plain, describe what is on screen as you do it, and say one idea per frame. Never tell the viewer it is good, show it and let them decide.
Before any product appears: the problem the viewer lives with, what Hyrax is in one line, and how you actually use it.
A real repo: a growing issue backlog, and the review-load numbers climbing. Optionally a large AI-generated PR scrolling by.
Set the situation before the product appears. AI made writing code fast and left review untouched, so problems pile up faster than anyone clears them.
Say it the way you would to another engineer at your desk. AI made writing code fast and cheap, and the slow part now is reviewing and fixing all of it. Point at the backlog and the review numbers climbing. You are just naming the thing everyone watching already feels, so don't bring up Hyrax yet.
A clean statement card with the one-line definition and the loop laid out as chips.
The first time the product is named. Give the viewer the whole shape in one breath so every later frame has a place to sit.
Now say what it is, plainly. It connects to your GitHub, finds the real problems in your code, fixes them, and opens a pull request you review and merge. Make the point that it is more than bugs, it handles security, performance, reliability, and cleanup too. Then read the loop once so they know the shape of what is coming.
The three steps from the user's side, plain.
Answer the very first question a viewer has: what do I actually do. Set expectations before the walkthrough.
Answer the first thing anyone wonders, which is what do I actually do. You sign up and connect GitHub, you pick your repos, and from there you review the pull requests it sends you. Nothing to install, and nothing about how you work changes.
The product, step by step on one repo. This is the spine of the demo and where most of the time goes.
Install the GitHub App, the repo picker, select the repos to cover.
The whole setup, live. You choose exactly which repos it can touch.
Walk through installing the GitHub app and choosing the repos. The point to make is that you pick exactly what it can see, and every run is isolated, its own scoped keys for that repo and that run. Anything it changes comes back as a pull request, it never pushes to main.
Discovery running, then the generated .hyrax context and the pointer added to CLAUDE.md.
Before it fixes anything, it maps the architecture and conventions.
Explain what happens the first time you add a repo. It reads the whole thing and maps it, your architecture and your conventions, and writes that down. Say why that matters: the fixes match how you already write code instead of the model inventing its own style, and that is what keeps it from fighting your codebase.
Findings ranked by severity. Click into one real finding, the hardcoded secret, showing file, line, category, severity.
The audit read the whole codebase and produced concrete problems, each tied to a location.
Show the audit. It scanned the whole codebase, and these are the findings, ranked by severity, with how risky and how much work each fix is. Click into a real one, the hardcoded secret in the env loader, and describe it in plain terms.
The test Hyrax wrote for that finding, failing on the current code.
For a finding, it writes a test that fails on the bug before offering a fix.
This is where you answer the doubt everyone is having, that it is just AI guessing. Before it even shows you a finding, it writes a test that fails on that bug. So you know it is real, not the model making something up.
Click Fix. The steps run in order: baseline test, apply, run the suite, build, lint, second-agent review. Let it play out, do not cut away.
The one-click fix runs full verification before producing anything. This frame carries the demo.
Slow down here, this is the whole demo. Click Fix and narrate what it does: it writes a baseline test, applies the fix, then runs your actual test suite, build, and lint. A second agent reviews the change. If a check fails, you decide whether it retries or stops. Then land the line that sets it apart, this is the part a plain coding agent skips, it just tells you it is done.
The PR: the diff with the secret moved to an env var, checks all green, the explanation linked back to the finding.
The fix arrives as a normal PR with the diff, passing checks, and the reasoning.
Show the pull request like any other. Here is the diff, the secret is pulled into an env var. Here are the checks, all passing. And it wrote up what the problem was and how it fixed it, linked back to the finding.
Read the diff, then click merge.
The human approves. This is where control lives.
Keep it simple and human. You read it, and you merge. Nothing ships unless you approve it, and it never touched your main branch to get here.
The Hacker News questions, answered on screen. Why this beats what you already do, what runs under the hood, and how your code stays safe.
A two-column contrast card: a scanner or telling a coding agent yourself, versus Hyrax.
Name the two things this audience already reaches for and show the gap plainly, without knocking them.
This one is for the engineer who has already tried a scanner or just told Claude to fix it. Grant that both get you part of the way. Then draw the line: a scanner flags problems and hands you a list, and a coding agent only fixes what you point it at and can't prove it worked. Hyrax finds it across the whole repo, fixes it, proves the bug and verifies the fix, and does it the same way every run for the whole team, not just whoever is good with AI.
The audit pipeline in three passes, the fix pipeline in one line, and the model note.
Answer the “how many agents, is the model yours” questions directly. Show it is a pipeline, and the model is Claude on AWS.
Answer the how-many-agents and is-the-model-yours questions straight. There is no single agent, it is a pipeline. The audit runs plain scanners first, then a set of tools for security, performance, and the rest, then a broader review on top. A fix plans the change, has other agents check the plan, implements it, then verifies. The models are Claude, Sonnet and Opus, on AWS Bedrock. There is no secret in-house model, the value is the harness around them.
The data-handling facts as chips. Optionally show the security or settings page in-product.
The first Hacker News question is “can you see and store my code.” Answer it before it is asked.
Get ahead of the first question a Hacker News crowd asks, which is can you see and store my code. Say it plainly: each job clones the repo into isolated throwaway compute, analyzes it there, and deletes it when the job ends. It does not keep your source, only the finding metadata. Tokens expire within the hour. It only ever opens pull requests, never pushes to main, and nothing merges without you. Mention SOC 2 Type II is in progress, and that the never-trained-on question comes down to the model provider's terms.
An improvement PR, dead code removed or a function simplified, then the repo score moving up.
Show the scope beyond security and bugs, and that it keeps running as new code lands.
Widen it now, since they believe the core. It is not only bugs and security. It also cleans up the codebase, dead code and over-complicated parts, and it keeps running as new code lands so it stays on top of it. Show the improvement PR and the repo score moving up.
The one thing to do next.
The connect screen and the first free audit.
The close. The one action to take next.
Close on the one thing to do next. Connect GitHub and run your first audit. Findings are free, and you pay only when you want the fixes. Say it like you are telling a friend where to start.