Full Tutorial: A Proven 3-File System to Vibe Code Production Apps | Ryan Carson - podcast episode cover

Full Tutorial: A Proven 3-File System to Vibe Code Production Apps | Ryan Carson

Oct 05, 202552 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Summary

This episode features serial founder Ryan Carson, who shares his innovative 3-file system for coding production apps with AI without frustration. He provides a live demo, showing how to leverage AI to create a detailed Product Requirement Document (PRD), generate atomic development tasks, and build automated tests for each. The discussion also delves into the strategic advantage of one-person AI companies, focusing on solving specific, high-pain "pain pill" problems, exemplified by his new venture, Untangle, an app for divorce assistance. Ryan highlights the unparalleled control and efficiency available to solo founders utilizing AI agents.

Episode description

Today, I want to share a new episode with Ryan Carson.Ryan is a serial founder who has developed an amazing 3-file system to vibe code without frustration that has 5,000+ stars on Github. In our interview, he demoed adding a new feature to his production app by using AI to create a spec, generate atomic tasks, and build automated tests for each task.


Ryan and I talked about:


(00:00) Why his 3-file AI coding workflow works so well

(03:22) Explaining each file: PRD, atomic tasks, test-driven development

(08:02) Live demo: Building a new feature from scratch

(22:32) How to practice test-driven development to avoid bugs

(34:18) How to get AI to be your tutor to become more technical

(42:03) Pain pills vs vitamins: Why divorce is a great AI business

(45:23) How to start a one-person company with AI's help


Get the takeaways: https://creatoreconomy.so/p/full-tutorial-a-proven-3-file-system-to-vibe-code-production-apps-ryan


Where to find Ryan:


X: https://x.com/ryancarson

Website: https://www.ryancarson.com/


📌 Subscribe to this channel – more interviews coming soon!

Transcript

Why his 3-file AI coding workflow works so well

Imagine that you had a very smart engineer show up on your doorstep. They have no context, no background. You wouldn't just tell a random new employee, make me a game that's super fun to play. And then... and expect them to succeed. This isn't rocket science, but I think the reason why this GitHub repo has like 4,000 stars is because folks do want a process to follow to give them better results.

I wouldn't want the AI to run off and create 30 tasks. I would want it to create a high level, you know, give me five tasks and then I want to approve those. Let's talk about your three-part system and also how is it different from a typical Vibe code. So I'm going to walk you through a little bit how it works. Okay, welcome everyone. My guest today is Ryan. Ryan is a serial founder.

who's building his next startup solo by talking to AI for a few hours every night. And Ryan has an awesome three-part system for coding with AI that I'm really excited again to demo. And we'll also talk about, you know, what it's like. building an AI startup as a solo founder. Welcome, Ryan. Awesome.

it's so fun to be here i like the description of coding for hours at night that feels like it's everybody so that's me looking forward to chatting and sharing some stuff i've learned yeah i don't know if you're a parent but like you know yeah i only have time to call tonight exactly yeah so the best time is either late at night or in the morning uh but as you know the problem is

If you're going to like one and then it gets to be two, then you're like, oh man, I'm going to pay for this tomorrow. So you have to cut it off at a certain point. Yeah. let's get right into it let's talk about your uh three-part system uh and maybe you can share what it's like and also how is it different from like typical vibe coding

Yeah, sure. So let me give people some context so they understand a little bit more about how I got here and kind of my skill set. So graduated from Colorado State, computer science degree in hand. Got my first job as a web developer. So I learned mostly reading O'Reilly books. So there's probably some fans out there that love O'Reilly. And I read PHP cookbooks and started building.

So then fast forward, I thought, okay, what's a problem that I care about? And I realized you need to send large files that you couldn't email. So I basically built Dropbox. It was called Drop Send. Built it myself. We racked our own servers. And that was acquired, I think, after two years. So that was kind of my first startup when...

It was really solo founded. It was a B2C product, but it was exciting. And then I realized, you know what? I really want to scale this and empower more people. So we built an online school teaching code.

Right. So that's where Treehouse was born. You ended up raising VC, you know, scaling this team to over a hundred people. And we ended up teaching about a million people how to code. So then I was just coding, coding, coding for hours and hours and hours at night. And my wife is like, you know, please. like come to bed at some point. So if I share my screen, I can show you what is this that we're talking about. Okay. So let me show you the actual GitHub repo. It's open source. So please use it.

and i'll walk you through the three files as we go here it is so we basically have three files so a create prd file we have a generate tasks file and then we have a process

Explaining each file: PRD, atomic tasks, test-driven development

task list file. And these are just prompts, right? So I'm going to show you the first one that you would use. Now, let me explain how you would use this really quick. So what is probably going to happen is you'll be using your agent. and you'll have an idea for a feature that you want to use. And then you'll talk about that feature and then you'll tag this file. So I'm actually going to show it to you and then I'll probably go over to an agent and show you how it might work.

