How I Use AI Without Letting It Own the Product

AI is useful enough that pretending otherwise feels dishonest.

It helps me move faster. It gives me a second set of eyes when I am stuck. It can draft a component, explain an error, suggest a migration, write a test, or turn a messy thought into a first version I can react to.

But I do not want AI to own the product.

That distinction matters.

Using AI well is not the same as letting it decide what the product should become. A generated implementation can quietly pull a project in a direction I did not choose: more settings, more abstraction, more pages, more edge cases, more ceremony. None of those things are automatically bad. They become dangerous when they appear because the tool was good at producing them, not because the product needed them.

The real skill is not prompting harder.

The real skill is staying awake while the machine makes progress look cheap.

The Rule I Keep Coming Back To

Here is the rule I use:

AI can help me make the thing.
It does not get to decide what the thing is.

That sounds simple, but it changes the whole workflow.

If I ask AI to build a pricing page, I still decide the pricing model. If I ask it to write onboarding copy, I still decide what the user needs to understand first. If I ask it to refactor a component, I still decide whether the refactor is worth the risk.

The tool can produce options. I own the tradeoffs.

That is the line I do not want to blur.

Where AI Helps Me Most

AI is strongest when the destination is already clear.

If I know the route, the shape of the data, the expected behavior, and the constraints, AI can be a very good builder. It can turn a clear decision into working code faster than I would type it manually.

I use it most for:

• scaffolding a boring first version
• writing test cases after I define the expected behavior
• explaining unfamiliar errors
• comparing implementation options
• drafting documentation from working code
• finding places where a flow is unclear
• generating small utility functions
• creating content outlines I can rewrite in my own voice

The pattern is important: I try to bring the judgment first.

When I skip that step, the work gets slippery.

I ask for one component and get a mini design system. I ask for a validation function and get a new abstraction. I ask for a product page and get a landing page that sounds polished but says almost nothing true.

AI is very good at filling empty space.

That is useful when the space needs filling. It is dangerous when the space should stay empty.

Where I Do Not Let AI Lead

There are parts of product work where I want AI in the room, but not in the chair.

I do not let it lead:

• product positioning
• pricing decisions
• what data the app collects
• security and permission boundaries
• database ownership rules
• billing flows
• deletion and cancellation behavior
• claims about what the product can do
• decisions that increase maintenance cost

Those areas need context that is easy to fake in text.

An AI answer can sound confident about pricing without carrying the cost of being wrong. It can suggest a broad roadmap without living through support burden. It can add a permission because the implementation is easier, while the user sees that permission and loses trust.

That is why I treat strategic AI answers as drafts, not decisions.

The Product Brief Comes Before the Prompt

Before I ask AI to help with a feature, I try to write a short brief.

Not a long product requirements document. Just enough to keep the work pointed.

Feature:
Let users save a shortlist of SaaS tools.
 
User problem:
They are comparing options and do not want to restart from memory.
 
First useful result:
A user can save one tool and return to it later.
 
Not included:
Team sharing, tags, notes, public lists, email reminders.
 
Risk:
Adding too many collection features before knowing whether users save anything.

That kind of brief protects me from a very common AI problem: scope expansion that sounds helpful.

Without the brief, the generated answer might include tags, folders, collaboration, reminders, sorting, filters, and export. Those are all plausible features. They are also a fast way to turn a one-day test into a two-week project.

With the brief, I can ask for exactly what I need:

Build the smallest version of this feature.
Use the existing project patterns.
Do not add tags, sharing, folders, or notifications.
Keep the database shape simple.
Explain any tradeoff before adding a new abstraction.

That prompt is not magic. It is just a fence.

The fence matters.

AI Should Explain Tradeoffs, Not Hide Them

When I use AI for code, I do not only ask for the code.

I ask for the tradeoffs.

Give me two implementation options.
Tell me what each one makes easier.
Tell me what each one makes harder.
Recommend one for a small solo-maintained SaaS.

That last phrase matters: "small solo-maintained SaaS."

The best solution for a large team is often wrong for a solo builder. A large team can absorb infrastructure. A solo builder inherits every clever decision at 11:47 PM when something breaks.

I want code I can understand on a tired day.

So if AI suggests a pattern that requires too much hidden knowledge, I usually reject it even if it is technically elegant.

Elegance that I cannot maintain is debt wearing good shoes.

The Review Checklist I Use Before Shipping AI-Written Code

I do not trust generated code because it compiles.

Compiling only proves that TypeScript, JavaScript, or the framework accepted the shape of the work. It does not prove that the product behavior is right.

