Amplify Best Practices: Use a Real Repo For Your First Test

Why Your First Run Matters

Amplify’s on-ramp is simple: you authorize the app via GitHub or GitLab, pick your repositories, and it starts scanning and fixing in minutes—no extra credentials or hand-holding required.

But how do you make sure you’re maximizing the value of your first look at the tool? Early impressions carry weight, especially with tools that promise to streamline or automate security work. Whether a platform feels credible often comes down to what happens in the first hour of use.

With Amplify, that first experience should center on how the system responds to real code: active pull requests, recent changes, and actual developer behavior. The product is built to catch in-flight issues, generate fixes, and surface patterns that reflect real-world usage. None of that comes through in a test repo.

If you're evaluating Amplify, the fastest way to understand what it does (and whether it fits your environment and use case) is to connect it to a repository your team actually uses. Here’s what that unlocks.

Why Real Repos?

Amplify’s functionality depends on the context generated by real developer activity. When connected to an active repository, Amplify starts scanning pull requests as they’re opened and flags vulnerabilities as they enter your codebase, then proposes fixes directly in the development workflow. That process can’t happen meaningfully in a static or abandoned repo.

You also get telemetry that only makes sense in motion. Amplify tracks which repos are producing new issues, which contributors are pushing vulnerable code, and which fixes are being applied. That data gives engineering leads a snapshot of how security debt is being introduced (and resolved) in real time.

Test repos obscure this picture. They’re often empty, inactive, or deliberately staged with unrealistic patterns. Amplify won’t break if you use one…but it won’t show you much either. A real repo is the shortest path to seeing what the platform actually does.

With each new pull request, Amplify regenerates remediations—and gets better at fixes over time. Test repos won’t be updated like a real repo, and that means remediations will remain static. Since Amplify is improving its AI agents all the time in response to real activity by real users, if you just see a static remediation, you’re missing out on a huge part of what makes Amplify special.

What You’ll See When You Connect a Real Repo

Once Amplify is live on a real repo, it starts tracking code changes automatically. Every new pull request is scanned for vulnerabilities, and if an issue is found, Amplify proposes a fix inline. In many cases, you’ll see auto-generated remediations show up as suggested commits or PR comments, depending on your setup.

You also gain visibility into patterns that are otherwise easy to miss:

• Which repos are introducing the most risk
• Which developers are opening PRs with recurring issues
• How many vulnerabilities are getting merged without review
• What’s old vs. what’s new: your ratio of security debt to newly introduced vulns
• How quickly remediations are applied, and whether they're accepted as-is or modified

This data is updated continuously. If your team is pushing code regularly, you’ll see Amplify in motion within minutes: flagging, fixing, and feeding back signal that you can actually act on.

Pro Tips for a Great First Run

Not every repository is a good candidate for a first impression. If you want Amplify to show meaningful results quickly, choose a repo that meets a few simple criteria:

• Active development: There should be open or recently merged pull requests. Amplify can’t fix what doesn’t change.
• Representative stack: Pick something written in the frameworks or languages your team actually uses. That’s where remediation will be most accurate.
  Medium complexity: A giant monolith may be noisy; a tiny utility repo may be silent. Something in the middle works best.

If you want to minimize disruption, you can onboard in silent mode, where Amplify will scan and suggest without commenting on the PR. That lets you observe behavior without involving your team too early.

Once you’ve seen Amplify handle real vulnerabilities in a live workflow, the value becomes much easier to judge. That’s the point of trying it out (and the reason we recommend skipping the test repo entirely).

TL;DR — Let the Product Prove Itself

Amplify isn’t a theoretical solution. You can connect it to a real repo in under five minutes and watch it scan live pull requests, generate fixes, and surface patterns based on actual developer behavior. Other tools offer canned demos, but Amplify gives you the chance to directly evaluate how the platform fits into your workflow.

The trial is free, doesn’t require a credit card, and supports silent mode if you want to observe before involving your team.

If you're going to test Amplify, do it in the environment where you actually ship code. That's where it shows up best.

Ready to see it work? Start your trial with a live repo and give it 30 minutes. You’ll know if Amplify fits—without the credit card, or high-pressure pitch from a sales team. Use real code, get real results. It’s just that simple.