So if we read through a little bit, the goal is to guide an AI assistant in creating a detailed PRD in Markdown. And the process is pretty simple, right? So it's a four-step process. The AI will receive the initial prompt. The agent will then ask clarifying questions. And then it will generate the PRD. And then it will save the PRD as a markdown file.

We gave it some example clarifying questions it might ask about the problem of the goal, the target user, et cetera. And then we talked a little bit about the PRD structure. the target audience and the output so yeah the clarifying questions is like pretty important because i i become so lazy like prompting ai i just go hey go build this like you know movie app for me or go build that this is forcing me to actually provide some more details

Yeah. Well, because one thing I like to say to everybody is that imagine that you had a very smart engineer show up on your doorstep, right? They have no context. you know they have no background and you wouldn't just tell you know a random new employee you know uh make me a a game that's super fun to play and then and expect them to succeed. Or they say, OK, I need to know more. So let's actually show you this in action. Let me switch over to Ghosty.

Okay, so I'm going to take you over to my terminal to actually show you this in action. I'm a big fan of Ghosty. So if you're on a Mac and you have to use a terminal, I would totally recommend Ghosty. It's amazing. And then I use Tmux as my pain management. Again, you might be using an IDE, which is absolutely fine. but I've kind of fallen in love with this kind of bare metal approach. So on the right, I have one pane, which I'm going to run amp in. So we're going to go ahead.

One second. And again, my HHKB keyboard is getting me right now. So we're going to do AMP. And we're going to run it with a special feature called TUI. It's a beta feature, which is kind of cool. Then on the left, we're going to run NeoVim. Let's start that up. Let's go ahead and show you.

On our left, we've got our project. And I'm actually going to be using the actual repo from my startup. It's called Untangle. It's a Next.js app. It's about 100,000 lines of tight strips. So it's a pretty decent repo. um and then on the right we've obviously got amp which is my agent of choice running on the command line so let's go ahead and think about a feature that we want to ship so

Now, Untangle is basically an app to help people through divorce. And the reason why is it's a real world problem that people have. Thankfully, I'm happily married. I've been married to my amazing wife for 21 years. But I have three sisters and we're best friends. And about...

Two, three years ago, unfortunately, my older sister went through a divorce and it was pretty rough and it was expensive and hard. And then unfortunately, a little bit later, my younger sister went through a divorce and I just watched how hard it was. And I thought, you know what? I feel like...

Helping people through that process, getting them through filling out all the forms, layering on a really smart large language model on top will save them a lot of lawyer fees, a lot of pain. It's not a lawyer. um but it it does a lot of things that should save you money so that's the context so i think what we're going to do is add a little feature um when

the user is onboarded to try to get a feel for, you know, what's their relationship like with their partner. So what I'm gonna do is go in here and I'm also a big fan of Whisperflow. So I talk most of my prompts. Me too, yeah. So I'm going to do that. Okay, so I want to build a feature that's going to help us understand.

Live demo: Building a new feature from scratch

the way that the user is relating to their current partner. We want to try to figure out, are they on good terms? Are they not on good terms? Are they speaking? You know, what's that relationship like? And we'd like to score it from one. to 10, one being it's terrible and 10 being that they're on good terms. Okay, so that is the feature of my sort of blah. Now what we're going to do is tag.

uh the um the prd so let's see if i can remember what it's called create prd all right so we're going to tag that and we're going to let it run and rock and roll And that's basically like a slash command, right, that you created? No, that is literally just tagging the file to put it in context. Okay. So it's very simple, right?

This is kind of why I built these as markdown prompts, that you're really kind of tagging in a prompt. So what we're seeing is some of the reasoning tokens, and then now we're getting back an answer. I'm going to keep this kind of light. Normally I would go through and respond to all these, but I'm actually just to speed this up. I'm going to say, why don't you pick what you think is best for all these things?

Okay. So AMP is going to run off and pick what it thinks is best of that, and then it will generate the PRD. So what's kind of happening here is this guided process. Do you need to do something like this when you're just shipping a quick fix? Of course not. Right. But this is a really helpful way to get through. All right. I need a pretty chunky feature written. I want to plan. I want to get through it.

and then uh i want to ship it so right now it's gonna it's gonna think about that and are you using like a sonnet or yeah so one of the interesting things about amp uh that actually i didn't like at first um is there's no model selector um and i remember when i first tried i'm like wait a minute like what model am i using and how is this working and also where the uh accept or eject

diffs right and what i learned is that amp is super opinionated about choosing a certain model that's been highly optimized for the agent harness Right. Because everyone who's building with models knows like every model is wildly different. Right. And you can't really hot swap models. Like it just doesn't work.

