Show it three pull requests.
Get a playbook for four hundred repos.
Kaydence mines the pattern from real, merged pull requests, verifies it on sample repos, then runs the change across your entire GitHub estate. Every change arrives as a pull request, validated against your own CI, reviewed by a human before it merges.
No card required · GitHub-only for now · No auto-merge, ever
Connect. Mine. Scan. Review.
Four screens between authenticating GitHub and a reviewable pull request in every repo that needed the change.
Connect, at the scope you choose
Sign in with GitHub. Connecting an organisation is a separate, explicit step. Signing in does not hand over your estate.
- Repo-level or org-level access, your call
- Personal workspace for trying it on side projects
- Point custom playbooks at a repo you control
Describe the change, and it mines the rules
Point at pull requests where you already made the change by hand, or just describe it in plain English. Kaydence does the rest.
- Searches GitHub for real merged PRs performing the same migration
- Parses every diff in parallel to extract candidate rules
- Drops anything that does not recur across repositories
- Decides which rules are safely programmatic and which need judgement
Scan the estate, priced in hours
Point the playbook at your repos. Kaydence parses build files, dependencies and test imports to work out exactly which repositories are eligible.
- Typically under five minutes for fifty repositories
- Files and lines affected, per repo
- Estimated engineering hours saved, per match
- Deselect anything you would rather leave alone
Run a campaign, review every PR
Roll a playbook out across many repositories under one named effort. Dry-run first, then execute. One pull request per repo, each carrying its rationale and risk level.
- Validated against your own CI before it is marked ready for review
- Human review on every change. No auto-merge, ever
- Closed PRs feed back in to make future runs smarter
Playbooks aren't written. They're mined.
Every other tool ships a fixed menu. Dependabot bumps dependencies. OpenRewrite recipes are hand-authored by people who have never seen your codebase. But most of your debt isn't a generic migration. It's your naming convention, your logging pattern, your way of handling errors, repeated across four hundred repositories.
So Kaydence goes and reads how the world already solved it. Below is a real build: forty-three merged pull requests found, every diff parsed, rules deduplicated and classified. One hour and twenty-eight minutes of compute. Open any of those PR numbers and check them yourself.
ipython/ipython #15290, scylladb/scylla-cluster-tests #13952, RDFLib/rdflib #2564. Real, merged, human-reviewed pull requests.The work that never wins a sprint planning argument
Mechanical, repetitive, and endlessly deferred, until a CVE lands or an end-of-support date arrives and it becomes everyone's problem at once.
Close the window before the auditor does
Vulnerability scanning across npm, pip, Maven and Gradle, with CVSS thresholds and grouped patching. SOC 2, ISO 27001, HIPAA and GDPR all come with mandated patching windows that don't move. This is how you hit them without stopping feature work.
End-of-support dates, handled in bulk
API removals, type inference changes, namespace migrations, build file updates. The kind of change that's straightforward in one repo and a quarter-long project across four hundred.
Fifty low-risk fixes, everywhere at once
Null checks, unused imports, empty blocks, redundant casts, all sourced from SonarQube and Checkstyle-style scans.
Rewrites that respect behaviour
Assertion, annotation and import updates across test classes. Behaviour-based rewrites for React suites with no React 18 adapter left to lean on.
The debt that's only yours
Your logging pattern. Your error handling. Your manifest format. No vendor ships a recipe for that, so mine one from your own pull requests.
One engineer automates a chore. The whole company inherits it.
This is the part that compounds. Somebody writes a playbook for a thing only your company does: generating service manifests, wiring a new telemetry standard, enforcing a review convention. It lands in a shared catalogue. Next sprint, four other teams run it instead of rediscovering it. Playbooks live in a repo you control, versioned like any other code.
Twelve system playbooks. Plus whatever you build.
Every one of them built the same way: mined from real merged pull requests, verified on sample repos, shipped as a reviewable change.
Also proven and available on request. If the change you need isn't here, that's the point. Build it.
Built for engineering leads, not just engineers
Existing tools handle slices of the problem. None of them let you point at three pull requests and get a playbook, and none give you a campaign layer, a debt dashboard, or a self-serve way in.
| Dependabot | Moderne / OpenRewrite | Kaydence | |
|---|---|---|---|
| Build your own playbook from example PRs | No | hand-authored recipes | Yes |
| Language migrations | No | Java-first | Java, JS/TS, Python |
| Security patching | deps only | partial | With campaign management |
| Code standardization | No | Yes | Static analysis + custom rules |
| Scan + opportunity dashboard | No | No | Yes |
| Engineering lead dashboard | No | No | Yes |
| Campaign management | No | No | Yes |
| Transformation engine | N/A | AST | Hybrid: AST + LLM |
You're about to give a tool access to your source code
We know exactly how that sounds. So the product is built to earn it in stages, and to never take a step you didn't watch.
No auto-merge. Ever.
Every change is a pull request that a person reads and merges. There is no setting that turns this off, because there shouldn't be.
Validated against your CI
Transforms run through your own pipelines before a PR is marked ready for review. Your tests are the gate, not our confidence.
Dry-run before anything moves
See the generated diff on sample repos first. The playbook itself arrives as a pull request. It only joins your catalogue once you merge it.
Scoped, explicit access
Signing in requests only what's needed to sign in. Connecting an organisation is a separate, deliberate step, at repo or org level.
SOC 2 In progress
Certification is underway and we'll say so plainly until it lands. If procurement needs the current state of play, ask and we'll send it.
Playbooks you can read
Rules are inspectable, versioned, and stored in a repo you own. Nothing about the transformation is a black box you have to take on faith.
Tech debt is not a "later" problem
Engineers spend between 25% and 42% of their time on rework, workarounds, slow builds and fragile dependencies. Security debt compounds it, and compliance deadlines don't move. The remediation work itself is manual, repetitive, and routinely deferred in favour of feature work.
Start with one playbook
Three playbook builds and five pull requests. Enough to take one real, annoying, repetitive change your team keeps deferring, and watch it run.
No card required. Try it on a personal repo first. That's what the personal workspace is for.