Large codebases rot quietly. Slack thinks automation is the fix.
Every codebase starts clean. When it is small, keeping dependencies current, cleaning up experimental code, and refactoring internal APIs is straightforward. But as the codebase grows, those same tasks multiply. A framework change that once touched a handful of call sites now requires editing hundreds or thousands of files. The cost of maintenance climbs past the point where it feels worth the effort — so teams skip it.
The consequences compound. Unused experimental code hides bugs. Copied legacy patterns propagate into new work. Outdated libraries introduce security and performance risk. And because this kind of work is slow, repetitive, and rarely visible to stakeholders, few developers are motivated to volunteer for it. Over time, every codebase degrades, and working in it becomes slower and less pleasant.
Slack’s answer is AutoTransform, an open-source framework for automating large-scale codebase modification.
Designing for leverage
Before building anything, Slack defined the problem in terms of cost: the goal is to make large-scale changes cheaper. Three principles guided the design:
- Value developer time. Merely shifting effort from one task to another isn’t enough; solutions requiring heavy boilerplate are out.
- Be language agnostic. Slack works in many languages, so any tooling must serve as many codebases as possible.
- Maximize leverage. Effort spent should produce maximum impact across transformations.
The framework is built around these principles and is designed to get better as more organizations adopt it. Most of the work involved in fixing a codebase with thousands of files applies equally to one with millions. Open-sourcing the tool means the industry can share the burden and the benefit, reducing the cost of maintenance for any single organization.
How AutoTransform works
AutoTransform defines codemods using a schema-based, component-based architecture. It also includes support for automatic scheduling through CI hooks and change management for handling outstanding modifications.
- Schema-based. Each modification is packaged as a schema that defines everything needed to execute it. Schemas can be shared across codebases and organizations, so library authors could publish a schema to upgrade all uses of their previous version to the latest.
- Component-based. A schema is composed of components that handle each step: gathering the items to modify, performing the modification, and validating results. Each component is treated as a black box, which keeps the framework language-agnostic while allowing organizations to customize it.
- Automatic scheduling. AutoTransform can be connected to a CI system to run transformations on a schedule, keeping a codebase continuously up to date or spreading a large run across many days.
- Change management. Tracking and rebasing large codemod-generated changes is time-consuming. AutoTransform provides functionality to manage outstanding changes.
The schema execution flow looks like this:
AutoTransform is available as a PyPI package (pip install AutoTransform), with documentation at autotransform.readthedocs.io and source code on GitHub.
What’s next
AutoTransform 1.0.0 is already running inside Slack’s codebase, but the project is in its early stages. Over the next six months, the team plans to deploy modifications across several repositories and open-source as many as possible — both the schemas and any new components they require. Some work will be Slack-specific, but anything broadly useful will be released. Initial targets include unused code in Hack, experiment cleanup, and automated lint fixes.
Future framework work includes support for running against human-authored changes as part of a CI system. Feature requests can be filed as issues on the AutoTransform repository. The broader ambition is straightforward: a codebase that maintains itself, so developers can keep their code modern without the usual grind.