And so the team at AMP decided to go with Sonnet 4 as the primary driver for the main agent. And then in a minute, I'm going to show you this kind of a cool feature where you can ask the Oracle to help. And what that does is that's a tool call out to 03. And then you get a bit more reasoning. It's a little slower, but you get more thoughtful. And I tend to think of that as like, I want to go ask my senior engineer a question.

and then get their input on that we also use um gemini flash for some summarization tasks so all right so let's head back over here okay so it's created um the prd it's called prd partner relationships assessment.md and then what i'm going to do is we're going to tag the next file to generate these tasks let's have a quick look though at this file so we're gonna let's see it's called uh prd there it is i'm actually gonna okay so you can see you know pretty straightforward prd

This feature will assess and score the current relationship dynamics, the goals, user stories. What else we got? A couple open questions, success metrics. So kind of what you'd expect out of a decent PRD. Yep. Okay, so now I'm going to switch my screen back. All right, so we're back on the GitHub repo, and I'm going to show you our next file that we're going to tag, which is the generate tasks file.

We've got a great PRD, and now what we want to do is build out the specific atomic tasks that we want the agent to knock out.

again this is a prompt that we're going to tag right so the goal is to guide an ai assistant creating a detailed step-by-step task list markdown um and it should guide a developer through implementation right so we want to go on a markdown file we want it to be in the tax task folder we want to get this file name so this is pretty straightforward again you've got 10 steps that i want the ai to follow

receive the PRD, analyze the PRD, assess current state. Phase one, it generates the parent task, right? So I wouldn't want the AI to run off and create 30 tasks. I would want it to create a high level, give me five tasks, and then I want to approve those. And then I want the detailed one. So that's what we're doing here, generating the parent tasks, telling the user.

waiting for confirmation and then generating the subtasks. Yeah. Yeah. I think the parent and subtasks is pretty important. Yeah. Cause normally it'll just generate like 30 different tasks. Yeah. I think this is, and this will get better as the models get better, right? But right now, I think all of us that are building with this stuff realize you really do need to pay attention. You have to read what the agent says it's going to do and guide it.

um now if you're just yellowing and vibe coding and having fun who cares but you know I'm not a vibe coder. I think a lot of people watching this are not vibe coders. We're just engineers that need to build real stuff. And so this step is super important. This is what the file will look like. So you've got... Relevant tasks. And this is just to keep in context for the agent. Hey, what files are we working on? So it can refer back to them. Some notes that it might need.

And then these are the tasks. And the reason why I'm using dot notation on these tasks is so they can be atomic and understandable. So you've got, you know, one, 1.1, 1.2, et cetera. So pretty straightforward. So let's show it in action. I'm going to switch back. Okay, so we're back in Ghosty, and we're going to use this generate task file. So let's hop back over here. A couple things that are kind of fun to note.

uh sonnet now has a lot more context right so you've got at least 400k sometimes it's up to a million depending if you want to use that it is more expensive though this is how many lines we've changed We've obviously added about 70 lines, which you can see over here. So let's go ahead and tag this. And I can actually, I'm going to tag both the PRD and the generate tasks. Generates tasks. There we go.

So I'm just going to tag both of them so that the agent has both those things in the context. And I don't even really need to tell what to do because the generate task instructions all there. So we're going to let it kind of crank away. on that, and we'll open back up our file so you can see what's going on. Yeah, normally you'll probably review the PRD first and make sure, you know, make some edits and then ask to generate a task, right? You would.

Yeah, I would generally read this PRD a little closer. But just so you don't all get super bored watching this, we're not going to read that too carefully. What's interesting is a lot of agents like AMP have to-dos now. Right. So you can see on the bottom right, it is building its own list of tasks. I have to say that, you know, whether it's cloud code or cursor CLI or AMP or really any agent.

It's pretty standard now. I think they're all shipping with tasks now. You have to actually manage a little bit between the two, right? So you can see these high-level tasks kind of make sense. But in a minute, I'm going to be asking it to... execute these very detailed atomic tasks and not use its own task system. So let's have a see what it's doing. So it says, I've generated the high-level tasks based on your requirements ready to generate. So I'm actually going to open this file.

Let's switch over here. What's it called? It's called tasks. There we go. All right, I'll hide this. All right, so we've got relevant files here. It's going to be looking at the schema because we're probably going to record these things. It's got the main relationship assessment questionnaire page.

It's got a ZOD validation schema, et cetera. And then a couple notes. And then the tasks. These are the most important things, right? So number one, database schema and data layer. Number two, assessment questionnaire UI. Number three, score calculation logic. Number four, results display interpretation. And number five, AI recommendation system integration.

I mean, that seems pretty good to me. If I wasn't recording a podcast, you know, I probably would dive into this a little bit more. Yeah. I'm going to give it a little feedback though and say, I think, so I'm going to say. We need to create a branch first before we do all this. So go ahead and add that as the first step. So there's six total steps. I also want to make sure that... Actually, never mind. We won't do that.

