As engineers we'd never add a dependency because a thread told us to. We check the bundle size, the maintenance status, the license, whether it fits the stack. Then we install.

Somehow, with AI tools, we throw all of that out. I know because I did it — I ended up with 43 signups and 4 tools I actually use. The other 39 were node_modules I never imported.

So I started treating AI tool selection like dependency selection. Same rigor, five-minute process. Here it is.

The core problem: discovery is broken

The bottleneck isn't capability — there are 15,000+ tools. It's discovery and evaluation. "Top 10 AI tools" listicles are ranked by affiliate commission, not fitness for your use case. It's the equivalent of picking a library by its GitHub star-count alone.

You need a selection function, not a feed. Four steps.

Step 1: Define the job as a function signature

Don't ask "what AI tool should I use?" Define the task like an interface:

transcribe(clientCall: Audio) -> TaggedTranscript
summarize(pdf: ResearchPaper) -> KeyPoints
generate(prompt: string) -> ProductImage
clean(rows: MessyCSV) -> NormalizedCSV

The moment the input/output types are explicit, the category is obvious and 14,900 tools drop out of scope. You're resolving one dependency, not browsing a registry.

Step 2: Resolve 3 candidates from a registry — not a Google search

Searching "best AI transcription tool" returns SEO spam. Instead I hit a categorized index and filter to the relevant namespace. Concretely, I map the job to a category page:

• Building something and need code gen / agents? → Developer & Coding AI

• Content pipeline? → Writing & Content AI

• Audio/transcription work? → Voice & Audio AI

• Asset generation? → AI Image Generator

• Ops/glue work? → Chatbot & Automation AI

Pull three candidates. Then evaluate them the way you'd vet a package:

1. Real free tier — can you test without a card? (Think: is it MIT or "email us for a license"?)

2. Output quality on your input — not the demo dataset.

3. Integration surface — API, webhooks, clean export? Or a walled garden with no egress?

4. Cost at scale — the O(n) question. Free at n=1, but what's the bill at n=10,000 calls?

Step 3: Write a throwaway integration test

The step everyone skips. Give all three candidates the same real payload from production-like work — not the vendor's cherry-picked sample.

for tool in [candidateA, candidateB, candidateC]:
    result = tool.run(myActualMessyInput)
    score[tool] = rate(result, outOf=5)   # quality + how painful was export

The famous option loses more often than you'd think. The winner is usually the boring one whose output format didn't require a post-processing script.

Step 4: Commit one to the stack, uninstall the rest

Pick the winner, wire it into your workflow today, and delete the other two accounts. A tool you "might need later" is a dependency with zero imports and a nonzero attack surface (spam, another password, another ToS). Prune it. If you need it later, this same function re-resolves it in five minutes.

Why job-first beats hype-driven

New models and wrappers ship daily. A reactive strategy — trying everything — is an unbounded loop with no exit condition. A job-first strategy is a clean function: input a task, output one committed tool.

When a need surfaces, I don't start from a blank search bar. I map task → category on a maintained directory — the full index lives at ailiststack.com/tools — pull three, run the test, commit. Deterministic, ~5 minutes.