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 an existing 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.

Like most maxims, this isn’t a hard and fast rule. I almost never use authentication libraries for the simple reason that any commercial application will have unique business requirements that make it cheaper and faster in the mid-to-long term to roll-your-own implementation rather than fight the library that inevitably wasn’t designed to do what your clients want to do.

Part of what makes a good engineer good is know when to follow this maxim and when not to. But when in doubt, Use Someone Else’s. 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 vibe coding a quick and dirty DIY 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.

90 minutes of vibe coding later, I published linear-rb and I can manage all my linear tickets from the terminal.