> We find that the adoption of Cursor leads to a statistically significant, large, but transient increase in project-level development velocity, along with a substantial and persistent increase in static analysis warnings and code complexity. Further panel generalized-method-of-moments estimation reveals that increases in static analysis warnings and code complexity are major factors driving long-term velocity slowdown. Our study identifies quality assurance as a major bottleneck for early Cursor adopters and calls for it to be a first-class citizen in the design of agentic AI coding tools and AI-driven workflows.
So overall seems like the pros and cons of "AI vibe coding" just cancel themselves out.
The part you quoted doesn't support your conclusion. Per your quoted paragraph, the benefit of "AI vibe coding" is a large, but transient (i.e temporary) increase in development velocity; while the drawback is a persistent increase in static analysis warnings and code complexity.
To me, this sounds like after the transient increase of velocity has died down, you're left with the same development velocity as you had when you started, but a significantly worse code base.
The implication seems to be that if quality assurance is prioritized, the negative impact would be eliminated.
This seems to assume the main cause is the accumulation of defects due to lack of static analysis and testing.
I think a more likely cause is, the code begins to rapidly grow beyond the maintainers' comprehension. I don't think there is a technical solution for that.
> This seems to assume the main cause is the accumulation of defects due to lack of static analysis and testing.
Neither (current) static analysis nor testing is sufficient to score the commit on complexity.
As a trivial example (i.e. probably not something the LLM would do), if the code was a series of 25 if-then-else statements when it could have been a lookup table, no tool is going to flag that.
Now imagine what patterns, which non-junior devs would reject without even thinking, that an LLM would inject. No test, nor any static analysis tool, is going to flag that non-essential complexity.
Another thing, tangential to what you talk about: if you have a junior programmer who does write some silly pattern, such as a 25 long if/else chain, you can notice that in code review and have a conversation with the junior programmer. Talk with them the possible alternatives; talk about switch, talk about lookup tables, discuss pros and cons of each solution. In the end, you have a better, slightly less junior programmer who will be more conscious of the choices they're making in the future. Repeat a few dozen times across a few years and you have a senior programmer.
You can't do this with language models. They don't learn. You can write in your CLAUDE.md stuff like "avoid long if/else chains" of course, but 1) cluttering the context with lots and lots of micro-managing instructions has its own downsides, and 2) you don't want a list of rules, you want deliberate weighing of the trade-offs involved in choices made.
So overall seems like the pros and cons of "AI vibe coding" just cancel themselves out.