Let me start with the confession, because it is the reason I can write the rest of this without sounding superior.

Earlier this year I lost a deal I should have won. The client had come in through the website, the use case was one I had wanted for a long time, and I was excited. I let the AI tool I use every day draft the proposal, and I let it set the price. It set the price high. Very high. I was going back and forth with it, and I told myself I was checking the work, but when I looked back at the thread afterward I saw that I had been copying and pasting more than I had been thinking. The proposal was long, it explained everything, and it talked the client out of the deal.

You have to stop Claude sometimes. You have to check it with real world expectations, scenarios, things like that. And with this one, I did not.

I have built AI systems for three and a half years and did IT and security for 25 before that. If it can happen to me, it can happen to the bright 26-year-old your friend recommended, and it will not look like a mistake from the outside. It will look like a lot of very confident work.

What it looks like from the client's chair

In August I audited a project for a compliance firm. The developer had produced a document titled, roughly, "the engine." Seven components. Four marked "fully built." A roadmap. Friendly reminders at the bottom. A command center dashboard. Landing pages with a quoting flow. It was, as a document, excellent.

Reading it with the owner on screen share, I could see exactly what had happened, because I had done it myself six months earlier.

"I can see through everything that he's done that he's letting Claude guide him, but it's guiding him into a place he doesn't know where he needs to go. So he's just saying, 'Yeah, what should I say next?' And he's just literally copying and pasting whatever it's saying."

What I told the owner

The tool had proposed a seven-part architecture because seven-part architectures are what the tool has read the most of. The developer built the parts that were easiest to build and marked the rest as planned. The owner, who had asked for one thing, a way to send a campaign and measure it, was looking at seven things and none of them was that.

Five tells

1. The plan is bigger than the ask. You asked for one workflow. You received an architecture. When the scope grows in directions you did not request, the agenda is being set by something other than your business.

2. The writing is long, polished, and hard to act on. A person who understands your business writes you three sentences. A person being steered sends you twelve pages, because the tool produced twelve pages and every one of them sounded right.

3. "Fully built" means "described." Ask to use it. Not see it. Use it, on your own login, doing the thing it says it does. The tools are extremely good at producing the description of a finished component. They are much worse at producing the component.

4. They cannot explain it in plain words. Where does it run? What does it do at night? What happens if I change my GoDaddy password? A person who is steering has the model in their head and can answer in a sentence. A person being steered has to go ask.

5. Your one pain point is still open. This is the tell that matters. Everything else can be forgiven if the reason you called has been solved. If it has not, the work, however impressive, was not for you.

This is not an argument against the tools

I use these tools all day. I have written a month of content for a client in four hours with them. I have built a reconciliation engine for a 49-store retailer that is on its 49th release. The tools are the reason a firm with one principal can deliver what used to take a team. The vibe coder era is real and I am glad to be in it.

The difference between a developer who steers and one who is steered is not the tool. It is whether there is something in the person that can say no to it. Twenty-six years of running businesses, of watching what customers actually respond to, of knowing that a proposal can be too long: that is what says no. It is also what tells you, before the tool does, that the client wanted one thing and you are building seven.

"It's the years of experience that make the difference. The tools alone are not it. If you want to put out this fire, we need to grab some water, not the kerosene. Because the kerosene, even though it looks good and smells good, is going to make the fire worse."

To the owner, on the discovery call

What to do if you recognize your project

First, do not assume bad faith. In August the owner said three times that the developer had done nothing wrong, and I agreed. I liked him. By the end of the handoff call we had booked coffee to talk about working together. Being steered by the tool is a leadership gap, not a character flaw, and the right response is leadership.

Second, ask the five questions above on your next call and write the answers down. If the answers are short and specific, you are probably fine, and you should hold the next payment to something you can log in to.

Third, if the answers are long, or the plan keeps growing, or the pain point is still open, get someone who can read the repository to look at it before the next invoice. That is an audit, it takes five business days, and it ends with a written list to hold the developer to, or a recommendation to move on. Either way you stop paying for someone else's learning curve.

I paid for mine with a lost deal. It was a cheap lesson compared to what some owners pay. The 25-point checklist is the shortest version of what I learned.