So let me do this last little bit. You'll see when we generate the subtasks, we're actually going to make sure that we're writing tests. And the reason to create a branch is just so you know, if something screws up, you can just revert, right? Exactly. Yeah. So typically, I'll create a branch for any feature I'm building. I'm actually part of the core AMP.

um, dev team as well. So we always commit, uh, we always create, uh, uh, PRs for everything we do so that they can be merged back in. Um, so, all right. It's saying great. you know we're going to add a first step in over here so let's go over here and refresh the file and you can see we've got create feature branch okay so now i'm going to show you

We're actually going to continue the process and say go. So you can see over here it said perfect. Update the task list to include branch creation at step one with six huddle ready to generate subtasks. I'm going to say you bet. Let's go. So now AMP's going to go ahead and crank out subtasks for each of those six parent tasks. Actually, no, I'm going to stop it. I'm going to show you something really quick that I want to do. I'm going to say...

So call on the Oracle to make sure we're not missing any larger parent tasks. I probably should have spoke that, but so this is an example of, I want to use a little bit more compute. to really make sure I'm not missing anything obvious. So in AMP, like I said, this is a tool call to O3, so it'll use a little bit more reasoning. It's a little more expensive.

And if you're on any other agent, you could obviously switch the model selector, you know, and then do this. But I kind of like the DX of just being able to sort of talk to a more senior engineer. So we can see right now it's consulting the Oracle and it's going to check out a couple of things. This is obviously running over three, so it'll be a little bit slower to come back. Yeah, it's probably going to check out.

Is it going to look at all your files or just this PRD? Well, not necessarily. So what it's doing is just using more intelligence, right? So what we're doing is using a slightly more heavy reasoning model. uh, and, and then saying, look at what we're doing, everything that's in context. Um, it doesn't do a lot of tool calling. Right. So I think.

this is what's kind of valuable is you're not going to get a lot of agentic behavior here what you're doing is saying i just want someone to to double check what i'm doing right um and it's saying okay actually we need to add a few more steps uh to that so um now the other interesting thing about amp that threw me off at first that people are probably noticing is there's no accepting diffs or rejecting diffs here

which I didn't like at first, but now I've actually learned to love it because it speeds me up. So let's go back over here and reload the file. Just to be realistic, I'm going to say, you know what? I don't think we need automated. I don't think we need analytics. So I'm going to go back over here and say, I don't think we need analytics and documentation. So why don't you remove those? and then we'll proceed. I'm just giving you a little more realistic back and forth here so that you can see.

what this might look like. So all right. Now that switched back to Sonnet 4, right? So now we're using the main agent. So we're going to go over here. There we go. Okay, so now what we've got is high-level tasks. Now we need to go ahead and generate all the subtasks. So let's go ahead and do that. It says, perfect, remove analytics. Now we have 11 focus parents ready to generate. Go.

So here we go. And again, this isn't rocket science, but I think the reason why this GitHub repo has like 4,000 stars is because folks do want a process to follow to give them better results. right and the problem is that we have these amazing magic agents now that can do so much and they're so eager to help that you can say something you know like this could have been a one sentence prompt right

And the agent would have got to work on it, right? But would it have been what we actually wanted? Would it have been guided? Probably not. So this process kind of helps it through. All right. So we've got our subtasks. They look pretty good. For the testing piece, ideally, you have testing on each step, right? Instead of at the end.

How to practice test-driven development to avoid bugs

Yes, absolutely. So let's have a look at this. So a creative feature branch, that's fine. We would expect that. Database schema and data layer. I think what we'd want to do is... implement former state management and react hook form, add form validation. I think we really, like you said, want to add testing at the end of each step. And as you know, so the reason why.

you have to really care about test-driven development now is because it's the loop that the agent needs to actually know if it's doing things right, right? Yeah. And so the faster you can speed up that loop, the faster you can build. So I'm going to go in here and ask you to do that. So at the end of each... step, I need you to add tests so that we understand if everything is working correctly. Let's use Jest, please. All right, so we're going to...

It's going to go ahead and modify those. So, Peter, you're obviously doing this a lot. You talked to a lot of people. How are you seeing people using test-driven development to really speed up their agentic workflows? I mean, just including that line.

or including the plan is key. Because otherwise, if you're not doing this, then you're basically doing vibe coding. You're like, hey, this is not working. Go fix this. I guess go back and forth for like two hours. It's not working. It's still not working. No, it's still not working. All right. So you can see, let's go over here. Yeah. So now we basically have Jest tests and we're using types. And what is Jest?

Just is just a nice testing framework for TypeScript and Next.js. So it's a really handy way to quickly run your CI checks to make sure everything is working correctly now. You could use all sorts of different frameworks, but I like Jest. And it's probably because an agent suggested it to me at some point. Okay, so we've gone through to kind of walk everyone through what we've done, right? So we had an idea for a feature.

