Software-Design | Bas Nijholt

Roll your own, fork the rest 🍴

Mon, 19 Oct 2026 00:00:00 +0000

Introduction: a follow-up to something I wrote #

In April 2025 I published Confessions of an asymmetric hypocrite, about my split personality on dependencies. Strict minimalism for the libraries I publish, and then, for applications:

For applications (especially CLIs in isolated environments), I’m far more liberal with dependencies to build features quickly.

I also wrote that I “strongly prefer dependencies that are already widely adopted and trusted by the community” because “these are less likely to cause unexpected issues”.

Then I spent a year building MindRoom, which is an application, exactly the category where I said I could relax.

I want to report back. “Prefer battle-tested dependencies” was the right rule. I just had the wrong idea of what battle-tested means. I thought a project with tens of thousands of GitHub stars qualified. Now I think it means millions of downloads, every day.

Table of contents

Update 2026-10-27: A week after publishing, I took my own advice twice. MindRoom’s knowledge search no longer uses ChromaDB, and code MindRoom owns has replaced Agno’s runtime; Agno stays only as the tool library. The full stories are in the comments.

1. Stars measure interest, not usage #

When I picked Agno as MindRoom’s AI framework, it looked like the safe choice. Today it has over 42,000 stars and 6,000 forks.¹

It also gets about 78,000 downloads a day on PyPI. httpx, one of Python’s standard HTTP libraries, gets about 25 million.²

A star is something you click once, when a README looks exciting. A download happens every time some project installs the package.

Most of those downloads are CI, not people, so downloads are not users either. But a package with millions of downloads a day is installed by a huge number of different projects. Many of them use the same functions you are about to use, so they hit the bugs before you do.

Battle-tested is also not the same as old. I use uv for everything, and it has only been around for a couple of years. I run into bugs in uv too, but there is simply no better alternative, and it gets about 3.6 million downloads a day.

2. A popular protocol is not a popular library #

The other place my old idea failed was Matrix.

Building on Matrix felt obviously correct. An open protocol, about a decade old, with serious security reviews from large organizations and governments. Millions of people use it.

Matrix is still a good protocol and I am still on it. But even though millions of people use Matrix, there are only a few client libraries.

MindRoom streams agent replies by editing the same message many times a second. Almost every part of the ecosystem I touched had a problem with that: Element, Cinny, matrix-nio, and the Matrix JavaScript SDK. In the JavaScript SDK, edits that arrived while a thread was still loading were silently dropped, so you saw stale text until you reloaded.³

What counts is how many projects use the library you build on. Element’s users do not test matrix-js-sdk for you. Other people building on matrix-js-sdk do. It gets roughly 100,000 downloads a day. matrix-nio, the Python client, about 23,000.

3. I checked the rule against my own code #

I pulled the daily download numbers for the packages I use and looked for workarounds, patches and forks in my own source.⁴

Package	Downloads per day	What it cost me
requests	49M	nothing I had to work around
pydantic	35M	nothing
numpy	33M	nothing
httpx	25M	nothing
aiohttp	18M	nothing
FastAPI	17M	nothing
chromadb	270K	workarounds for a bug that holds the GIL
matrix-js-sdk	~100K	patched
mem0ai	79K	largely reimplemented
agno	78K	126 documented workarounds
matrix-nio	23K	forked

Above a million a day, I had nothing to work around. Below it, every package on this list cost me a patch, a fork, a rewrite, or a pile of workarounds.

Take ChromaDB, the vector database behind MindRoom’s knowledge bases. In some cases it holds Python’s GIL during I/O, which blocks every other thread in the process. I opened a pull request to fix it, and nobody has looked at it yet. Instead of forking, I run every knowledge read in a short-lived child process, because a process can be killed and a blocked thread cannot.⁵

My fork of matrix-nio has about 8,900 lines added and 2,000 removed in the library code since the last upstream release.⁶

This does not mean every small package needs replacing. MindRoom pulls in a few hundred packages in total, and plenty of them have modest download numbers. The scrutiny should match how much I depend on a package. Something I use for one small, specific purpose is fine. Agno and matrix-nio are the base that MindRoom is built on, which is probably also why they hurt the most.

