AI architecture · Open-source consumption

Open Source Was the Shortcut. Now It Can Be the Trap.

A mature repository no longer hands you free months of implementation. It hands you a compiled North Star — thousands of design decisions aimed at someone else's mission. With AI-cheap regeneration, adapting that alien design is often more expensive than mining its discoveries and generating your own system.

Scott Farrell · LeverageAI · Extends Don't Buy Software, Build AI into open-source application reuse

I kept doing the thing every builder does when a new system starts to take shape. You search GitHub. You find projects that are "close." You feel the old relief: someone already solved a lot of this. Then you look harder — and every nearby repo is too far from what you actually want.

Not worse. Differently aimed.

I was designing a specialised AI news radar — wiki-grounded, queue-driven, obsessed with evolving signal cases rather than a feed of posts. The adjacent open-source world is full of aggregators, readers, scrapers, "AI news" apps. On paper they look like a free head start. In practice each of them would have imported a pile of technical debt: features I do not want, state models I do not believe, and a product North Star that is not mine.

That is not arrogance about my idea being better. Their code is doing a different thing.

Open source used to save you from writing the code. Now it can trap you inside somebody else's design.

This is the open-source half of an inversion I have already argued for products and platforms: don't buy software, build AI when the economics favour ownership of the mission layer. That parent piece flipped SaaS build-versus-buy. This piece is about the case it never fully argued — what to do with a mature repository that is almost what you want.

The gold standard that aged overnight

It is not that long ago that finding a GitHub project close to what you wanted to do, and using it, was the gold standard. Free software. Cool features already built. Host it yourself, make a few changes, ship. That was smart engineering when writing code was the scarce, expensive step.

Now a lot of builders — myself included — look at the same move and feel a different instinct: I would not do that. It is too much alien crap to deal with. Building my own code is the reward. The hard work is the design.

The market is already voting with custom work on the purchase side. Retool's 2026 Build vs. Buy survey of 817 builders found that 35% of teams had already replaced at least one SaaS tool with a custom build, and 78% expected to build more of their own tools in 2026.¹ That is not the same decision as forking an open-source app — but it is the same economic weather. Custom generation stopped being the shameful last resort.

Measured coding assistance also shifted the cost of "write it ourselves." Peng and colleagues' randomised study of GitHub Copilot found developers completed tasks about 55% faster with the tool.² You do not need to believe every productivity headline to notice the direction: the side of the ledger that used to say "months of free implementation" no longer dominates the way it did.

What free code actually contains

Code is not neutral.

A mature repository embodies thousands of design decisions: its unit of work, its state model, its data grain, its source assumptions, its audience, its latency expectations, its UI, its storage choices, what it treats as success, and what it deliberately ignores. That bundle is its compiled North Star.

You can delete features. The deeper assumptions remain in:

• schemas
• module boundaries
• event flows
• names
• tests
• abstractions
• dependencies
• control paths

So adopting an existing project often means:

The technical debt is not necessarily poor code. It is good code organised around a different purpose.

That distinction matters more than most "tech debt" talk admits. Practitioners have started separating technical debt (local, visible, fixable in a pull request) from architecture debt (systemic misalignment that does not show up as a broken unit test). Clean modules can still sit inside a dysfunctional city plan.³ Forking a mature application is often how you import architecture debt wholesale while congratulating yourself for avoiding code debt.

Enterprise numbers rhyme with the same trap. An HFS Research study found most organisations spend two to seven times their software license cost on implementation and integration — turning a million-dollar purchase into a multi-million total commitment — and that average code reuse sits around 33%.⁴ The free or licensed layer is frequently the cheap part of the story. Adaptation is the expensive part. AI, as HFS put it, is an amplifier of whatever architecture you already have; it will not magically cure a brittle stack.⁴

With expensive software development, accepting a North Star mismatch was rational. Existing code saved months. With cheap AI coding, it can be cheaper to extract the useful ideas and regenerate around your own design than to spend weeks unbending somebody else's architecture.

The fork-gone-wrong shape

Here is the composite shape I keep seeing — and the shape I almost walked into with "close" news projects.

