LangChain Keeps Getting Buried, and the Discussion Keeps Growing: Three Threads on the Cost of Abstraction

A post on Hacker News on May 4, 2023 described re-implementing LangChain in 100 lines of code. 252 points, 83 comments. On July 8, 2023, a thread titled "Langchain Is Pointless" reached 386 points and 174 comments. On June 20, 2024, Octomind published a post called "Why we no longer use LangChain for building our AI agents" and it reached 480 points and 297 comments.

Three threads, 13 months apart, each one larger than the last. The conversation grew. The complaint stayed the same.

LangChain didn't necessarily get worse. What the threads track instead is the gap between what a framework is for and what it becomes once a team knows what they're doing.

What 100 lines actually proves

The May 2023 post reproduced the core of LangChain (the ReAct reasoning loop) in roughly 100 lines. HN generally agreed the exercise landed. The interesting pushback came from cube2222, who had looked at this carefully: "The magic in LangChain, though, is the ecosystem. I.e. they have integrations with tons of indexes, they have many tool implementations, etc. This is the real value of LangChain. The core ReAct loop is quite trivial."

So the 100-line reproduction is accurate, but it proves something narrower than "LangChain is replaceable." What fits in 100 lines is the orchestration loop: the part that strings prompts together and routes outputs. What is much harder to replace is the ecosystem: pre-built connectors to vector stores, tool implementations, integrations with specific embedding databases. If you chose LangChain because you needed one of those connectors, the 100-line argument is beside the point.

This is the same logic that separates the £6 microservice from the embarrassing cron job in the software engineers passive income thread. The scaffolding is fast to write. The integration with the specific API you need is where the hours go. A framework's value is highest when you don't know which integrations you'll need yet, and lowest when you've picked your stack and the framework is getting between you and it.

The npm left-pad comparison surfaced in both the 100-lines thread and the Pointless thread. Left-pad was famously a package for a function that fits in one line, used everywhere because it was popular. The comparison was made to say: adoption isn't validation. It's a fair point, with one wrinkle. Left-pad had no ecosystem. LangChain's integrations are a real asset for a team at the right stage.

The case for keeping it

"Langchain Is Pointless" ran on LangChain's own subreddit, and the HN thread about it attracted enough people who disagreed that the defenses are worth cataloguing seriously.

The most honest characterization came from cyanydeez in the Octomind thread: "In some sense, this could be retitled 'We no longer use training wheels on our bikes.'" That is not a dismissal. Training wheels do what they are designed to do. The objection is to still having them on once you know how to balance.

The specific use cases that held up:

Vendor neutrality. lmeyerov from Louie.ai described their situation: they need pluggability to support different LLM vendors and bring-your-own models, and LangChain helps code to interfaces rather than against specific vendor APIs. teaearlgraycold mapped out two concrete scenarios where the framework earns its keep: beginners who need the mental models and something to start with, and teams that want to swap embedding databases or model providers without rewriting orchestration logic.

Prototyping speed. Kydlaw put it plainly: "IMO LangChain provides very high level abstractions that are very useful for prototyping. It allows you to abstract away components while you dig deeper on some parts that will deliver actual value. But aside from that, I don't think I would run it in production." Multiple people landed on roughly that same position across the three threads. The framework earns its keep in chapter one of a project.

On-ramp quality. Spivak made the sharpest case for the prototyping argument: "Langchain is absolutely perfect though, it's bad enough that you'll be driven to write something better out of pure frustration but gives you enough good ideas and breadcrumbs to actually do it. It's probably the best on-ramp for 'practical uses of LLMs' because it scratches just the right developer itch." That is a high compliment in a specific direction: useful until it becomes an obstacle, at which point you know enough to leave.

CharlieDigital, who still uses Semantic Kernel (a different LLM framework, from Microsoft), illustrated what "using the right parts" looks like in practice: they found agents too hard to debug and replaced those with three sequential prompts and an explicit control loop, but kept the framework for lower-level abstractions that they would have written themselves anyway. The verdict wasn't "frameworks bad"; it was "agents bad, primitives still useful."

Finally, dcole2929 pushed back on the entire "frameworks are bad for LLMs" narrative directly: "I've seen a lot of stuff recently about how LangChain and other frameworks for AI/LLM are terrible and we shouldn't use them and I can't help but think that people are missing the point... Opinionated workflows that enable a specific kind of application. Ideally the goal is to cover 80% of the cases and provide escape hatches to handle the other 20%." The criticism of LangChain specifically, they argued, was being used to prove something broader that doesn't follow.

