The Filter Was The Feature

AI has energized my nerdy side in a way I haven't felt since my friend Dave Petet convinced me to ditch my TI-99 for a Commodore 64. If only I could find the cassette tape backup of my Beatbox with ASCII Interface.

Building software with AI (mostly Claude and a little bit of Codex) has been eye opening. My previous experiments were a couple of years ago when the state of the art felt like extremely advanced code completion. Very useful, but unlikely to completely upend the way I ran my company. That has changed. Small AI-amplified "Tiger Teams" can build software at a pace that feels like a superpower. Like a cheat code. I'm not talking about vibe coding a functional prototype that would never scale. Real software engineering. And in the right hands, real software engineering with all the hallmarks of a disciplined, experienced team of professionals.

We all understand AI will amplify team productivity. What I find myself thinking about quite a bit is how AI will amplify team weaknesses.

With smaller teams, the reverberation of every single human decision has higher magnitude. The inefficiency of larger teams sometimes had the unexpected benefit of catching more bad ideas earlier. Plans and proposals flowing through a larger audience was partly a velocity tax and partly a quality filter. Tiger Teams reduce the tax and the filter simultaneously. The output velocity is what people notice. The erosion of the quality filter will show up later.

Where I'd expect the failures to concentrate:

Architecture decisions in the first month. Early in a project a small team makes a flurry of decisions, and AI executes all of them beautifully — fast, consistent, well-tested. Including the bad one. In a traditional team, one of fifteen engineers has scar tissue from a previous project and pushes for the right pattern. Tiger Teams have fewer sets of scar tissue, and flawless execution makes the flaw harder to spot. By the time it surfaces, the team has burned through real capital.

missing scar tissue = missing filter

Scope discipline. The cost of adding a feature used to enforce prioritization. Now it doesn't. Tiger Teams ship 3X–10X faster, and a meaningful fraction of what ships is features nobody asked for — surface area to maintain forever. The hidden virtue of "we don't have engineering capacity for that" is gone. Product teams built for a world where engineering was the bottleneck now scramble in one where well-documented requirements are.

missing capacity constraint = missing filter

Executives who made an app over the weekend. A weekend binge coding produces something that actually works, and the takeaway is hard to argue with from inside the executive's head: this engineering thing was always overpriced theater. The decisions that follow — slashing engineering budgets, compressing timelines, promoting the people who present demos over the people who ship reliable systems — don't look like recklessness from that chair. They look like finally catching on. The gap between a weekend prototype and a production system that survives real customers is enormous, and this executive has never personally crossed it. (I'm being unfair to executives, but really only about 75% of them.)

missing engineering org = missing filter

What ties these together is that AI compresses the early signals of competence. Everyone ships. Everyone's product looks polished in a demo. The signal that used to differentiate mediocre from exceptional teams — did they actually pull it off when the hard parts hit? — only fires 18 to 30 months in. By then capital is committed, narratives are entrenched, and admitting the disaster has career costs for the people who empowered it.

This sets up an adverse selection problem on the empowering side. Often the decision makers in a position to greenlight projects will tend to be the ones least able to distinguish between mediocre and exceptional technical talent. The space fills with confident-but-wrong allocators making confident-but-wrong bets, and the disasters cluster in that population.

None of this means small AI-amplified teams are a bad bet. It means the aggregate "small teams will win" framing obscures a brutal selection process at the individual-team level. The best Tiger Teams will win spectacularly. The median will build something mediocre that wastes a year of runway. A non-trivial subset will produce actively destructive outcomes. People who say "small teams will win" without acknowledging the variance are setting themselves up to be in the wrong tail.

How do we join the right tail?

Decompose the project into the most important components. Look around the table. For each component, do we have someone here who has successfully shipped and maintained something similar? Now catalog the gaps. (If there aren't any gaps, maybe you're building something so derivative that it doesn't need to be built.) For each gap that a larger team might have covered, what is our BRRP? (Blindspot Risk Reduction Plan)

That was the easy mitigation I used to lure you into thinking we can hold onto our new AI panacea.

Here's the more challenging exercise. What are our weaknesses? What deficits are we about to amplify with AI? This is challenging because it is hard enough to be honest with ourselves. Being vulnerable in a work setting feels completely wrong. Ok, I'll start. I tend to rationalize why we should ship the prototype. I underestimate the time it takes to do things carefully. I trust my blink reactions too much. I'm too impatient to create an environment for less confident voices to speak up. I overestimate my expertise. I give more weight to contributions from charismatic people. (Turns out once I lower my defensiveness force field, it's actually a little difficult to stop listing weaknesses.)

"Wait a minute. This guy's a fuckup. Why am I reading this? Does he expect me to give my coworkers reasons to doubt my carefully constructed facade of competence?" Well, ok. Unless you have the great fortune to work with a team that truly trusts each other, maybe don't say all that vulnerable stuff out loud. But think it. And try and think of ways to compensate for it. If you and your team do that, you're going to build amazing things. Or I suppose you could just wait a couple years and say,

"Claude Mythos, look deep into my soul and build the things that I would build were it not for my imperfections. Please cap agent count at 10. Amen."

The primary audience for this mini essay is me. I'm trying to temper my excitement. I loved building new things from scratch with a tiny team of passionate experts. Managing multiple, larger teams was much less interesting. (The previous sentence should read, "I was not good at managing multiple, larger teams.") Augmenting a tiny team with AI feels like a panacea. It feels as if ambitious products are suddenly within reach to a micro team with vision and a credit card for tokens. I believe that's true. I'm just looking for the gotchas to avoid to make it extra true.

---

This piece was drafted in collaboration with Claude. The ideas and prose emerged from a real back-and-forth — there's no clean way to attribute who said what. You can't even use em-dashes as the tell — I overused them long before Claude was an embryonic unweighted neural net.