4. Roll your own: the library gives you the easy 10% #

Take memory libraries, Mem0 and friends. I have already written about this: I cloned LlamaIndex, LangChain, Letta, Mem0 and PydanticAI, studied how they work, and re-implemented the parts I needed. My memory system ended up “mostly modeled after Mem0”.

The core idea is not hard. With RAG, you chunk, embed, retrieve, re-rank and reconcile. Once you have read a couple of implementations you can write it, and afterwards you understand every line.

The same is true of an agent framework. It builds a JSON payload, posts it to an HTTP endpoint, parses a streaming response, keeps a list of messages, and loops when the model asks for a tool call. With AI, that is a day or two of work.

The hard part is making it reliable at scale: never blocking the event loop, and handling the crazy edge cases. With an agent system you end up building a very complicated state machine, and if you do not watch it, any combination of states is possible. Almost all of them are edge cases.

A library gives you the easy 10% and leaves you the hard 90%. And you do that 90% inside somebody else’s code, where you cannot fix the root cause.

MindRoom is now about 360,000 lines of Python, plus about 750,000 lines of tests.⁷ A good part of that is code I wrote instead of depending on a library:

Memory and knowledge: about 15,600 lines across 50 files.
Conversation history and compaction: about 8,400 lines.
An OpenAI-compatible API: about 2,300 lines, so MindRoom agents show up as selectable “models” in any chat frontend that speaks the OpenAI protocol.
Claude provider support: about 3,000 lines.

If I have to write the hard 90% either way, I might as well write the easy 10% too.

5. Fork your own: when the problem is hard #

I am not going to write my own end-to-end encrypted Matrix SDK, or my own homeserver. Those are hard, and also far below the line. So there I fork.

I forked the Python Matrix client. MindRoom ships its own fork of matrix-nio rather than the upstream package.

I forked the Matrix server, twice. First Synapse. When I ran into scaling problems I moved to Tuwunel and forked that.

I forked the web client. Cinny is the Matrix web client MindRoom uses.

None of these are AI projects. AI is just where I felt it most.

Whether a fork stays a fork depends on the maintainers. Tuwunel is extremely receptive to my patches, so I upstream anything that is general enough, and over the last six months I am its fourth most active contributor by commits.⁸ Cinny has not accepted any of my pull requests, so I forked it and stopped trying to upstream. Same with LibreChat: I had patches open for over a year without a reply, so I forked.

Keeping a fork up to date used to be miserable. With an LLM doing the rebasing, pulling in the latest upstream is now cheap, though still a bit of a risk every time. The bigger cost is that once you fork, you are responsible for the whole codebase, including the parts you never changed.

Agno: patches instead of a fork #

I did not fork Agno. I monkey-patched it. Agno is very actively developed, I have talked to the maintainer, and they know about these problems, so I hoped to upstream my fixes. I have filed 33 issues and pull requests there.⁹

That got out of hand. MindRoom now carries 126 documented workarounds for Agno across 59 files. Most of them live in 36 dedicated compatibility modules, about 7,200 lines of code, with the rest patched inline in 23 other files. Every one uses the same comment format, so I can find all of them with one search. Each one says what is wrong upstream, links the issue or PR, and says when I can delete it.¹⁰ A few examples:

Search failures become plausible empty results. A failed knowledge search and an empty index return the same empty list, so my agents confidently told me things did not exist.¹¹
Streamed tool calls get malformed or merged.¹²
Reasoning is silently lost when tool calls are replayed.¹³
Provider errors collapse into a generic 502, which throws away the error code you need to decide whether to retry.¹⁴

At this size, the patches amount to a fork.

6. I am not dunking on open source, including mine #

Everything I named is open source I use every day, for free, built by people doing their best. I filed issues and PRs, and where maintainers merged fixes I deleted my workarounds.

My own software is in the same category. Most new AI tooling is not very good, and MindRoom may well be included. It is large, fast-moving, and nowhere near millions of daily downloads. By my own rule, you should think twice before depending on it.

