The argument in one line.
A repeatable five-step pipeline — a question-driven PRD skill, adversarial deep research, screen-by-screen AI design, vertically sliced epics, and an OpenSpec implementation loop with a mandatory review sub-agent per phase — is what lets an unattended coding agent build a real app overnight instead of just producing a lot of unreviewed code.
Read if. Skip if.
READ IF YOU ARE…
- A non-developer or solo builder who has a clear app idea but no repeatable system for turning it into working software.
- Someone already using Claude Code who wants a concrete example of spec-driven development instead of ad-hoc prompting.
- A builder curious about running long, unattended AI coding sessions safely, with verification built in rather than trusting a single overnight run blindly.
- Anyone who wants copyable, open-source skill definitions (Light PRD, PRD-to-UX, PRD-to-epics) instead of a closed proprietary workflow.
SKIP IF…
- You want a five-minute vibe-coding demo — this workflow deliberately front-loads hours of planning before any code gets written.
- You're looking for a finished, production-ready fitness app — this is a personal-use MVP with known gaps (missing weight fields, redundant loading states) left unresolved on camera.
The full version, fast.
Sean Kochel demonstrates the five-step system he uses to take an app idea from scratch to a working prototype with Claude Code. He starts with a question-driven 'Light PRD' skill that interrogates every ambiguity in a rough idea, runs a deep-research pass with adversarial fact verification on the technical and domain unknowns, feeds the resulting spec into Claude Design screen by screen, splits the plan into vertically sliced epics, then hands each epic to an OpenSpec proposal-review-implement loop. The final phase runs autonomously overnight with a sub-agent per build phase and a mandatory adversarial review after each one — seven epics landed in about 20 hours, producing a working (if rough) fitness-tracking app with a handful of expected gaps still to fix.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 01:18
01 · Intro
Cold open pitching AI building as a generational opportunity, then previewing the five-step process end to end.
01:18 – 03:37
02 · The problem / idea for the app
Explains the real annoyance driving the build: the Mountain Tough fitness program delivers weekly workout PDFs with no tracker, forcing users to log reps in YouTube comment threads.
03:37 – 16:39
03 · STEP 1: hand-written / Light PRD
Lists raw functional requirements, then runs the Light PRD skill, which interrogates the idea with round after round of scoping questions until a lightweight PRD is produced.
16:39 – 23:35
04 · STEP 2: research
Kicks off a deep-research workflow to investigate the technical parsing/generative-UI approach and the real schema hidden in two sample program PDFs, with adversarial fact verification.
23:35 – 26:59
05 · Design planning
Folds research findings back into the PRD as new follow-up questions, then runs a PRD-to-UX skill to plan mental model, information architecture, and per-screen states before any visuals exist.
26:59 – 27:28
06 · Breaking into actual screens
Converts the UX plan into copy-pasteable, screen-by-screen design prompts ready to hand to an AI design tool.
27:28 – 28:41
07 · STEP 3: Claude Design
Loads app context plus a reused design system into Claude Design, then builds the library/week screen first to test the approach.
28:41 – 32:38
08 · Design output
Pastes each remaining screen prompt in one at a time; the resulting mockups match the original rough wireframes, and the set is turned into a clickable interactive prototype.
32:38 – 38:26
09 · STEP 4: vertically sliced epics
Downloads the design as a zip into the project's docs folder, then runs a PRD-to-epics skill that reconciles the PRD and designs into seven vertically sliced, independently buildable epics.
38:26 – 40:22
10 · STEP 5: OpenSpec proposal + implementation loop
Initializes OpenSpec, generates a proposal/design/specs/tasks bundle for the first epic, and explains the sub-agent-per-phase-plus-adversarial-review pattern before letting it run.
40:22 – 45:13
11 · First working screen
The first vertical slice (upload, parse, log a week) comes back functional with minor state bugs; then the dynamic epic-runner workflow is launched to build the remaining six epics autonomously.
45:13 – 46:13
12 · Next-day update
Returns the next morning: the epic-runner ran for about 20 hours (mostly verification overhead and time waiting on his answers), and all seven epics are implemented, verified, and archived.
46:13 – 52:25
13 · Testing screens
Drives the simulator against real PDFs; some blocks parse and log correctly, others are missing fields like weight — attributed to the non-deterministic nature of LLM-based PDF parsing.
52:25 – 54:05
14 · Bug tracking / outro
Shows how bugs found in manual testing get filed as tagged GitHub issues and cleared by a separate scheduled bug-fix workflow, then closes with the community CTA.
Lines worth screenshotting.
- A five-skill pipeline — Light PRD, deep research, Claude Design, vertically sliced epics, and an OpenSpec implementation loop — turns a rough idea into a working app without a single unplanned build step.
- A question-driven PRD skill keeps asking follow-up questions until every ambiguity in a feature request is resolved, rather than letting the coding tool guess.
- Deep research workflows run adversarial verification on every fact pulled from the web, refusing to trust a single blog post before it's cross-checked.
- Picking the lightest-weight option at every decision point — manual entry over auto-confidence logic, view-only history over full editing — is what keeps an MVP from quietly turning into a much bigger build.
- Feeding a PRD into a screen-by-screen design tool one screen at a time, instead of all at once, produces designs that actually match the planned wireframes.
- Splitting a build into vertically sliced epics lets a spec-driven tool like OpenSpec generate a proposal, design doc, spec, and task list for each feature before any code is written.
- An autonomous 'epic-runner' workflow assigns a separate sub-agent to each build phase and forces an adversarial review sub-agent to check the work after every phase completes.
- Letting an agent build unattended overnight only makes sense for low-stakes, well-scoped work — high-stakes features still call for spending more time in the human-reviewed proposal phase.
- Seven epics with verification loops baked in took roughly 20 hours of unattended overnight runtime, not because the work itself took that long, but because the agent paused waiting for morning answers to its own follow-up questions.
- Using a language model to parse unstructured PDFs into structured app data is inherently non-deterministic — the same document can produce different results on different runs, a real limitation when that output doubles as core app logic.
- Recurring bugs get filed as tagged GitHub issues and cleared by a separate scheduled workflow that reads the backlog, diagnoses each one, fixes it, and tests the fix itself.
- Telling a model the motivation behind a feature, not just the specification, measurably improves the decisions it makes when it hits an undocumented edge case.
A five-skill pipeline is what makes overnight autonomous builds safe.
WHAT TO LEARN
Interrogating ambiguity at every stage — PRD, research, design, and epics — plus a mandatory adversarial-review sub-agent per build phase, is what turns an unattended overnight coding run from a gamble into a repeatable process.
02The problem / idea for the app
- Ground a new build in a real, specific annoyance before listing any features — the workaround people already tolerate is the actual spec.
- List functional requirements first (what the system must DO) before touching feature lists or UI, so early decisions aren't anchored to a specific screen design.
03STEP 1: hand-written / Light PRD
- A question-driven PRD skill keeps generating follow-up questions until every ambiguity is resolved, and logs every answer inside the project so later sessions can be pointed back at prior decisions instead of re-litigating them.
- Choosing the lightest option at each fork (manual re-entry over confidence-scoring logic, view-only history over full editing) is a deliberate discipline to stop an MVP from quietly becoming a much bigger build.
- Giving a language model the motivation behind a feature, not just its spec, produces better fill-in-the-gap decisions when it hits something you didn't explicitly define.
04STEP 2: research
- A deep-research pass should target the actual unknowns in the build — here, the technical parsing approach and the real-world schema of the source documents — not generic best practices.
- Adversarial verification of research claims matters because individual blog posts frequently turn out to be wrong once cross-checked, and those wrong claims can get baked into an app's data model if unchecked.
- Deep research workflows can be capped with token budgets, agent-count limits, and per-step model choices — treat it as a cost lever, not an all-or-nothing switch.
05Design planning
- Route research findings back into the PRD as explicit follow-up questions so new information changes the spec before it changes the code.
- UX planning upfront — mental model, information architecture, and every state (empty/loading/error/partial) for every screen — keeps a design tool from making silent, ungrounded decisions when it renders mockups.
06Breaking into actual screens
- Breaking a PRD into per-screen prompts, one at a time, is what lets a generative design tool actually match a pre-planned wireframe instead of improvising a layout.
07STEP 3: Claude Design
- Feed a design tool the app's context plus one target screen at a time rather than the whole app at once — screen-by-screen prompting is what keeps output faithful to the plan.
- Reusing an existing design system from an older project is a legitimate shortcut when visual polish isn't the point of the build.
08Design output
- An interactive prototype exported from a design tool is a cheap way to sanity-check that upload, week, and day flows behave as planned before any backend code exists.
- Exporting the finished design as a project-ready zip and dropping it straight into a docs folder keeps the design artifact in the same repo the coding agent will read from.
09STEP 4: vertically sliced epics
- A PRD-to-epics skill reconciles the requirements doc and the design output into vertically sliced feature epics — each buildable, testable, and completable independently.
- Spec-driven tools like OpenSpec exist specifically to keep autonomous or semi-autonomous builds 'on rails' and well documented, which matters more, not less, as more of the build is delegated to an agent.
10STEP 5: OpenSpec proposal + implementation loop
- Each OpenSpec change bundles four artifacts — proposal (why), design (system approach), specs (per-capability requirements), and tasks (the build list) — generated before a single line of implementation code.
- Epics with dependencies on earlier epics must be built in sequence, not parallel-batched, even when using otherwise-parallel sub-agent workflows.
- Assigning a dedicated sub-agent to each build phase, plus a mandatory adversarial review sub-agent after every phase, is the actual safety mechanism that makes long unattended runs viable.
11First working screen
- The first vertical slice working end-to-end is worth manually testing before letting the rest of the epics run unattended, even with verification loops in place.
- A single feature slice that looks simple still took two to three hours of agent build time — budget for that even on 'straightforward' scoped work.
12Next-day update
- High verification overhead (adversarial review per phase, simulator-driven checks) is why seven modestly-scoped epics took roughly 20 hours of wall-clock time rather than a couple hours of raw compute.
- An unattended overnight run can still stall on legitimate blocking questions it needs a human to answer — checking in the next morning, not assuming a clean finish, is part of the workflow.
13Testing screens
- Parsing unstructured PDFs into structured app fields with a language model is inherently non-deterministic — rerunning the same document can produce different field coverage each time, a real limitation when that output becomes core app logic.
- The concrete failure mode to expect from this approach is inconsistent field coverage rather than wholesale crashes — spot-check specific data fields, not just whether screens render.
14Bug tracking / outro
- Logging bugs found during manual testing as tagged GitHub issues turns ad hoc 'stuff is broken' into a queryable backlog a separate automated workflow can process.
- A scheduled bug-fixing workflow that reads the tagged backlog, diagnoses each issue, fixes it, and tests the fix itself closes the loop without a human re-describing each bug by hand.
Terms worth knowing.
- Light PRD
- A lightweight product requirements document generated by a question-driven skill that keeps interrogating ambiguities in a rough idea before development starts.
- PRD-to-UX
- A skill that converts a PRD into UX planning artifacts — mental model, information architecture, and per-screen states — before visual design begins.
- PRD-to-epics
- A skill that reconciles a PRD and its design output into vertically sliced feature epics ready for spec-driven development.
- OpenSpec
- A spec-driven development tool that generates a proposal, system design, feature specs, and task list for each planned change before any implementation happens.
- Vertically sliced epic
- A self-contained feature unit with its own requirements, design decisions, and task list, buildable and testable independently of other epics.
- Adversarial verification
- A second AI pass whose only job is to challenge and check the first pass's claims or completed work, rather than accepting it at face value.
- Generative UI
- An interface a language model assembles on the fly to fit content whose structure varies case to case, instead of a single fixed, hand-built layout.
- Loop engineering
- Repeatedly chaining an agent's own output back into a new prompt so it can propose, implement, and move to the next task without a human re-triggering each step.
- Sub-agent
- A separate agent instance spun up to handle one isolated phase of a larger task, run in parallel or in sequence with other sub-agents.
Things they pointed at.
33:30toolOpenSpec
27:30toolClaude Design
27:35toolGoogle Stitch
Lines you could clip.
00:20
“It's kinda like investing in Apple in the eighties or learning the Internet in the nineties.”
10:05
“These things will grow and get crazy very quickly if you're just every single time you move through this going with the more aggressive option.”
36:50
“Language models are really much better when they're provided motivational intent behind something.”
44:57
“This thing ran for twenty hours overnight.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
metaphoranalogy
Becoming an AI builder is one of those generational type of opportunities. It's kinda like investing in Apple in the eighties or learning the Internet in the nineties.
But a lot of people, especially those that aren't developers by background, have no systems or context for how to actually build things properly or systematically. So if you're somebody that struggles to go from amazing idea to implementing something that other human beings will actually use, this video is for you because I'm gonna go through a full five step process to go from idea through to fully researched, implemented, functioning app.
And if you wanna go deeper on any of the stuff that I show you in this video and, like, actually build real stuff with real people, you can check out the links in the description below. So here's what we're gonna do. First, I'm gonna explain the problem we'll be solving with this app, because all great apps start by solving a real problem.
Then we'll walk through translating the raw idea into features, exploring the domain of this app that we're gonna be building in, designing the app, and slicing it up so that we can actually build it, and then do the actual build. So by the end, I'll have a functional fitness app, and you'll have an awesome system that you can use full of a ton of awesome hacks, skills, and other workflows.
Alright, guys. So we're gonna start off by first talking about the actual problem so that everything that we're gonna be talking about is actually grounded in, like, why we're doing it. We're not just, you know, building an app that there are already, like, solutions for out there.
And so this fitness program that I personally follow, it's called Mountain Tough. Basically, the way that this thing works is that Monday through Friday, they deliver these, uh, like, it's programmed exercises, and they do it via video.
So you have, like, these follow along videos. And the the big issue with it is that there's no way to actually track systematically.
They do not have an app to track what is going on. So they'll deliver you all of the programming, which is great. But in order to actually, like, know what weights you did last time in order to, like, do it this time.
You have to essentially comment below every video with what your reps were. And then in the next week, when you go to repeat those exercises, you're basically having to flip back and track your progress through, like, comment threads, which is probably .
And now the problem and why we're gonna be building this app is that the programming that they do is meaningfully different from week to week.
So there are, like, these kind of, like, interesting, not entirely standardized types of rep schemes that they use.
And the way that they, like, build their blocks and, like, all of this type of stuff, it's pretty, like, unique. And by that, I mean, there aren't apps out there that are programmed to work with the way that this, you know, company does their programming.
And so what I wanna do in order to solve for this is create an app where I can load in the PDF. So they will give you a PDF every week that has all of the exercises. I wanna be able to load that PDF in, have something, maybe a language model, maybe something else, parse it, and build it into an actual trackable workout tracker.
So that's gonna be the general system. I come through and I download the PDF for a week. I upload it into this app.
It parses it out, and it builds it into, again, an actual, like, workout tracker. And so the way that we're gonna start here is by simply listing out all of the things that we think as far as how the app should actually function. So we're not necessarily getting in and talking about, like, what are all of the different specific features.
We're talking specifically about what functionally needs to go on inside of this system.
So in our case, a user needs to be able to upload the PDF like we talked about, and then just specifying that each PDF is gonna be a week's worth of workouts. The app can then parse and understand the structure of these workouts, and this is gonna be important because it it really varies.
And so under the hood, as, like, I'm thinking through this, what we're inevitably going to need is some sort of, like, generative UI, where the model is able to render these workouts that don't conform to, like, a typical standard.
It's gonna be able to actually render those types of things on the fly so that in the long term, you could upload any sort of exercise or programming workout into this type of system, and it can build a tracker for you on the fly, essentially.
That that is what we're trying to get to, but I'm gonna obviously build the wedge for this thing for my specific use case so that I can validate it. And then we can start, like, abstracting things away and making it a little bit more, like, applicable to any type of situation.
So it should be able to then assemble what it has parsed out into a, like, a week's worth of workouts, because, again, that is how they deliver for this specific app. They deliver things in weeks.
Then on a workout day, I can load up the app. It has all of those workout blocks, and the proper structure, and all the different, like, variants, and the weights I need to do, and, like, all of that stuff is loaded in there.
I can track as I'm going with my reps, and my sets and all of that type of stuff. And then last but not least, I can go back and look at entries from previous weeks. Now something that I I know I'm probably gonna want in here at a certain point is that it needs to be able to reconcile exercises so that I can track the performance of those exercises over time.
So when it's parsing these things out, we're gonna eventually need some sort of system to be able to say, like, hey. This, you know, barbell deadlift that I'm parsing right now, like, I actually have a matching exercise for that in the database. So there's gonna be different logic going on under the hood, and that's why I'm gonna try to keep this pretty simple because it seems like it is going to be, you know, entirely straightforward, and this could just be built in a few seconds.
But realistically, there's gonna be a lot of different logic under the hood that is gonna be needed in order to actually power this. And so I I don't wanna bite off too much than I can chew, given that I'm trying to actually get this thing built in a day or so.
So what I wanna do from here is I wanna take all of this, and we're gonna get into the first step of this process, which is turning this into what I would call, like, a light PRD.
And so what I'm gonna do is I'm gonna just copy all of these notes that I have, and I'm gonna pop down into my terminal. And I'm gonna boot up, in this case, Claude, though you can apply this process to any tool that you use.
So And I have this custom skill called light PRD. You can get a copy of this in the description below.
And what I'm gonna do is I'm gonna paste in those different notes that we had about, like, what this should be able to do. And now, specifically does is two things.
Number one, it is going to try to ground itself in the actual problem we're attempting to solve and generate a PRD force, like a very lightweight PRD.
And then the second thing that it's gonna do, which we see happening now, is it's going to start asking us questions. So one thing that I think is really important if you wanna be able to build things that actually work is to spend a lot of time in the planning phase, making sure that the intent for the feature and the acceptance criteria are very, very, very specifically defined and tuned in before you start actually building something.
And so that is what we are doing here. And so we're taking this rough idea that we have, and we are passing it into a skill that can put that into more of a structure that's gonna work down the line for us when we wanna start building actual specs we can build from and do actual designs inside of tools like claw design. We wanna make sure, again, that we're translating those raw ideas that we have into something usable.
So who is the primary user of this app whose workouts are in these PDFs? This is, like, functional fitness athletes, so it it's not for bodybuilders.
It's not for people that are trying to do power lifting or anything like that. It's like a very specific style of workout.
Though it's gonna move through a bunch of different, uh, questions. This skill is configurable, so you can have it go deeper if you want to. But it's just, again, it's asking us stuff about the audience, the core pain, where we're gonna build this.
In this case, I'm gonna build a a mobile app because I'm typically using this in my garage. And so this process is gonna continue where it will continue to ask us question after question.
And so the way that I've developed this skill is that if you answer a question in a way that it creates a new question that needs to be answered, it will continue to traverse the design tree or that decision tree until it's actually resolved all of the core ambiguities.
And so we're gonna continue to move through here answering all of these questions. And so we're gonna continue through here now answering these questions.
What is the format that we need to be able to support? So how is the parsing going to actually work?
Now, this case, I'm I'm gonna optimize it for my own format. We can expand this down the road, but I have a specific format that my PDFs come in, and so that's what I'm gonna optimize it for, at least for the wedge for the MVP.
So then what happens if, like, the parsing doesn't actually work? I'm gonna say this should be a combo of number two and number three, which is that, like, it should auto save, and a user should be able to edit it later. But I I'm gonna want it to point me to the blocks that I should be paying attention to.
You what? Know Actually, now that I'm thinking about this, I want this to be very simple, so I don't wanna have to go down the rabbit hole of creating confidence logic.
So I'm just gonna do the auto save and and edit later, just to keep this very tightly defined. So now we're gonna talk about, like, very basic or we're gonna plan for, like, very basic UX. We're gonna go into claw design to work on more of this stuff in in detail.
But for now, we're just gonna say, hey. This is minimal, and then we're gonna proceed forward. Now one thing to point out is that the again, the way that I have this skill developed is that all of these questions that we are answering are being placed inside of our project so that we have a log of everything that we have answered.
This type of thing's really valuable when you want to go back or you're developing something, you know, hours from now, and you wanna make sure the feature is integrating things that you have already specified that you want to be the case, and you find that maybe it's not always listening, I find that pointing it to the decision making log that you have already decided on, super, super, super valuable thing to do.
So, again, we're just continuing this process, and this is why it's important to do this. If you were to think of that initial query that we gave, it seemed like it was pretty, you know, dialed in to a certain extent.
Like, we were clear in our mind on what it needed to be, but there's actually a lot that comes out of that in terms of decisions that need to be made. And that is why I like to use these types of systems that will, like, quiz you and grill you on the specifics before we move forward.
Because if I had just given this to a tool like, you know, Roarc or Replit or even ClaudeCode, it would just be making these decisions, and it might not be something that we're actually on board with. So, again, for purposes of this, I'm trying to keep this MVP really tightly scoped.
So there's things that, like, I would want in the future. For example, being able to edit past entries and things like that. But those are all new surfaces that you need to build for, you need to have tests for.
And I'm just trying to get to a minimal version of this thing that I can use maybe today, maybe tomorrow. And so things like making it view only, that's fine for me in the context of the MVP, because, again, I am using this for myself.
Though, I do think that a system like this could be something that we could actually monetize potentially, but that's not the thing that's top of mind for me right now. So, again, since this is for me for accounts, like, we're not gonna do any sort of accounts.
We're just doing local. Everything's gonna be local. The only thing that we need to think through a little bit is this is going to have to be parsed.
There's gonna be a language model that has to be used here in order to do some of the parsing. But parsing unstructured data is something that or, like, semi structured data is something that a language model is actually good at, which is why I wanna use it for this use case. So, again, we're just answering all of these questions, and then I'm gonna choose a cloud provider for this so that the language model there's gonna be a language model somewhere parsing this thing.
There will be a lot of choices that we have for that. I'll probably use something like OpenAI because I have a ton of credits sitting in an account there. But this is something where if we really wanted to optimize for cost, we could use other providers and use open source models that would probably be a lot cheaper and just as effective for this type of thing, because at the end of the day, it's it's fairly straightforward.
We're just gonna be parsing a PDF and trying to, like, format it into a known like, roughly known schema. So, again, staying on theme here, I'm picking the lighter weight of all of these options wherever I have the opportunity. And the reason that I'm doing that is that these things will grow and get crazy very quickly if you're just every single time you move through this going with the more aggressive option.
Like, I could have chosen to have a full block editor in cases where the parsing got messed up and they need to edit it. But while something like that may seem simple, it's going to actually grow and grow and grow and grow.
And next thing you know, you have something that is not in fact an MVP, and it's going to be a real mess to try to get all of those things actually implemented. So that is what we are trying to avoid here by being as simple as we can.
So I'm gonna continue through and answer all of these questions. So what happens if the parsing fails? I think in this case, I'll just make it so that I can type things in manually.
I think that'll be fine. And then I can always go back since this is my app and fix it or, like, migrate the data, whatever I need to do.
In this case, we ended up going through 15 questions. But like I said, this skill is configurable.
If you pass it a flag that says deep, you can go further on this, I think, to 50 questions. And, of course, you can use the skill.
It's open source, so you can make this go as deep as you want to as far as questions that it will ask. But from this point now, we're gonna move through, and it is going to actually create for us the PRD, and that is what we're gonna take forward into the next stage, which we will look at as soon as we get this PRD.
But that is going to be the research stage. And that's gonna be important because there is a lot going on with this from, like, the technical side of things as well as the actual domain specifics, and we need to think about how all of those things are going to come together.
And that's why, like, a deep research phase is is super, super, super valuable to do. So now that that's done, we get two different outputs. First is going to be the light PRD.
This is what we're gonna take forward and use for the researching phase. Also, for the design phase inside of a tool like claw design, we can pass this in. It's gonna make things really simple.
And then we also have all of those questions that were asked and the answers that we gave. So if we were to look through this light PRD real quick, we have an elevator pitch.
What's the problem that we're solving? This type of motivational context is valuable for language models. Because when it goes to fill in something that is an ambiguity and it needs to make a decision on its own, if it knows the motivation behind what it's building, you are going to get a better output than you otherwise would if it didn't actually know why it was building this thing.
So what we have here is, uh, basically a list of our features. So the PDF upload and parsing, and then all of the decisions around how this needs to actually work. Being able to view, like, the weekly and daily structure, being able to actually run the tracking each day, being able to view the history, being able to do the edits, different UX and UI considerations, and then all of those nonfunctional requirements that we specified.
For example, like, how this is local first. It obviously needs to be very fast, because this is gonna be used, like, in in the gym as we are moving. And then there are some, like, other open questions that we could come through and answer.
But for right now, we're probably just going to skip through these. And so the next stage of this process then is the actual research.
So in any situation where there's kind of unknown unknowns or known unknowns, like, you know there are things about this that you do not have the full context for.
At least not as we're sitting here, like, getting ready to build the thing. I don't have a library somewhere of every possible, you know, functional athletics style of exercise programming, but I'm gonna need to be able to account for that stuff in terms of building this parser out.
And so I need to go out then and do that type of research. And so there's a lot of different approaches you could take to this. I am using ClawdCode, and ClawdCode has a built in deep research workflows.
But one thing to be aware of, this can consume a a shit ton of tokens. And so what we're asking this thing to do is say, hey. I need to understand the full scope of the problem space for this app and specifically in a few different areas.
Number one, I'm thinking about the technical implementation of that parser and the language model and how that is going to connect to this on the fly kind of UI generation, we need to go out and research best practices for that type of stuff.
I'll often pass in, like, the month and year of when I'm doing this to get the most up to date version of those best practices. And then the second thing is based on the two example PDFs that I have given it.
So these are actual PDFs from the program. I wanted to go out and investigate the likely schema that we're gonna need.
So what is, like, the data model going to be based on this style of programming? And so what I'm thinking of here is I wanted to go out and try to understand what are all of the different ways that this type of PDF could manifest into something, and how can we plan the database for them?
And then that needs to be tied through to how we are going to parse things out and structure the actual schema of things so that we can track these things, and we can generate the UI needed since this could take any number of shapes.
We need to be able to plan for that, and that is something I think where a generative UI can be super valuable.
So this thing is first going out and reading the PDFs, and now we can see that it has moved through, and it has kicked off this deep research workflow.
Now the thing that I will say is that this can be very expensive. Running this type of deep work, uh, deep research workflow can be very expensive. If we go through and look at what's actually happening inside of this so we can see that first it scoped out the search.
Now it's going out, and it is running a bunch of different searches. And then based on what was returned from these searches, it's now going out and fetching all of the different sources. So we can see inside of this there.
Right now, it's pulling at least 22 different searches across both of those domains.
It's gonna fetch all of the context that it needs, then it will run an adversarial verification.
So this is something, again, that I really like about this style of workflow. If it pulls something out in one of these fetches that is an alleged fact, it's not just going to assume that is the truth.
It's going to actually kick off an adversarial verification of any of those facts so that we're not taking just some random blog post at face value and then integrating that into how our app is built, only to find out down the road that it's actually not right.
That would suck if that ended up happening. And so this workflow is gonna help us out with all of that. So we'll let this thing run.
And then once it's finished, we will, uh, we will come back and chat about it. But like I said, this will consume a lot of tokens. You do have the option to put, like, limiters on this.
You can tell it that it has maximum token budgets. You can tell it that it's only allowed to use certain amounts of agents.
You can tell it the models that it can use for different steps. But, yeah, this thing is out and running right now, so we will talk about the output when it comes back. Alright, guys.
So now that that research is done, we are going to kick off a follow-up. And so what we wanna do here is now we have all of this research.
Right? So we went through, and we looked at, again, what those two research questions were. The first one was the domain of this area, which in this case is, like, functional fitness and what that programming tends to look like.
And we got a lot of really good insights out of this about how these documents tend to be structured and really thinking through, like, okay.
If we were to try to abstract this out so that it would apply to almost anything, what do those structures tend to tend to look like, and how can we start building around that?
And then we did the same thing for the technical side. So when it comes to actually parsing this PDF out, what are the key considerations?
This was a really good thing to do because a lot of those claims, and this is why I like this deep deep research workflow, a lot of these claims that we found in blog posts as the research was happening ended up being refuted. And this is why you can't just rely on a pure web search, and it's good to have these sort of adversarial reviews.
And so now that we have all of this, there's obviously new decisions that need to be made, and we wanna make sure those get integrated back into this PRD before we move forward and decide to actually start building things. So all of that needs to be reconciled.
So we're gonna move through now and start answering what these follow-up questions are. Uh, in this case, what is the actual scope of what we're doing? So this is obviously for for me to use, and so the v one out of the gate here is going to be just this specific program, but I don't want it to lock into this specific cycle, which they've called Apex two point o.
I don't want it to be just that. I I want it to work in in any context. And so I do have other PDFs from other months that I can provide, and I've just told it, like, that is the situation.
So one thing that came out in the research as it was looking through all of this was that the way they build those PDFs is that they have expert level, intermediate level, and beginner level for everything, and that wasn't accounted for inside of our initial PRD.
So we need to think through how we're gonna integrate that. So just picked for me, I picked option three, which is I want you to show me those, but I don't wanna build all this logic where it's, like, auto filling them and things like that. I don't wanna deal with that.
So now what we're gonna do is just continue answering these questions. So I won't show all of this on screen because it's literally just me answering things specific to my application. But if there's any point where it's relevant, I think it's, like, a a learning point, I will come off pause and explain to you guys.
Okay. So the next step that we're gonna get into now is getting this thing ready to actually do the designs. And so in an ideal world, like, the doing the design of the product and doing all of, like, the research and understanding what's gonna happen on, like, the back end and then on the technical side, those things should happen, like, at the same time with teams that are communicating.
But in this case, it it's just us doing it. And so we're gonna kick this off as a we can think of it as, like, a parallel process. And so I have this skill here, which is on my, uh, my free GitHub repo called PRD two UX.
This is like a a lighter weight version of one of the ones I have in my in my paid community. And what this thing does is that it's gonna go through, and it's gonna attempt to take that PRD that we have and break it down into something that we can pass into one of those, like, generative design tools, like a Claw Design or Google Stitch or any of those tools.
And it's gonna do it through a multistep process. So before we move through and start using a tool like Claw Design to design the thing, we wanna have an understanding of, like, the general UX approach that we are going to take to this, like, for for this thing that we are building.
What should that general approach actually look like? That is what this is going to help us hash out. So depending on how detailed your PRD was, you are gonna have more or less work to do in this phase.
In this case, Archer's, like, fairly detailed. And so a lot of this UX work, we kind of decided on already, which is why it didn't take us through some, you know, investigation or interrogation.
So for example, like, the idea of what the dominant mental model that a user is going to approach this thing with, already pretty clear for us.
The information architecture is going to be very clear how you how information's gonna be presented to the users, in this case, me, and how that is going to actually inform the build that ends up getting done, how things are gonna be grouped.
You know, what's the library going to be? What's it gonna look like when a user navigates somewhere where they can actually start the exercises?
What does the history navigation actually look like? What are the different affordances inside of the app?
How does a user know they can interact with certain things? I really like to do UX planning upfront so that we're really forced to think through, like, what is going to make this app a thing that someone actually wants to use.
Now, like I said, this is a lighter weight version where it's making a lot of these decisions for us based on context we've already given. But in an ideal world, this is an iterative back and forth.
So you can take this skill from the GitHub repo and modify it however you decide you want to, But this is what we're doing. So we're going through all the different, like, primary components or screens inside of our app, and we're thinking through, like, what is the design going to be for all of the different states.
So what does it look like when it's empty? What does it look like when something is loading? When it's succeeding?
When there's partial data? When there's erroring data? And we're doing this for all of the different pieces.
So the library, the individual week or day, inside of an actual workout that we're tracking.
We're detailing all of this upfront so that the language model doesn't just make game time decisions when it decides to go. And so the final step of this before we hop into claw design is going to be breaking this down now into actual screens.
So we wanna be able to basically copy paste prompts from our Versus Code in this case into claw design so that it can just move through and start designing everything out for us. And then from there, we'll have a really clear idea of what this is going to feel like, make sure we're on the same page with it.
And then from there, we'll be able to start building the thing. So we're gonna now pop down into our Claude design, and we are going to start building this thing out.
So I've chosen Claude Designs mobile app design template, and I have a a design system from another project that I'm just gonna use for this, because I think it's nice and it works for this. And so I'm giving it two different pieces of of context.
Number one is the actual app context. What are we actually building?
And then I'm going to build this screen by screen. So one mistake I think that people make is trying to just give it all of the screens at the same time. I'm going to give it just our first screen, and we're gonna see exactly what it can do with it.
So we'll kick that off. And just for context, what we are specifically designing here is what this, like, main library looks like. So if somebody opens up the app and it it loads in, we're gonna assume they have a plan already.
What are they actually looking at? What does that that surface look like? That is what we are looking at right here.
So this would be week five. Someone would be able to click into week five, and then this is where they would see all the individual days.
They can click into a day, and then they can start doing their doing their workouts from from there.
Alright, guys. So at the other side, we have very basic design. Right?
The whole intent of this was that we weren't going over the top and trying to design anything crazy. We didn't go through some involved, like, UX brainstorming or or anything like that. You can and should do that.
If it's something that, like, you really kind of care about and you wanted to feel a little bit, like, innovative and unique, you should go through that type of process. But for this, again, this is an app for me to use at home that, like, maybe one day, I think I would think about trying to sell if it seemed like it was something that was valuable that other people wanted.
But for now, I'm trying to make something like a utility for myself. And so this screen that we have here matches almost exactly what our design looked like.
Right? So if we were to think this was the little wireframe that we had, this looks almost identical to that.
So that's good. The next thing that we need to work on then is the next piece, which is if we pop back down in here, it is going to be the the upload parsing.
So, like, what does this look like? This will be a very basic one for us to do. So we can paste this one in, and we can say, hey.
I want you to build me out a new screen, and here is the the details of it. So we're basically just following this process of going through, taking those, like, rough UX concepts.
Sometimes we don't even have wireframes. Like, in this case, we have, like, these low fidelity kind of, like, wireframes that we're using and pasting over. But sometimes it's just the actual concepts for the features, but we're pasting this over.
And then we're just gonna go down this list, pasting each one of these things in. And then once we're done, we will start planning the next piece, which is how do we actually take these designs that we have and move them over into our development environment so that we are building things out and they're true to what we had in this design.
But then the back end and everything is also there and works the way that we need it to. That is what we'll be getting to after we are done with building out the designs for all of these screens. Alright, guys.
So we have now, like, a a functional prototype. So I basically went through, and for each of those screens, all I was doing was pasting them in here, and now we're good to go. The one other thing that I prompted in after we had these final screens was to ask it to turn it into an interactive prototype so that I could pop in and, like, see what it looks like.
So we can see what the kind of uploading phase would look like. We can see if I wanna pop into a specific week, I can see what this looks like.
And basically, so all of these things that we had been planning for are in here, and for the most part, they are all working. So from here, we're we're good to move into the next phase.
And the next phase is going to be, how are we gonna take all of this now and turn it into something that we can actually use?
So we want to be able to, like, build all of the functionality, like the back end and the front end and the data storage and the language model calls and all of that type of stuff. And then we also want to make sure that it's, like, faithful to this design that we have.
And so what I'm gonna do here is I'm gonna choose the option to first send this to ClawdCode, and I'm gonna tell it that I want it to download it as a a ZIP.
So we'll come through, and I'll download this zip file, and this is gonna have everything that we could possibly need for this specific project. And so now all I'm gonna do is I'm gonna pop down into Versus Code, and I'm going to copy that file into this root directory, and I'm going to put it inside of our docs.
So what we're going to do now is we need to now turn those designs into something we can actually work with and start fleshing out the ideas for how we're gonna turn this into like an actual functioning app.
And so in this case, we have this skill for PRD to epics. Again, this will be in the in the repo.
And what we're gonna do here is we are gonna point this to our docs folder. And so what we have now inside of this docs folder is number one, our PRD and all of the context we had for that, and then we have the actual designs in there as well.
And so we're gonna call this command, and we're just gonna point it at that directory. And now what this is going to do is it's going to create vertically sliced epics.
So whenever I build something, I use tools like OpenSpec to actually manage the the build process itself. I think most people, especially if they're beginners, should be using SPECT driven tools, but even people that are more experienced tend to use SPECT driven tools, and there's a reason for that. It's gonna keep everything on rails, and it's gonna keep everything super well documented.
And so what we're doing now is we're saying, hey. Here are all of the things functionally that I want to be able to do and all of, like, the details that we pulled out in the research, and now here are the designs that are gonna be basically powering that thing.
And we wanted to marry all of those things together for us. And then the result of that are gonna be a bunch of epics that we can then take, and we can go build something with it using those spectrum and tools.
So once this is done running, I just realized I'm actually using Fable five for this. So at least it'll be planned well. Once we're done with this, we will move through, and we will start actually building the thing out inside of our project.
So similar to what we had in, like, other stages, we're now gonna go through this question answer exercise just to make sure that, again, we're on the same page with everything that's gonna be done because now we're starting to plan out, like, what are the phases of development here.
We need to make sure before we go and build things that we're, like, a 100% on the same page about what precisely is going to happen. And so, again, you can configure this to whatever depth you want. The source for all of this stuff is gonna be in the repo linked below.
Alright, guys. So that thing has run through, and basically now we have seven different epics.
So there there are seven different things essentially that we're gonna be implementing here. And like I said, we're gonna be doing it with OpenSpec. So what I'm gonna do is copy this initialization command.
We're gonna come into this project. We're gonna initialize OpenSpec with ClogCode. Now we're gonna pop ClogCode open.
I'm gonna switch over to Opus. And so the way that this process is gonna move is that we are going to copy this proposal command, and we are going to just have it run.
And so what this is gonna do and the way that OpenSpec works is it's gonna generate a proposal. So this is the, like, intent as to, like, why we are building this thing, the actual system design, the specs for the feature, and then the actual task list.
So it'll go through and generate all of those artifacts for each of these epics. And then once we are good to go and we're, like, on board with it, then we can just run the apply command, and it will move through and actually build this thing.
And you can use a bunch of different skills to help run that process. You can use over superpowers. You can use compound engineering.
You can use any skills that you have, Matt Pocock stuff, in order to actually, like, run this spec driven process.
But it's important that you're even if you're using those types of things, that you are doing it on rails. Okay? And that's what Spectre of in development tools allow us to do, and that is what we are doing here.
Alright, guys. So now if if you've never used OpenSpec before, I'm gonna show you quickly how this works because, again, I genuinely believe that if you are a beginner, even if you're intermediate, honestly, any stage, I don't know why I even said beginner, you should be using SPECT driven tools.
You should be using SPECT driven tools in order to build stuff because, again, it's gonna keep you on rails, and it's going to build documentation over time.
So for example, if we look at this artifact that we just created or these artifacts, we can now see this is the change.
Right? So the change here is that we need to be able to upload and log a week. Inside of that, there are three different specs that would be, you know, considered part of doing this.
So parsing the PDF, for example, is a spec with all of the different requirements listed inside of here. Same thing with tracking individual days.
Same thing with our actual library. And then we can see the proposal. So this is like the what and the why of what we are changing or what we are doing.
Language models are really much better when they're provided motivational intent behind something.
So inevitably, it's going to run into a situation where it has to make a decision, a game time decision that you did not specify how it should handle that.
And if you are providing intent about what it is exactly that you are doing, it can fill in that gap more easily because it knows the the rationale behind why we are doing what we are doing.
So we have the proposal, then we have the design. So, like, what is the actual system design?
What are our goals of what we are doing? What are the decisions that have been made?
And then we break that down into task lists. So in this case, we have one, two, three, four, five, six, seven different phases here.
And once all of these phases are done, then this ability to upload and log a week is considered complete. Obviously, Obviously, we we would would wanna wanna test it, but this is the general process. And so we have seven of these changes that we are going to do.
I will say this is a situation where loop engineering, hand hand wave, , loop engineering can be valuable because we can move through then and we can create loops that will generate these proposals for us, implement the proposal, and then move on to the generation of the next proposal.
And the reason we wanna do it in that order is that these things actually rely on what was done in previous phases. And so we can't just like parallel batch all of this work. Like, some of these things have to be done in sequence.
So what we're gonna do now is we're gonna move through, and we are going to implement this. So the way that we can do that is running this command for open spec apply.
And then the only thing that we need to do here is we need to pass in the name of the change, which in this case is upload and log a week. And now, like I mentioned earlier, we can start using different skills and things like that in order to really run this process as effectively as possible.
So, for example, we could come through and just copy this real quick and actually start up a new session. Fresh context window, we can paste this in, and then we could give additional commands. So for example, we could come through and say something like use sub agent, and we could point specifically to something like OBRA superpowers, for example, sub agent driven development.
We could say use sub agents for each phase. And so what I mean by that is each of these individual phases would get its own sub agent for the implementation. And then we want one adversarial review sub agent after each phase.
So after each phase completes, we'll have another model spin up a sub agent and really quickly check to see were things done properly. There's a lot more you could extend into into this. And so we are going to just let it run.
Alright, guys. So this is now properly working.
So we're able to upload some PDFs, and then it shows us the different days, and then we have the ability to come in here and actually, you know, insert info in.
Looks like we have some some errors with, like, how the state's being managed, but that's fine. So we have our warm up block, then we have our, you know, banded fire hydrants so we can come in and, know, put in all of our stuff.
And so, yeah, for the most part, everything seems to be working. Some of these should have weights on them, and they don't.
But the big bulk of what we needed to have done here what we needed to have done seems to be seems to be working, which is nice. So we can come through now and actually potentially use this thing.
But, again, this is just the the first spec of all of those epics. So if we were to move through and look at our look at our stuff here.
So we had this ability to do, like, basic upload and log. This is what we just implemented. So what we have here is a dynamic workflow.
And so that process, by the way, this parser and everything that was building in the background, that took, like, two or three hours to to build out fully. And so I don't want to sit here babysitting the thing for for all of that time. At the end of the day, like, this is a, like, a pretty straightforward thing realistically.
There's not very high stakes, and it's also pretty well defined and well scoped.
Like, there there's not a lot of areas where it can go wrong. And so in this case, I am willing to let it go off and attempt to actually build all of this.
Now I would still apply this exact same process for something that I did care a lot about. The difference is that I would spend a lot more time in the proposal phase, which we're gonna see right here. I would spend a lot of time actually reviewing this and making sure I'm on the same page with all of the proposals before I move through and automate, like, the apply and the verify and, like, finalizing it and testing it and all of that.
I think it's really, really important to get on the same page with the intent of the thing via the the proposed phase. But what this workflow is going to do is it's gonna automate building this entire thing. So how is it going to do that?
Inside of our docs directory, we created these epics. Right?
We had epics for number one, which we just we just did, but then we had epics for two through seven. And so how this skill is going to work or this workflow, it's going to on a new run, it's gonna look here, and it's gonna try to determine all of the unimplemented changes that, like, we we have not done so far.
It's then going to run through this proposal phase for that specific epic.
Once it's finished with that proposal, it's gonna move through and it's going to actually implement the thing. And we're telling it to, you know, use an implementer per sub agent per per phase, do the adversarial review. We can tell it to call specific skills, all of that type of stuff.
Then we're gonna verify the work, and then we're going to finalize it, which in this case means, like, syncing our specs and archiving things, and then moving on to the next epic. And so this thing should run through then and implement this entire thing for us.
So that is what we are going to test out right now. And so I am going to come down into our project, and I'm gonna basically just tell it run this dynamic workflow for the epic implementation.
Now the thing that's gonna be nice about this once it actually boots up and starts running is that, yes, this is obviously going to, like, consume more tokens. Right?
It's gonna consume more tokens. It's something a lot of people like to complain about. But why is it consuming those tokens?
Well, it's because this thing is going to be running autonomously for hours and hours and hours.
And so, obviously, that is something that is going to consume more in order to run. Right?
It's running continuously in the background. And so we can see this thing running now. So it moved through the discover phase.
It found all of the epics that have not yet been planned for, and now it's gonna move through. It's gonna run that proposal, generates the proposal dot markdown file, the design markdown file, the specs, and the tasks.
It's implement them. It's gonna do the adversarial review.
All of that stuff, you could put testing phases in here where you give it access to an MCP server that can control browsers or iOS simulators, like, actually do the testing, and then it will move on to the next one. So this thing should theoretically theoretically run potentially overnight depending on how long this is gonna take, but we will we will let it run, and then we will pop back depending on how long it takes.
I might be in different clothes. What's up, guys? It is tomorrow.
So this thing ran for twenty hours overnight. Now the reason this took so long is that when I let these things go unattended, I bake in serious verification loops.
I do not let it just run through and try to build the whole thing, and then I I wake up the next day and and none of it's been tested. So, again, I have things built into this process where it's going to verify things.
It kicks off adversarial reviews. It will drive the iOS simulator to check the work.
I try to put a lot of checks and balances in place, which is why, in this case, seven epics, which isn't the craziest amount of work, ran for so long. And now some of this was I had to wake up the next morning, and it it had some questions for me that I had to answer.
And so that's part of why this is sitting here for so many hours. It didn't actually take twenty one hours worth of work.
It was it was definitely shorter than that, but there were some time sitting there waiting for me to answer stuff because it was done really early in the morning. So that being said, we should be able to go in now and actually test this thing. So if we open up the simulator, and I'll go full screen here, we can see that we have a completely blank screen.
Again, I haven't spent a lot of time, much time at all realistically, on thinking about the UX and and the UI and what this is meant to feel like and all of that, because this is, again, a basic utility app for me in the course of my daily life. I don't really care that much about certain aspects of it.
So just keep that in mind. If if we were to actually do this for a real project or real product, we would have spent a lot of time, several hours, if not days, in the actual UX planning phases.
So just keeping that in mind. So now, we can come through here, and I have a few different PDFs uploaded into this simulator already, so I'm gonna come through it.
I'm just gonna select one of them, and hopefully, works. So it's gonna move this process move through this process of of loading. I think it's a little redundant.
We have three different loading indicators in here. So this is the type of thing that you're gonna end up with if you if you skip some of the planning processes, because, again, we move through this pretty quickly.
This is why we get things that are, like, redundant, and they're all trying to do the same thing, and certain things might not make sense. That was pretty quick for the for the parsing of it, and now we should be able to click into these days. What I'm expecting based on what we had built is that if it wasn't able to parse any of the specific days exercises, it's gonna ask us to confirm them against the PDFs.
So let's just move through some of these and see what it is like. So for our warm up here, let's see.
It's got the mountain climber, the renegade row, body weight, reverse lunge, and burpees. That is correct for the the first one.
If we were to look in here now, so for block one, we had a hip airplane, dumbbell pecked flies, and then a calf raise.
The one thing that's obviously missing or maybe not obvious, but is missing from this for sure, I'm not gonna pretend like this stuff just flew through and did everything on a one shot. This should have more for us. So dumbbell peck flies, for example, like, those are weighted, and we don't have the option to put in the weight in this specific section.
Part of the difficulty with this, just for full context, is that what is happening is that the way this back end or this system is working is that the language model is parsing our PDF out. And then based on what it parses out, it's trying to generate these weeks on the fly.
It's, again, it's using, like, a generative UI type of type of thing to say, hey. These are the types of things that I can create, and this is what the user asked me for. This is what was in the PDF, so I'm gonna try to assemble these things.
And that is not a super deterministic kind of thing.
You could run this PDF through several different times and get different responses every time you do it. That is one of, like, the fundamental weaknesses, if that's what how you wanna think of it, of using agents and language models to do things that are, you know, logic.
They're meant to be, like, core app logic. That's one of the the big hiccups that you can run into when you try to do this type of stuff. So this is something that we would then need to come through and actually resolve, and we would need to have some back and forth with our system to of point it in the right direction and start refining this thing.
So, for example, I should be able to come through here. If I'm running through this block multiple times, I should be able to log these things through multiple times, and we can actually pop open the PDF and look at what what this should be. So what we're looking at here, this is what it is meant to be.
So we're looking at block one, and it's meant to be five minutes. So it's a five minute running clock, and you do as many rounds through this as you can. But the thing is the dumbbell pec fly needs to have a wait, obviously, and then we need to be able to specify how many of the rounds that we got through and making sure that we're specifying how many reps we did each round through, and that is currently missing from our from our user interface.
And so that's the type of thing that I'm talking about that that we would need to dial in. If we go to block two over here, we can see that it it is dialed in for for this one.
So there's five rounds that we can move through, and then in each round, we're specifying, you know, what was the what was the wait we did, and then what were the number of reps that we did. And so we would be able to go through and continue logging all of this.
So it's it's working in some of the situations, and it's not working in other situations. And I think that's just due to the nature of it trying to it's trying to parse this thing out again on the fly.
And so the way that I would think about fixing this in a simple way is that any exercise on here is something that the user could decide to add weights to, weights and reps, as a as a specification.
And so if we were to add that in, then anytime we run into one of these situations, that's something that we could we could move through and just resolve. So now if we were to move through and just, like, look through some of the other days, if we go into day two, we can see, you know, similar thing where there's there's probably some situations where it's not rendering exactly as we would want to.
But overall, this is something where I could move in and and actually start, uh, using it. So here's another example with the single arm dumbbell press.
This is something that we would we would wanna be able to specify what the weights were that were being used. So out of everything in here, I think that's that's the one big thing that I see is is missing.
But that and in the grand scheme of things, that's not like a a big thing to have to resolve. Right? We can just move in and and resolve that.
And then there's some situations where there's things that definitely should not be, like, weighted. For example, like a a frog stretch. Like, that's not something that we're putting weights on, so this would probably just be for time.
So there's small little things that we would need to dial in. But again, we did not spend a lot of time in the actual, like, specking phase for this project. So stuff like that is honestly to be expected.
We can't just think that the language model is gonna fill in the blank and do all this crazy stuff that we never told it to to do. So before we go, I just wanna show you guys really quickly what I would do with all of these bugs.
And so what we're looking at here is a different project. This is a an AI native nutrition tracker that I've been building. And what I do in here whenever I run into bugs, like the bugs that we've been looking at inside of this project, I will put those inside of GitHub, and I will specifically tag those issues as bugs, and we can see that here.
And then what happens is, like, once a day or several times a day, depending on how much I'm testing it and trying to get this thing ready to go, I will kick off a workflow just like the other one that we ran that moves through the bug backlog specifically, makes the fix, or first tries to understand why is it broken, makes the fix.
You can configure it to reach out to you as the user if you want it to, in order to, like, get on the same page about certain things. And then, again, it'll move through. It'll actually perform the fix.
It can test the fix itself, interact with the the simulator or the browser or whatever it is that you need it to do, and then that becomes a a really fast way to move through and fix things instead of us just having some, like, really janky, not systematized way to actually track all of these things inside of our projects.
So that's it for this video, guys. If you want help with any of this stuff, like configuring workflows that work in the context of your project, figuring out how to, like, define MVPs properly, scope them properly, build them so that they're production ready, and then actually take them to market and make money from them, check out the link in the description below.
But that is it for this video. I will see you in the next one.
The Hook
The bait, then the rug-pull.
Becoming an AI builder, Sean Kochel argues, is a once-a-generation opportunity — but only if you have a system, not just a prompt. He spends the next 54 minutes proving it: turning a genuinely annoying personal problem (tracking gym PDFs in YouTube comment threads) into a fully scoped, researched, designed, and autonomously built app, using five stackable Claude Code skills instead of one long freeform conversation.
Named ideas worth stealing.
00:40list
The 5-Step Claude Code Build System
- Light PRD
- Deep research
- Claude Design
- Vertically sliced epics
- OpenSpec proposal + implementation loop
The overall pipeline the video demonstrates end to end, each step handled by its own reusable skill.
Steal forany solo build going from idea to shipped feature with an AI coding agent
39:10list
OpenSpec change bundle
- proposal.md (why)
- design.md (system approach)
- specs (per-capability requirements)
- tasks.md (build list)
The four artifacts OpenSpec generates for every planned change before implementation starts.
Steal forany spec-driven dev setup that needs a human review gate before an agent starts coding
41:40list
Epic-runner workflow phases
- Discover
- Propose
- Apply (implement)
- Verify
- Finalize
The five phases the dynamic workflow runs per epic — scan for unimplemented epics, draft the OpenSpec proposal, implement with a sub-agent per phase, run adversarial review, then sync specs and archive.
Steal forany long, unattended multi-feature build that needs guardrails instead of a single giant prompt
How they asked for the click.
VERBAL ASK
53:20link
“check out the link in the description below”
A brief, unforced single-line CTA at both the open and close pointing to his Skool community for hands-on help — no hard pitch inside the tutorial itself.
MENTIONED ON CAMERA
Visual structure at a glance.
