Connect your repositories. Set the date when AI tools entered your team's workflow. Scryable builds the before-and-after view automatically, from the commit history you already have.
No CLI. No webhooks. No agents running in your codebase. Everything Scryable surfaces comes from what your team is already creating.
Sign in with GitHub. Select the repositories you want to analyse — one team's work, a full organisation, or a single project to start. Scryable ingests your commit and pull request history. The first sync takes a few minutes. After that, refreshing is on-demand: you pull current data when you want it.
Add repos later, remove ones that are no longer relevant, or scope your view to a subset at any time. The dashboard always reflects exactly what you've selected.
Pick the date when AI coding tools entered your team's workflow — the point at which Copilot, Cursor, Claude Code, or any combination of them became part of how code gets written. You can set this globally or per-repository, which matters if different teams adopted at different times.
From that date, every metric in Scryable splits automatically into two windows: before, and after. You're not reading your team's current output in isolation. You're reading it relative to your own history, on the same repositories, with the same contributors.
The dashboard surfaces your team's output across four dimensions, described below. Every figure shows the current-period number and its pre-AI baseline alongside each other. The comparison is always to your own history — not industry benchmarks, not a model of what a healthy team should look like.
Filter by date range, repository, branch, or contributor. Save any view as a named report and share it with a colleague or bring it into a leadership conversation.
Most engineering analytics count commits, or lines added, or pull requests merged. A commit that adds 400 lines and rewrites 380 of them within a week tells a different story than a commit that adds 400 lines that stay. Standard output metrics can't tell those two situations apart.
Churn measures the difference. It's the fraction of newly added lines that are quickly rewritten or removed — and it tends to rise with AI adoption in ways that raw output figures don't show. The pattern GitClear documented across hundreds of repositories in 2025 was more code shipped, but a meaningfully higher proportion corrected shortly after. Scryable surfaces this at the team level, the contributor level, and the individual commit level, so you can see where the pattern appears and where it doesn't.
The data doesn't tell you what to conclude. It gives you what you need to work it out.
Scryable works well for engineering managers who have been running AI tools in their team for a few months and want to understand what actually changed — for internal clarity, for a structured retrospective, or for a conversation with leadership about whether the investment is justified.
It works well for non-technical stakeholders who need a plain-speaking view of what their engineering team is shipping. The dashboard is designed to be readable without a background in software development. Numbers are shown in context, not presented raw.
It works less well if what you want is to rank developers against each other. The data isn't designed to support that, and we haven't built for it.