Don't hammer a nail with a broom.

A few years ago, when a manager came to me with an idea, the first question was how long it would take to build. Today I can build almost anything in an evening, with Claude Code open on the side, and that question has almost disappeared.

Code got cheap. So did implementation: the API integration, the deployment, everything that used to be a quarter's project is now a matter of days. That didn't solve the problem. It moved it somewhere else.

Because when everything is possible, the hard part is choosing.

A broom is a great tool

A broom is a great tool. It just wasn't made for hammering nails, and if you try, it will even work a little. The nail goes in half a centimetre and you tell yourself a few more hits and it'll be fine.

That's what most stuck AI projects look like. Not a bad tool and not bad code, but a good tool for the wrong job, with just enough early progress that nobody stops to ask.

It happened to us too

I'm not writing this from the outside. On Pele's own site we built an AI agent that talked to every visitor, asked questions, diagnosed the pain and led to a meeting. We put real work into it: a persona, playbooks, objection handling. It was impressive, and for a company that sells AI it looked like the obvious choice.

The result was one lead since August and zero meetings booked through it, while it cost money every month.

The problem wasn't the agent. The problem was that the job it had to do wasn't a conversation. A busy manager arriving from an email wants one thing: to book twenty minutes in the calendar. That doesn't take an agent, it takes a page that shows open times and a button. We replaced it with a page like that in a day.

The difference between the two versions isn't technological. It's the question of what the job is.

The menu is longer than it looks

When people say “AI” today, most of them picture a chatbot or an agent. But between the problem and the agent there are steps, and each one is a different tool:

• A simple rule or automation, when every case looks the same
• Ordinary code, when there's clear logic that has to be exact
• A predictive model, when the decision leans on history and numbers
• A single call to a language model, when you need to understand free text, classify or draft
• An internal assistant, when people need answers from the organisation's own knowledge
• An agent, when there's a task with a start and an end that has to be carried out alone inside the systems

Most of the problems I see are solved in the first three steps. An agent is a powerful tool, and it's also the most expensive to build, monitor and maintain, so it has to justify itself.

Five questions before choosing a tool

• 1. What's the job, and how will we know it's done?“How many orders go in without an error”, not “improve operations”.
• 2. How often does it happen?Something that happens twice a month doesn't need a system.
• 3. What does a mistake cost, and who will catch it?An imprecise email is one thing. A wrong price on a quote is something else entirely.
• 4. Where is the data, and in what state?If it lives in three systems and one person's head, that's the first job, not the tool.
• 5. Who owns it the day after?A tool nobody in the organisation can maintain is a temporary tool.

And after all of those, one question that overrides them: what's the simplest thing that will work?

You can't ask the model for this

The model will write the code for any of these tools, and do it well. What it won't tell you is which one to build. As Shahar wrote, the model has all the knowledge and none of the hits.

That judgment is learned one way: by building things that didn't work. More than fifteen years of engineering, five of them as CTO at Abra, and most of what I know about choosing tools I learned from my own wrong choices.

That's what has really changed. Experience used to be measured by the ability to build. Today everyone can build, and experience is measured by knowing what not to build.

Before the question of which model

So the next time someone suggests “let's build an agent”, ask first what the nail is, and only then pick the hammer.

Related

• Process automationOrder entry, CRM updates, quotes and reports that someone copies by hand. We take one process that costs you hours every week and rebuild it inside the systems you already run.
• Autonomous agentsAn AI agent doesn't just answer questions. It carries out a task end to end: it reads, decides by rules we define together, acts in your systems and reports back. In a project Shahar Peer led before founding Pele, at a medical equipment company, one agent built into the existing lead process lifted lead conversion by 56%.
• Organisational enablementMost AI projects don't fail because of the technology. They fail because nobody owns the process, the data isn't ready and nobody was trained to carry on. Organisational enablement is the work that makes it hold after we leave.