AI vibe coders all have the same thing to say.

What I find ground breaking is what this points to as a blind spot.

Getting good results has always been about knowing what you want to be building. If you don’t know what you should build, stop. Really, stop right now and figure it out.

This is even more important when dealing with people than AI.

If you think giving a vague outline to people and expecting greatness is the solution then. I have bad news for you.

If you’ve been giving vague direction and getting greatness, you’ve been lucky or have hired people who are probably on the way out the door.

Signs your team doesn’t know what to build

It’s easy to overlook if you are not in the moment. If your team are asking too many, or too basic of questions, they are confused. If your team are not asking questions, they are going in the wrong direction. You want the right level of engagement.

When the team ships work that surprises you, there's a definition problem. Output is great, but if it's not what you asked for, it's pure waste.

If you've had high variability in your task estimates, you have high variability in your problem understanding.

If you regularly need to “course correct”, it's because you haven't correctly set the course.

A CLEAR definition of of the problem

Problem statements should be CLEAR.

• Context: why are we doing this?
• Logic: what are the core constraints or principles?
• End state: what does success look like?
• Assets: what input, tools, or data is needed?
• Roles: who owns what?

Every piece of work should have these elements.

Test for understanding

You’ve realized a problem exists, you’ve outlined the clear definition, and shared it with the team. How do you know it stuck?

First, ask then to replay what you told them. Ask them to tell you what they took from the exchange and test it against your expectations.

Next, have them describe what done looks like. Of they can’t visualize the end, they will have trouble figuring out the path.

Last, test with micro-scenarios. Ask them how they would respond to cases where problems might come up. Probe for alignment with intent, not just the ability to execute.

Fixing it

Write it down. That’s so important, I’m going to repeat it. Write it down. Really, this is the number one way to kill ambiguity.

Define the problem before the solution. In your document, as the very first line or paragraph, have the problem statement.

While you’re doing this, model good questions. Ask, “What would this look like if there are problems?” Or, “What’s out of scope?”

Work for you

If your team can’t explain what they’re building in one or two sentences, the problem might not be them—it might be your clarity.

This week, pick one project.

Ask three people on the team: “What are we building, and why does it matter?”

If the answers diverge, you’ve found your next blind spot opportunity.