I also have to admit that I have not yet built a project the roll-your-own way from the start. So comparing “what I would do next time” with what I actually did is not entirely fair. This is what I think right now, and a year from now I may have to write another post correcting this one.

7. My rule for the next `uv add` #

I weigh three questions.

How many projects use it? Daily downloads of the actual package, not stars, and not how many people use the product built on top. In the millions: depend on it.

How much do I rely on it? Agno and matrix-nio are the base of MindRoom. A library I use in a CLI to format a question is not, and if I use it in a narrow way I do not need my own version.

How hard is it, and how receptive is upstream? If the library is something AI can write in a couple of days, roll my own. If it is hard, fork it. If the maintainers accept patches, upstream what is general enough.

If I started MindRoom over today, I would write the HTTP requests to the model providers myself. Not even the OpenAI or Anthropic SDKs. And even httpx is less safe than its download numbers suggest: in early 2026 its maintainer closed the issue tracker and discussions, and the latest stable release is from December 2024.¹⁵

In 2025 I wrote that the right answer is “it depends on the situation”, and I still believe that. I just had the wrong threshold. Battle-tested means millions of downloads a day. Below that: roll your own, and fork the rest.

From the GitHub API (api.github.com/repos/agno-agi/agno) on 2026-10-02: 42,385 stars and 6,041 forks. ↩︎
PyPI numbers are the last_day field of the pypistats.org API (/api/packages/<name>/recent), fetched on 2026-10-02, except uv, fetched on 2026-10-18 (3,648,827). The matrix-js-sdk number is npm’s weekly download count (about 730,000) divided by seven. Daily numbers wobble, so treat them as orders of magnitude. ↩︎
When events arrive for a thread that has not finished initializing, the SDK’s replay path never applies them, so an m.replace edit (the event type Matrix uses for “this replaces message X”) is stored and never shown. I replayed a captured event trace through the SDK: unpatched, zero of seventeen edits reached the listeners; patched, all seventeen. MindRoom carries the fix as a patch-package patch on the SDK’s thread.ts. ↩︎
For each direct dependency I looked at three things in the MindRoom repository: whether pyproject.toml pins a fork instead of the upstream package, whether patch-package patches it, and whether the source has workaround markers or comments pointing at upstream issues for it. The packages above a million downloads a day had none of those. ↩︎
The PR is titled “Release GIL during metadata I/O”. On the MindRoom side, knowledge/read_process.py starts the child process, and a TODO says to remove it once a Chroma release with the fix is pinned. A blocked thread holding the GIL cannot be interrupted from Python, but the kernel will always terminate a child process. ↩︎
Compared with upstream matrix-nio 0.25.2 (released 2024-10-04): git diff --shortstat on the library code gives 8,872 lines added and 1,966 removed across 52 files, from 89 commits, 76 of them mine. The fork is published on PyPI as mindroom-nio. ↩︎
Counted with git ls-files and wc -l on the MindRoom repository on 2026-10-18: 360,513 lines in 1,222 Python files under src/, 750,657 lines under tests/, and another 81,543 lines of TypeScript in the frontend. The per-feature numbers below come from the same count over the relevant directories. ↩︎
Non-merge commits on Tuwunel’s main branch since 2026-04-18: Jason Volk 1,332, June Strawberry 325, dasha_uwu 55, me 42. ↩︎
Issues and pull requests in agno-agi/agno with me as the author, counted on 2026-10-02. ↩︎
Every workaround starts with a comment like # AGNO_COMPAT: Knowledge search hides provider failures as empty results., followed by Reason:, Upstream issue:, Upstream PR:, Remove when: and the tests that cover it. The counts come from grep over src/: 126 AGNO_COMPAT: markers in 59 files, and 7,160 lines in the 36 agno_compat_* modules. ↩︎
Knowledge.search catches vector store and provider errors and returns []. agno#10150, partially fixed by agno#10152. ↩︎
When a streamed tool-call index does not start at zero, Agno leaves empty placeholder calls. agno#8879, fix proposed in agno#8880. ↩︎
With the OpenAI Responses API, Agno keeps only the last reasoning item, so it cannot be replayed with the tool calls it belonged to. agno#9960; partial fixes landed in agno#10075 and agno#10395. ↩︎
Unclassified ModelProviderError failures default to HTTP 502, so a real network blip and a permanent error look the same. agno#8869, partially addressed by agno#8870. ↩︎
The latest stable release on PyPI is 0.28.1, uploaded 2024-12-06. There have been 1.0 development pre-releases since, the latest in August 2026. The closing of issues and discussions was widely discussed in the Python community in March 2026. ↩︎

