Civic Innovations

How Open Source Projects Need to Adapt to the AI Coding Era

When the sugar first hits your bloodstream everything feels awesome. You’ve got energy, an almost hyperactive level of activity, and even a sense of euphoria. Then, inevitably, the crash.

A new study out of Carnegie Mellon University captures exactly this dynamic playing out in open source software projects that have adopted AI coding tools, specifically Cursor. And it has important implications for how open source communities need to evolve.

The Study: Speed at a Hidden Cost

The paper, Speed at the Cost of Quality by He, Miller, Agarwal, Kästner, and Vasilescu, is the first large-scale causal study of how adopting an LLM agent assistant (specifically Cursor) affects real-world software projects over time. By analyzing about 800 GitHub repositories that adopted Cursor and comparing them against a carefully matched control group, the researchers were able to isolate the effects of AI-assisted coding on both development velocity and code quality.

The velocity findings confirm what many developers have experienced firsthand: the initial boost from using AI tools is real and substantial. The projects the group examined saw lines of code added jump by as much as 281% in their first month of Cursor adoption. Commits surged. Things felt productive. Sugar in the bloodstream, baby.

But the effect was temporary. Within two months, the velocity gains had largely dissipated, and what remained was something more troubling. Static analysis warnings increased by 30%. Code complexity increased by 41%. And importantly, these quality metrics didn’t bounce back. 

The researchers dug deeper into the mechanism using dynamic panel models, and found that the technical debt introduced by AI-assisted development was itself causing future velocity to slow down. A 100% increase in code complexity, they found, leads to roughly a 65% drop in future development velocity. The sugar rush, in other words, doesn’t just wear off – it leaves the codebase harder to work with, which makes future AI-assisted development less productive. The initial burst of speed is borrowed against future output.

When the researchers examined the types of quality issues that were accumulating, the picture was clarifying. The biggest increases were in naming convention violations, code hygiene issues (unused variables, TODO comments, commented-out code), code style problems, and structural complexity. These are the fingerprints of code generated quickly without strong project-specific guidance – code that technically works but doesn’t fit the codebase it lands in.

The Case for Better Instructions

Included in the paper’s practical implications section is a suggestion that points toward a possible solution. The authors note that to overcome technical debt accumulation, AI-adopting teams should consider “prompt engineering (e.g., engineered Cursor rules) to enforce rigid quality standards for LLM agents.”

It’s a brief mention, but it’s an important one. It acknowledges that the quality problem isn’t simply an intrinsic property of AI-generated code:i t’s partly a problem of AI agents operating without adequate project-specific guidance. These agents are generating code into a vacuum, without the institutional knowledge of what good code looks like in this specific project.

So, if the problem is inadequate guidance for AI tools, then better guidance is a meaningful intervention. And if we think about how that guidance should manifest, it turns out open source communities already have a well-developed playbook for exactly this kind of challenge.

A Natural Evolution of CONTRIBUTING.md

Open source projects have always needed to shape the contributions they receive. The challenge of coordinating dozens or hundreds of contributors (each with their own habits, preferences, and interpretations of what “good” looks like) is as old as open source itself. And over time, communities have developed increasingly sophisticated tooling to address it.

The evolution has followed a consistent pattern: push quality standards earlier and earlier in the contribution workflow.

CONTRIBUTING.md, which first evolved in open source communities around the time that GitHub was initially launched, was the first major step. This file is a human-readable document that communicates project norms. How to write a commit message. What branching strategy the project uses. What coding style to follow. It’s an onboarding document for contributors, an example of what “good” looks like for project contributors.

Issue and PR templates went further, shaping not just contributor knowledge but the actual structure of contributions before they’re written. A good PR template doesn’t just ask contributors to describe their changes, it prompts them to confirm test coverage, describe the problem being solved, and call out any potential side effects. It structures the conversation on a contribution before it starts.

Linters, formatters, and CI gates automated enforcement at submission time. Rather than relying on reviewers to catch style violations, these tools catch them automatically, freeing human reviewers to focus on logic, architecture, and correctness.

Each step moved quality standards upstream. Each step reduced the burden on human reviewers while raising the floor on contributions.

Agent instruction files are the next step in this progression.

