Everyone uses AI now, and most people use it badly. They paste a vague prompt, accept the first output and ship something that reads as generated, because it was.
I’ve used AI every day for over a year. I used it to ship atlas.core, a web and iOS SaaS, on my own. I use it for outbound messaging, CRM setup, content and code. This post is how I use it without losing the part of the work that is mine.
The autocomplete habit
The default way people use AI goes like this. Have a vague idea, ask the AI to do it, accept the output, ship it.
That works for trivial tasks and fails for anything that matters. The output is generic because the input was generic. The model doesn’t know your constraints, your audience or your standards, and it optimizes for the most plausible answer, which is usually the average one.
So we get a flood of competent, forgettable content, code that runs without having been designed, and products that look assembled from templates.
AI doesn’t have taste. You do. The moment you hand over the judgment call, you lose the thing that makes your work different.
What I do instead
Breaking the work into parts
I don’t ask the AI to write the thing. I ask it to help me split the thing into pieces.
When I built role-based access for atlas.core, I didn’t prompt “write a role-based access control system in React with Supabase.” That gives you something generic that you spend days debugging. I asked smaller questions:
- What are the standard patterns for RBAC in a SaaS on Supabase row level security?
- Given these five roles, what’s the permission matrix for these twelve actions?
- What edge cases appear when a user’s role changes while they have an active session?
- Show me the RLS policy for “trainers can read their assigned clients’ data and nobody else’s.”
Each prompt is specific and each answer can be checked. I’m still deciding the architecture. The AI speeds up each piece.
Attacking my own work
After I write something, whether code, copy or a strategy doc, I ask the AI to find what’s wrong with it. I never ask whether it’s good.
- What are the three biggest weaknesses in this cold email sequence?
- Where does this database schema break at 10,000 users?
- A skeptical CTO is reading this proposal. What do they push back on?
This is the most useful thing I do with AI. People are bad at critiquing their own work because we’re anchored to the decisions we already made. The model has no stake in my decisions, so it finds the holes if I ask it to look.
Listing options
AI is very good at listing possibilities and mediocre at choosing between them. I use it for the first part and keep the second.
I’ll ask for 20 subject lines for a cold email, then pick the two that sound like me. I’ll ask for every state a subscription can be in, then decide which ones need a screen and which I handle quietly. I’ll ask for ten ways to structure a landing page section, then choose the one that fits the story. The choosing is where taste lives.
What I hand over completely
Some tasks are pure execution with a clear pass or fail, and I let the AI own them.
- Boilerplate. A new React component, a Supabase migration, a test fixture. Clear input, clear output.
- Format conversion. A JSON schema into TypeScript types, a design spec into Tailwind classes, English copy into Portuguese.
- Research summaries. “Summarize the differences between RevenueCat and Adapty for mobile subscription billing” beats reading ten docs myself.
- Debugging. Here’s the error, here’s the code, here’s what I expected. The model is good at matching that against known failure patterns.
What these share is that I can check the result right away. The boilerplate compiles or it doesn’t, the types match or they don’t, the translation reads right or it doesn’t. No judgment is needed, only verification.
What I never hand over
- Voice. A model can write in any voice, which means it has none. If your outbound emails read like everyone else’s, you’ve optimized yourself out of the inbox.
- Architecture. Ask “microservices or a monolith?” and you get a balanced answer. You need a decision with trade-offs you’ve committed to, and that’s on you.
- Prioritization. “What should we build next?” The model doesn’t know your runway, your team’s energy, your competitor’s roadmap or what your three biggest customers said last week.
- Hiring. AI can screen resumes. It can’t judge whether someone is coachable or whether they’ll care about the work.
The checklist I run
Every time I reach for AI, I run the same short checklist.
- State the task in one sentence. If I can’t, I’m not ready to use AI yet and need to think first.
- Decide whether it’s execution or judgment. Execution goes to the AI, and I verify. Judgment stays with me, and the AI helps me split the problem and attack my draft.
- Be specific. “Write me a landing page” is a bad prompt. “Write the hero section for a B2B SaaS selling to Series A CTOs who need to scale engineering. Direct tone, no buzzwords, under 40 words” is a usable one.
- Attack the output before accepting it. Better still, critique it myself first and then ask what I missed.
- Own the result. If I ship it, it’s mine. “The AI wrote it” has never been an excuse for bad work.
Where this leaves you
AI makes you faster at whatever you already are. If you have clear thinking and high standards, you decompose faster, see more options, catch more edge cases and ship sooner, at the same quality bar. If you have vague thinking and low standards, you ship more mediocre work, faster, which is worse than shipping less of it.
The people who get the most out of these tools know when to use them and when to sit and think. That’s taste, and nobody has automated taste.