An open-source lab exploring how we understand repositories, review changes at scale, and use automated tests to build confidence in software evolution.
The work starts with questions we encounter in our own projects: What changed? What depends on it? Which tests exercised it? What remains unknown? How can we coordinate changes across repositories without losing the ability to inspect and work on the code ourselves?
- Repository understanding: code structure, dependencies, architecture and their evolution across projects and languages.
- Code review at scale: connecting changes with their direct and indirect impact, relevant tests and supporting evidence.
- Automated testing: making test execution, coverage and verification results useful in everyday development and refactoring.
- Engineering workflows: combining human decisions, command-line tools and automation into repeatable, inspectable work.
Our guiding idea is to give non-deterministic work—including AI-assisted changes—explicit inputs, observable outputs and deterministic checks. Facts and verification help us make decisions; uncertainty and missing evidence should stay visible.
The lab's currently open-source project. Scryer collects repository facts and compares code changes with available test execution evidence, with machine-readable data and reports for people, tools and AI consumers. Java analysis is the current starting point; support for more languages and architectural relationships is a longer-term direction.
A workspace-centered engineering workbench for organizing projects, composing plans, running manual and automated steps, and retaining execution history and outputs. It is currently closed source, with a future open-source release planned.
Its longer-term direction is an interactive view of software architecture: moving from a workspace to repositories, components and source code, exploring change impact, and checking architectural expectations against implementation evidence. These are ongoing experiments, not a claim that the complete vision exists today.
We develop these tools by using them on our own repositories. Interfaces and ideas will evolve as we learn. Questions, bug reports and concrete examples of difficult review or testing workflows are welcome in the public project repositories.