What we did is we went into AMP and we spoke, you know, all the text of the feature and then we tagged the PRD generation prompt, had it generate the PRD. Then we took the PRD and we generated high-level tasks. We edited those tasks and then we asked. And then we used the generate tasks prompt to then generate all the subtasks. So that's where we're at. So we have a pretty detailed list of tasks here. Under each one of these, we've got six or seven pretty detailed tasks that are atomic.

And then what we'll do now is we use the third one. OK, so we are back at GitHub. And what we're going to do is go to our third file, which is the process task list file. Now, what this is doing is it's basically controlling how fast the agent can move. I've chosen to say do one subtask at a time and do not start it until I say yes or why. and then when you finish a subtask immediately mark it complete with an x and then if all subtasks underneath the parent are finished then go ahead and

First, run the test suite. It's actually saying, hey, remember to do this. If I'll pass tests, then you can add it and then you can commit it. So the idea is we're trying to create this behavior of... code, test, then commit, right? In an iterative sort of... It's basically software engineering best practices. Yeah, exactly. This is how you should work if you are a software engineer. Again...

This isn't rocket science or new. Like you said, this is basic software engineering behavior. So what we're going to do is head back over to Ghosty and see how it works. All right. So we're back in Ghosty with AMP. And on the left, we have our tasks that we want to accomplish. And we're actually going to say to the agent, let's get going. So I'm going to tag the process.

task list here. I'm going to tag that. And then I can actually just execute it because it has all the instructions in it. And then we'll start looking at it. It's saying, okay, I should only do one task at a time. It knows it should do 1.1. Okay, so basically we've been talking for like 20 minutes, right? And now it's finally starting to code. Yeah.

isn't that wild i mean it's it's so different than the you know yellowing kind of one prompt and then just seeing what happens now it's probably super boring to watch and i'm sorry but this is actually the way real software development happens with agents um yeah it's saying should i proceed And we'll say, you bet. So yes, if I can type correctly today.

All right. So I've had now everyone who's coding with an agent has different opinions on this. Do you go yellow mode and let it run any tool it wants or do you have to ask permission? I generally say don't do any get commands without me approving. I do have my agent run or at least type all my Git commands because it's just easier for me to remember them.

All right. Of course, we are already on main, but it's checking it out just in case. And now it's going to create a feature branch partner relationship assessment. And then we're going to see it spin that up. And then you can see it marked it as complete, right? Yeah. Now... And again, this is where it's kind of nice for me not to accept all these diffs. It's just nice. I can see, okay, yep, it changed 1.1 to checked. I didn't have to approve it. So we're just kind of rocking.

Should I proceed? We'll say yes. Okay, so I guess this third step of your system actually requires you to sit here and watch it code, because normally I would go get a coffee or something. Yeah. And I think I may revise or this is open source. So someone should, you know, create a PR to revise this. I think, you know, when I shipped this, we were on Sonnet 3.7.

And I think with Sonnet 4, you really don't need to handhold it quite as tightly, which is kind of interesting. So we'll see it kind of crank through a couple of tasks. Yeah. hey so while we wait um quick question like when i was using cursor i could scroll back in the chat and revert any previous checkpoint right yep and like uh

Is there an easy way to do that? Or with AMP, is there an easy way to go back? Yes. If you use the VS Code extension, you can revert. In our current CLI, you can't. We're actually building that out now. But what's interesting is there's a lot of times where if I'm pretty concerned what I'm doing is not going to work, I'll just commit and then I'll revert the commit. Okay. Yeah. Yeah, just use get to do it, yeah. Yep. All right, so we'll say yes. Let's go ahead and do this.

We're now messing with the database schema, which is always fun. We have to do a migration here, which I don't like. Yeah, the database is where things can get screwed up. Yeah, hopefully. But what's interesting, I mean, but again, this is where if you're working from a PRD, you have a pretty detailed task list. If you're going to have to change the database schema and do a migration, it's most likely going to be fine.

Again, this is probably not the most exciting thing for you all to visually see, but I think seeing, you know, real software development happening with an agent and the way that actually looks and works, hopefully. It kind of gives you a behind-the-scenes view in that. I mean, this is still, like, infinitely easier than, like, writing code yourself, right? I mean, like, you know, like, the parent after 9 p.m., like, I can write code myself.

crank these commands and you can click yes you can you can read you know you can speak into whisper flow a little bit um so all right we're gonna say yes let's keep cranking so It's interesting to kind of see all this happening, right? And see, well, how much of your code do you truly read now? How much are you relying on your tests? And obviously, you want to be doing all of that.

But it's interesting to see how this is playing out. I think we just saw Mitchell Hashimoto, the creator of Ghosty, one of the founders of HashiCorp, recently say he's requiring all. uh prs that were ai assisted to clearly say so oh okay you know which makes sense and a lot of them do now it says you know co-authored with amp or co-authored with uh cloud code I mean, that's going to be like every PR, man. I don't know. Yeah. So that's what I said. I think it's going to be like 99%.

