DIY vs USE

A battle-tested maxim of software engineering is to never DIY unless you absolutely have to.

Not-Invented-Here syndrome is costly. Reinventing the wheel is unnecessary and every line of code your team writes needs to be maintained.

Using Some Existing (USE) library or off-the-shelf solution can save you wasting time and resources building something that already exists. It can mean missing out on well-tested and well-maintained solutions that have been subjected to more scrutiny than your DIY effort.

LBut like most maxims, this isn’t a hard and fast rule. I almost always roll my own authentication workflows - login flows, permissions, business rules - because it is always cheaper to DIY business rules than fight an authentication framework that doesn’t quite match business needs. Yet I always use established crypto libraries like bcrypt for the actual cryptographic operations.

Part of what makes a good engineer good is knowing when to follow the rules and when to break them. Never DIY the primitives, especially when dealing with cryptography!

Agentic coding is changing the DIY vs USE dynamic though.

Features with a clear and narrow scope are perfect candidates for DIYing a quick and dirty solution. Today, Claude can implement a comprehensively documented and tested feature in the time it used to take to search for and evaluate existing libraries.

Better still, it is trivial to wrap a terminal interface to your DIY library and throw it in bin. This gives CLI agents near-native access via their bash tool without having to create /commands or MCPs.

An anecdote - last week I was wondering if there were any decent integrations for Claude and Linear. No perfect matches were immediately obvious but Linear does have a GraphQL API.

So I gave the docs to Claude and asked it to list my current backlog across projects. Claude diligently crafted a GraphQL query and voila - my tickets were listed in my terminal.

After doing this a few times, I thought about creating a linear /command or a skill but then the penny dropped - a gem with CLI and programmable access is more reusable, and more importantly, far more testable than any prompt written in markdown.

Less than 2 hours of vibe coding later, I published linear-rb and I can manage all my linear tickets from the terminal.

Of course, there is always a maintenance trade off. Code you write is code you need to maintain. But with the correct prompts and scope, LLMs are shifting the balance to favour DIY.