Teams report wildly different results from the same coding agents. Some describe a step change; others describe a flood of code nobody wants to review. A new study from Stanford and Carnegie Mellon asks whether part of that difference is written down in the repository itself.
The researchers built a scanner that looks for the files teams commit to configure their AI tools, such as rules files, coding standards, named agent definitions and workflow definitions. Run across hundreds of corporate repositories, it found that two thirds had committed nothing at all, with no shared instructions, no house conventions, nothing an agent could read on arrival. They then took an existing dataset of open-source projects that had adopted coding agents and split it by the same measure.
The split is sharp on quality and absent on speed. Among projects where an agent was the first AI tool in the codebase, those with no committed configuration saw code tangle up about twice as fast after adoption, a 53% rise in a standard measure of how hard code is to follow, against 27% where configuration existed, with a similar gap in how much an automated code checker flagged. Commit volume rose in both groups by a comparable amount. Nobody traded speed for quality here. One group simply paid more for the same acceleration.
"Across all checks the asymmetry holds: agents accelerate both strata, but the steepest quality costs concentrate in repositories without structured practices."
The obvious reading is that a team should write the rules first and then turn the agent loose. That isn't what the study tested. Buried in its validity section is the detail that in the comparison carrying the headline result, only about 4% of the well-configured projects had committed their first configuration file before the agent showed up. Almost all of it arrived alongside the agent or after it. Which suggests the finding is less "preparation pays" than "somebody eventually bothered, and that correlated with a healthier codebase."
The authors are careful about why. They offer three possibilities. The files act as guardrails on what the agent writes. Or the files merely mark teams that were already disciplined. Or a shared written reference speeds up how quickly a team learns to handle agent output. They say plainly that they can't tell these apart.
"Our design cannot distinguish among them."
A second gap they name should govern how this gets used. The scan detects whether a configuration file exists, not whether it says anything useful. A placeholder scores identically to a document a team actually maintains.
That matters for the version of this result destined for a vendor deck. If tooling ships a starter rules file by default, every repository clears the bar and the signal disappears along with the choice it was tracking. Treat any claim that a template alone moves the number as unproven.
Two things follow anyway. Put the configuration files in the review rotation. Roughly three quarters of them were committed once and never touched again, which means whatever got written in the first month is still steering the agent years later. And keep expectations modest, because even the best-configured group watched complexity climb by about a quarter anyway. On this evidence, a few pages of markdown reduce the bill rather than remove it.
Sources
- Denisov-Blanch, Y., Agarwal, S., Azaletskiy, P. et al., "A Few Pages of Markdown: Committed AI Configuration and Lower Quality Cost after Coding-Agent Adoption" — https://arxiv.org/abs/2608.25241