What should I build, and how?
The expensive mistake in a short program is building the wrong thing well. Agentic Buildcamp puts a cadence of people around that decision, a gym that adapts to where your project actually is, and a build loop that makes you validate before you sink weeks into it.
Who You Build With
Deciding what to build is a lonely call when you make it alone. The program surrounds that call with people, not just process. For when each of them sees your work, see the calendar below.
Your mentor
A practitioner who has shipped this kind of system, watching your build every week: live at stand-ups, async on Slack, and on every demo you submit.
Your cohort
Builders working the same weeks you are. Hearing what they are stuck on, and what they tried, is often as useful as your own mentor's answer.
The wider practitioner room
Your public demo goes in front of the broader community and network, not just your cohort: experienced practitioners, founders, and sometimes angel investors or corporate directors. Builders regularly land follow-up meetings with people from that room.
+ If you've added 1-on-1 mentorship
You'll also meet weekly with your mentor to discuss your project one on one, at whatever timing works for both of you: you book directly against your mentor's availability using a link they share with you, for one week or several at a time.
What Is On The Calendar
The schedule below is the live calendar for the cohort currently open for signups. Every marker on it is one of a handful of recurring session kinds, and here is what each one is.
- Meet & Greet
- The opening session of a cohort. You meet your mentor and the other builders, and you leave knowing who you are building alongside for the next several weeks.
- Stand-ups
- Short live group sessions with your mentor and cohort, daily in the first week and again in the final week. You say what you are building, what is blocking you, and you get feedback and answers on the spot.
- Cycle Demos
- Each build cycle ends with a recorded demo. Mentors review every submitted demo individually, and the group watches and discusses a few of them together, so you see how other builders approached the same problem and what feedback they got.
- Public Demo
- The final demo, presented to the broader community and network rather than just your cohort: experienced practitioners, founders, and sometimes angel investors or corporate directors.
Full schedule
Loading schedule…
Your Personalized Journey
The calendar above is the same for every builder in the cohort. What is not the same is what happens between those sessions: which Blocks are open for you and what Sherpa-B hands you next depend on your own project and stage, not the week number.
Your program is a set of Blocks, not a fixed syllabus
Sherpa-B lays your work out as Blocks, each a risk-driven arc of Tasks inside one of three Zones: Build, Reach, Monetize. Each Task is a single sitting of work, either guided (a step-by-step workout runs it with you) or freestyle (you agree an approach and go). Which Blocks are open for you depends on what you have already done, so two builders in the same cohort rarely see the same next step.
A coach that decides what is next with you, from live context
You keep the
/coachcommand running in one terminal while the work happens in another. Before it recommends anything, it pulls your upcoming and recently touched Tasks, your open GitHub issues, the cohort calendar, the date, and your own running list of open worries. Then it gives you an actual recommendation with a reason (continue the thread you were deep in, or deliberately switch), and you agree, push back, or redirect.Ideation runs differently on your first feature than on your fifth
On a first run, with nothing built, the
/ideationworkout works generatively from your project idea. On later runs it works reflectively, grounding the problem framing and the options in how your thing actually behaves today. Same workout, shaped by where your build is.
The Build Loop
A workout is a guided, step-by-step procedure you run in your coding agent. These five are the loop you repeat every cycle: decide, build test-first, review yourself, ship clean, rehearse the objections. You learn the methodology by running it on your own build.
- 1
Ideation
/ideationThe front end of every build cycle, not a one-time kickoff. Frame the change you want to make, surface the assumptions under it, look at genuinely different ways to do it, and pick one. It ends with a spec and an experiment plan for validating the riskiest assumption, plus a GitHub issue the next workout picks up. If the honest answer is "go talk to real users first," it writes no spec at all.
- 2
Begin Coding
/begin-codingSelect the issue, create the branch, write the tests first, then implement against them. The order is the point: a coding agent will happily build the wrong thing quickly, and tests written up front are what keep it honest.
- 3
Review My Code
/review-my-codeA structured self-review of your changes against the branch base, with quality checks and iterative fixes, before anyone else looks. You catch what you would otherwise hear about in a demo.
- 4
Finish Coding
/finish-codingUpdate the specs, file the follow-up issues, clean up, and mark the pull request ready. Nothing ships with a stale spec or an unlogged loose end.
- 5
Sparring Session
/sparring-sessionBefore any demo or pitch, one round with one persona (a customer, a CTO, an investor, a hiring manager, even a grandma) who pushes on your choices hard enough to find the real gaps. Findings land on a shared feedback checklist your coach reads back to you, and anything that needs a code change becomes an issue.
Evaluation is folded into this loop rather than graded after it: quality risks, test cases, and agent evals are written as you build, and user interviews and stakeholder conversations are part of the work, so what you ship is grounded in what people need rather than what you assumed.