Why I Asked AI to Build a PEFT Atlas
PEFT already has hundreds of methods. I wanted to ask how they fit together. Which differences matter? Which methods can express the same updates? Why can similar parameterizations train differently?
The aim was an atlas: a common language for asking these questions across methods. AI helped turn that aim into a catalogue, a mathematical framework, a paper, and an interactive website.
Letting the sea rise
The starting point came from Grothendieck's image of a rising sea. A hard problem can be attacked at particular points. Another approach is to develop a theory around it, until the problem becomes part of something we understand more generally.
For PEFT, that meant asking whether methods that look separate could be studied as instances of one construction. The requirement was practical: a new abstraction had to shorten a proof, remove an assumption, or reveal a real connection. An impressive name was not enough.
The framework studies a weight-space method as a map from its trainable parameters to model weights, starting at the pretrained checkpoint:
Its image tells us which weights it can reach. Its fibres tell us which parameter choices represent the same weights; together with the optimizer's metric, they matter for training. Moving the base point gives a way to study initialisation, restarts, and merging.
The point is to connect questions we usually study separately. A common framework is useful only if those connections tell us something about the methods.
What I asked AI to do
This was not just a request to polish a manuscript. As the Making of records, we chose the research question and the main scope. The AI system planned much of the work, proposed frameworks, searched the literature, classified methods, developed mathematical arguments, wrote the paper, and built the site. Separate agent runs challenged the claims and checked sources.
That distinction matters. It would be misleading to describe the system as a copy editor, or to imply that we supplied all the mathematics and it only supplied the sentences.
The process also had a rule for deciding what to keep. Four candidate frameworks were assessed for mathematical rigour, fidelity to PEFT, and clarity. The relative point of view became the backbone. Other constructions were included where they helped explain the methods, and decorative ones were removed.
The corrections belong in the story
The Making of reports 905 catalogue corrections. Its first round of mathematical review led to repairs of 27 results; later rounds narrowed statements and made further fixes. Corrections made while writing the paper were carried back into the website and data.
These details are as important as the size of the output. A polished argument can hide a missing assumption. A claim about an idealized optimizer can be wrong for a default implementation. The useful result is the statement that survives those distinctions.
But separate agents are not independent human reviewers. They used the same underlying model, so they can share errors. Numerical checks on small examples do not establish a theorem. We did not run fine-tuning experiments on real models; the proposed empirical predictions remain untested. The authors remain responsible for the claims.
What remains for me
In my first essay, I asked what AI removes from writing and what it makes possible. This project makes that question harder. AI contributed to the arguments themselves, not just their presentation.
Having a paper is not the same as understanding everything in it. The next work is to learn from the framework, check its claims, and find out which connections are genuinely useful. The question I want to keep asking is whether AI helps me become better at that work, rather than only helping me produce more of it.
The atlas is an invitation to examine the idea. Explore the constructions, read the assumptions, and tell us where the map fails.
Read the paper · Explore the atlas · Making of
The process details above come from the website's Making of and Appendix F of the PDF, pp. 395–402. They are the project's account of its workflow, not a separate audit of the agents' logs or proofs.