Before I ship AI-assisted code, I check:

• Does this match the original product brief?
• Did it add files, dependencies, or abstractions I did not ask for?
• Did it change permissions, auth, data access, or billing behavior?
• Are errors understandable to the user?
• Are loading and empty states handled?
• Is the happy path manually tested?
• Are obvious edge cases tested?
• Does the code follow the existing project style?
• Can I explain the implementation without rereading every line?

That last question is uncomfortable but useful.

If I cannot explain it, I do not own it yet.

Security Is Where I Slow Down

AI can write code quickly. Security is where I deliberately become slower.

Any time AI touches auth, database policies, secrets, payments, permissions, uploads, email sending, or user data, I stop treating the output as a convenience and start treating it as untrusted code.

That is not paranoia. It is basic engineering.

The OWASP LLM01 guidance on prompt injection is a good reminder that AI systems can be influenced by direct and indirect instructions, especially when they process external content or have access to tools. OWASP recommends safeguards like least privilege, output validation, separating untrusted content, and human approval for high-risk actions.

I apply the same spirit to my own AI-assisted workflow.

If an agent can edit files, run commands, query a database, or touch deployment settings, I want boundaries. I want to see the change. I want tests. I want the risky parts made explicit.

This is the practical version:

AI can draft the migration.
I review the schema.
AI can suggest the RLS policy.
I verify the access model.
AI can write the webhook handler.
I test the failure paths.
AI can generate permission copy.
I decide whether the permission should exist.

The point is not to be afraid of AI.

The point is to keep responsibility where it belongs.

A Small Example: The Feature That Almost Got Too Big

I once asked for help designing a simple saved-items flow.

The first version came back with a lot of good-sounding extras: labels, sorting, archived state, shareable lists, visibility settings, email reminders, and a dashboard card showing recent saves.

None of it was absurd. That was the problem.

Bad suggestions are easy to reject. Reasonable suggestions are harder because each one asks for only a little bit of extra time.

But the original question was simpler:

Will users save this thing at all?

The first version only needed:

• a save button
• a saved state
• a place to see saved items
• an unsave action

That was enough to test the behavior.

The better AI workflow was not "make the feature richer." It was:

Strip this down to the smallest version that proves whether users care.

That prompt changed the answer.

It also changed my mindset. I stopped asking AI to make the product impressive and started asking it to make the product testable.

Taste Still Matters

Taste is a quiet advantage for a solo builder.

Not fancy taste. Not expensive taste. Product taste.

Taste is knowing when a feature should be one button instead of a settings panel. Taste is knowing when copy sounds clever but not true. Taste is knowing when a dashboard needs fewer numbers. Taste is knowing when a user needs confidence more than options.

AI can imitate taste.

It cannot care about the product the way the builder does.

That sounds emotional, but it has practical consequences. The builder knows the awkward parts: the thing users misunderstood, the feature that broke twice, the page that looks fine but nobody clicks, the pricing sentence that still feels dishonest.

That context should shape decisions.

If AI suggests something that ignores that context, the answer may be well-written and still wrong.

The Prompt That Keeps Me Honest

One prompt I use often is this:

Challenge this direction.
What am I adding that does not help the user reach the first useful result?
What will increase maintenance cost?
What would you remove for version one?

This is more useful than asking:

How can I improve this?

"Improve" usually means add.

"What would you remove?" usually leads to better product thinking.

When I am building alone, removal is a superpower. Every feature I do not build is a feature I do not debug, document, support, redesign, migrate, or explain.

AI can help me see that if I ask the right question.

My Working Agreement With AI

This is the working agreement I try to follow:

That agreement keeps the relationship useful.

AI becomes a collaborator, not a hidden product manager.

The Best Use of AI Is Momentum With Judgment

I do not want to build slower just to prove I am doing everything by hand.

That would be silly.

The goal is not manual purity. The goal is better software.

AI gives me momentum. Judgment gives that momentum direction.

When both are present, the workflow feels powerful. I can move faster without abandoning my standards. I can test more ideas without turning every idea into a platform. I can get unstuck without pretending the answer is automatically correct.

When judgment disappears, AI becomes a very fast way to build the wrong thing.

That is the line.

The Takeaway

AI should make a solo developer more capable, not less responsible.

It should help with the blank page, the boring code, the second opinion, the edge case list, the test draft, the explanation, and the cleanup.

But the builder still has to choose the problem, protect the user, shape the product, read the code, reject the extra feature, and decide what matters.

That is not a burden I want to give away.

It is the work.

And honestly, it is the part that makes building feel alive.