You clone a mature repo because it already has connectors, a UI, auth, and a deployment story. You strip features. You rename a few entities. You write adapters so your concepts map onto theirs. Week two, the adapters have opinions. Week four, your team is explaining their domain model in every design review. Week eight, the product still behaves like their product with a skin, and every new requirement arrives as a negotiation with foreign assumptions.

Nothing about the original code was "bad." The project may be excellent at being the system it intended. Fitness is relative to intent. That is precisely why it is a poor starting point for yours.

The old calculus assumed:

AI pushes it toward:

The free code may now be the cheapest part of what you inherited.

How to consume open source after the inversion

This does not make open source bad. It changes what you consume from it.

The useful question is no longer: Which project should we fork?

It is: What did each project learn that we should carry into our design?

Treat GitHub as a parts and priors library. Extract connectors, event schemas, deduplication tricks, scheduling strategies, failure modes, fixture data, terminology, and the things they tried and later removed. Borrow individual libraries where the contract is genuinely commodity. Treat the project as a design specimen, not as your foundation.

Copy discoveries, not destiny.

Three tiers of consumption

That hierarchy is the open-source twin of keeping commodity plumbing while owning the mission layer — the same spirit as the Don't Buy Software / platform-escape argument, applied to code you clone rather than software you rent.

LangChain, consumed correctly

I have used parts of LangChain before without adopting LangChain's whole worldview. Some of the RAG tooling was useful. The chunking tool, especially — a bounded capability with a clear contract. Lift the mechanism; leave the framework's idea of what an application is behind.

That is not a dunk on LangChain. Public docs still describe text splitters as a focused job: break large documents into smaller chunks that fit retrieval and context limits.⁵ That is exactly the kind of semi-commodity edge you want to reuse. The mistake is answering "can we implement this with LangChain?" when the stronger questions are about how they modelled the problem — and which pieces are hard-earned domain learning versus interchangeable plumbing.

The stronger questions replace the fork reflex:

• How did they understand the problem?
• What objects and boundaries did they choose?
• What did they make first-class?
• Which assumptions live in schemas and interfaces?
• Which parts are hard-earned domain learning?
• Which parts are commodity mechanisms we can safely reuse?

Read a repository at five levels

A mature repo is less like a free product and more like a fossilised design investigation. Its greatest value may not be the code. It may be the years of distinctions encoded in the code's shape.

Walk every candidate foundation at five levels before you decide what to keep:

Five-level walk: LangChain as specimen (not foundation)

Use LangChain as a public example of the method — not as advice to build your product "on LangChain."

Once you have walked those five levels, the fork decision usually answers itself. If level 5 is alien and level 3 fights your domain, no amount of level-1 reuse will make the repository a cheap foundation. Take the discoveries from levels 1–4 that survive contact with your North Star. Generate the organism.

Decision table: fork, mine, or generate?

When in doubt, force the question into writing: If we delete their repo tomorrow, which discoveries would we still want in our design docs? Keep those. Everything else is a candidate for regeneration.

What changes when the trap is visible

In the old world, code was scarce, so we reused applications and tolerated design mismatch. In the AI world, code is abundant, so we reuse ideas, standards, and components — and regenerate the application around our own intent.

The ecosystem starts to standardise below the application: protocols, libraries, eval cases, reference architectures, failure write-ups. The application layer becomes a Cambrian field of mission-shaped software — similar conceptual ancestry, radically different local forms. That is not a failure of open source. It is open source doing a more honest job: sharing the physics while letting each organism fit its environment.

For builders, the practical shift is small and sharp:

1. Stop treating "there is a close repo" as a green light to clone-as-foundation.
2. Run the five-level reading before you invest identity in their tree.
3. Reuse commodity contracts without apology.
4. Generate the mission-shaped spine around your North Star.
5. Put the discoveries in design notes so the next regeneration is smarter than the last.

I still look at GitHub projects when I design. I just stopped asking them to be my destiny. I ask what they learned. Then I build the narrow system my own mission demands.

When code is cheap, do not inherit an alien North Star merely to avoid generating code. Mine existing projects for compressed experience, then build the system your intent requires.