Confessions of an asymmetric hypocrite: on Python dependencies

Sun, 27 Apr 2025 00:00:00 +0000

Introduction: The Dependency Dilemma 🤔 #

I just listened to a podcast “Build software that lasts!” with Bert Hubert (a fellow Dutch), who prefers to reduce the number of dependencies to an absolute minimum (also see his related blog posts [1] and [2]). While I agree one shouldn’t use is-even as a dependency (is-odd is a better choice 😏), I think there is a lot of value in reducing the number of dependencies but also in using the right tool for the job and not continuously re-inventing the wheel. The podcast got me thinking about my own stance on dependencies and how I actively avoid introducing dependencies into my libraries while expecting (hoping 🤞) others to depend on my work.

Like many software developers, I’ve spent countless hours wrestling with dependencies. Dependency hell is easy to fall into, especially in dynamic languages like Python. Those moments where installing or updating one package breaks another, or where a tiny library pulls in hundreds of transitive dependencies, are frustratingly common. This frustration partly motivated me to create unidep, a tool aimed at simplifying dependency management across different Python tools like pip and conda.

But working on unidep and my other projects forces me to think about my own relationship with dependencies. I’ve realized I operate with what feels like an “asymmetric hypocrisy.” My standards for the libraries I publish are extremely strict regarding which external dependencies I consume. Yet, as an author of over 30 Python packages, I inherently produce dependencies, hoping others will adopt my work. And then, when building applications or CLIs, my caution often disappears entirely.

This post dives into that asymmetry. It’s about the different hats I wear: the minimalist library author (as a dependency consumer), the hopeful library author (as a dependency producer), and the pragmatic application developer. In this post, I’ll explain why I take these different approaches and why it’s really about the situation, not a contradiction.

Table of contents

1. The Library Author Hat 🎩 (as Dependency Consumer): Maximum Caution #

When I build and publish an open-source Python library – like Adaptive, pipefunc, or unidep – my primary focus shifts to the users who will depend on my code. My choices directly impact their projects. This responsibility means I have to be very careful about adding external dependencies:

Minimize and Scrutinize: Fewer dependencies mean fewer potential conflicts for users. I aggressively minimize the core runtime dependency list.
Favor Battle-Tested Dependencies: I strongly prefer dependencies that are already widely adopted and trusted by the community. (I have been called that person that always wants the latest and greatest, the truth is that I am a sucker for shiny new things but typically only adopt them once they are already quite popular.) Think numpy or cloudpickle. These are less likely to cause unexpected issues or disappear overnight.
Low Transitive Dependency Count: A key criterion is how many other packages a potential dependency pulls in. Ideally, I choose dependencies with zero or very few further dependencies. For example, in pipefunc, dependencies like numpy, networkx, and cloudpickle are good examples – they are popular and don’t rely on many other things.
Optional Dependencies for Heavy Features: If a feature really needs a large or less common dependency, I try making it a optional extra (project.optional-dependencies). Users opt-in only if they need that specific capability.
Avoid Pinning (Mostly): As mentioned before, hard version pins (==1.2.3) in libraries are usually harmful. Minimum versions (>=1.2) or safe upper bounds (<2.0) are preferred.
License Awareness: The license of a dependency matters immensely, especially regarding compatibility and obligations (GPL considerations).

The guiding principle is: Do not cause pain for your users. A library should integrate smoothly into diverse environments.

2. The Library Author Hat 🎩 (as Dependency Producer): The Paradox #

Here’s where the “hypocrisy” might seem to surface. While I’m cautious about consuming dependencies for my libraries, I am also the author of over 30 packages. I invest time and effort into these tools, naturally hoping they prove useful and that others will adopt them – making my libraries dependencies in their projects.

