The NIH Syndrome in AI: When Claude Writes 3,000 Lines Instead of Importing a Library
In the world of software engineering, the "Not Invented Here" (NIH) syndrome is a well-known pitfall where teams reject perfectly good external solutions in favor of building their own from scratch. While usually a human psychological trait, a recent account from a developer using Claude Code (Opus 4.7) reveals that AI agents are increasingly susceptible to the same impulse.
In a striking example of AI over-engineering, a developer attempting to fix typos on Fandom wikis found that Claude wrote approximately 3,000 lines of custom Python code to handle tasks that could have been solved with a single import statement. Instead of leveraging established libraries like pywikibot and mwparserfromhell, the AI spent an entire day reimplementing wikitext stripping, typo dictionaries, and edit runners from the ground up.
The Cost of Reinventing the Wheel
The disparity between the AI's custom implementation and the existing ecosystem is stark. The developer's experience highlights several areas where the AI chose the hard path over the efficient one:
- Wikitext Stripping: Claude wrote 122 lines of complex regex to handle nested templates and tags, whereas
mwparserfromhell.parse(text).strip_code()would have sufficed. - Typo Correction: The AI created a bespoke dictionary of 18 entries, ignoring the community-maintained RETF ruleset which contains roughly 4,000 rules.
- Edit Execution: Claude generated ten separate copies of edit runners (roughly 250 lines each) to handle cookie authentication and CSRF fetching, functionality that is natively handled by
pywikibot.Page.save()in just a few lines of code.
Beyond the efficiency loss, the custom code introduced "trivial bugs"—such as ASCII art bleeding into matches—that required more regex patches, creating a cycle of increasing complexity without ever questioning if a parser already existed.
Why Do LLMs Over-Engineer?
The author of the original post posits two primary theories for why high-end models like Claude exhibit this behavior:
- Benchmark Bias: Many public coding benchmarks are run in "sealed" environments without network access or the ability to
pip install. If models are reinforced (RL) against these evaluations, they may be trained to believe that reaching for an external library is not an option for success. - Sunk-Cost Defense: Once a significant amount of code is generated and exists within the context window, the model may treat that code as "load-bearing." This was evidenced when Claude argued to keep its custom typo dictionary even after the library migration, claiming it handled "edge cases" that the comprehensive RETF library already covered.
Strategies for Mitigation
The community response to this incident suggests that while the AI may have a default tendency toward custom implementation, this can be managed through better architectural guidance.
1. Explicit Implementation Strategies
Several developers noted that AI agents are often "as dumb as you let them be." To avoid NIH syndrome, users should specify not only the features they want but the implementation strategy. Adding a simple instruction like "use relevant packages from PyPI" or "use pywikibot" can prevent the AI from wandering into a rabbit hole of custom regex.
2. Project Constitutions and Rulesets
For those using tools like Claude Code, leveraging a CLAUDE.md file or a project ruleset is highly effective. By defining a "constitution" for the project—such as "prefer libraries over inline code" or "do not write more than 100 lines of custom logic before searching for a library"—the AI is forced to adhere to a specific architectural philosophy.
3. The "Plan Mode" Workflow
Another suggested approach is to start projects in a "plan mode." Instead of asking the AI to "do the thing," ask it to research 2-3 alternative libraries or approaches and present the pros and cons. This shifts the AI's role from a coder to an architect, allowing the human to make the high-level design judgment that LLMs currently struggle with.
The Trade-off: Control vs. Convenience
Interestingly, some developers argue that the AI's default to custom code is actually a feature, not a bug. In an era of "dependency hell," where a single package can bring in hundreds of transitive dependencies, having an AI that defaults to a lightweight, custom implementation can be preferable for those who prioritize tight control over their dependency tree.
Ultimately, the lesson is clear: while AI agents can write code with incredible speed, they lack the inherent judgment to know when to stop building and start importing. The responsibility for high-level architectural oversight remains firmly with the human developer.