---
title: Unfeature request
description: ""
lang: en
date: 2026-06-02T02:59:00.000Z
tags:
  - Architecture
  - Agents
  - LLM
  - Practices
---

June 2, 2026

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](https://en.wikipedia.org/wiki/Unix_philosophy). 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](https://github.com/burntsushi/ripgrep), [yq](https://github.com/mikefarah/yq), [jq](https://jqlang.org), or [dasel](https://github.com/tomwright/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.

## Tags

[Architecture](/tag/architecture/), [Agents](/tag/agents/), [LLM](/tag/llm/),
[Practices](/tag/practices/)

## Navigation

[← Spotlight: human.json](/post/spotlight-humanjson/) | [What is B19?
→](/post/what-is-b19/)