Building with AI: which calls can't be delegated?

Trying to be an indie developer now, I rely on AI tools at almost every step.

Discussing requirements, breaking down features, PRDs, interaction design, technical design, writing code, review — a lot of this work isn’t me thinking it all through first and then handing it to AI to execute, but something we complete together through repeated conversation.

It really does let me do things one person could hardly do before.

But the deeper the collaboration, the more often I run into a question:

which things can I just let AI do, and which judgments must the PM still make?

If the PM has to think everything through first, with AI only organizing and rewriting, the value it can provide is very limited.

But if you let AI break down requirements, set the scope and fill in rules, then pick a reasonable-looking option from the results, the PM can easily become the person who just signs off at the end.

So what really needs distinguishing isn’t:

• which documents the PM wrote;
• which documents AI wrote.

It’s:

whether a piece of work is organizing and exploring, or deciding on the product’s behalf.

AI can do a lot, but “generating” isn’t “deciding”

A product document usually mixes several different kinds of work:

• organizing known information;
• filling in what might be missing;
• proposing different options;
• choosing between options;
• settling how the product will ultimately behave.

The first few are well suited to AI.

It can quickly organize discussions, break down flows, list edge cases, point out contradictions and propose several different phasing plans.

But when it comes to trade-offs and final confirmation, the responsibility is different.

AI can make suggestions, but it doesn’t really bear the results. If the product gets too complex, development has to be redone, or users run into problems, in the end it’s a person who has to explain why it was decided this way.

So these days I’d rather understand the division of labor as:

AI widens the options and fills in detail; the PM converges, makes trade-offs and confirms.

What problem the product solves can’t be defined directly by AI

AI is very good at turning a fuzzy idea into a complete problem statement.

It can quickly generate target users, use cases, pain points and product value, and they usually read as very reasonable.

But reasonable isn’t the same as real.

Sometimes AI has just packaged an idea, based on existing material, into a complete product opportunity. Whether the problem really exists, whether it matters enough, whether users are willing to change their current behavior — it doesn’t know.

This part can certainly be discussed with AI.

It can challenge the problem definition, offer other explanations, and help me notice if I’ve jumped to a solution too early.

But in the end I still need to judge:

• what I really want to solve;
• whether this is the users’ problem or one I imagine;
• whether I’m doing it now because it matters, or because it’s easy to turn into a feature;
• whether the product addresses the root cause, or just adds a layer of AI on top of an existing flow.

AI can help me think the problem through, but just because it has written a complete problem definition doesn’t mean the thing has been validated.

AI can break down the scope, but the PM has to confirm the boundaries

Scope and phasing don’t necessarily have to be done by the PM alone.

Often I only have a general direction and don’t know how far each phase should go.

Having AI propose a few ways to split it, then comparing dependencies, effort and risk, is usually more effective than starting from a blank page myself.

But AI’s breakdowns tend to aim at making the plan look complete.

It may add more features, states and error handling along the way, because from a document’s point of view, all of that is reasonable.

The thing is, scope was never just “a complete list of what needs doing,” but deciding, with limited resources:

• what exactly this phase is meant to validate;
• which experiences can be acceptably incomplete for now;
• which users and situations won’t be covered this time;
• which risks must be solved now;
• which problems can be explicitly left for later.

AI can propose a scope, but where to stop and why to stop there still needs the PM’s confirmation.

Especially in indie development, the hardest part usually isn’t finding more things to do, but having good reasons not to do them.

Product rules mustn’t be decided by default while “completing the flow”

Much of what really shapes product behavior doesn’t appear in the product goals, but forms gradually in the flows and details.

For example:

• under what conditions it moves to the next state;
• who may perform a certain operation;
• when the user needs to confirm;
• how uncertain AI output is handled;
• which rule wins when two conflict;
• whether the system continues or stops when data is missing or a service fails.

These are well suited to having AI help flesh out.

It often finds edge cases the PM didn’t think of, and fills in more complete states and failure paths.

But the risk is that, to make the flow complete, AI naturally fills the blanks with answers.

If the PM doesn’t realize it’s a new rule, it may go straight from “what AI guessed from context” into the PRD, and end up as product behavior in the implementation.

So when reading flows AI has generated, I need to tell apart:

• which parts are fleshing out rules already confirmed;
• which are reminding me of questions I haven’t thought through;
• which are decisions AI made up itself to finish the document.

AI can enumerate risks, but a person has to decide which risks to accept

AI can list many potential risks.

But different products tolerate risk to different degrees.

For example:

• whether a result can be executed automatically, or only offered as a suggestion;
• whether users must confirm before an operation;
• whether mistakes can be undone;
• whether the system should continue the task or stop when it’s uncertain;
• how much misjudgment is acceptable for the sake of efficiency.

These questions usually have no purely correct answer.

Behind them is what the product is willing to sacrifice and what it wants to protect.

AI can help analyze pros and cons and remind me of what I’ve missed, but the final risk boundary can’t be chosen by it by default.

A PM doesn’t need to think everything through before using AI

Stressing that these judgments can’t be outsourced doesn’t mean the PM has to have every answer ready before AI starts work.

In fact, many judgments form gradually during the collaboration.

Only when AI proposes several scopes might I realize what I really want to validate.

Only when it fills in an automated flow might I notice that one step must keep human confirmation.

Only when it lists the edge cases do I discover the original design had no recovery path at all.

That’s where AI is truly valuable.

So I don’t think a sensible division of labor is:

• the PM finishes the thinking alone first;
• then AI handles execution.

A more realistic way is:

• the PM provides goals, facts and constraints;
• AI helps explore options, fill in details and find omissions;
• the PM confirms the key trade-offs;
• AI then continues to flesh things out based on the confirmed decisions.

Product judgment can form through the interaction between people and AI.

But at the end of a round of discussion, the PM should at least know:

• what was finally decided;
• why it was decided this way;
• what is still only an assumption;
• what is only AI’s suggestion;
• which outcomes they’ll have to own.

What really can’t be handed to AI is the default power to decide

I won’t insist on writing everything myself first just to prove I’m still doing the PM’s job.

The organizing, breaking down and fleshing out that AI does better, I’ll hand straight to it.

But direction, priorities, boundaries, rules and risk shouldn’t become product decisions without confirmation just because AI gave a complete answer.

AI can take part in the thinking, and can influence the judgment.

But in the end someone has to say clearly:

I understand this decision, and I accept its consequences.