AI Made Us Faster. Then It Made Us Slower.

For the past year, we’ve been hearing the same story from customers, from our own teams, and across the industry. Engineers adopt an AI coding tool and feel like superhuman coders. They ship features at record speed, pull requests skyrocket, and then, mysteriously, a few months later the work slows to a pace below where it was before the tool arrived. The codebase has grown harder to manage and change because nobody remembers exactly what changed during that superhuman burst. The industry now has a name for that gap: cognitive debt, which is the growing distance between how much code a system contains and how much of it the team still understands. Nobody had the data to show it. Now we do.

A Carnegie Mellon University (CMU) study of 807 open source repositories quantifies what we’ve been hearing. Adopting an AI coding assistant produced a large but temporary speed gain: lines added increased by 281% in the first month but then became statistically indistinguishable from control projects by month three. Not just a loss in speed, but a persistent quality decline. Automated code checks flagged 29.7% more issues, and the code scored 40.7% higher on a standard measure of how hard it is to read. The paper’s models show that accumulated complexity suppresses future velocity. And, a finding we think deserves highlighting, AI-generated code turns out to be inherently more complex than human-written code, even after controlling for how fast a project is growing. We think the root cause is a training problem. Models are optimized for what’s cheap to verify (does the code run?) rather than for what makes codebases resilient (architecture, readability, consistency). The way to fix the downstream effects is two-fold. The tooling fix is to give the AI context, memory, and guardrails. The practice fix is to have your engineers, not the AI, write the spec and design doc before the first line of code.

Researchers measured code changes, not self-reported productivity

The study is “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” by He, Miller, Agarwal, Kästner, and Vasilescu. Self-reported productivity is an unreliable instrument, though. A separate 2025 controlled study found that experienced open source developers using AI tools were not measurably faster on real tasks, despite believing they were. So the CMU team measured repositories instead of surveying developers. They found 807 GitHub projects that adopted Cursor between January 2024 and March 2025 (adoption is visible in git history once a team commits Cursor’s configuration files) and matched them against 1,380 similar projects, with the same coding language and comparable activity trajectories, that never adopted it during the study.

The experimental design means the question is not “did AI-assisted projects go fast” but “did they go faster than they otherwise would have, relative to their non-adopting twins.” Framing it this way washes out anything that affected the whole industry at once (for example, better base models or a slow holiday quarter) because those affect both groups equally.

Adoption in this study was detected, not enforced. Committing a Cursor configuration file proves a team started using the tool, not that every developer used it every day. Here’s an analogy that we’ll carry through the rest of this post. Imagine studying whether coffee makes people more productive by tracking everyone who bought a home coffee machine. Some of those buyers brew a pot every morning and some let the machine gather dust, but the study counts every owner the same (researchers call this an intent-to-treat design, and it tends to water down the measured effect). What strengthens the study is a pattern called dose-response. The idea is simple. If coffee is really what’s driving the effect, the heaviest drinkers should show the biggest effect. The CMU team checked for the same pattern in the repositories and found it. When they narrowed to the daily brewers (i.e., projects with evidence of heavy, sustained Cursor tool use), every effect got stronger, not weaker, which is exactly the signal you’d expect if the tool itself is causing the changes.

The control group wasn’t necessarily coffee-free. Adopting Cursor leaves a trace in the repository, but using Copilot or ChatGPT leaves none, so there’s no way to know which control projects were using those other tools. In the analogy, the control group is everyone without a machine at home, and people without a machine are hard to track. Some walk to a café every morning, some never drink coffee at all, and from the outside, they look identical. Not everyone in the study drinks coffee, but what separates the groups is the friction. The study therefore measures owning the machine against that unknown mix. It’s still a meaningful comparison, because a machine in your kitchen turns coffee into an all-day habit in a way an occasional coffee run never will. Similarly, an agent living inside the editor produces far more code than a chat window you have to manually type into. But it does mean the baseline isn’t caffeine-free, so to whatever extent the control projects were already using AI, the reported effects underestimate the real ones.

Therefore, the authors found that adopting Cursor does make projects faster… just not for very long.

In the first month after adoption, lines added jumped 281% and commits rose 55% relative to the matched controls. Month two dropped to +48% lines and +14% commits, and by month three, the adopters were statistically indistinguishable from the control group. Averaged over the entire post-adoption window, lines added were up 28.6% and the average effect on commit counts was not significant at all. The entire velocity benefit of adopting the tool is concentrated in the first eight weeks.

Figure 1: AI coding with Cursor speeds delivery at first, but slows teams two months later while increasing code complexity. Source. 

Where the speed goes

To understand why the productivity boost fades, we need to go back to the coffee analogy. The first cup you ever drank hit immediately. You had a buzz going; you felt energized and ready to take on the day. A few months of daily cups later, that same cup of coffee barely registers. It no longer lifts you above normal; it just gets you to normal. What matters for our story is that the coffee never changed. Your body did, adapting in the background, building up the resistance that reduced the caffeine buzz.

Software projects adopting AI coding tools follow a similar transformation. The study shows that code complexity is what plays the role of the body’s resistance. The tool keeps generating code at the same pace it always did, but each month of AI-assisted output leaves the codebase a little harder for humans to read and follow, and hard-to-read code slows down everyone who touches it afterward. The authors were able to quantify this effect by concluding that doubling a codebase’s complexity cuts future development speed by roughly two-thirds. In other words, the tool that speeds up progress in the first month is also building up the complexity that makes it harder to manage six months later.

