--- title: The Lisp curse, now coming to your ecosystem | daily.dev description: The author asks what could happen to mainstream language ecosystems like Java if LLM code generation becomes easier than using libraries. Fewer developers... canonical: https://daily.dev/posts/the-lisp-curse-now-coming-to-your-ecosystem-r8usyljys twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The Lisp curse, now coming to your ecosystem | daily.dev og:description: The author asks what could happen to mainstream language ecosystems like Java if LLM code generation becomes easier than using libraries. Fewer developers... og:url: https://daily.dev/posts/the-lisp-curse-now-coming-to-your-ecosystem-r8usyljys og:image: https://api.daily.dev/og/posts/r8USYLjYs.png og:image:alt: The Lisp curse, now coming to your ecosystem og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The Lisp curse, now coming to your ecosystem **[Hacker News](https://daily.dev/sources/hn)** · 4 min read · 1 upvotes · 1 comments ## Summary The author asks what could happen to mainstream language ecosystems like Java if LLM code generation becomes easier than using libraries. Fewer developers might use open source projects, reducing feedback to maintainers, and the creation of new libraries might stagnate. The two effects might amplify each other over time. The author says they'd rather rely on proven libraries than generate code for local problems, calling 'Not generated here' a different version of 'Not invented here'. They think LLMs in coding are here to stay and that open source collaboration will decline to some degree, and development might become a lonelier task. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the LISP curse and why does it cause a lack of libraries? The LISP curse describes how LISP's power and flexibility lets developers easily build custom solutions, so they work in isolation and reinvent the wheel instead of using shared libraries. The resulting code is often powerful but poorly documented, making it hard for others to reuse, so developers keep writing their own modules and the pattern perpetuates itself. _Developers weighing custom code versus shared libraries follow this kind of ecosystem debate on daily.dev._ ### Could relying on LLMs to generate code instead of using libraries hurt open source projects? Yes, according to one argument: if generating code with an LLM is cheaper than learning a library's API, fewer developers will use existing open source libraries, cutting maintainers off from feedback. New library creation would also stagnate since maintaining open source (versioning, compatibility, hosting) is harder than just generating a one-off module, and these two effects could reinforce each other over time. _Anyone deciding whether to reach for a library or generate code with an LLM can track this discussion on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 111 comments across hackernews (as of 2026-11-05). **TL;DR:** Opinions split on whether LLM-generated code will hollow out open-source ecosystems: many welcome fewer bloated dependencies and more vendored/custom code, while others worry about license violations, duplicated security vulnerabilities, and the erosion of shared, reviewed libraries. **Sentiment:** 30% positive · 45% mixed · 25% skeptical **The case for** - Having an LLM generate or vendor just the needed slice of functionality reduces dependency bloat and attack surface. - Custom-generated code avoids fighting awkward third-party abstractions and framework lock-in. - Fragmented, non-uniform codebases could reduce the blast radius of mass exploits compared to monoculture libraries. **The pushback** - LLM-vendored code can introduce license violations or get exposed to vulnerabilities even when unused. - Rolling your own code instead of relying on vetted libraries risks reintroducing well-known bugs (e.g. crypto, numeric edge cases) that mature libraries already solved. - People now hesitate to upstream agent-written patches since they haven't personally reviewed them, reducing contributions back to projects. - GitHub is increasingly filled with low-effort AI-generated ('slop') repos, making genuine open-source contributions harder to find or trust. **By community** - hackernews (mixed): Discussion is split between people excited about LLMs reducing dependency bloat and those warning about security, licensing, and the long-term health of open-source collaboration, with a long tangent debating whether the 'Lisp curse' itself is even real. **Hottest debate:** Whether it's actually safer/better to have LLMs vendor or reimplement small bits of functionality versus relying on mature, widely-vetted libraries. **Open questions** - Will AI vendors create private, LLM-curated library ecosystems to replace public open-source sharing? - How will supply-chain and license-compliance risks evolve as more code is LLM-generated or vendored rather than imported as dependencies? - Does fragmentation from custom-generated code meaningfully reduce mass-exploit risk, or just shift the problem? **Highlights** > "I’d rather rely on proven libraries with well-defined abstractions than generate hundreds of lines of code which solve a local problem for me. “Not generated here” is just a different version of “Not invented here”. I disagree generally, and the problem is two fold.. I've just seen "well-defined" abstractions go wrong too many times. Over- encapsulation, over-abstraction, or just overall over-cleverness in third party packages that has led me to spend large parts of my career just frustrated trying to glue third party dependencies together in a sensible way... and the abstractions only adding complication. The joy and temptation of having an LLM "just make it" is that this goes away. The functionality fits my existing structure and abstractions and I'm not fighting a war with the architecture that the third party maintainer decided worked best for them. And getting only the parts I need, not your whole giant framework with it. (And yes, I know the LLM could easily hallucinate something far far worse, but let's just... play pretend here for a minute) The second part is that since the dawn of Maven, NPM, Crates.io generally there has just been this insane explosion in programs of transitive third party dependencies out into the stratosphere, and the cognitive, technical, and legal debt of so many deps generally is not sufficiently recognized by the community. Running "cargo tree" in my project is often frankly depressing. Multiple linked MD5/SHA256 implementations, random number generators, HTTP protocols, people dragging in tokio deps where I don't want them, multiple versions of the same thing compiled and linked... It's exceedingly frustrating, and with the explosion of security concerns we've seen recently, it's also potentially dangerous. I don't love the idea of having LLMs "just yeet it" esp if people misapply this to things like security/cryptography domains. But I'm also more than skeptical about the actual real world quality of many hallowed third party packages. I've been burned too many times. > — [cmrdporcupine on hackernews](https://news.ycombinator.com/item?id=50382796) > LLMs stop me using open source libraries for two reasons (1) GitHub is now full of slop. The majority of new open source libraries are now generated by AI. Many come from students who are just looking for resume garnish. Others come from devs who are more excited about being an "open source developer" than actually doing open source development (2) With AI I can probably build something better. And if it's crap? No problem! I can just wait 6 months and rewrite it with gpt_galaxy or Claude Torah or something At the same time I have no real incentives to contribute back. Anything I create competes immediately with a sea of slop. Any actual work I do gets identified and swallowed up by the plagiarism machine. And to be honest I only occasionally had good experiences with OSS anyway I think we are looking at the end of open source software. Not the end of free software - in fact that may end up flourishing with LLMs and reverse engineering and the like. But the idea of programmers sharing code, for communal interest and career building, is completely dead. > — [zero\_shift on hackernews · 4 comments](https://news.ycombinator.com/item?id=50381692) > > I’d rather rely on proven libraries with well-defined abstractions than generate hundreds of lines of code which solve a local problem for me. I 100% disagree with this. Supply chain attacks are already at an all-time high due to agentic hacking assistance, and that trend shows no sign of slowing. Every dependency you add is another potential attack vector, and just checking the dependency’s code doesn’t solve the issue - your dependencies also have dependencies! The cost of rolling your own has gotten so low that it’s almost always a better security tradeoff to reimplement the thing yourself. Is that a good thing? I’m not sure. > — [jdormit on hackernews · 3 comments](https://news.ycombinator.com/item?id=50382067) > This is absolutely correct. I recently found myself asking my agent to modify a local copy of an open source project to fix bugs that I found. It fixed the bugs, and it rebases against the public repo on occasion. Why haven't I submitted my patches? Because my agent wrote them and I didn't review them. I would feel bad submitting my patches without looking at them, and I don't have time to look at them. > — [jedberg on hackernews · 2 comments](https://news.ycombinator.com/item?id=50383555) > This is rather interesting. But it misses the point somewhat. The problem is whether or not we want to view code as a medium of communication between other humans vs code as an abstract machine that solves a problem. We know that "programs" in the general sense are fairly objective entities that can be studied objectively, which is where the famous Sussman line about this comes from. But as a language for expressing execution semantics that a machine can then execute to produce a desirable effect on the real world (a solution to a problem), we would not expect such code to be written with other humans in mind, and as lisp is a strictly more expressive language (both for expressing the meaning of an algorithm that other humans will be able to study and understand and that a machine can execute), and that more people who program are concerned with producing a solution to a problem, the "curse of lisp" is the logical conclusion. But it's overblown. There exist many excellent and fairly complete libraries for Lisp: Closer MOP, UIOP, ASDF, Bordeaux Threads, etc. And no surprise, these libraries are virtually ubiquitous and considered (at least by me) to be more or less extensions to the language. And these libraries are written in a fairly readable style that anyone can go and try to understand the code. Secondly, the curse isn't really much of a curse at all. It is more likely to yield more robust programs. The assumption that code reuse through libraries increases software quality doesn't really hold up in practice: libraries that are "complete" tend to add bloat to applications; managing different versions of libraries on the same platform leads to arguments about static vs. dynamic linking, and so on and so forth. Ever had to debug .so versioning bugs on Linux? It's not fun. And yet, that is par for the course if you try to persist in the notion that "libraries and code reuse is always better than reinventing the wheel". As a reaction to the utter failures that have occurred due to following that ideology, entire programming communities have popped up to fight it, particularly the "Handmade Hero" that became Better Software Conferences as well as "Software Should Work". And while those people aren't a huge fan of Lisp, they really do embody the Lisp mindset of "don't be afraid of building your own system in your own solution's language". And this does usually yield nicer systems to work with because programming is theory building: bringing in different ready-made libraries introduces conflicting theories that requires even more glue code to rectify and the glue code rarely foresees all the discrepancies. And so bugs appear in the integrations between them. That's not to say that increasing "the curse of lisp" always yields higher quality. The kinds of developers that make great software with that mindset are the ones that are allergic to inconsistency at any level and so squash bugs as quickly as possible and that is what leads their software to be better. But on the practical side of programming work, you feel a lot less inhibited in trying to fix bugs when you're certain you understand the code and how the implementor decided to map the problem domain onto the range of possible solutions. This is where the issue with LLMs comes in: if programming is theory building (which I firmly believe), then what we're really after with using LLMs to generate code is a more effective technique of translating high level theory of the problem into the low level code that executes to solve the problem. As such, maybe vibe coding can work if the vibe coder diligently keeps in their mind what they're after. But usually what that means is writing notes about the desirable properties of the resultant application. And then they're just back to theory building... just at a somewhat higher level. > — [d-us-vb on hackernews · 1 comments](https://news.ycombinator.com/item?id=50381487) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50349667) · 150 points · 111 comments ## Community discussion Top comments from developers on daily.dev. **@baturhanpro** · 0 upvotes >  ## Similar posts on daily.dev - [The people vs the AI overlords](https://daily.dev/posts/the-people-vs-the-ai-overlords-kduxszp2n) · Planet Python · 1 upvotes · 0 comments - [The fate of “small” open source](https://daily.dev/posts/the-fate-of-small-open-source-0n6ascfne) · Read the Tea Leaves · 25 upvotes · 5 comments - [How Vibe Coding Is Killing Open Source](https://daily.dev/posts/how-vibe-coding-is-killing-open-source-xc0nz3mk2) · Hackaday · 277 upvotes · 50 comments - [Programming used to be free](https://daily.dev/posts/programming-used-to-be-free-ceydkqepr) · Lobsters · 53 upvotes · 16 comments - [Is Open Source Dead?](https://daily.dev/posts/is-open-source-dead--adywhetx6) · Container Solutions · 32 upvotes · 18 comments --- Tags: [#open-source](https://daily.dev/tags/open-source), [#ai-coding](https://daily.dev/tags/ai-coding), [#lisp](https://daily.dev/tags/lisp) [View this post on daily.dev](https://daily.dev/posts/the-lisp-curse-now-coming-to-your-ecosystem-r8usyljys) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The Lisp curse, now coming to your ecosystem","url":"https://daily.dev/posts/the-lisp-curse-now-coming-to-your-ecosystem-r8usyljys","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-lisp-curse-now-coming-to-your-ecosystem-r8usyljys"},"datePublished":"2026-11-05T17:09:56.266Z","dateModified":"2026-11-05T20:37:33.214Z","description":"The author asks what could happen to mainstream language ecosystems like Java if LLM code generation becomes easier than using libraries. Fewer developers...","image":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","thumbnailUrl":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/the-lisp-curse-now-coming-to-your-ecosystem-r8usyljys","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"open-source,ai-coding,lisp","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"The Lisp curse, now coming to your ecosystem"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/the-lisp-curse-now-coming-to-your-ecosystem-r8usyljys","comment":[{"@type":"Comment","text":"","datePublished":"2026-11-05T18:22:14.089Z","url":"https://daily.dev/posts/r8USYLjYs#c-oRaFEOkmt","author":{"@type":"Person","name":"baturhan","url":"https://daily.dev/baturhanpro","image":"https://lh3.googleusercontent.com/a/ACg8ocJQ5s2w7kYYdDOtufZ5g50O0V3n1gmNk50z9iPj53RuGAjc2Ss=s96-c"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/the-lisp-curse-now-coming-to-your-ecosystem-r8usyljys#faq","mainEntity":[{"@type":"Question","name":"What is the LISP curse and why does it cause a lack of libraries?","acceptedAnswer":{"@type":"Answer","text":"The LISP curse describes how LISP's power and flexibility lets developers easily build custom solutions, so they work in isolation and reinvent the wheel instead of using shared libraries. The resulting code is often powerful but poorly documented, making it hard for others to reuse, so developers keep writing their own modules and the pattern perpetuates itself. Developers weighing custom code versus shared libraries follow this kind of ecosystem debate on daily.dev."}},{"@type":"Question","name":"Could relying on LLMs to generate code instead of using libraries hurt open source projects?","acceptedAnswer":{"@type":"Answer","text":"Yes, according to one argument: if generating code with an LLM is cheaper than learning a library's API, fewer developers will use existing open source libraries, cutting maintainers off from feedback. New library creation would also stagnate since maintaining open source (versioning, compatibility, hosting) is harder than just generating a one-off module, and these two effects could reinforce each other over time. Anyone deciding whether to reach for a library or generate code with an LLM can track this discussion on daily.dev."}}]} ```