The Discipline of Not Building
Every piece of software starts with nothing, and the only way forward is to add capabilities. When development was slow and expensive, the bottleneck to a great product was always "we need more features." Teams fought for engineering time. Roadmaps were wishlists. Shipping a feature felt like progress because it usually was.
Coding agents changed this equation completely. Every idea on the backlog now looks feasible. Every feature request gets a "sure, why not." And so teams do what they have always done, which is to pile on features, except now they pile them on many times faster.
We are guilty of this too, btw.
Though, I get the feeling we are optimizing in the wrong direction. The goal has become feature delivery. Ship more, ship faster, and make the product do more things, but "more things" is not the same as "better" or "right." The agent can churn out the code in minutes, yes, so the question of "should we build this?" gets skipped entirely.
Features are liabilities, not assets! It is true. Every feature you ship expands your attack surface. It adds security exposure, compliance obligations, stability risk. It increases the maintenance burden forever. It makes the product harder to understand, harder to onboard, harder to explain, and worst of all, it can dilute the core idea of what the software does to the point where nobody remembers why it exists.
When writing code was slow, the obstacle to greatness was not having enough features. In a world of abundance, the obstacle is shipping features you don't need.
So here is what you should do instead. Stop writing features in advance and hoping customers will come. They never do. Instead, defer the feature until the very last moment when a real customer actually needs it. In the meantime, evaluate options, write specs, test ideas, prototype on paper and sketch architectures. Do everything except commit the feature to production code.
The feature does not need to exist until the need does.
It is discipline. It is harder to say "not yet" when an agent can build the thing in an afternoon. But the cost of the feature is never just the afternoon it takes to build it. The cost is every day after that.
This is where ChatBotKit is heading. We have built a featureful platform that can do a lot of things, and we are proud of that. We are now shifting gears. We spend more time now thinking about which feature is right, not just which feature is possible. We evaluate, we prototype on paper, we test the idea before we test the code. We only build when the need is real and present.
Trust me when I say we can build features. That is not the hard part anymore. The hard part is choosing not to.
A practical note: the features that matter most are often discovered, not planned. Build the infrastructure to move fast when the signal arrives, but resist building the feature before it does.