The natural follow-up question is whether the AI wrote worse code. There are two dimensions to the quality of code: whether it’s written in a style less likely to result in errors, and whether it does the job in a simple or a complex way. A common measure of the former is with static analysis warnings (raised by tools that scan a codebase and point out likely bugs, security gaps, and hard-to-maintain patterns), and the latter with code complexity measures (also tool-generated). The paper examines each separately.

The AI did not write stylistically worse code (as measured by static analysis warnings). Line for line, AI-assisted code collected about the same number of flags as human-written code. What changed is the amount of code. The projects grew much faster, and a codebase with twice as many lines carries roughly twice as many flags, no matter who wrote them. The problem count went up because the code count went up, not because the code got worse.

The AI, however, did write more complex code. Take two projects growing at the same pace, one using the AI tool and one not. The authors tracked all 2,187 projects month by month, scored their code with the same automated tool throughout, and adjusted for each project’s size and rate of growth. Even then, the AI-assisted projects ended up with code roughly 9% harder to read. Same amount of code, just harder-to-read code. And harder-to-read code is harder to review, harder to debug, and harder to change, which is exactly the kind of resistance that wipes out the velocity gains we mentioned earlier.

What enterprises can do to avoid the slowdown

The paper’s recommendation is simple. If the AI is writing twice as much code, you need twice as much checking. We’ve noticed two ways to keep up, one in tooling and one in practice.

Fix #1: Give the AI context, memory, and guardrails

All three of these tooling fixes amount to showing the AI things it cannot figure out on its own. Context tooling builds a searchable index of your repository, so instead of reinventing work your team already finished, the model finds it and builds on it. Memory files (.cursorrules, CLAUDE.md, AGENTS.md) are standing instructions the AI reads at the start of every session, where you tell it how your team works, for example, that all database access goes through one layer. There’s an important detail in the study’s method, since the CMU researchers identified adopters by scanning for exactly these files. The teams that adopted the earliest were already following software engineering best practices, and they brought those habits into the AI coding world.

Some rules are too important to leave in a memory file, though, because a memory file is only an instruction, and instructions can be missed or ignored. Rules like that belong in the pipeline itself, as part of your automated testing. Think of the difference between a speed limit sign and a speed bump. The sign asks you to comply, but the speed bump enforces it. A guardrail wired into automated testing is a speed bump. The AI cannot break it no matter how confused it gets, and neither can human contributors.

None of this tooling stops at the codebase because an agent doesn’t just write code; it reads and produces enterprise data just as fast. And data problems have an equivalent code twin. 

Start with the context index. A repository index stops an agent from reinventing code your team already wrote. A data catalog stops it from reinventing or misreading data your business already owns. That’s what Everpure Data Intelligence does. It discovers data continuously across the whole estate. Point a capable model at data that’s scattered, unclassified, and stripped of context and you get back confident, well-worded nonsense. It’s the data equivalent of code that runs and nobody can maintain. 

Memory files have a data twin too. CLAUDE.md tells an agent how to work with a codebase. An enterprise ontology tells it what your business means by “customer,” “active user,” or “revenue.” 

So do the guardrails, and, honestly, this is the one most enterprises fail to implement. An evaluation framework is a speed bump in our earlier analogy. On the data side, that means classification and policy that travel with the data itself, so an agent can’t reach regulated or unsuitable data no matter how the prompt is phrased. AI output needs auditing the same way AI code needs testing. 

Understanding your data is only half of the solution. Everpure Data Stream takes what you now understand and turns it into something an agent can use, automating the path from raw enterprise data to vectorized, governed, AI-ready context. Data Intelligence gives you the context AI can trust. Data Stream gives it the form AI can use. 

The stakes on the data side are also higher. A codebase carrying cognitive debt slows your team down, and everyone sees it in the sprint numbers. A data estate carrying cognitive debt doesn’t slow anything down. The agent keeps answering at full speed, and the answers come back wrong, in that same confident, well-worded voice that nobody double-checks.

Fix #2: Write the spec first

The second fix borrows an idea from curriculum design called backward design. A good teacher writes the final exam first, then builds the syllabus and curriculum that prepares the students, because the exam is where you decide what actually matters. A spec or design doc plays the same role in an AI-assisted project. It’s where the engineers decide what matters before the first line of code gets written: which features to build, which failure modes to anticipate, which tradeoffs to accept—the forethought that separates a production codebase from a vibe-coded prototype. Write the exam at the end instead and you’ll be testing students on material the curriculum never covered. Review the code at the end and you hit the same problem. 

There’s one more reason the doc matters more now than it used to. On a human team, a design doc might get read a dozen times over the life of a project, whenever someone checks that the work still matches the plan. An AI agent reads it every time it touches the codebase, hundreds of times in a single sprint. A document that used to be an occasional reference now guides nearly every line of code written. This also means that the level of care that goes into writing it has to increase as well.

Keep the coffee machine

The CMU study confirms the story customers keep telling us. An AI coding tool delivers a real burst of speed, roughly two months of it, while building up the cognitive debt that eventually reduces the gain, similar to how a daily cup of coffee builds the tolerance that reduces the buzz. The code isn’t buggier than what humans write; there’s simply much more of it, and line for line, it’s harder for people to read. One caution on scope is that the data comes from open source projects, where code review is famously inconsistent. An enterprise with mandatory review and testing may weaken the effect, but nobody should assume they’re immune.

None of this is a reason to return the AI coffee machine. It’s a reason to move human judgment upstream, into specs the AI consumes, memory files it reads, and automated testing rules it cannot break, instead of spending that judgment downstream reviewing thousands of generated lines. The first month boost tells you the capability is real. Whether you still have that boost six months later depends on the engineering you put around the tool. Put those practices in place when you adopt it—not when things start to slow down.