Let me ask you this while we're waiting for this thing to generate. You taught a million people how to code, right? But I'm sure when you taught it, it was about learning loops and learning functions and stuff. And now, do you think this is a better way to learn how to code? You just get to build stuff, and then you ask questions about the code? How would you learn how to code now?

well what's interesting is you're basically coding with a tutor now right that's right and and it's really down to the student about about the depth of their knowledge, right? As you know, I'm just going to keep this going. As you know, you actually don't need to understand the code to actually ship now. Now you should.

right? Because that's a little scary if you're shipping and you have no idea what's actually happening, but you could technically do that. But, but the problem with that is that's sort of like, it's sort of like building a house and you have a robot that knows how to use a saw, right? And it's like, okay, well, you could do it, but what if things start to break and you have no understanding of how the plumbing was put in or why that wall is there? So I think there's this very valuable...

very, very, very valuable skill in understanding code still. And I think that's going to last for years. But how do you learn it is the question. So I think... you know if tree if ai had existed at least large english models had existed when i was running treehouse it would have been completely different and and what we would have said is okay the the learning experience is that you're going to sit down

And you're going to chat with AI about something you care about, right? Let's go ahead and keep this going. So should I proceed with adding the TypeScript types? Let's do it. Okay. And so you would say, you know, what's something you care about? You know, is it Warhammer or is it basketball or is it selling? Right. So you pick a topic you care about and then say, OK, well, what's something we should build for that topic that you care about?

right so if it's sewing you know maybe you want to build a program that helps you design a pattern Right. Or say it's about basketball. Maybe you want to track, you know, your favorite NBA all star and keep track of their stats and have them loaded on your screen in the top right. Right. So the key is to build something you care about. Right.

How to get AI to be your tutor to become more technical

And so I think everyone's like, well, I don't know how to code or I don't know how to build with agents. Just say, pick something you care about and talk to an agent about that. Ask them to build it with you and explain as it goes, right? And I think that's the way people are going to learn in the future. Yeah, you should make a new three-step system for learning with AI. There we go. So that it explains the architecture and everything. That's my next idea. Thank you. I'm going to steal that.

Yeah. So now we're running some tests and seeing, well, is what we built actually going to work? I'm not really paying attention to the code. Obviously, if I was coding, I wouldn't be chatting to Peter and not really paying attention. that that's what's happening now so this is sort of realistic um when can we get to like if we do step three no step we gotta get all the way down to step

five to see some UI or? Well, we've got, so we've got the assessment question, question UI in step three. And so we're on step 2.6. So I think. So pretty quickly, we're going to get to 3.1. And probably what we can say to the AI is, I'll actually want you to create a static version of this so I can see a mock-up of it.

I may go back and actually revise this workflow a little bit because what I am learning is it's sometimes better to have the AI mock up a completely static version of the UI first. you know, no functionality, um, uh, just use tailwind and then show it to me. Right. Yeah. And then that will actually flesh out a lot of confusion. Like, Oh wow. I didn't mean that. Or, or this is terrible. You know, let's not do that. So.

Yeah, I think that's best practice because it might change the database for something that you don't actually want. Right. I don't even care about that. So what are we doing? Let's go ahead. I'm going to actually interrupt this because it's basically doing what we want, which is iterating through these tests. But I'm actually going to stop it. And I'm going to say,

I actually want to skip to step three and just view the UI. Do a static version of the questionnaire UI just so I can see it and kind of make sure we're on the same page. All right. So AMP's going to say, what? We were doing this whole process. What are you doing? But what we'll do is we'll get, hopefully... Is Untangled your app live and people are using it to manage their divorce?

It's brand new. So we're basically, I essentially launched our first ads today. Wow. Exciting. Yeah. So if you go to untangle-us.com, you can see it. You know, hopefully none of you listening are going through divorce. But if you are, you know, you can check it out. So actually, while this is building, I'll quickly show you what it looks like. So Untangle is an app to help people get through divorce, but it's just for Connecticut. So I think this is a good example of the...

myriad of startups that we're going to see where people solve a very specific vertical problem. Right. And the idea is, you know, Divorce in Connecticut is not a sexy startup problem to solve. But the point of all of this is that this is a specific market that I think that I can help a lot of people.

And so I tackled it. And I think we're going to see thousands of startups like these. So it's going to be fun to see how it goes. And is it only connected because Connect has their rules from other states? Yeah. If you haven't been through divorce, you know this, but unfortunately if you have, you're very aware that the divorce statutes are very different in each state. Got it. And the kind of painful thing, the reason why I showed this like pile of PDFs is.

Because in Connecticut, there's 14 divorce forms with 2,077 unique fields that you have to fill out correctly. Wow. It's a nightmare, right? There's a lot of fun features to build here. So that's what I'm building. That's what Entangle is. But let's take you back to the code and see how it's doing. All right. So we are back with AMP and NeoVim inside of Ghosty. So it said it's create a static version of the relationship assessment questionnaire UI. Here's what I built.