Is it hypocritical to be wary of adding dependencies while simultaneously creating them for others? Perhaps slightly, but it’s also the nature of contributing to an ecosystem. I try to handle this by strictly following the rules from Section 1 for my own libraries. If I expect others to rely on my code, I feel responsible to make that dependency as low-risk and stable as possible. I want my libraries to be the kind of well-behaved, minimal-friction dependencies that I myself would be comfortable adding.

3. The Application Developer / Contributor Hat 🧢: Practicality is Key #

When the context shifts to building an application – like a command-line tool, a web service, or a personal project – my rules become much less strict. The key differences are isolation (keeping things separate) and how far the effects reach.

Isolation Reduces Risk: Applications often run in controlled, isolated environments. Docker, conda/micromamba (Python Environment Jungle post), or simple venvs contain the dependencies. A conflict within the application’s environment doesn’t break the user’s entire system or other unrelated projects.
CLIs as a Prime Example: Many tools I’ve built are CLIs (like tuitorial or helpers within my dotfiles). These might have tens of dependencies. Because they are installed into isolated environments (often via uv, pipx, or within a dedicated conda env), this complexity is okay. The risk is contained.
Developer Tools Welcome: Productivity boosters like ruff, mypy, etc., are fair game as development dependencies (My Python Project Toolkit). They don’t impact the end-user runtime (if packaged properly), so I am much more lenient with dev tools.
Focus on Functionality: The goal is often to deliver features or solve a problem efficiently. Leveraging existing libraries, even those with dependencies, is usually faster and more robust than reimplementing complex logic. It usually makes more sense to use existing libraries.

In this context, the focus changes from minimizing external impact (libraries) to maximizing internal capability and maintainability within a controlled scope (applications).

4. Conclusion: Not Hypocrisy, but Context-Driven Strategy 🙏 #

My approach to dependencies is “it depends on the situation”. I’m stricter about dependencies for my libraries than for my applications or personal tools. I am cautious about adopting dependencies while actively producing them for others.

But I don’t see this as hypocrisy. It’s a practical approach based on different situations and goals:

Libraries (as Consumer): Focus on keeping the software community stable and making things easy for users. Be conservative.
Libraries (as Producer): Create software responsibly, following the same high standards you expect from others.
Applications: Focus on adding features and developing quickly within separate environments. Be pragmatic.

Understanding the different risks and goals for each situation helps make good decisions about dependencies. It’s about choosing the right trade-offs for the specific situation, whether you’re building a foundational block for the community or a specific tool for a controlled environment.

How do you handle dependencies across different types of projects? Do you find yourself navigating similar questions? Share your thoughts!

Functions over classes? Why I prefer a simpler, functional style in Python 🐍

Mon, 14 Apr 2025 00:00:00 +0000

Over years of building software, from scientific simulation tools like Adaptive and pipefunc to package management packages like unidep, I’ve found myself preferring a certain coding style: using small, focused functions more than large classes with complex internal state and deep inheritance hierarchies. This isn’t about dogma, but about a pragmatic approach that, in my experience, leads to code that is easier to understand, test, and maintain.

This post outlines why I lean towards this functional-inspired style in my Python projects, while still recognizing where classes are the right tool.

Table of contents

1. Taming Complexity: Avoiding the Over-Engineering Trap 🧠 #

One of the biggest challenges in software development is managing complexity. As systems grow, keeping track of how different parts interact and understanding the internal state of objects can become a lot to keep track of mentally (high cognitive load).

I’ve often observed a pattern, especially when developers first start using object-oriented programming: the tendency to use classes everywhere. This can lead to over-engineering – introducing many layers of inheritance, abstract base classes with only a single implementation, and generally creating complexity when simplicity would suffice. Thinking you’re being clever by building complex class structures can sometimes just be a form of overgeneralization that makes the code harder, not easier, to follow.

Classes, particularly those with many methods modifying internal attributes (self.x, self.y, etc.), require you to constantly hold their state in your head. When you call a method object.do_something(), the outcome might depend not just on the arguments you pass, but also on the object’s history – what methods were called before, and in what order? This hidden state can make reasoning about the code’s behavior difficult and debugging tricky.