The Octomind employee who disclosed their affiliation in the thread offered the clearest framing of what the original article was actually saying: "It's hard to find a good abstraction in a field that has not settled yet on what a good abstraction is. In that case, you might want to avoid frameworks as things shift around too much." That is considerably narrower than the headline suggests. It's a timing argument, not a categorical one.

Where the tax shows up

The complaints across all three threads focus on the same friction: LangChain mostly works, but when it doesn't, you can't see why.

autokad put it directly: "prompt engineering requires the ability to see what is happening at various steps and LangChain makes that harder if not impossible."

risyachka: "All LangChain does in these cases is introduce useless abstraction that takes longer to implement and makes things less transparent. And when you need some customization, instead of taking you 10 minutes it takes an hour to work around this abstraction."

The sharpest production cost in the material came from crazyedgar, who ran LangChain in production and traced a greater-than-30% request failure rate to an undocumented default: LangChain sets a 60-second timeout on every request, and "this behaviour isn't documented." The system worked for weeks, then started failing frequently. "Such spurious decisions made by LangChain are everywhere, and will all eventually come back to bite. In the end we replaced everything with vanilla request clients."

The framework tax isn't a single line item. Opacity means you can't see what's being sent. Undocumented defaults mean the framework made decisions you didn't know about. And when its abstractions don't fit your use case, you spend time working around them instead of solving the problem. Those costs appeared, across the threads, to scale with time in production. Teams in prototyping mode didn't feel it. Teams six months into production did.

arpowers named the root cause: "false abstraction." It "abstracts some work only to introduce its own API (which is ultimately more complicated, less documented, introduces limits and constraints, and comes with its own bugs and dev politics)." The replacement API is new surface to learn, new failure modes to find, and no guarantee of stability in a field that is still moving.

Who showed up to bury LangChain

The Pointless thread and the 100-lines thread attracted commenters promoting competing products under the cover of technical criticism.

ibains from Prophecy.io argued that LangChain and LlamaIndex were reinventing ETL, that enterprises should use Apache Spark, and linked to their company's talk at the Data+AI Summit and a company blog post. The criticism of LangChain may be valid. The Prophecy.io pitch arrived on its back.

lmeyerov, posting under their Louie.ai/Graphistry handle, made similar points about pluggability and vendor neutrality, added that they were building related capabilities as custom libraries, and mentioned they were hiring. They stated the affiliation, but multiple comments, each one building a case for the company's approach, is still a distribution strategy.

fchief announced they had ported LangChain's core to Ruby and linked to BoxcarsAI on GitHub. No disclosure, framed as contribution.

This is the same mechanism we noted in the build-vs-buy thread: genuine technical criticism is the easiest possible cover for pitching an alternative. The affiliation disclosures varied from explicit to absent. The move is the same.

One tool, two phases

Our project page at /toolbox/projects/langchain-ai/langchain shows LangChain's 90-day star history, the top-upvoted open issues, and the neighboring projects in its category (the alternatives that keep appearing in these threads). The star count reflects continued adoption. The issues list reflects where the friction is concentrated. The neighbors show what teams actually move to when they leave.

The three threads together span from prototyping-era LangChain through a year of production experience. In that window the framework earned a reputation for being hard to debug in production without necessarily failing in prototyping contexts. Both things are true at the same time.

The pattern is the same one the build-vs-buy analysis finds in internal tooling: the same tool that's right for the discovery phase starts to extract a cost once the discovery is done. LangChain accelerated getting to a working demo. It slowed down the debugging and monitoring that production requires. The cost appears in the second chapter, not the first, which is also when most teams started writing about it on HN.

What nobody in any of the three threads answered cleanly: if you start a project today, do you reach for a framework or write a thin wrapper over the SDK yourself? The comments across all three threads converge on something like: use the provider SDK directly, write your own orchestration (it's 100 lines), and adopt a framework only for the specific integrations it already has and that you have verified you cannot easily replicate. That's the inverse of "install LangChain first, figure out what you need later." And it's not the same as calling it pointless.

The complaints came mostly from teams that had been running LangChain in production for months. The defenses came mostly from teams still prototyping. Both were right about the same tool.