All right, so we're actually going to, let's create, let's get the, let me see, one second. All right, we're going to start the dev server. all right so we're running over on 3000 and then i think it said the url is case new relationship right so let me hop back over All right, everybody, we are back in a browser, and we're going to go to localhost, and we're going to fire this up. So we just started the web dev server, and I believe it was case.

let me just check it was at case relationship case new relationship All right, everybody. So we've got the web developer, sorry, the web development server up and running, and you can see the very basic UI. Obviously, this is not rocket science. You can see, okay, we're doing a relationship assessment.

We're asking, how would you describe your communication with your spouse? So, Peter, how would you describe your communication with your spouse? Let's see. Generally, I can't communicate. Not close to divorce yet. Okay, good. How willing is your spouse to cooperate on divorce-related decisions? Hopefully, completely uncorruptive. Hopefully, it doesn't happen. Hopefully, because you're not getting divorced at all. How would you describe the level of conflict?

I think low conflict with spouse, high conflict with the kids. That sounds like every parenting, marriage, relationship in the world. How would you describe your spouse's emotional state? regarding divorce yeah she'll be disappointed like you know she's married to the best person in the world so she's probably extremely upset She'll be very upset if it happens. Yeah. Okay. So there we go. Okay. All right. So unfortunately you are high conflict because she's very upset.

Oh, okay. Okay. Because, okay. Yeah. Okay. Well, I don't think I'm a target audience. Yeah. Hopefully you and no one watching is my target audience. So, yeah, but you can see, you know, the basic process, right? So. I think actually what I would do is encourage people, and I'm actually probably going to go do a pull request on my own repo here, is actually add the UI generation at the beginning, right? As soon as you do the PRD.

Um, cause then you can flesh out a lot of these, uh, a lot of these issues early. So, yeah, this is, this is awesome, man. So I want to talk a little about the right problems to solve as an AI solo founder. Like I actually really love the fact that you're doing this.

you know, Connecticut divorce problem because like, you know, like all the 21 year olds are like, you know, I don't know what they're doing. They're like building fancy AI coding agents or like in San Francisco. Right. But like as a solo founder, I think solving a super high pinpoint for a niche audience that's willing to pay a lot seems like a really good fit. How do you think about this? Yeah, so what's interesting is I didn't have an idea after Treehouse was acquired, right?

Pain pills vs vitamins: Why divorce is a great AI business

Because as everybody knows, when you start a company, you have to be passionate about a problem you want to solve. And you can't magic that out of nowhere, right? And so there was a period of time I was like, I don't know what to build.

Right. And then that's why I joined Intel. I thought, I'll just go learn about Silicon. Right. I don't have the idea. And I also want to learn how enterprise companies work because I've never worked in a massive, you know, a hundred thousand person company. So. went and just learned and then you know when i saw my sisters go through their divorce i was like why is this suck so bad like why is it so expensive like this doesn't seem like this should be happening um

And it seems incongruous. And I think as a founder, whenever you feel that feeling like, why is this like this? It shouldn't be like this. That's always the seed for the idea. And you can't. Unfortunately, you can't manufacture that moment. And I think you're right. This is not a sexy startup idea, right? But this could be a very real, important company.

right? Because it's solving something that really, really exists. You know, you either pay $15,000 up to $40,000 for your divorce or you pay $300 for Untangle and then probably a couple thousand dollars of attorney fees, right? Yeah. So I would encourage people to think about real problems in their life. The last thing I'll say is even though Treehouse was my most successful company financially, it was a hard startup.

And the reason why is because what we were doing is selling a vitamin, not a pain pill. And I'm sure people have heard this analogy before, but you really want to tackle a problem or build a company that is a pain pill, not a... vitamin and what i mean by that so learning how to code is very something that you do because you want to get better right you do it because you want to be smarter you do it because you want a better job right so that's why it's a vitamin whereas

divorce is a pain pill. It's an acute, painful moment in your life that you want the pain to go away. Right. And so if you can find a pain pill, it's always, it's always a better business than a vitamin. So be aware of that. You were leading like 100 employees or something, right? Like, so how would you say?

And I feel like a lot of people are kind of chasing that, like they want to be in charge of a large team and so on and so forth. So how do you compare your life back then to now? We're just like playing at night. I love, you know, not having a hundred employees. It's wonderful to grow a team and to take care of them and do the best you can and be successful and hire a lot of people. But it draws you away from doing.

And so, like I said, in the beginning, I was a solo founder. When I launched DropSend, it was me. I coded it. I did customer success and marketing, and I did all of that. and then you fast forward to treehouse where you know started it with a friend and then it grew and we hired hired and i got abstracted away from all the code and i think we're now in a phase where you absolutely can be