Functions, particularly when kept small and focused, tend to be more explicit. Ideally, a function takes inputs and produces outputs, with minimal side effects (or ideally, none - making them pure functions). Its behavior is primarily determined by its arguments. This makes the code flow easier to follow: data comes in, transformation happens, data goes out. There’s less hidden context to juggle mentally.

2. The Power of Small, Focused Functions 🎯 #

This leads directly to the preference for small functions, each doing one thing well (adhering to the Single Responsibility Principle). When functions are concise and have a clear purpose:

Readability Improves: It’s easier to understand what a small, well-named function does quickly.
Reusability Increases: Small, focused functions are more likely to be reusable in different parts of the codebase or even in other projects.
Refactoring is Simpler: Modifying or replacing a small unit of logic is less risky than altering a large, complex method within a class.

This philosophy is something I actively apply. Looking at the codebase for unidep, for example, you’ll find many utility functions in modules like _dependencies_parsing.py or _conda_env.py, each handling a specific, well-defined task.

3. Keeping Classes Simple & Using Them Where They Fit 🛠️ #

So, where do classes fit in this picture?

Firstly, as simple data structures – think NamedTuples or dataclasses (preferably with frozen=True). Their main role is to group related data attributes together, providing a clear structure for passing information around. They hold data, but don’t typically manage complex state transitions.

# Example of a simple data class from unidep
from dataclasses import dataclass
from pathlib import Path

@dataclass(frozen=True) # Use frozen=True for immutability
class Spec:
 name: str
 which: Literal["conda", "pip"]
 pin: str | None = None
 # ... other simple attributes ...

# Used to pass structured data, not to manage complex state
def process_spec(spec: Spec) -> Path:
 # ... function logic using spec data ...
 pass

Secondly, and importantly, classes are excellent for defining user-facing APIs. For the end-user of a library, having a single object with easily discoverable methods (object.<tab>) is often a great user experience.

A good example from my own work is the pipefunc package. It provides two main classes, Pipeline and PipeFunc, which encapsulate the core functionality. Users interact primarily with these objects and their methods.

# Simplified example from pipefunc's user perspective
from pipefunc import Pipeline

pipeline = Pipeline(...)
pipeline.add(some_function, ...)
results = pipeline.run("output_node")

However, inside the methods of these API classes (Pipeline.run, Pipeline.add, etc.), the actual logic is often delegated to smaller, internal functions. The class acts as a clean interface or facade, orchestrating calls to these more focused, functional units. This gives the user a nice API while keeping the internal implementation modular and testable.

I also actively avoid deep inheritance hierarchies. Composition (having objects contain other objects) often provides a more flexible and explicit way to combine functionality without the tight coupling and complexity inheritance can introduce.

4. The Testability Advantage ✅ #

One of the most significant practical benefits of prioritizing functions and simple classes is testability. Small, pure (or mostly pure) functions are incredibly easy to test:

Provide known inputs.
Assert expected outputs.
Minimal setup or mocking is required because there’s no complex internal state to manage.

Even when testing the methods of the API classes (like Pipeline in pipefunc), the fact that they often delegate to well-tested internal functions simplifies the process. You focus on testing the orchestration and interaction logic at the class level, knowing the underlying functional units are already verified.

Testing classes with intricate internal state inherently involves more setup (instantiating the object, getting it into the right state before calling the method under test) and potentially more complex assertions to verify state changes. Aiming for more functional units significantly simplifies the testing process.

5. It’s About Pragmatism, Not Dogma 🙏 #

This isn’t a wholesale rejection of object-oriented programming. It’s about choosing the right tool for the job and prioritizing clarity, testability, and maintainability. Classes are fantastic tools, especially for building clear APIs and structuring data. Deep inheritance and complex state management, however, should be used carefully, not just because the language allows it.

For much of the work I do – building libraries, tools, and performing data analysis or simulations – I’ve found that prioritizing functions, keeping API classes focused, minimizing internal state, and avoiding deep inheritance leads to code that I find easier to write, understand, debug, and maintain in the long run. The reduction in cognitive load and the ease of testing are strong points for how I work.

