Why is the Lisp curse becoming a problem again in AI coding?

Because AI lowers the cost of code generation, making it easy for individual developers to create dedicated DSLs or mini-frameworks, leading to more custom abstractions that differ from project to project. This results in a lack of common standards, increasing maintenance and collaboration costs.

What should a team do first to prevent fragmentation in vibe coding?

First, establish standards and reuse policies for generated code, and apply a shared-library-first principle. Allowing only internally verified common components and DSLs, and specifying them in AI prompts, can reduce fragmentation.

How is fragmentation of AI-generated code measured?

Track the number of newly defined abstractions within a project, the number of duplicate similar DSLs and mini-frameworks, and the reuse rate of shared libraries. Monitoring the growth rate of abstractions over time along with code review turnaround time can help detect fragmentation signs early.

Why do onboarding and code review burdens increase?

When each project has different custom abstractions generated by AI, it is difficult for new team members to understand the intent of existing code, and reviewers must review non-generalized patterns one by one. A study from October 2026 also confirmed that increased AI code generation is blocked by human review and does not lead to actual output increases.

AI Code Generation Brings the 'Lisp Curse': The Vibe Coding Ecosystem Is Fragmenting

md-logNovember 6, 20266 min read

AI code generation has driven costs to zero, causing personalized abstractions to proliferate and ecosystems to fragment like the Lisp curse. Standards, reuse policies, and measurement tools are needed.

AI code generation costs are approaching zero, making it easy for individual developers to create dedicated DSLs or mini-frameworks. As a result, the 'Lisp curse,' where different custom abstractions proliferate across projects, is spreading throughout the vibe coding ecosystem. Non-standardized generated code may boost short-term productivity but significantly increases onboarding, code review, and maintenance costs, ultimately eroding team and ecosystem collaboration efficiency. Therefore, it is important to first establish standards and reuse policies for generated code, along with fragmentation measurement tools.

Fragmentation Caused by AI's Zero-Cost Abstractions

The Lisp curse refers to the phenomenon where, when a language is overly flexible and expressive, individual developers create their own macros and DSLs, causing common standards to disappear. This problem, long discussed in the Lisp community, is now being reproduced among a much broader group of developers through AI coding tools. With just a few lines of prompt, AI can generate project-specific query builders, configuration file parsers, state management helpers, and even its own scripting languages. For developers, it is convenient to instantly obtain abstractions that fit their intentions exactly, but even within a team, multiple different mini-frameworks solving the same problem can easily emerge.

For example, if three backend developers on a team each ask AI to "create a helper that simplifies DB queries," three query utilities with different return types and error handling can emerge. Such generated code may appear to work well, but if it is not consolidated into a common library, every variant must be fixed separately when features change or bugs are fixed later. Ultimately, a significant portion of the initial writing cost saved by AI is shifted to maintenance costs.

Worsening Onboarding and Review Bottlenecks in Vibe Coding

Vibe coding is a development approach where intentions are conveyed in natural language and AI generates code. In this environment, onboarding becomes especially difficult because each project has different custom abstractions created by AI. Newly joined developers must infer the meaning of unofficial DSLs and helper functions generated by their predecessors, rather than relying on official documentation or widely known frameworks. Reviewers also must examine dozens of generated code fragments that deviate from standard patterns, which lengthens review time and lowers the actual defect detection rate.

This issue is also confirmed by recent research. According to a study released in October 2026, the increase in code generation by AI coding agents is limited by human review, so it does not lead to an actual increase in software output. Even if AI produces code quickly, the human review and approval stage becomes a bottleneck, and fragmented abstractions further exacerbate this bottleneck. Therefore, organizations should consider filtering AI-generated code to meet internal standards and using internal AI coding environments to prevent unverified personalized abstractions from entering the codebase.

Team Standards and Reuse-First Principles Are the Answer

The first step to prevent fragmentation is to establish team-level standards and reuse policies for generated code. For example, document rules such as "Before creating a new DSL or mini-framework, first search for the same functionality in the company's shared library," and "When requesting code generation from AI, specify existing internal utility packages and coding conventions in the prompt." The second is a shared-library-first principle: create verified common components and encourage AI-generated code to compose these components. By using an internal Private LLM or internal AI assistant, you can automatically recommend organization-approved libraries and patterns.

In practice, it is effective to require AI-generated code to go through the same review process as regular code, and to require that if new abstractions are defined in generated code, the reasons be documented. This reduces unnecessary personalized abstractions, and only when truly necessary can they be incorporated into standards after team discussion. Additionally, templating AI prompts to prioritize existing open-source libraries or proven design patterns can prevent fragmentation to a significant degree.

Tools Are Needed to Measure Fragmentation and Encourage Consolidation

Because policies alone may allow fragmentation to reappear over time, tools are needed to measure the degree of fragmentation in the codebase numerically and monitor trends. For example, regularly track the number of newly defined abstraction classes, functions, and DSLs within a project, the number of duplicate helpers performing the same function, the reuse rate of shared libraries, code review turnaround time, and onboarding duration. If these metrics deteriorate, they can trigger team-level standard realignment or refactoring.

At the ecosystem level, meta-tools are needed to detect fragmentation in AI-generated code and encourage consolidation. For example, tools that automatically cluster similar DSLs generated by AI across multiple projects and suggest opportunities to consolidate them into a common library, or tools that search for duplicate abstractions across the entire internal codebase. These tools reduce the burden of human review while enabling early detection of fragmentation that progresses quietly, like the Lisp curse.

Conclusion: Controlling Fragmentation with Logging and Review Loops

The productivity gains from AI code generation are clear, but behind them lies a structural cost: fragmentation caused by personalized abstractions. Team standards, reuse-first principles, and fragmentation metric monitoring must be applied together to avoid the paradox where AI-generated code makes collaboration more difficult. In particular, by using a human-in-the-loop review and archive layer like md-log, which allows humans to comfortably review AI-generated work logs and analysis results and stores each save as an immutable version to leave a collaboration history, you can record and review the fragmentation process itself and detect deviations from standards early. Ultimately, what matters is not the speed at which AI produces code, but the structure that allows teams and ecosystems to maintain that code together.

References

#AI coding #Lisp curse #vibe coding #code fragmentation #DSL #maintenance

Frequently asked questions

Why is the Lisp curse becoming a problem again in AI coding?: Because AI lowers the cost of code generation, making it easy for individual developers to create dedicated DSLs or mini-frameworks, leading to more custom abstractions that differ from project to project. This results in a lack of common standards, increasing maintenance and collaboration costs.
What should a team do first to prevent fragmentation in vibe coding?: First, establish standards and reuse policies for generated code, and apply a shared-library-first principle. Allowing only internally verified common components and DSLs, and specifying them in AI prompts, can reduce fragmentation.
How is fragmentation of AI-generated code measured?: Track the number of newly defined abstractions within a project, the number of duplicate similar DSLs and mini-frameworks, and the reuse rate of shared libraries. Monitoring the growth rate of abstractions over time along with code review turnaround time can help detect fragmentation signs early.
Why do onboarding and code review burdens increase?: When each project has different custom abstractions generated by AI, it is difficult for new team members to understand the intent of existing code, and reviewers must review non-generalized patterns one by one. A study from October 2026 also confirmed that increased AI code generation is blocked by human review and does not lead to actual output increases.

← All posts