"Knowing when to stop is as important as knowing how to start."
The Myth of the Infinite Tool
After using AI well for a few weeks, there's a temptation to expand the scope.
It worked for competitive research — can it replace the analyst? It worked for meeting summaries — can it handle the sensitive conversation? It worked for the internal dashboard — can it build the customer portal?
Sometimes yes. Often no. And misreading the boundary costs time, trust, and occasionally real damage.
This chapter covers the limits of each category, and the signals that tell you when to stop.
The Building Tools: When to Stop and Call a Developer
The output needs to be reliable for people other than you
Your personal weekly summary can break occasionally. You'll notice and fix it. A tool your sales team depends on for their daily workflow cannot afford to break silently and go unnoticed for three days.
AI builders are optimized for personal, high-context use. When other people depend on the output, you need error handling, monitoring, testing, and on-call ownership that AI-built tools don't have by default.
The project requires more than one session to define
If you sit down to brief an AI builder and realize you don't know what the inputs are, what the outputs should look like, or what the edge cases are — the project isn't ready. This is true for any project, but for larger ones it means you need a proper spec, a proper team, and a proper process.
One useful test: can you fill out the project brief template in 15 minutes? If the answer takes an hour and still has open questions, the project is bigger than AI building.
You're touching customer data, payments, or authentication
No exceptions. Systems that handle:
- Customer PII (names, emails, addresses at scale)
- Payment processing
- Authentication and access control
- HIPAA, GDPR, or other compliance-governed data
...require professional engineering, security review, and ongoing maintenance. The cost of getting these wrong is not a failed script. It's a breach, a fine, or a lawsuit.
An AI builder can help you prototype what you want so you can brief a developer precisely. It should not build the final system.
You need integration into your production systems
Connecting to live production databases, making writes to your CRM, touching your billing system — these are not places for experimentation. The cost of a bug is production data corruption, not a broken CSV on your desktop.
AI builders are appropriate for read-only connections to production data in controlled circumstances. Write access to production systems belongs to your engineering team.
You've had the same build fail three times
If an AI builder has attempted the same problem three times and can't produce something that works, the problem has hidden complexity you haven't surfaced. Stop, brief a developer, and let them tell you why it's hard. You'll learn more in that conversation than in a fourth attempt.
What to hand off, and how
When you hit one of these signals, you have more than you started with:
- A working prototype (even if rough) that shows what you actually want
- A project brief you've already written
- Clarity on the edge cases (from the sessions that showed you what broke)
- Specific questions you now know to ask
Hand that to your developer. A one-hour AI prototype is a better brief than a one-hour requirements meeting. They'll know exactly what you mean and exactly what the edge cases are.
The Research Tools: When to Stop and Call a Human
The question requires proprietary data
Perplexity and deep research search the public internet. They don't have access to Bloomberg terminals, legal case databases, specialized industry databases behind paywalls, or anything that hasn't been published.
If your competitive question depends on data your competitors have filed only with regulators, or lives in a database your firm subscribes to, AI research won't find it.
The stakes require primary sources
AI research summarizes what other people have written. For high-stakes decisions — an acquisition, a significant regulatory exposure, a legal position — you need the primary sources themselves, reviewed by people qualified to interpret them.
Use AI research to get oriented and to prepare the questions. Use lawyers, accountants, and domain experts to give you the answer that matters.
The question is about your own organization
No AI research tool knows what your sales team knows about a specific client, what happened in the conversation three years ago that shaped the relationship, or why the previous attempt at this market failed. Internal knowledge lives in people, not in public data.
The Writing Tools: When to Stop and Write Yourself
This was covered in the Writing chapter, but the core rule:
If the relationship is the product, write it yourself.
A personal note to someone going through a crisis. A message to your team after a difficult decision. A letter to a co-founder. An honest reference for someone you know well. These carry weight because they're unambiguously from you. An AI draft, even a good one, carries none of that weight — and the recipient often knows.
If you haven't finished thinking, don't start drafting.
The temptation: use AI to figure out what you think by having it write something and then reacting to it. The problem: you end up reacting to the AI's framing rather than developing your own. Use writing to think, not to skip the thinking.
The Meeting Tools: When to Turn Them Off
Off-the-record conversations
Some conversations — negotiations in early stages, honest performance feedback, sensitive interpersonal discussions — are better without a transcript. The presence of a record changes what people say. Trust your judgment about which conversations need that space.
Contexts where you haven't disclosed it
If participants don't know a recording tool is running, turn it off. This is both a legal requirement in many jurisdictions and a basic standard of integrity.
The Table
| Use AI | Don't use AI |
|---|---|
| Personal research and synthesis | Questions requiring proprietary or restricted data |
| First drafts of structured documents | Communications where your voice is the relationship |
| Building tools for your own use | Building systems others depend on |
| Capturing recurring meeting action items | Off-the-record or sensitive conversations |
| Prototyping before briefing your team | Replacing the team's judgment on complex problems |
| Read-only analysis of your data | Write access to production systems |
| Accelerating work you understand | Making decisions you haven't thought through |
The Right Relationship
AI tools and your team are not competing for the same work.
The executive who uses AI for the right problems — and hands off the right problems to the right people — gets better at both. They research faster, brief more precisely, write more efficiently. Their team gets better briefs, less noise, and more time for the work that requires human judgment.
The executive who tries to use AI for everything either produces unreliable outputs or burns out on problems that were never in the tools' wheelhouse.
Know the tools. Know their limits. Use them for what they're for.
That's the complete guide. Start from the beginning or read The Shopkeeper's Terminal.