Unfeature request

I believe we can add a new item to the list of "code smells / project smells":

Too many features

Most modern vibe-coded agent-engineered CLI tools have 20, 30, or 40 verbs and internal commands in their TUI. Often, these feature duplicate or overlap existing functionality. They include things that could just be a flag on an existing command, things that could be hidden three keypresses away because 1% of users use them 1% of the time, or features that should never have been built in the first place because you could achieve the same result with Unix pipes and a smart use of core tools.

Why is it a problem?

Cognitive overload

If you are making a tool for real humans, you should consider human nature: a short memory and a limited attention span. Humans get tired and bored. Well-established UI principles still hold true: give users fewer options to make choices easier, guide them, keep the learning curve in mind, and treat their attention as a limited resource.

Of course, you can also build a tool intended solely for agents. If you're honest about that goal, why not? Translate your help output to Claudespeak, drop all the formatting, and they will be happy. Just don't leave your tool stuck in an intermediate state where it is disrespectfully terse and confusing to a human user, yet not structured enough for a clanker.

The illusion of power

You may think an intimidating list of two dozen commands makes your tool look sophisticated and professional. Yet the tools that truly make the world go round usually follow the Unix Way. Look at anything from cp to make for reference.

Less code, please

More code means a bigger attack surface and more things to cover with tests (and let's be honest, even with cheap LLM-generated tests, people still forget or don't care enough to maintain them). In other words: more moving parts to pay attention to, and more things that can go wrong.

What to do instead

Split

A pair of smaller, focused tools will almost always be better than one monolithic beast. If you need them to work together, use pipes, the filesystem, or even gRPC.

Sometimes documentation is the feature

If your tool benefits from being piped through grep, rg, yq, jq, or dasel, just tell the user how to do it in the docs.

The "unfeature" request

Ask yourself: What can I delete from my project today?

What will never be used? What lowers my signal-to-noise ratio? What could be done with the help of another tool? (Yes, you will have to set your ego aside.) Maybe when you originally built a feature, a better external solution didn't exist, but it's here now.

Start depending on it (with proper precautions). An interlinked ecosystem of focused projects is much healthier than a dozen egotistical developers trying to reinvent the wheel from scratch for 2.5 users. You won't become the next Daniel Stenberg or Fabrice Bellard anyway.

I recommend asking yourself this question weekly. Ask your audience, too. If nobody cries about a feature being removed, neither should you.

Almost every discussion about "taste" in software development touches on the mantra of "knowing what not to build."

But once you've already failed with that, the right move is learning how to cut.