An AI Cofounder That Coaches Instead of Doing the Work

The first design decision was what it would refuse to do.

Make First has an AI cofounder. It’s in private beta, and everyone who hears about it asks the same question: so the AI builds the business for the kid? No. It never writes the product. It never writes the posts. That constraint came before any feature, and it’s the one I’d defend against any amount of user demand.

This post is the reasoning, and what it taught me about shipping any AI product.

Why the constraint comes first

If the cofounder writes the product, the student learns to prompt. That’s a real skill, but it’s not the one the program exists to teach, and it doesn’t survive contact with the gates. Every stage of Make First ends at a First with evidence: a URL a stranger can use, a stranger’s name, a payment record. If the AI produced the build, the evidence is real and the learning is fake. The student passed a gate they can’t pass again without the AI.

So the rule is simple. The student does the work. The cofounder makes sure the work is real.

That inverts what most people expect an AI product to be. Most AI products are judged by how much they do for you. This one is judged by how much it gets you to do, and how honestly.

What it does instead

Three verbs, in the order a stuck teenager needs them.

It checks. The cofounder is stage-aware: it knows which gate the student is trying to pass and what evidence that gate requires. When a student says they’ve launched, it asks for the URL. When they say they have a user, it asks who. It’s the least popular thing it does and the most important.

It coaches. Questions before answers. A student who says “I don’t know what to build” doesn’t get a list of ideas; they get asked what annoys them, what they’ve noticed their friends complain about, what they’d fix if they could. The idea has to be theirs, because the gate evidence for First Idea is a problem and a person, and you can’t borrow those.

It unblocks. When a student is genuinely stuck, the cofounder’s job is the next smallest step, not the whole path. “Show it to one person today” beats a growth strategy. Paul Graham’s advice to do things that don’t scale is built into the design: the unblock is almost always “go talk to a human.”

How it says no to a fifteen-year-old

This was the hard product problem, and I don’t think it’s fully solved.

A refusal that just says “I can’t do that” is useless and, to a teenager, insulting. The cofounder has to refuse in a way that moves the student forward. The pattern I designed to:

1. Name what it won’t do, once, plainly. “I won’t write this for you.”
2. Say why, in terms of the gate. “If I write it, you can’t pass Make on your own next time, and the next gate needs you to.”
3. Offer the next smallest step. “Tell me what you’ve tried, and I’ll tell you what I’d try next.”
4. Point to the lesson. The Academy exists so the cofounder can send a student to a lesson instead of substituting for it.
5. Escalate to a human when it should. The program has weekly office hours with me. The cofounder’s job is to get a student to the point where that conversation is worth having, and to hand off rather than loop.

Whether that pattern holds up across a whole cohort is exactly what a private beta is for.

Why not just let it write the first draft?

This is the objection I get from adults, and it’s a fair one, because it’s how I work. In the studio, agents draft almost everything and I sign it. Why hold a teenager to a stricter standard than I hold myself?

Because I’ve already passed the gates. When an agent drafts a page for this site, I know what a good one looks like, I know which claims I’m allowed to make, and I can tell in thirty seconds whether the draft is right. That judgment is the thing a first-time founder doesn’t have yet, and it’s the thing the program exists to build. Letting the cofounder draft would skip the part where the student learns what a good draft is.

There’s a version of this that applies at every age. The first time you do anything, you should do it yourself, badly, so you know what the tool is doing when you hand it over. The tenth time, delegate. Make First is built for the first time.

What a session looks like

An illustration, not a transcript, of the pattern in the Launch stage:

A student says they’re ready to move on because the app is finished. The cofounder asks for the URL and gets one. It asks who has used it. The answer is “my brother.” It says that’s a start and doesn’t count, because the gate needs someone unrelated, and asks who the student has in mind. The student doesn’t know. The cofounder doesn’t write an outreach message. It asks where the kind of person with this problem spends time, gets an answer, and proposes the smallest step: show it to one person there today, and come back with their name. Then it points at the Academy lesson on finding a first user, in case the student wants more than one step.

Ten minutes. No output the student didn’t produce. One name by tomorrow, or a real conversation about why not.

What I’m willing to say about how it’s built

I’m going to say less here than a technical reader wants, because the program is in beta and because the interesting decisions aren’t architectural.

The principles are the ones in Anthropic’s Building effective agents: “finding the simplest solution possible, and only increasing complexity when needed,” with humans at checkpoints. The cofounder is closer to a well-constrained workflow than to an autonomous agent, on purpose. It doesn’t roam. It knows what stage the student is in, what the gate requires, and what it must not do, and it stays inside that.

The refusal list was written before the first prompt. So was the escalation path. Everything else has changed at least once.

Parents are the account holders. These are minors, and the program is built around that from the first screen rather than patched for it later.

The lesson for anyone shipping an AI product

I didn’t expect the Make First cofounder to change how I build the studio’s other agents. It did.

Decide what the model must not do before you decide what it does. Every agent I run now has a refusal list written before its first task. For the cofounder it’s “don’t write the product.” For the agents that build this site, it’s “don’t make a claim that isn’t in the spec,” enforced by a build guard I’ve written about before. The list is the product. The capabilities are the easy part.

Make the refusal useful. A model that says no and stops is a bug. A model that says no and offers the next step is a coach. That’s true whether the user is fifteen or fifty.

Keep humans at the checkpoints. The cofounder hands off to office hours. The site’s agents hand off to a pull request I read. The pattern is the same: the agent does the work between the checkpoints, and a person decides at each one whether it’s real.

Judge it by what the user did, not by what it did. The cofounder succeeds when a student passes a gate on their own. Most AI products are measured the other way around, and I think that’s why so many of them make their users worse at the thing.

If you have a teenager

The cofounder won’t build your kid’s business. That’s the point. It will check whether the business is real, ask the questions a good mentor asks, and get out of the way.

The founding cohort is at makefirst.ai, with the six stages and six Firsts laid out. If your teenager reads them and wants to start at Spark, the cofounder will be waiting at the first gate, asking what problem they’ve noticed.

---

This is the seventh post in the Studio of One series. Previous: How I Choose What to Build Alone, and What I Kill. The gates themselves are in The Firsts.