Tools like Cursor, Claude Code, and others support configuration files (.cursorrules, CLAUDE.md, AGENTS.md, and similar) that encode project-specific instructions for an AI agent. These files can specify naming conventions, architectural patterns, complexity thresholds, required documentation standards, and anything else that defines what good code looks like in a specific project. When a contributor opens their AI coding tool, these instructions can shape the code the agent produces before a single line is committed.

This is the same instinct that produced CONTRIBUTING.md and PR templates, applied to a new layer of the contribution workflow. Instead of shaping how contributors describe their work, it shapes how AI agents assist in producing it.

Instructions for Generation and Review

Here’s where this approach gets more impactful. These instruction files don’t have to serve only contributors; they can serve reviewers too.

The same file that tells a contributor’s AI coding agent “avoid deeply nested functions, follow the project’s naming conventions, ensure all public functions have docstrings” can also power an AI-assisted review step that checks incoming contributions against exactly those standards. The knowledge is encoded once and applied symmetrically at both ends of the contribution pipeline.

This is the same logic behind PR templates. A good template shapes what a contributor writes and structures what a reviewer looks for. Agent instruction files can do the same for the code itself.

Concretely, this might look something like:

• A project-maintained AGENTS.md or .cursorrules file, versioned alongside the codebase, that encodes project-specific quality standards
• A CONTRIBUTING.md file that explicitly ask contributors to configure their AI tools with the project’s instruction or skills files before submitting code
• An AI-assisted pre-review gate in CI that runs incoming contributions against project standards before they reach human reviewers
• Human reviewers who use the same instruction files to support their own review, ensuring consistency

This creates a closed-loop quality system where generation and review are governed by the same standards — which is precisely what’s needed when AI tools are accelerating the volume of incoming contributions faster than human review capacity can scale.

It’s also worth noting that this doesn’t replace the value of traditional automated quality tools. Linters, static analyzers, and security scanners remain essential, and arguably become even more critical in an AI contribution era, since the volume of code arriving for review is higher and AI-generated code may carry systematic patterns of issues. Agent instruction files and automated tooling are complements, not substitutes.

Writing Effective Instruction Files

Proposing that maintainers create and distribute agent instruction files is one thing. Knowing how to make them effective is another. A second study, SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks, provides useful empirical guidance here. 

Across 84 tasks, seven agent-model configurations, and over 7,000 evaluated trajectories, the researchers found that curated, human-authored skills raised agent pass rates by 16.2 percentage points on average. Self-generated skills, where the model was instructed to write its own procedural guidance, provided essentially zero benefit. The value of these files comes from human expertise that models don’t have, which is exactly what project maintainers possess. 

The study also surfaces three design principles directly applicable to open source instruction files:

• Less is more: focused 2-3 module skills outperformed comprehensive documentation, which actually hurt performance by creating cognitive overhead. 
• Procedural beats declarative: concrete how-to guidance and specific examples outperform abstract principles. 
• Project-specific knowledge has the highest value: encode what the model doesn’t already know (your project’s conventions, architectural decisions, and quality standards) rather than generic best practices it can already apply. 

Finally, the study conducted an ecosystem analysis and found a mean skill quality score of just 6.2 out of 12 across publicly available skills, a reminder that having instruction files isn’t enough. They need to be actively maintained or they just become noise.

A New First-Class Artifact for Open Source Projects

We are at an inflection point in how software gets written, and open source communities are feeling it acutely. AI coding tools are accelerating contribution velocity in ways that are genuinely exciting. They are also creating quality challenges that are genuinely concerning. The He et al. study gives us hard evidence of both of these phenomenon.

For many open source project, the path forward isn’t to resist AI-assisted contributions. That ship has probably already sailed, and the productivity gains are real enough that most projects will probably want to capture them. The path forward is to build the quality infrastructure that allows communities to capture those gains without accumulating the technical debt that eventually erases them.

Just as CONTRIBUTING.md was a response to the challenge of coordinating human contributors at scale, project-specific agent instruction files are a response to the challenge of coordinating AI-assisted contributors at scale. They are the natural evolution of the open source contribution stack, versioned alongside the codebase, maintained by project leaders who understand what good looks like in their specific context, and used symmetrically by contributors and reviewers alike.

The open source communities that thrive in the AI era will be the ones that treat these files as seriously as they treat their test suites, their linters, and their CONTRIBUTING guides. Not as a nice-to-have detail, but as a first-class project artifact that encodes what the project stands for, and that ensures every AI agent touching the codebase – whether contributing or reviewing – understands that too.