If you often find yourself struggling with complex state management or tangled inheritance trees, perhaps consider if a simpler, more functional internal structure, potentially fronted by a clean class-based API, might bring some clarity and simplicity to your projects too.

Vibe coding worked—until the 15‑hour cleanup

Fri, 21 Mar 2025 00:00:00 +0000

I tried “vibe coding” for 3 hours, my application worked, but then I spent 15 hours fixing it #

That’s not an exaggeration—it’s really what happened.

Recently, I tried “Vibe coding,” a term coined by Andrej Karpathy, a prominent AI researcher, co-founder of OpenAI, and former AI lead at Tesla. In his viral tweet from February 2025, Karpathy described vibe coding as a programming approach where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” It’s essentially about letting AI handle the coding based on natural language prompts without closely reviewing the generated code.

Intrigued by the hype, I decided to experiment with vibe coding using Cursor on a new Python project I called dotbins (check out my detailed write-up here)." Dotbins manages CLI tool binaries within Git repositories, automatically downloading the correct binary from GitHub for the user’s platform and architecture, significantly simplifying my dotfiles and bootstrapping process. I am super excited about this project but it is not what this post is about.

Initially, it was fun to get something working so quickly. Within just three hours, I had a functioning prototype—without carefully examining the code. But I had unknowingly created a monster—a true spaghetti monster! 🍝

Once I started reviewing the AI-generated code, I realized it was totally incomprehensible. The AI had implemented the most complicated and roundabout ways to achieve simple tasks. It introduced redundant checks for impossible conditions, irrelevant error handling, and execution paths that would never trigger. The code worked superficially, but beneath the surface, it was chaotic and nearly impossible to understand or maintain.

This realization turned three hours of fun into fifteen hours of meticulous debugging, refactoring, and cleaning up the mess. Essentially, I had to rewrite the entire project.

My main takeaway: AI-assisted coding, or “vibe coding,” is incredibly powerful for quick prototyping but dangerous when used without oversight. According to this recent Y Combinator discussion, many startup founders are building products almost entirely with AI-generated code, “vibing” the code, meaning they let the AI write the code and don’t review it. For writing a couple of hundred lines of code it likely works pretty well, but for anything more complex, it’s a recipe for disaster. Personally, I would never invest in, build upon, or use such products—they’re essentially constructing technical prisons for themselves.

AI is fantastic for inspiration, quick prototyping, writing code, and refactoring—but letting it run wild without careful human review can quickly lead to severe technical debt and hidden bugs.

Thanks for reading!

Software-Design | Bas Nijholt

Roll your own, fork the rest 🍴

Introduction: a follow-up to something I wrote #

1. Stars measure interest, not usage #

2. A popular protocol is not a popular library #

3. I checked the rule against my own code #

4. Roll your own: the library gives you the easy 10% #

5. Fork your own: when the problem is hard #

Agno: patches instead of a fork #

6. I am not dunking on open source, including mine #

7. My rule for the next uv add #

Confessions of an asymmetric hypocrite: on Python dependencies

Introduction: The Dependency Dilemma 🤔 #

1. The Library Author Hat 🎩 (as Dependency Consumer): Maximum Caution #

2. The Library Author Hat 🎩 (as Dependency Producer): The Paradox #

3. The Application Developer / Contributor Hat 🧢: Practicality is Key #

4. Conclusion: Not Hypocrisy, but Context-Driven Strategy 🙏 #

Functions over classes? Why I prefer a simpler, functional style in Python 🐍

1. Taming Complexity: Avoiding the Over-Engineering Trap 🧠 #

2. The Power of Small, Focused Functions 🎯 #

3. Keeping Classes Simple & Using Them Where They Fit 🛠️ #

4. The Testability Advantage ✅ #

5. It’s About Pragmatism, Not Dogma 🙏 #

Vibe coding worked—until the 15‑hour cleanup

I tried “vibe coding” for 3 hours, my application worked, but then I spent 15 hours fixing it #

7. My rule for the next `uv add` #