How to start a one-person company with AI's help

a one-person company. And the size of that company may not be as large as a company with 10, 20, 100, 1,000 employees, but that maybe isn't what you want. And so with Untangle, you know, I specifically decided to build it myself and I decided I'm going to bootstrap it and I'm going to do everything myself. And it's just joyful. Like to be able to ship and build and know and understand and go as fast as I want. It's so amazing. Like what an amazing time to be a founder. Now, why did I join AMP?

Because there's another part of me that wants to empower as many people as possible to do what I do. If I can empower a thousand, a million. 10 million 100 million people to do what i'm doing with untangle or to ship better software inside of their team and get a raise you know to build things that truly change the world like what an amazing opportunity

And I wasn't going to go build another coding agent company. So it just made sense to build Untangle inside of AMP. Yeah, I think Untangle has much higher chance of success than another coding agent company. Yeah, I think the battlefield is pretty set on the coding agent battlefield. And I believe AMP has a good chance to win that, but it's going to be a battle, right? I think this is really important, man.

A lot of people haven't realized this. Now is a better time to be a solo AI founder than any other time. And you don't have to go raise VC funding and do all the crazy stuff, right? Because if you're a CEO of a 100% company...

Yeah, you're probably just in back-to-back 30-minute meetings again, like all day. For like nine hours a day. Yeah. I think, I don't know if you can talk about this, but it depends on what kind of lifestyle you want, right? And how much money you want to make. Yep. I think this is huge. And I want to give... you know, credit to Jason Fried and DHH because they've been saying this stuff for like 20 years, right? Yeah. Where the idea is, you know,

You can build a wonderful business that unlocks you financially and is much smaller, right? So you kind of imagine, okay, we'll say that I had a really well-paying job as an engineer. And I had benefits and a 401k. And how much money would I need to make per year? It's like a reasonable amount, but it's not millions, right? And then you think, well, wait a minute.

If I build my own company and it's basically me or me and a contractor, maybe me and one employee, you don't have to build a very big business to have at least as an amazing life as that. And then it could be much better because you just cashflow and become, you end up becoming wealthy. But the thing is you control your time, right? So people aren't understanding the value of your time, right?

And it may be sexy and exciting to be a Silicon Valley founder who's venture funded, right? But the truth is, it is insane. Like, you don't control your time at all. you know you've got a board you've got you know hundreds of employees to take care of and feed and protect and you've got competitors that are trying to kill you and you have no time right so i think you have to kind of balance these things and

And it's interesting because I think in the past, I did want to build a company that was sexy and huge. And people would say, wow, Ryan built this huge company. And I don't care about that now. It's like, I want to work on a problem I care about. I want to work with people that I respect and I want to be able to control my time and take care of my family. And that actually is the ultimate wealth, right?

Um, so yeah, more power to everybody listening that wants to build a company by themselves. You absolutely can for real now. Like you don't need anybody else. If you are agentic yourself. Wow. Yeah, that's my plan for my kids to get on this track to avoid the whole rat race. Yeah. We're all trying to like make our kids as agentic as possible. Yeah, exactly. You know, if you have any question, ask an AI first, right? Because it's very likely you'll get way further.

And just one little sort of anecdote. It's kind of interesting joining AMP. I think I'm on day 22 maybe now. You know, and AMP is a big code base, right? And it's so wild to... to all I have to do is open up the repo in AMP and ask AMP a question and say, where is in the code base does this happen? And it figures it out. And then I'll say, well, which developer worked on it?

right um and i'll i'll figure that out and then i can go into slack for instance and ask much smarter questions right i can go to the engineer who worked on it i know exactly where you know the code is and what it does and i can ask a very intelligent fast question that doesn't slow them down uh and this is this is just an example of one thing in life you can do like apply that to anything right

We are so much more powerful now because of agents. It's just bonkers. Yeah, I totally agree. All right, man. So where can people find Untangled and also AMP? So if you want to use the AMP, just go to ampcode.com. The cool thing is you can sign up for free. We give you 10 bucks to use it for free. So just have at it. And hit me up on X. So I'm just Ryan Carson, right? So hit me up on X. Tell me you're using it.

I'll cheer you on if you have any trouble. I'll make sure that we get it to the right person. Try it out. Have fun. Then if you want to find me, like I said, I'm just Ryan Carson everywhere, but I live and breathe on X all day, every day. I love it. And then if you want to, hopefully you're not getting divorced in Connecticut. But if you are, just go to untangle-us.com and let me know what you think.

Awesome, Ryan. Yeah, it was great to connect with you on X. I think I have kind of like a love hate range of X, but you know, it's good to see you on there. And yeah, thanks for walking through everything. It's super practical. Thanks, Peter. Appreciate it.

This transcript was generated by Metacast using AI and may contain inaccuracies. Learn more about transcripts.
For the best experience, listen in Metacast app for iOS or Android