That’s from a thread on r/jobs I’ve been reading for the last couple of weeks. It’s not an outlier. I’ve now read hundreds of comments from people working through knotted emotions around job obsolescence, losing meaning, feeling like a “meat proxy” in steering AI.

“I’m scared, I fear my career may have just come to a screeching halt.“

“Lately for the past year I’ve been super depressed knowing that the end is near for the industry.“

“It just really hurts that I spent well over a decade of my life learning and honing skills to engineer safe, quality software and now it’s just, useless.“

One person described grinding their teeth in their sleep. Another wrote that employees are now seen “as a liabilty to be replaced with AI as soon as practical.”

People are scared and I think I’m uniquely positioned to do something about it.

Anyone can build now

I’ve taught 22 people to build with AI in my vibecoding course. All 22 shipped a working app.

Some of those changed lives. Ramin had an idea for a health app he could sell to enterprises and he took my course, vibecoded a proof of concept, raised a pre-seed round and is now off to the races with Healthy Canary. Shannon had an app idea sitting on his to-do list for as long as he can remember built on material from a mentor, a doctor friend who has since passed. In the course he finally built it and launched it in his friend’s honor.

William had managed multiple tech projects that never got finished, and had never written a line of code. Here’s how he put it:

“You get past those first couple days and you realize this is just the best time to be alive.“

“Tech is so much of a creative. You’re an architect of whatever you want to build.“

He has since built Dynamic Event Suite, a tool to improve the efficiency of his own events business and then productized it and offered it to other event organizers struggling with dwindling event numbers to help them reinvigorate their events and maintain profitability.

Watch the student testimonials

Building things right is no longer the hard part. It’s now a matter of building the right thing.

These students above knew their fields deeply so they had the pre-existing audience and domain expertise to build the right thing based on previous experience. For the rest of us unless you have fought in the trenches alongside your prospects, you won’t have the degree of customer empathy necessary to serve them.

The hard questions

What do you build? Who is it for? How do you make something people will actually buy?

These are the real challenges my students wrestle with now that they know how to build. The vibecoding craze has democratized who can create software and lowered the bar for who can build software. And while this is amazing it’s like giving Promethian fire to people that don’t know what to do with it so they’re out scorching the countryside.

Why this matters right now

If these threads on Reddit and Hacker News are to be believed, society (starting with programmers) is now wrestling with a crisis of meaning and all the gnarly emotions that come from realizing the craft you spent a lifetime to hone is being performed better by machines.

The way to defend one’s relevance in this scenario is not to turn a blind eye and pretend it’s not happening. Nor is it to take the Luddite stance and chuck wrenches in the gears sabotaging data centers. Nor is it to pout around and complain online pining for the glory days of old. The way forward is to lean into the role change and immerse early in learning how to leverage these tools.

DHH gave this amazing talk recently framing it so eloquently. Watch all three minutes of this clip:

My thesis

The best way to learn anything is by diving in and getting your hands dirty with it.

Build a lifeboat using Agentic AI in the form of a cashflowing, passive revenue-generating side hustle that you can build up in your spare time and this becomes your insurance policy. Once you have it working you have max negotiating leverage and peace of mind.

Ironically in the process of building the lifeboat the skills you acquire are exactly the skills that make you the last one to be let go in a company. So not only do you have the fallback but you represent more value to your current employer.

One senior engineer in a thread about feeling obsolete put it plainly: “I’ve been showing my managers in different ways that I know more about AI than many people in the company.“ Another, 22 years in: “I was scared a year ago, I’m still uncomfortable today but at least now I’m in favorable position.“

That all sounds great Sean, but how?

There are time-tested entrepreneurial frameworks that have already proven themselves. They have Lindy having served entrepreneurs for decades. By stacking these and sequencing them in order we can leverage AI to assist with the grunt work and spend our time on the parts that truly need our judgment, domain expertise and taste.

That’s FounderOS.

What it is

A stage-gated system that draws inspiration from Amy Hoy and Alex Hillman’s 30x500, Steve Blank’s customer development, the Business Model Canvas, Infusionsoft’s lifecycle marketing and about a dozen other frameworks I’ve used over the years. Each step has a deliverable, and it coaches you until you get it right before you move on. You go at your own pace and it leads you from zero to hero.

There are a bazillion courses and programs and mastermind groups out there but I have yet to see the resource that pulls apart the best frameworks, agentifies them and leads you through a system self-serve with AI as co-pilot to reliably get to a winning result.

How it works (and how this post was made)

Everything quoted at the top of this post came out of FounderOS. I picked an audience (people worried about their jobs in the age of AI), found the threads where they were congregating, and ran them through the system: 25 threads, over 13,000 notes on what they struggle with, what they fear, how they are dealing with it. A process which would have taken months of reading and analysis pre-LLM can now be done in days with the right tooling.

• Start with people, not an idea. Pick an audience you want to serve.

• Go where they talk. Observe the communities and read the conversations already happening there.

• Make sense of it all. Fears, dreams, what they buy, their vocabulary. The LLMs do what they’re good at: chewing through huge piles of text, finding patterns, surfacing clusters.

• Help first. Speak to them in their own words and give away small, useful fixes. That builds trust and starts conversations.

• Map it all onto a Business Model Canvas. This is your overhead map of all the physics of the business and how you navigate and perform experiments.

• Own your real estate. That content lives on your blog, so the equity builds up with you: SEO, and now AEO and GEO too. You get a reliable fountain of highly-calibrated educational content.

• Let the product emerge from analyzing all those conversations. All the insights from digging into what people are saying and reading between the lines then aggregating it across threads and formulating and testing hypotheses.

You still need to read (a TON) and load up the ultimate computer (your brain) with the source material but at this point we have LLM’s to assist with the grunt work of finding and surfacing insights.

You retain agency: the direction, the hypotheses, the vision, your own personality in the messaging - the system surfaces the opportunities and proposes avenues to explore. You still have to walk the avenues but the result is a level of customer empathy and depth of understanding that emerges organically from the market vs. you imposing your idea on the market. It avoids the doom loop trap of endlessly pivoting, duct-taping and product-market-fit retrofitting to preserve the thing you built instead of building the right thing from the start.

Is it finished?

No. Reid Hoffman famously said: “If you are not utterly embarrassed by the first version of your product, you’ve launched too late.”

FounderOS is embarrassingly early, but it’s to a stage where I’m now using it myself so it’s time to invite a select few to begin trying it.

What happens on November 5th

I’m unveiling FounderOS for the first time to the people in the room at this event. We’ll take a volunteer and run FounderOS live from literally zero: find where they hang out, mine the threads, pull out the insights, write a first helpful piece of content.

People in the room get:

- A first glimpse at FounderOS and skip the waitlist

- €200 off the Agentic AI Mastery Weekend happening Dec 11 to 13 at DOMA in Mafra

Seats are capped at 50 and it’s free, but you need to RSVP to claim your spot.

Claim your spot

If you’re not in Lisbon the event will be recorded and posted to the site. You can read more about FounderOS and join the waitlist here.

There is no better time to be building but only if you’re building the right thing. Let’s help you figure out what that is for your people and in the process of doing so give you both the lifeboat and the superpower that makes the lifeboat unnecessary.

-Sean

If you’ve done much work with LLMs you’ve likely experienced this “cognitive swiss cheese” feeling - the mental tax of wading through paragraphs of LLM-generated text. This thread went viral in the development community a few days ago with hundreds of people piling on expressing this frustration.

LLM’s are great token predictors for generating textual responses. But there are two main contributors to that “brain damage” cognitive fatigue everyone is experiencing: 1) LLM’s don’t fundamentally “understand” concepts the way humans do - they don’t maintain mental models of the world and perform assimilation/accommodation on their schemas, they are just predicting the next most logical token in a sentence. This means they can’t explain phenomena like physics the way Richard Feynman could explain physics because they lack a ground up mental latticework of the concepts. 2) Even if they were to gain this capability, they are inherently text-generating factories that return paragraphs of verbiage as responses. Not everyone learns best from reading - some of us are auditory and/or spacial/visual learners and we need a multi-modal experience.

#1 is a deficiency of the current state of the tech. This is gradually getting solved by stronger models, tool use and deep reasoning chain of thought iterative calls. Almost at some point with enough parameters and stackable model tooling it will arrive at something approximating cognition and understanding. Until that happens we can’t solve deficiency #1. #2 however is fully-solvable today and I’ll show you how.

A multi-modal tutor that meets you where you’re at

What if instead of receiving blocks of text responses to your questions you could get back animated explainer videos that meet you precisely where you’re at? What if the “tutor” could first do an archeological expedition to unearth your current level of understanding of a subject to know exactly where your knowledge gaps are and then fill those in via custom-built animated explainer videos?

The Video Explainer skill

I use Loom a lot for making narrated screencasts that capture requirements with me explaining something to the LLM and being able to talk through it on my screen. I open sourced this plugin back in July to make it so my bot could ingest my Loom videos and immediately have the narrated transcript to correlate with the video frames and be able to make sense of my videos. This has been a game-changer for communicating complex requirements, reproducing bugs, or even just talking through my todo list and priorities to communicate complex info quickly and with high fidelity.

This video explainer skill I just released is the other side of that coin giving any agent the ability to respond with its own equivalent of a narrated Loom video. This too has been an absolute game-changer as an alternative to having to wade through paragraphs of explanation for understanding what it’s trying to convey. We can essentially have high-bandwidth inbound/outbound comms with our agents now the way we would communicate by trading Loom videos.

The irony here of me explaining all this via paragraphs of text is not lost on me… so here’s a real example of how I used this tandem set of skills today:

I’m currently learning how to solve a type of number puzzle called “KenKen” (it’s like a variant of sudoku with these caged regions in which the contents have to obey certain math). Here is the Loom video I made today for my bot Jax when I got stuck:

KenKen Strategy for Spotting Logic Errors - Watch Video

And below is the animated explainer video I got back from Jax as a response:

What’s great about this is I’m able to very quickly give it my current understanding and express what I’m struggling with and why. It can then process that and instead of giving me a wall of text to decipher and understand, it can just talk me through it the way a tutor would explain something at the whiteboard.

The implications

I showed this to my buddy Marc and immediately he said “Khan Academy should be all over this.” 100% agree with him. This would definitely amplify the Khanmigo AI tutor to be more useful to audio/visual learners. But think about the other implications this has:

• To content marketers: this is a factory for lead magnets that show concise solutions to customer problems.

• To site owners: imagine the evolution of context-sensitive help widgets that rather than giving boilerplate tutorials could ingest your visitor’s session through something like Hotjar and then give return a custom explainer vid based on their session and their inferred intent.

• To educators: your students who are falling behind can now get calibrated help to meet them exactly where they’re at and clear up their misunderstandings. Conversely your star students can get stretch tutoring to push them beyond the standard book material with more sophisticated concepts.

These are just a few of the use cases that come to mind. Auditory & visual learners are finally on equal footing with reading-centric learners in being able to get bespoke tutoring from the LLM’s via the formats at which they excel.

How to use it

These are two separate skills that can work independently but are more powerful together. If you’re using something like Claude Code, easiest is to point it to this github repo and tell it to install the loom-vision and video-explainer skills.

How it works under the hood

This post explains the Loom Vision skill.
The Video Explainer skill basically has two generation modes:

1. Simple: uses ffmpeg + whisper to make a basic narrated explainer vid with just frames that change.

2. Advanced: uses Remotion + whisper to make a narrated explainer vid that can do fades and animation and save the template so that it can be used to change elements dynamically next time.

The simple mode is faster and uses less tokens whereas the advanced mode uses more tokens and requires extra time to render the full video.

Where to go for more

There are a handful of other useful skills in that github repo above. These and more come standard in Behalf.bot which is itself open source. I’m also now teaching others my methodology for using SiYuan as a 2nd brain and building up a bespoke knowledge base of interlaced learning videos for being able to learn anything. You can learn more about that program here. I hope this pair of skills helps you in having a more audio/visual way of communicating with your agents.

If your job involves Agentic AI then you likely spend a good portion of your time conveying complex, nuanced directions to your agent daily by pasting annotated screenshots and writing paragraphs of narrative text to explain current and desired behavior. I was doing this for a long time until I had the “1MM words” epiphany.

My workflow for the past few months has been to freehand write out my priority list on my reMarkable tablet in the morning of all my high-level todo’s prioritized by importance. I then record a followup Loom video in which I narrate my list cross-referencing the notes from the reMarkable app on my iPad with web pages and anything necessary for explaining the rationale and goal of each request.

Claude Code is my daily driver and already has read/write access to my tablet to be able to ingest and transcribe my handwritten notes so when I’m doing the loom vid narrating my list, it has already scanned it and I’m just enriching what it has with context and explanation. This has yielded a complete step change in terms of my ability to convey high-level goals accurately with near flawless information fidelity at high speed. I then have CC parrot back its understanding of my directives before it launches into anything and 98% of the time it gets the list exactly right, deconstructs goals into its own actionable todo’s, asks any clarifying questions and then just goes and executes. And because it has my narrated rationale and stream-of-consciousness thoughts it on occasion can catch false assumptions on my part and provide even better suggestions than I had proposed.

How it works

Here’s an example of the most recent Loom I just recorded:

iOS recording - 18 Jul 2026 - Watch Video

What’s actually happening behind the scenes via the video ingestion skill is CC:

1. Downloads and parses the transcript

2. Downloads the video file and uses ffmpeg to parse it into frames

3. It then correlates by timestamp in the transcript which frames correspond to my narration so it can understand when I say “Move this here” exactly what I’m pointing to and talking about.

I use this not only for software engineering tasks in reproducing bugs or conveying ideas for complex UX sequences that involve many screens, conditionals and lots of moving parts but as you can see in my example video, I am using it for handling high-level operational issues across many aspects of my life now. I have it integrated to SiYuan as my second brain and it uses that system as persistent long-term context storage with Memory MCP as short-term context storage. Combined with various tools/skills it enables it to serve essentially as my EA automating a ton of admin for me.

How to set it up

I’ve made this skill available via ClawHub.ai here so you can get it with a single line install:

clawhub install @scrollinondubs/loom-vision

Or if you prefer you can grab the source code directly from github here. It comes as a core primitive of Behalf.bot along with the ability to read/write OTA to the reMarkable tablet. Installation is straightforward via the README and it should work with both Claude Code and Claude Cowork as well as any LLM powering OpenClaw.

Nota bene: I teach my systems thinking-based approach to using CC via this course and as well run weekly office hours helping people gain leverage with Agentic AI in their lives via Vibecode Lisboa. I’m also in process of recording a follow-on second half to that course that teaches how I use Behalf.bot as my EA for high-leverage operation as a solopreneur - if you want to be the first to receive that course, request a notification here. Hopefully this skill helps you streamline how you’re interacting with your agent and improves your efficiency.

I’m going to share the key learnings from this experience and how I used the open source Behalf.bot agent day-to-day to keep me on track.

What is “Body for Life?”

This is a 12-week fitness program created by Bill Phillips back in 1999. You can still get the book here on Amazon - it’s very good. It’s basically a regimen of diet and exercise that can be distilled down to some very simple rules:

Diet:

1. Eat six times per day

2. Portion sizes are size of your fist and you should eat a protein, carb and vegetable or substitute a protein shake for a meal.

3. There’s a list of authorized foods and ones that are off limits (primarily saturated fats and trans fats)

4. Sunday = cheat day. Eat whatever you want. Pizza. Ice cream. Whatever. The sanity valve...

Exercise:

1. Alternate gym and running every day

2. In the gym alternate between upper/lower body each workout. Muscle groups: Upper = chest, shoulders, back, biceps, triceps. Lower = quads, hamstrings, calves and abs.

3. Interval training:

   1. In gym start high reps, low weight and work up to low reps, high weight. Do that for each muscle group then add an extra exercise for same muscle group where you go back to high reps low weight and try to hit a high intensity point and the end of each where you go to failure.

   2. In running: runs are short - 20min. 2min warmup then 4min blocks of progressively increasing intensity aiming to go flat-out during minutes 5, 10, 14, 18-19 then a 1min cooldown.

4. Take Sunday off. No exercise.

That’s it. That’s the entire program.

Of course it’s easier said than done and success in the program comes down entirely to your ability to stick to it for twelve weeks.

I had actually completed the program 17 years ago and achieved some impressive results back then. The open question this time was whether I could pull off similar results at age 50...

How I used Agentic AI to stack the odds

The program encourages participants to keep a meticulous journal of their meals and workouts by logging every meal, run and workout.

I started out logging everything in a notebook but wanted to have the info digitally. I teach a vibecoding course and initially figured I’d just vibecode an app to track all this stuff. But thinking through what that experience would be like constantly tapping on my phone in the gym after every rep logging the exercise seemed super annoying. It occurred to me I already have a capable agent accessible via Discord via the Behalf.bot code I open sourced and that maybe a simpler option instead of coding a new app from scratch would be to just make a dedicated channel for health stuff. I could then log my workouts via shorthand in a notebook and then just upload photos of the journal and have handwriting recognition parse those pages into data in a database. I could also have an LLM estimate the macronutrients of my meals and log those. Combined with my sleep and recovery data from my Oura ring this should give a really comprehensive picture of everything.

Using the bot itself to implement these as skills I taught it my shorthand for logging exercises and it became as simple as snapping a photo of my notebook after every workout and snapping a photo of every meal. I had it use gpt-4o-mini for photo recognition and at less than $.01 per image it gives me a decent estimate of the macronutrient breakdown of everything I’m eating and extracts the reps, weights, intensity, exercise, muscle group and workout date & time and logs it in the database.

With a little more work I made a little dashboard using FastAPI that allows me to see all my workouts, meals, runs and sleep data in one place. And because it’s structured data in a db it’s queryable ad hoc by talking to the agent.

I then have my bot Jax configured so that every morning when I take my Oura ring out of airplane mode it syncs and Jax gets the night’s sleep data and then assembles a morning briefing with a bunch of helpful stuff starting with a plan based on the previous day’s workout, meals, sleep, etc. It puts together a little motivational briefing starting with the health rundown and an analysis of the day’s Daily Stoic thought.

Some takeaways from this process

1. Could you do this program without using a bot to track everything? Of course. And millions of people have since 1999 but if you’re a quantified self person and seeing the data day-to-day motivates you to stick with it then the tools are all there today to make it relatively frictionless for logging the data and presenting it in a helpful format. I managed to make it the full 12 weeks without missing a single run or workout. On the meal regimen I admittedly averaged around 4-5 meals falling short of the prescribed 6. Had to find a feasible balance of convenience and effectiveness.

2. Working with agents gives you malleable fabric that can adapt to the way you want to work vs. trying to shoe horn your process into a brittle app that works its own way. It was less work to build and ultimately a better UX to just upload photos to Discord rather than build a mobile app for tracking this stuff. I baked the Body for Life skills into the Behalf.bot chassis so that’s a standard plugin that anyone else can now use. And I packaged it using the OpenClaw plugin format so that it can be easily ported to that system if that’s the harness you’re using.

3. Bill Phillips’ program still holds up a quarter century later. Its strength is its simplicity and I was stoked to be able to use what I know how to do to stack the odds of sticking to it and completing the program in my favor. Hopefully at this point the diet and exercise habits are ingrained enough to stick beyond the 12 weeks of the program.

I had Jax export all the data from my 12-week program and create a clickable dashboard replica of my dynamic one so you can see how my dashboard for this works. Click image below and browse to any day of the program to see how it worked.

And here’s a Loom vid showing how I actually use it:

If you’ve read this far, thanks for reading. I highly endorse the Body For Life program. I’m planning to share some other creative uses of how I’m using Behalf.bot to help me in my day to day. Subscribe to my substack to follow that journey and/or get your own Behalf.bot here. And if you want to learn to vibecode as a non-technical founder using Claude Code we’re taking applications for the next cohort here.

What is Behalf.bot?

It’s basically a more capable Open Claw that can legally run under a Claude Max subscription so you have it for a monthly fixed cost with an incredibly capable model powering it.

The story behind it

Back in early February I setup Open Claw and tinkered for about a month but it was like the main character from Memento - incapable of performing any kind of ongoing work that involved multi-step tasks. Anytime I could get it do something useful it would wake up the next day like an amnesiac oblivious to what we had done. I’d spec out a skill to compose a morning briefing and one day it’d be in HTML format with all the desired sections and the following day it was in markdown format with completely different sections and content… even the simplest templated jobs couldn’t be replicated reliably - very frustrating.

Rather than give up though on the vision of having a capable virtual assistant agent I played a hunch that Claude Code itself could become a capable harness for an assistant. Anthropic had just announced their new channels feature which made it possible to use chat apps like Discord, Telegram and WhatsApp to interface with it.

Fast forward three months and Behalf.bot has evolved to become an essential employee for me. Just some of the things my agent Jax does for me daily:

• Content marketing (research, revisions, social promotion)

• Morning briefings (aggregate info from multiple sources)

• Quantified-self tracking & advisement (workouts, macros, sleep, runs)

• Dating profile automation (concierge full-serve handles chatting up people and setting coffees)

• Customer service and billing for Vibecode Lisboa

• Multi-modal interaction (voice in/out & collab via the reMarkable tablet)

• Claude Pulse self-improvement (auto finds ways to make itself better)

• Autonomous software engineering (builds apps and landing pages end-to-end with just voice direction)

• Midnight Oil (autonomously ships PRs overnight)

You can see demonstrations of these in the video below where I unveiled this at our last user group meeting:

Why this all matters

The world of work is rapidly evolving. Some activities and roles are being commoditized while other new opportunities are blossoming from agentic AI. We are still incredibly early in the game but now is the time to roll your sleeves up and get dirty with this suff to learn how it works.

Pick a fun idea as a side project and see if you can accomplish what you’re imagining using an agent like Behalf.bot. This is all just practice and gives you early first-hand exposure to agentic engineering which is the only way to learn. You don’t learn to surf by reading a book about it - you learn by getting in the water and trying to ride waves. It’s no different with this stuff.

What’s next

You can download the entire codebase here. I’ve also created a fully-managed whiteglove install option that’s available for purchase on Behalf.bot for €250.

We’re just finishing Cohort 4 for Build School. Cohort 5 will be completely restructured around using Behalf.bot to do fully-agentic software development as well as marketing, sales, customer service and other functions of whatever side hustle you’re intending to start. If you want to be part of that next group join the Vibecode Lisboa community and stay tuned for the announcement once dates are locked down for Cohort 5.

There has never been a better time to start tinkering with agentic AI. Watch the video above to see what it can do and star the repo on Github to follow along as this project evolves.

When someone spends two decades learning to write production-grade code by hand and then watches a non-engineer ship a working product in a weekend with English prompts, it’s understandable why the reaction is to lash out. The pushback takes a familiar shape: vibe-coded apps are buggy, insecure, unmaintainable, unscaleable.

We have run this play before. Twice that I can remember, and both times the people in front of the curve got called clowns by the people behind it.

ColdFusion, 1998

I started my career building web applications in ColdFusion. ColdFusion was a tag-based language. You wrote it like HTML with a few extra verbs. If you could write <table>​, you could write <cfquery>​. Bolt a database to a website without learning CGI or Perl or anything that had a real syntax tree. The learning curve from a static HTML page to a real dynamic application was measured in days.

The CS-trained developers hated it. They had spent years on pointers, memory, threading models, build systems... ColdFusion let laypeople who hadn’t done any of that ship working web apps. The criticism was identical to today’s vibe-coding pile-on: the code is sloppy, the apps don’t scale, the security model is whatever the developer happened to think about that morning.

And some of that was on point. ColdFusion apps did get hacked. They didn’t always scale. There were sloppy ones because the bar had been lowered for who could write applications.

But net net the pie exploded. A whole generation of people with deep domain expertise and zero CS background suddenly had a way to build the application their job needed. Real estate agents, lawyers, school administrators, small-business owners. Software that never would have been written before now existed, served real people, and eventually needed real engineers to harden it once it mattered. The “bad apps” complaint was the visible cost. The invisible win was a much bigger software ecosystem.

Twitter, 2007

Then we ran the playbook again.

Twitter launched on Ruby on Rails because Rails was what let two guys ship a working SMS-to-web service in two weeks. SXSW 2007 took it from 20,000 daily messages to 60,000 overnight. By 2008 the Fail Whale was a weekly regular occurrance. Eighty-four hours of downtime were logged that year. TechCrunch ran a piece literally titled “Twitter Said to Be Abandoning Ruby on Rails.” A Hacker News thread from May 2008 called the dev team “the biggest jackasses in history” for not having written it in Java or C++ from day one.

The critics weren’t altogether wrong in their criticism that Rails wasn’t ideal at Twitter’s eventual scale. But they were also completely missing the point.

If Twitter had been written in C++ from the start, there would have been no Twitter. The team would never have iterated fast enough to find product-market fit. The scaling problems happened because they shipped fast and people loved the thing. That’s the good problem. We should all be so lucky as to build something that generates such incredible demand that it has the fortunate problem of encountering scaling issues.

DHH put it best on Lex Friedman: Twitter was “the best advertisement ever for Rails... because nothing happened for 10 years after they switched over.” The eventual rewrite to Scala didn’t unlock new product innovation. It just shored up what Rails had enabled them to unearth and establish product-wise.

A single Twitter dev ported the message queue to Scala in his spare time and turned a 2.5-hour processing backlog into 20 seconds. That’s the punchline. The “wrong tool” was right enough to keep Twitter alive long enough for one engineer’s spare-time project to become the fix.

The Pattern

Both times, the priesthood got angry that someone had moved their cheese.

Both times, the bar lowered because a new tool let people who weren’t in the priesthood ship working software. Both times, the early output had real flaws. And both times, those flaws were the visible, narratable cost. The invisible benefit was a permanent expansion of who got to build.

Vibe coding is the third turn of this same wheel. People with deep domain expertise but no CS background can now build the application their work needs. Some of those apps will be buggy. Some will leak data. Some will fail. None of that contradicts the bigger point. The surface area of buildable software just got dramatically bigger. The amount of useful software in the world goes up. And with all this new surface area the amount of work for actual engineers (to harden, refactor, architect, secure) goes up too, not down.

What’s actually left for engineers

Software engineering was never just code. It was code-writing plus architecture, taste, customer-extraction, judgment, the ability to look at a half-formed business idea and know which technical decisions you’ll regret in two years.

The code-writing piece is what got commoditized. A model can do bricklaying better than I can now. It cannot, yet, sit across from a customer and figure out what they truly need and translate that into a system that won’t fall over in eighteen months.

The profession of software engineering is evolving, not disappearing.

It’s just decoupling the brick-laying (science) from the architectural aspects (the art). Brick-laying is commoditized and solved at this point. But if anything the artful aspects are ever more in demand.

The engineers who are mad about this decoupling are mad because part of their job got easier and they’re worried their craft is now on the chopping block and will be valued less. The reverse is true. The architects, the taste-havers, the customer-whisperers, their work just became more leveraged. One good engineer can now own decisions that used to require five.

Adapt or cling to what once was. We’re witnessing a Darwinian transition in progress. The people who embrace the evolution of the craft are positioning themselves to capitalize on this disruption. The ones who spend the next year writing angry comments under HN threads are going to be replaced by the people they’re calling clowns.

We should be so lucky

The real risk isn’t building something that doesn’t scale.

It’s building nothing at all.

If a non-engineer vibe-codes an app that gets traction, generates revenue, creates real value for real people, then yes, they will eventually need to hire engineers to harden it. That is the good problem. That is the problem every founder I know would trade their morning coffee for. The gatekeeping impulse (you shouldn’t build software unless you can do it “properly”) is the same impulse that told Twitter to use Java in 2007 and ColdFusion users to learn Perl in 1996. Both times it was wrong. This time is no different.

This is the work, by the way. Vibecode Lisboa, Build School, Confabulator. This is exactly what we help people do. Take an idea, get it to a working prototype, ship it to real users, find out if it matters. The next great applications are going to come from people who weren’t supposed to be in the room.

The bricklayers can keep grumbling. The pie keeps growing.

Sources

• How Twitter Slayed the Fail Whale (Time, 2013) - definitive retrospective on the scaling journey

• Twitter Said To Be Abandoning Ruby on Rails (TechCrunch, 2008) - peak of the Rails criticism

• Did Rails Sink Twitter? (SitePoint) - good analysis concluding it was architecture, not language

• Twitter Clears Ruby on Rails on Scaling (ZDNet) - Twitter’s own defense of Rails

• DHH on Lex Fridman - “nothing happened for 10 years after they switched”

• Scaling Twitter: Making Twitter 10000% Faster (High Scalability) - the technical details

• HN thread on Twitter/Rails (2008) - raw developer sentiment at the time

• The Story Behind Twitter’s Fail Whale (The Atlantic, 2015) - origin of the icon

• ColdFusion (Wikipedia) - history of Allaire’s tag-based language and its market role

• Jeremy Allaire (Wikipedia) - same person, ColdFusion to Circle/USDC

One of the many epic and mind-blowing things about working with agents and AI is that this paradigm that was fantasy 20 years ago is now real today. Our agents can instantly assimilate bottled experience in the form of skills that are just markdown files of procedural instructions which give them new capabilities as if they had trained a lifetime to develop them.

In this post I’ve distilled two months worth of lessons from building my personal assistant Jax from the ground up using Claude Code as the harness. You can find the talk I did last month demo’ing some of its capabilities and how I use it day-to-day. Jax has become indispensable to how I work and live at this point. It’s assisting me in realms of business, health, social life and handling minutiae so can be more strategic in my daily life.

Why now

Tomorrow is AgentsDay in Lisbon and my buddy Marc and I are going to hack on an idea for making prediction markets more agent-friendly. In advance of that event I figured it might be helpful for the participants to have a “training program” they can inject into their agent to get the benefit of what I’ve learned over the past two months in building mine. Some of these are specific to my unique situation but most are universally applicable to anyone attempting to setup their own decidedly-not-Open-Claw personal assistant agent. This is purely an index of the lessons - the expanded version with all the detail on each is available via this talk the access to which requires either a Vibecode Lisboa subscription or purchasing a content license to the talk. Once you have them though you can just say: “Please review the lessons from this blog post and incorporate the ones that make sense given our objectives and scenario into our own setup.”

Wild times.

Without further ado, here is the index of all the lessons having Claude Code reflect and examine our entire working history over the past two months to extract the key places where we went off the rails or down an unfruitful rabbit hole. Note these lessons apply for the scenario of building an Open Claw replacement using Claude Code as the harness on a Mac Mini. I’m using N8n as helpful duct tape and deploy some helper apps to Vercel and Google Cloud.

The 30 Lessons

1. The platform features you think you need, you don’t.

2. tmux is the seatbelt of every headless agent setup.

3. OAuth tokens expire ~8 hours headless and you don’t fight that, you build around it.

4. Discord-channel mode is incompatible with auto-mode today, period.

5. When official APIs hit a permission wall, Playwright against the logged-in browser is the answer.

6. Treat the AI like an employee with its own accounts, graduated trust, and hard limits.

7. Gather first, prompt second — let cheap shell scripts decide whether the model gets to run.

8. Issuing /clear​ over Discord kills the channel pairing — context resets aren’t scoped to the conversation.

9. Pre-emptively respawn Claude Code on a schedule, don’t wait for it to fail.

10. For apps with no web interface, an Android emulator plus UI Automator XML dumps is the universal escape hatch.

11. Scheduled features can be fully scaffolded and still dead if not registered in the dispatcher config.

12. Auto-throttles need new-block auto-lift, not just high-usage auto-enable.

13. Sharing destructive-read state between two heartbeats is a race waiting to happen.

14. Merge-conflict markers in a JSON config silently break every consumer.

15. ​gh issue list --label “a,b”​ requires BOTH labels (AND semantics), not “either” (OR).

16. UserPromptSubmit hooks don’t fire on Discord-channel inbound messages.

17. Vercel Deployment Protection silently breaks automated Playwright testing against preview URLs.

18. Google Workspace primary-domain flip does NOT auto-rename users.

19. DKIM record values get chunked by DNS hosts into 255-char quoted strings.

20. The dispatcher gather script is the right place for expensive checks to no-op cheaply.

21. Adding “negative references” to a similarity-based scorer can collapse scores to zero.

22. n8n’s splitInBatches​ iterates over INPUT items, not nested array fields.

23. Webhooks that send email need to persist the returned Gmail threadId​ immediately after send.

24. When testing an auto-picker, the trigger conditions matter more than the query logic.

25. Three failure patterns recur: silent dormancy, subtraction-or-race collapse, implicit assumptions about API behavior.

26. LaunchAgents pause without a logged-in user; LaunchDaemons survive reboots.

27. Substring-grep guardrails false-positive on documentation inside heredocs.

28. What matters for behavior is what’s on disk, not in the merge log.

29. Single-tool reverse-image search false-positives in noisy domains — triangulate before you act.

30. “The agent can read everything” doesn’t scale ethically — privacy boundaries are surface-specific.

To get the expanded version of this list to feed to your agent with all the granular nitty-gritty detail that can juice up your agent, you’ll need to purchase this resource bundle or buy a subscription to Vibeode Lisboa.

And if you want to get on the waitlist to have your own Jax, I’m distilling the chasis of my agent into Behalf.bot - a bootstrappable, customizeable version that anyone can deploy for themselves. It leverages Karpathy’s idea file concept to combine the core pieces of my repo with the custom bits you specify in an interview to give you a bespoke virtual assistant agent that functions at an insanely competent level. Look for that next month and follow this substack to get the announcement.

We just ran seven non-technical people through a month of learning how to build apps with AI. All seven shipped working apps some already with traction.

But here is the kicker for Cohort 4: eight of the sixteen seats are now entirely remote.

Why this matters

IBM laid off 8,000 people earlier this year to replace them with AI agents. Intel: 21,000. Microsoft: 15,000. Here are some of the more striking moves with companies signaling or even explicitly stating they’re going AI-first:

Block (Jack Dorsey) - Feb 27, 2026 - ~40% of workforce cut, AI-attributed

Cut 4,000+ of 10,000+ employees. Dorsey’s shareholder letter: “the intelligence tools we’re creating and using, paired with smaller and flatter teams, are enabling a new way of working which fundamentally changes what it means to build and run a company.” Stock jumped ~22-24% on the announcement. Dorsey followed with: “Within the next year, I believe the majority of companies will reach the same conclusion and make similar structural changes.”

• BBC: Jack Dorsey’s Block cuts thousands of jobs as it embraces AI

• Forbes: Jack Dorsey Bets Block’s Future On AI, Cuts Nearly Half Its Workforce

• Fortune: Intelligence tools have changed what it means to build and run a company

• Jack’s X post

Shopify (Tobi Lütke) - March 20, 2025 - prove AI can’t do it before you hire

Leaked-then-shared internal memo: “Reflexive AI usage is now a baseline expectation at Shopify.” Core hiring policy change: “Before asking for more headcount and resources, teams must demonstrate why they cannot get what they want done using AI.”

• CNBC: Shopify CEO: Prove AI can’t do jobs before asking for more headcount

• The Verge: Shopify CEO says no new hires without proof AI can’t do the job

• Business Insider: Before hiring anyone new, employees must prove AI can’t do the job better

Zapier (Wade Foster) — 2025 — 100% AI fluency required for new hires

Foster made AI fluency a hiring requirement across every role at Zapier, published a four-tier rubric (Unacceptable / Acceptable / Adaptive / Transformative), and ran a company-wide hackathon that took internal AI usage from ~10% to 97%.

• LinkedIn (primary-quote post by Daan van Rossum): “100% of new hires must be fluent in AI”

• GTMnow podcast with Claire Vo: How one hackathon took Zapier’s AI usage from 10% to 97%

Duolingo (Luis von Ahn) - April 2025 - “AI-first,” contractors phased out

Duolingo announces it will stop using contractors for tasks AI could handle (content creation + translation specifically), and tie AI usage to both hiring and performance reviews. Analogy Von Ahn drew: “We’re making a similar call now, and this time the platform shift is AI.”

• Computing: Duolingo goes ‘AI first’ as it phases out human contractors

• USA Today: Duolingo going ‘AI-first’, replacing contractors with artificial intelligence

Klarna (Sebastian Siemiatkowski) — Feb 2024 → 2026 — replaced 700 CS workers with AI

Klarna replaced 700 customer service agents with AI in Feb 2024 and initially claimed major wins (2-minute resolution vs 11-minute human baseline). CEO later (2025-2026) said AI had “halved the workforce without layoffs” via attrition + hire-freeze.

• The Independent: Klarna’s AI replaced 700 workers. It now wants some back

• Digital Applied: Klarna Reverses AI Layoffs

Basically you can stick your head in the sand or you can spend four weeks with a cohort of people who are all recognizing the profound moment we’re in and treating it like the industrial revolution shakeup that it is.

The good news: Cohort 4 welcomes you wherever you are

Same curriculum, same office hours, same Demo Night - just joining from wherever you are. The tools and methods taught are all remote-friendly.

Bonus: Agentic design. This cohort I’m teaching the same pattern I used to build Jax, my AI assistant who handles my customer support, outreach, devops, assists with content promotion and of course, engineers new features.

Cohort 4’s curriculum. Four Friday coworks, nine office hours, a kickoff, a Demo Night. You have an MVP launched and in-market by the end of the 30 days but most importantly you have the skills and experience to build whatever you need going forward.

The schedule

• Kickoff: Monday May 4, 18:00 Lisbon

• Four-week sprint: two office hours per week, Friday coworks

• Demo Night: Saturday June 6 at Tribe Social Club (+ live stream for the remote cohort)

• Price: €498.

How to apply

Apply here.

2min to fill out the application. If you are a fit, funds capture, you’re approved and you’re in.

One more thing: Cohort 3 Demo Night is next Wednesday

We are going to try to live-stream it this time, for people considering Cohort 4 who cannot make it to Lisbon. This is our first time live streaming so this is one big experiment but it will be available here vibecodelisboa.com/live

Watch talks from the seven amazing participants of Cohort 3 as they share their creations and the lessons they learned in the process of building them.

If you’re based in Lisbon come join us in-person here.

I will teach you how to thrive and not just survive in the coming storm. It’s not scary once you learn how to work with this stuff but the time to begin playing with these tools is today, not next year. Apply for Build School today.

I look forward to meeting you.

Sean

You can think of it like an architect shipping a conceptual blueprint for a house with aspects that are open to interpretation by the builder. The builder comes briefed on the buyer’s wants & needs and puts his spin on the architect’s original plan to create a bespoke house for the client.

The old model of parameterizing settings of a cloned codebase

Every piece of software you’ve ever installed was a clone. Same installer, same binary, same app. Maybe you tweak some config settings, pick a theme, toggle a few preferences. But underneath, it’s the same code base running on every machine and simply adjusting parameters to yield a slightly-modified variant of the experience to the user.

That made sense when humans had to write every line of code. Write once, ship it to millions. Economies of scale.

The equation changes here though when the cost of writing custom software approaches zero with agentic coding platforms.

A sufficiently well thought-out idea file is the ultimate installer

Karpathy’s proposal: what if instead of shipping the building, you ship a blueprint that’s open to interpretation by the consumer? Not even a detailed blueprint - more like an architectural philosophy. “Here’s what this system should do, here’s how it should be structured, here are the constraints.”

Then an AI agent - Claude Code, Codex, whatever you’re using - reads that spec and builds it fresh and builds it just for you. It factors in your existing tools, your preferences, your technical context, your actual needs.

Software 2.0 looks more like sexual reproduction

Maybe a better analogy for what Karpathy is proposing is not blueprints and buildings but more about cloning vs sexual reproduction from two parents.

The software provider contributes one set of chromosomes - the specification. The goals, the architecture, the patterns, the constraints.

The consumer contributes the other set - their unique context. Their existing infrastructure. Their preferences. Their specific problem. Their resources.

What comes out is a software baby conceived uniquely from the ground up that carries the DNA of both parents but is identical to neither. And just like actual offspring, it’s a better fit for its environment than either parent would produce alone.

Every “install” is non-deterministic and produces something different that’s uniquely yours and adapted to your scenario.

We’re already doing this at Vibecode Lisboa

We’ve been doing a version of this at Vibecode Lisboa with the Confabulator tool.

When a student goes through the Confabulator, they describe their project in plain English. The tool takes that description - their chromosomes - and combines it with our template architecture - our chromosomes - and produces a unique GitHub repo. Same idea file. Different user DNA. Different software baby every time.

Ben, a non-technical student in Build School Cohort 2, used the Confabulator and had a deployed micro-SaaS for investors in two days. His app looked nothing like the app I built the same weekend (Prep.Training) using Confabulator. Same tool, same birthing process, completely different output because our unique inputs shaped the result.

Why this matters for you

If you’re building software: think about whether your distribution model should shift. Instead of shipping apps, maybe you ship idea files. Let the user’s agent build what they actually need.

If you’re a non-coder: this is the future getting closer to you. The gap between “install this app that kind of does what I want so I’ll accept the tradeoffs” and “describe exactly what you need and an agent builds it” is closing fast.

If you’re somewhere in between: this is why learning to work with AI agents matters. The person who can clearly articulate what they need and mesh that with a promising idea file is the person who can generate custom software that fits like a glove. The person who can’t is still tracking down installers and settling for shoe-horning his/her business into a shoe that knowingly doesn’t fit right.

Where do we go from here

We are living in the future. The software you use tomorrow might share DNA with a million other installations but be genetically unique to you. Karpathy sees it. Dorsey sees it. The 16 million people who viewed his tweet see it.

If you’re shipping software consider distilling the essence of your application to an idea file that your consumers can give to their agent to birth the perfect app for their needs.

And if you’re a non-technical user seeking to wade into these waters and test this stuff out, take five minutes and create your first Confabulator project and experience this new “software birthing” process first-hand.

Today Anthropic finally issued this ultimatum that confirms they are officially closing this loophole:

They’re now actively blocking third-party harnesses from using subscription tokens. This thread on Hacker News is hovering just under 1000 points and 700+ comments in hours. The community is furious.

I don’t blame Anthropic for this move at all. Any subscription model relies on some level of breakage and a vast majority of users not consuming more than their subscription is worth. Open Claw as an always-on, proactive, autonomous agent is throwing the curve, breaking their subscription economics and they know it. So they’re doing the rational response here.

If you’ve been running Opus through Open Claw on your Max plan, the math just changed dramatically.

Your options now:

1. Switch to API billing. Variable costs. Horror stories of $200+ inference bills from runaway agent loops are no longer hypothetical - they’re your new reality.

2. Downgrade to a lesser model that fits within whatever free tier you can cobble together. Good luck getting meaningful work done reliably.

3. Give up on the whole autonomous agent idea.

None of those are great paths.

I went through all of this already last month. I spent 30 days and 40+ hours trying to make Open Claw work for me. Tried every model. Local models on my Mac Mini weren’t powerful enough. Frontier models meant runaway costs because you have one runaway heartbeat checking snafu that eats up a bunch of tokens and don’t realize it until it’s too late. The memory was broken. The context kept falling apart. It couldn’t even parse my RSS feed to figure out my writing voice - a task that Claude Code handles trivially.

So I went a different direction.

I know from experience Claude Code is an incredibly capable platform and its Opus model is super competent at complex, goal-oriented, multi-stage tasks. My hypothesis was that I could setup a persistent, autonomous agent running on a Mac Mini using Claude Code to replace Open Claw as the always-on agent. Discord as the interface via their new channels feature. Voice notes in via Discord, trustworthy work out. Persistent memory that actually works and gets smarter over time. A heartbeat system for scheduled tasks. MCP tools wired into Gmail, my production database, my note system, browser automation, analytics - all the key systems.

This thing runs legally under the Max plan. Fully compliant with Anthropic’s terms of service. Fixed monthly cost. No OAuth hacking. No wondering if you’re going to get banned or forced to API-based billing.

Where Open Claw struggled to perform any kind of meaningful work reliably, my Claude Code-based agent is working with me like a dependable teammate.

Every day it drafts my outreach emails, scores leads from my production database, researches blog topics in my actual voice, monitors 30+ community groups and surfaces what matters in a morning briefing I can read in two minutes all while slaying issues on Github. I interact with it the way I’d converse with an employee: high-level goals instead of micromanaged instructions.

I’m demoing this setup live on Wednesday, April 8th here in Lisbon. Small group. I’ll show exactly how it works, the repo structure, the tools, and a side-by-side comparison of Open Claw fumbling a task that this setup handles cleanly.

If you’re in Lisbon, come see it: RSVP here

If you’re not in Lisbon, the recording will be available after. If there’s enough demand I’ll sanitize my repo and make an installer skill for it and put it out there for all the Open Claw Opus refugees who are up in arms today.

Anthropic’s move may have just handcuffed everyone’s Claws but it doesn’t have to mean the end to your subscription-based, fixed-cost, Opus-powered agent.

Sean Tierney builds software with AI at Vibecode Lisboa. He runs Build School, a 30-day cohort where non-technical founders ship their first product.

Ben Lakoff is the General Partner for Bankless Ventures. He’s spent years working with external dev teams and internal tech teams, and he knows what that costs in time and money. He joined Build School to finally understand the tools himself.

“Taking this course was more on the spirit of learning as opposed to developing the next billion dollar idea,” Ben said in his demo. He started with a throwaway project - an AI influencer - and finished it on day one. Then he pivoted to something he actually needed.

MacroDigest is a dashboard that pulls market signals from everywhere: indices, sentiment analysis, Reddit’s WallStreetBets, RSS feeds from analysts he follows. It runs NLP on everything and tries to gauge where markets are heading.

The fun fact of Ben’s story: he didn’t realize there was a syllabus in the beginning. He just dove into the self-paced video course and came out the other side days later with a deployed product. He’d gone through Confabulator, hooked up Stripe, spun up a marketing site and made it all work in the first week of a 30-day course proving Derek Sivers’ point that there is no speed limit.

Petra: Years of waiting, one month of building

Petra runs her own business and came to Build School with an idea she’d been carrying around for years for JustLooking: an app to help people passively scout for promising career opportunities.

“2.59 billion people are passive job seekers,” she explained at demo night. “They’re open to switching jobs if something better comes along. Figuring out what’s better is usually the hardest part.”

Her app works like the Hinge dating app for careers. You swipe through roles. The system learns your preferences over time. It notices when you keep liking remote positions even though you said you wanted hybrid. It builds a calibrated picture of what you actually want - like a recruiter who takes the time to really understand your interests.

“I tried to build this years ago but I didn’t manage.”

In a month with Claude Code and no prior experience she made it real.

From her testimonial: “Claude Code can do pretty much everything you want. That’s not the hard part. The hard part is knowing what you want to build and actually leading Claude into building it.”

Her advice to anyone considering the course? “Don’t wait. Just get started. The first week might feel like you don’t know what you’re doing. But after a week or two, you’ll be self-sustained.”

William: 16 years of events, one month of tools

William has thrown over 500 events in his career, mostly in the nightlife and entertainment space. Sixteen years running he’s a veteran of this space.

He also knows demand for alcohol-centric events is receding. Younger people drink less. Health consciousness is up. Event attendance across the industry is down.

Instead of accepting the down-tick in attendance, William is building features to find and recruit his customers.

“I approached Sean and said these are the first two tools I’m going to start with,” William recounted. “I said I hired a dev company and he said to me, ‘You’re going to fire them.’ I said okay. He said, ‘You’re going to do this yourself.’”

So he did. Six weeks later he built Dynamic Event Suite consisting. Dynamic pricing that works like surge pricing in Uber - set your min and max, and the system adjusts based on actual demand. An affiliate system that turns every ticket buyer into a promoter automatically. Analytics that track where every click and purchase comes from.

“Your best tool has always been your buyers,” William explained. “We turn all your buyers into affiliates for you.”

The social boost feature is already outperforming his paid advertising. His St. Patrick’s Day events in Chicago are live right now with the new tools running.

“I don’t want to personally respond to questions about why things are so unfair while you’re drunk at 2 a.m. anymore,” he joked. “I’ve earned it after 16 years. I want Claude to take care of that for me.”

Koos: The language learner who built a better Anki

Koos is Dutch, living in Portugal, and frustrated with current language learning apps. He’d used Anki previously - the spaced repetition tool that everyone recommends and nobody enjoys. It works, but it’s cumbersome, uses an antiquated algorithm and doesn’t tailor specifically to the words you use everyday.

His insight: vocabulary should be contextual. You should learn words relevant to your actual life, in the dialect spoken around you. His Brazilian Portuguese is out of place in Lisbon so he’s using his app to teach himself European Portuguese.

He built Learn the Language you Live In (currently US/China only - if in Europe take Koos’ survey here) to be his own spaced repetition system. It’s an iOS app that makes vocabulary learning contextual to your location and your life.

Koos has the most commits of anyone in the cohort. Feature after feature, refinement after refinement he’s tweaked it to be exactly the tool he himself wanted and has now made it available to others via the Apple App Store.

Cristiano: Capturing stories before they disappear

Cristiano cares about legacy. About the stories families carry forward and what gets lost when people pass without recording them.

He built Mabel, an iOS app that acts like a guided memoir-authoring interviewer and coach. You speak into the app via voice notes. An AI interviewer prompts you, draws out your stories the way a skilled biographer would.

Using his app anyone can speak an autobiography into existence.

Think about your grandparents. The stories they carry that you’ve never heard. The ones that will disappear when they do. Cristiano’s app makes it almost effortless to capture them. No writing required - talking is the UX so anyone can use it including your grandparents.

What these five have in common

They built tools for themselves. Ben wanted market intelligence. William wanted event optimization. Koos wanted better language learning. Petra wanted a career exploration tool. Christiano wanted legacy preservation. They had strong visions and willed these into existence via natural language.

They prove the thesis of Build School: that the tools have evolved to the point that with a small amount of hand-holding anyone regardless of background can use natural language to make their dream reality.

Cohort 3 begins

We kicked off Cohort 3 on Monday with eight students - our biggest cohort yet.

Applications for Cohort 4 starting April 20th are now open. Early-bird pricing runs until April 1st.

If you have an app idea you’ve been carrying around, if you’ve been waiting for a technical co-founder who hasn’t shown up, if you’re curious whether you could actually build the thing yourself - this is for you.

Build School is a 30-day sprint. You show up with an idea. You leave with a deployed MVP. And in the process you learn a mindset and system that you’ll be able to leverage for the rest of your life. Come see what it’s all about.

Learn more about Build School →

About 60 people came out for demo night. If you’re in Lisbon, join us at the next Vibecode Lisboa meetup. If you want to build, start with Confabulator to lay your project foundation.

Origin Story

Git is the open source technology underpinning Github. It was created by Linus Torvalds, the creator of the Linux operating system. Git is his second amazing contribution to the world of computing and arguably has had as much an impact if not more in terms of total benefit to other software creators. Before Git, software developers relied upon less ideal platforms like Visual Source Safe, SVN and CVS for source control but Git fixed a lot of the deficiencies with these systems by offering a more flexible, efficient way of how it handles changes.

What are Source Control, Git and Github?

Source control (sometimes called “version control”) is the term of art for any system that allows you to reliably manage files in software development. Git is a source control system that makes it possible to collaboratively develop software with other people in a more sane manner and to manage your changes with peace of mind. You can build software without it but it’s a bit like rock climbing without a rope. You and I aren’t Alex Honnold - we use protection when climbing any structure above ten feet and we use source control when developing any software application that we want to build and maintain over time.

What is a commit?

If we follow the rock climbing analogy for a minute it gives a useful mental image because every time you check your source code into a source control system like Git, it’s like clipping into protection on a precarious rock face. As we scale the rock wall that is our increasingly-complex software project we want to periodically “clip in” so that we don’t fall all the way back to the ground in the event of a catastrophic mistake.

The way we “clip in” while climbing is by saving or “committing” our changes. Doing so gives us a save point or a “commit” that we can always revert to if things get messed up. This should give you great peace of mind because as long as you’re committing regularly at sensible progress points there are no fatal mistakes you can make while developing and the furthest fall you can ever have is to is the point of your last commit.

Setting up your first Github repo

If you use Confabulator on the last step it will create your Github repository (or repo). It takes the foundational files you developed (plus some other helpful scaffolding) and injects those into a new Github repo into your account. Obviously first you need to create your Github account and then grant Confabulator access (it will prompt you to do so when using it for the first time) but once you do that it has everything it needs to operate on your behalf and create new repos. The newly-created repo now exists on Github’s servers.

Understanding Local vs. Remote

We call this a “remote repository” (or repo) because it’s not stored locally - it lives remotely on someone else’s computer (in this case, Github’s). This is important to understand because until we clone that repo locally to our machine it only exists in the cloud. Once we clone locally though then Claude Code running on our machine can begin to work with the files. When you then commit code it’s storing those changes in a git repo that’s running locally on your machine and until you push that commit remotely to the Github repo (or “origin server”) those changes exist only on your laptop. So every time we make a commit and want it to end up in our Github repo there are actually two sequential steps happening: committing the code locally and then pushing that code remotely. If ever we have a teammate working in parallel and pushing their changes to Github and we want those changes we need to periodically fetch the remote repo to check status and pull down the new remote changes locally to incorporate them into our local instance.

The good news with this stuff is that Claude has a deep understanding of Git commands so you don’t need to memorize the nitty gritty syntax necessary to perform these operations. Once you’ve setup your local IDE (Integrated Development Environment - in our case Cursor) to talk to your Github repo and given Claude Code the necessary access to operate on your behalf by installing the Github CLI (Command Line Interface) or Github MCP (Model Context Protocol) you can just direct it in english and it will handle issuing the appropriate commands to do what you want. You only need to know conceptually what’s going on and have Claude Code execute your directives via natural language translating those into the necessary git commands.

What are branches?

When we’re working by ourselves on an early project, often we’ll develop directly on “Main” or the trunk of our tree if we use that analogy. It can be advantageous in different situations though to create a branch from the main trunk and do our work there. For instance when you have different developers or even entire teams working on different features, for sake of not stepping on each others changes, they’ll each be working on their own branch. You can think of a branch almost like an alternate timeline that splits from the base reality and goes off in another direction. You initiate this new timeline by checking out the code into a new branch that you name typically with a short descriptive name. You can have a whole set of changes occurring there and being committed without affecting the main timeline. Then when you’re ready for these changes to be incorporated back into production (the trunk or the live version of the app visible to the world) you can merge your branch.

What is a merge?

Merging is the process of incorporating the changes from one branch into another. Main is actually a branch itself - it’s the root branch so it’s technically the trunk, but it has all the same behavior of a branch. Once again you don’t need to worry about the specifics of how to merge. Once configured properly Claude Code will handle this for you and handle even sophisticated “branches of branches” merging strategies. The net net of merging to Main is that your changes get incorporated into your main timeline and therefore your production instance.

What is a merge conflict?

What happens if you and I have both created our own branches and are working on the same files and then go to merge? When this occurs you can end up with conflicting changes on different branches - this is called a “merge conflict.” If you used Confabulator to create your repo it takes an extra step and creates a dependency graph and git worktrees for your issues. These devices identify which github feature issues can be worked on in parallel and which require sequential development and in what order. This reduces the likelihood of merge conflicts when building the project. Even with these safeguards though sometimes merge conflicts are inevitable. Fortunately Claude Code is extremely good at resolving these. And worse case you can always revert to your last commit on one of the branches and have it do the work over from the new merged branch.

What are issues and epics?

Github issues are like support tickets independent of the code that are used to capture instructions about new features, bugs and any modification you intend to make to the source code. A typical workflow is to work with Claude Desktop or Claude Code to brainstorm a sensible feature and then have it create an issue representing what’s called an “Epic” for that feature. An Epic is a comprehensive summary of the requirements and acceptance criteria of a feature. It’s basically the “what” without the “how” of the specific implementation details necessary to make it real. This allows you to create new features agnostic of how they’re to be implemented and then delegate that job of translating those into detailed implementation issues to Claude Code. Claude Code has intimate familiarity with your codebase and therefore is better qualified to convert these logical requirements into an actionable implementation plan.

What are Github actions and CI/CD pipelines?

Github actions are recipes that can be set to run when code is committed. A common use case is to setup a Github action to push code into your deployment environment when it’s merged into your Main branch. You can get fancy and setup a gauntlet of different security and unit tests that check to ensure things work properly before code is allowed to be pushed to the Main branch. This is called a Continuous Integration / Continuous Deployment Pipeline and typically implemented once the cost of any downtime on the live site merits having a more bulletproof approach to ensuring no bad code is deployed. As you can imagine sites like Amazon and Facebook have rigorous CI/CD pipelines with extensive automated testing to minimize the chances of a bug making its way into the production environment. For early-stage founders though when working on your MVP before you have users a CI/CD pipeline is probably overkill and mis-spent calories and unnecessary friction early on. Once you have paying customers it’s a good idea to get a more disciplined approach to your deployment workflow.

How to revert if things get messed up?

Let’s say you’ve been developing your app and you’ve had a great idea for a feature and attempted to implement it but something got messed up and now your code doesn’t work. Assuming you haven’t committed it yet, all you need to do is revert back to a previous commit. That will preserve your changes in the commit history while allowing you to rollback the app to its prior state. Alternatively you can just backup your local .env file (where your API keys and variables are stored), nuke your local repo and clone your remote repo to your local machine again. That will put you back in the state of your last commit. If you happen to have checked in the bad code and pushed it to your remote Github repo it’s still no trouble because everything is versioned there so you can “peel off” the latest commit and have it revert to a previous commit. If you’ve ever used TimeMachine on MacOS it’s similar to reverting your filesystem to a previous state. If you want to preserve what you did instead of trashing it completely (maybe there was some useful functionality you created) you can have it store those changes on a side branch and revert the main branch to the last commit. Again Claude Code can handle these details for you so you don’t need to know the sophisticated commands to make all this happen, you just need to know it’s possible.

Linking commits to issues

Issues can be resolved by one or more commits and commits may contain code that resolves multiple issues. A good strategy is to link your commits to the issues they resolve. If you’re using the process taught in my course then Claude Code is already linking your commits to issues. This is valuable because it allows you to cross-reference things and later determine which commits were responsible for which features and bugfixes.

Where to go from here

Git and Github are powerful systems that can do so much more that what we’ve covered here but this short intro gives you the 80/20 primer of what you need to know to get started using them. Taking my course gives you the “just-in-time learning” approach to this stuff where we dive in the deep end and start using them and then backfill the explanations as we go along. If you want a more methodical, Github-focused, comprehensive course this Udemy course is a great way to get deeper on this foundational tech that you’ll use on every project.

And now you have all the foundational understanding of a fledgeling Github wizard. Please report to platform 9 3/4 to build your first app using Github. Try Confabulator for your next project if you haven’t already as it helps with the ideation and setup of your github repo when beginning a new vibecoding project. 🦉🪄

Friday morning I went through Confabulator and had it generate my first github repo commit:

Fast forward to now Sunday afternoon and I have Prep.Training live and wired up to accept payments via Stripe. This is an idea a buddy and I had talked about wherein we gamify the art of improving ones disaster preparedness in a way that appeals to ordinary, rational people and not just the diehard doomsday preppers. We need to make it simple for the average person to carve out 15min per day towards taking small incremental steps that greatly improve their resilience in the face of life’s curveballs. Prep.Training uses standard gamification patterns like streaks, badges, points and unlocks to introduce preparedness concepts and give people a tool for improving their readiness.

Even if this app doesn’t make a dime it’s a win because it’s a tool I wanted myself to be able to load up material from various sources and have it gamify a bunch of instructional content to help me and my friends have these conversations and help each other level up.

This is the future where anyone regardless of their programming background in short order can conceive and implement a business idea that delivers value and creates another passive income stream to make him or her more self-reliant. This is my feature backlogue with the features I want to add:

My process from here is to work through this list having a conversation with Claude Desktop (which has access to my github) to strategize about how to optimally implement these. I have Claude Desktop stub out the detailed Epics as Github issues, then work via Claude Code to refine them and execute the Ralph Wiggum system via /ralph-orchestrate slash command that now comes in all Confabulator repos to implement these features while I sleep.

This time ten years ago I was living in Newport Beach I had attempted a startup concept called SurvivalSchool.TV. If you want to see a cringe-worthy season premier trailer check this out:

What’s funny though is with my current effort teaching people vibe coding via Vibecode Lisboa, the goal remains the same: to help make people more self-reliant. The method to accomplish that goal has changed but the Prep.Training app I just spun up this weekend is a convergence themes. The timeline from start to finish working on this was two days with the majority of one of those spent up in beautiful Nazaré watching the big waves from tropical storm Ingrid.

The guy on the left side of that pic is my good buddy Ben who is currently a student in Cohort 2 of Build School. As a non-technical person he picked up this stuff extremely quickly via my course and was able to build and launch his own micro-SaaS for investors in two days as well. More on that wild story in this LinkedIn post.

We are living in the future. If you’re “vibe-curious” the best way to dip your toes in this stream is to start with my course and complete the first section (first section completely free - full course $69). I used the same Confabulator tool shown in the course to jump start Prep.Training. This stuff works. If you’re considering building an app idea there is no better time than now to jump in these waters and get to it.

I took my guitar everywhere. I’d fall asleep with it. When I couldn’t bring my guitar I’d bring this little “grip master” device with individual spring-loaded pistons you squeezed to improve your finger strength. Within six months I would record an album of songs I wrote, perform solo’s live in concert - basically zero to full-on guitar hero in six months.

Was I naturally a musical prodigy? No. I had tried and failed twice before to learn piano and violin. So what was different about guitar? My previous attempts at learning these other instruments were train wrecks. The violin was a disaster trying to learn via the Suzuki method - I just never could get it. I flamed out on piano as well and eventually gave up - practice was boring and the finger exercises excrutiating. So what was the secret sauce that made guitar stick? This man, Frank Danna:

He intuitively understood what my piano and violin teachers did not: that the way to learn any instrument is in service of playing the song you want to play.

He didn’t start me out learning scales, reading music, establishing finger picking techniques, acquiring chords, etc. The first thing he said to me was “What song do you want to play?”

I was obsessed with the guitar from the song “Hungry” by White Lion so we dove head first into that. Frank and I would sit weekly in a little practice room at Keyboard City only slightly bigger than a phone booth and bar-by-bar, measure-by-measure work through that song until I could play the entire thing. Each session I would learn a little bit more. “Here’s what he’s doing there- that’s called a ‘hammer-on / pull-off’. That’s a pentatonic scale that he’s playing. He’s muting the string with his palm - that’s why it sounds chunky like that…” After each session I had something new I could go home and show my friends and celebrate. The wins stacked in a virtuous loop that pulled me deeper into the instrument and instead of being put off by the theory and practicing scales, I was seeking those out so I could play the song better. Little by little I picked up all the knowledge and techniques via just-in-time learning to play that song and countless others.

Years later I’m still in love with the guitar and I attribute my life-long obsession largely to Frank’s intuition as a teacher of the best way to learn an instrument. I believe these same dynamics apply with any kind of instrument, software being one of them.

The way to learn a tool like Claude Code is not to read the docs and reference materials cover-to-cover or even take a course that teaches all of its functionality and capabilities. The way to learn is to learn the instrument in service of playing the song, or in this case, through gradually bringing your app idea to life. This is why I structured my Claude 101 course the way I did to help you acquire all the important concepts along the journey to making your app idea progressively more real.

I don’t know where Frank is now but it’s rare that a single individual has such outsized impact shaping not only one’s life-long hobby so profoundly, but simultaneously instilling a worldview for a fundamentally different approach to teaching. If you want to try applying this approach to learning Claude Code for app building I invite you to join the course or signup for our next cohort of Build School.

Build School is back. In Cohort 1, five founders went from little to no coding experience to deployed applications in 30 days. Now we’re doing it again - with a refined curriculum and everything we learned from round one.

This post serves as both the official syllabus for Cohort 2 students and a look inside the program for anyone considering joining. (Yes, we still have one spot left.)

How Build School Works

You’ll work through the Claude Code 101 video course on your own time, completing assigned lessons before each session. Then we meet three times per week:

• Mondays & Wednesdays (6-8pm): Virtual office hours via Zoom - bring your questions, blockers, and wins

• Fridays (10am-2pm): In-person cowork session in Lisbon - focused building time with support

The course has 12 lessons across 3 sections (~4 hours of video total). We’ll cover one section per week, leaving Week 4 for polish and demo prep.

Communication: We’re using Discord this cohort (not Slack) so your conversation history never expires.

Week 1: Plan Your App

January 12-17 | Section 1 of Claude Code 101

Before you write a single line of code, you need to know what you’re building. This week transforms your app idea from a vague concept into a concrete, buildable plan.

Session 1: Kickoff (Monday, Jan 12 - In Person)

Our kickoff event doubles as the first office hours

Complete before this session:

📺 Lesson 1: Start with Confabulator (35 min)
📺 Lesson 2: Configure your local development environment (16 min)

What you’ll learn:

• How to use Confabulator to generate your foundational project documents (PR/FAQ, PRD, Vision Doc, Biz model canvas, etc.)

• Setting up your machine with the prerequisite technologies: Node.js, Git, VS Code, Claude Code

Why this matters: Without proper planning documents, you’ll waste weeks building the wrong thing. Without a working dev environment, you can’t build anything at all. We knock out both of these blockers on day one. This is the biggest technical lift so we do it in person and once you’re past it everything gets easier because you can actually use Claude Code to help you solve technical challenges like these from then on.

By end of session: Your project has a GitHub repo with foundational docs, and you can run claude in your terminal.

Session 2: Office Hours (Wednesday, Jan 15 - Virtual)

Complete before this session:

📺 Lesson 3: Create mockups of the screens in your app (28 min)
📺 Lesson 4: Conduct an Architectural Review (17 min)

What you’ll learn:

• Triangulating your UX by generating mockups through three independent approaches

• Working with Claude Code to tighten up your implementation plan and create detailed GitHub issues

Why this matters: Mockups force you to think through user flows before you’re knee-deep in code. The architectural review ensures your technical plan is realistic and properly scoped. Skip these and it leads to unnecessary pain and thrashing.

By end of session: You have visual mockups of every screen and a prioritized backlog of GitHub issues ready to work.

Session 3: Cowork (Friday, Jan 17 - In Person)

No new lessons—this is building time.

Use this IRL session to:

• Complete any planning work that’s still in progress

• Get to know your fellow cohort members

• Resolve any environment setup issues

• Start exploring the codebase Claude Code generated

• Ask questions before diving into the Build section next week

By end of session: Planning phase complete. You’re ready to start building.

Week 2: Build Your App (Part 1)

January 20-24 | Section 2 of Claude Code 101 (Lessons 5-7)

Now the real work begins. This week you’ll convert mockups into functional screens, add user authentication, and connect your app to a real database.

Session 4: Office Hours (Monday, Jan 20 - Virtual)

Complete before this session:

📺 Lesson 5: Create your app screens (14 min)
📺 Lesson 6: Add authentication (10 min)

What you’ll learn:

• Converting your mockups into usable screens with real UI components

• Adding login functionality and enforcing authentication for protected routes

Why this matters: Screens are where users actually interact with your app. Authentication is table stakes most applications - users will expect accounts and you need to know who’s using your product and provide varying levels of access depending on who they are.

By end of session: Your app has real clickable screens (not mockups) and users can sign up and log in.

Session 5: Office Hours (Wednesday, Jan 22 - Virtual)

Complete before this session:

📺 Lesson 7: Implement the database (13 min)

What you’ll learn:

• Replacing hard-coded dummy data with live data pulled dynamically from a database

• Database schema design and data relationships

Why this matters: Static data is fine for demos, but a real app needs persistent storage. This is where your app starts to become a real product - the data your users create persists.

By end of session: Your app reads and writes to a real database. No more dummy data.

Session 6: Cowork (Friday, Jan 24 - In Person)

No new lessons—focused building time.

Use this session to:

• Catch up if you’re behind on lessons 5-7

• Debug database issues

• Work on your specific app’s core features

• Get unstuck on any blockers from the week

By end of session: Core screens, auth, and database are working. Foundation is solid.

Week 3: Build Your App (Part 2) + Deploy

January 27-31 | Section 2 (Lessons 8-9) + Section 3 (Lesson 10)

You’ll complete your core features and get your app deployed to the internet. By the end of this week, you’ll have a live URL you can share.

Session 7: Office Hours (Monday, Jan 27 - Virtual)

Complete before this session:

📺 Lesson 8: Build the Admin Dashboard (20 min)
📺 Lesson 9: Add Appointment Bookings (13 min)

What you’ll learn:

• Creating admin interfaces for managing your app’s data

• Building interactive features like scheduling and bookings

Why this matters: Most apps have two sides: what end-users see, and what admins/operators see. The booking system demonstrates a complete user flow from request to fulfillment - a pattern you’ll reuse constantly.

By end of session: Your app has both user-facing and admin-facing functionality. Core features are complete.

Session 8: Office Hours (Wednesday, Jan 29 - Virtual)

Complete before this session:

📺 Lesson 10: Deploy your App (29 min)

What you’ll learn:

• Deploying your application to Vercel (frontend/backend)

• Setting up Turso for production database hosting

• Environment variables, build configuration, and deployment troubleshooting

Why this matters: An app that only runs on your laptop isn’t a product - it’s a prototype that only you can use. Deployment is the point at which your app becomes real. You get a URL you can share with anyone in the world.

By end of session: Your app is live on the internet with a working URL.

Session 9: Cowork (Friday, Jan 31 - In Person)

No new lessons—deployment and debugging focus.

Use this session to:

• Troubleshoot any deployment issues

• Test your production app thoroughly

• Fix bugs that only appear in production

• Start thinking about polish and Demo Night

By end of session: Your MVP is deployed and stable. The hard part is done.

Week 4: Polish + Demo Night Prep

February 3-13 | Section 3 (Lessons 11-12) + Demo Preparation

Your app works. Now we make it shine. This week is about visual polish, final features, and preparing to present your creation.

Session 10: Office Hours (Monday, Feb 3 - Virtual)

Complete before this session:

📺 Lesson 11: Refine and Launch your App (24 min)
📺 Lesson 12: Make some post-launch tweaks (20 min)

What you’ll learn:

• Improving visual identity and branding

• Launching under a custom domain

• Running “fire drills” to boost confidence in your deployment

• Post-launch improvements: favicon, logo fixes, additional features

Why this matters: First impressions matter. A polished app with a custom domain signals credibility. The fire drill process ensures you can recover from problems quickly.

By end of session: Your app looks professional and runs on your own domain.

Session 11: Office Hours (Wednesday, Feb 5 - Virtual)

No new lessons—demo prep focus.

This session is dedicated to:

• Practicing your Demo Night pitch

• Getting feedback on your presentation flow

• Fixing last-minute bugs or polish items

• Preparing screenshots, talking points, and demo scripts

By end of session: You have a clear 3-5 minute demo plan and have practiced it at least once.

Session 12: Cowork (Friday, Feb 7 - Virtual)

Final working session before Demo Night.

Use this session for:

• Last-minute fixes and polish

• Full dress rehearsal of your demo

• Peer feedback on presentations

• Mental preparation for Demo Night

By end of session: You’re ready to present.

Demo Night (Week of Feb 9-13)

Exact date TBD based on venue availability

You’ll present your MVP to the Vibecode Lisboa community and invited guests. Each participant gets 3-5 minutes to:

• Explain the problem you’re solving

• Demo your working application

• Share what you learned

• Field questions from the audience

This is your moment. You came in with an idea. You’re leaving with a deployed product.

The Full Lesson Schedule At a Glance

Session Date Homework Due Topics 1 Mon Jan 12 Lessons 1-2 Confabulator + Environment Setup 2 Wed Jan 15 Lessons 3-4 Mockups + Architectural Review 3 Fri Jan 17 - Cowork: Complete Planning 4 Mon Jan 20 Lessons 5-6 Screens + Authentication 5 Wed Jan 22 Lesson 7 Database Implementation 6 Fri Jan 24 - Cowork: Core Features 7 Mon Jan 27 Lessons 8-9 Admin Dashboard + Bookings 8 Wed Jan 29 Lesson 10 Deployment 9 Fri Jan 31 -Cowork: Deployment Debugging 10 Mon Feb 3 Lessons 11-12 Polish + Launch 11 Wed Feb 5 - Demo Prep 12 Fri Feb 7 - Final Cowork + Dress Rehearsal 🎉 Feb 9-13 - Demo Night

Time Commitment

Video content: ~4 hours total (spread across 4 weeks)
Weekly sessions: 6-8 hours (2 office hours + 1 cowork)
Independent building: 5-10 hours per week (varies by project complexity)

Total: 10-15 hours per week for 4 weeks.

One Spot Left

We keep cohorts small (5-6 people) so everyone gets direct attention. Cohort 2 has one remaining spot.

If you:

• Have an app idea you’re serious about building

• Can commit the time for the next 4 weeks

• Are willing to learn AI-powered development tools

• Want to ship, not just plan

→ Apply for Build School

You get a response within 24hrs and applications are reviewed first-come-first-serve. Program starts January 12th.

Questions?

Join us at the next Vibecode Lisboa meetup or ask a question in our Q&A section.

See you at the kickoff. Let’s build something great together.

- Sean

Build School is part of Vibecode Lisboa, a community of 100+ builders learning to create software using AI tools.

Regardless of your current level of proficiency with CC you’ll gain value by incorporating these suggestions into your current workflow.

1. Begin Every Feature with Plan Mode

Always start in Plan Mode.

Resist the temptation to dive directly into implementation. You can give CC the exact same prompt but by starting first in plan mode and having it think through things up front it will give you a far better result every time by having to propose and defend a plan up front.

This slightly-delayed gratification vs. rushing into implementation is well-worth the 2min wait.

You engage plan mode by hitting “Shift Tab” from the CC command line and you’ll know you’re in Plan Mode when you see

2. Know When to Use File Scaffolding vs. GitHub Issues

Both preserve context, but they serve different purposes:

Create a .md scaffolding file when:

• The context is something that will be referenced repeatedly in the future

• It’s a distilled representation of complexity that saves CC from having to ingest the entire codebase to gain specific understanding

• It’s a living document that will evolve and there’s benefit to versioning it in source control

Create a GitHub issue when:

• It’s related to a solvable issue and will be obviated once it’s resolved

• You want to associate this context with a specific feature or bug

• The task is discrete and can be closed when complete

The two are not mutually-exclusive. It’s totally fine to save as a GitHub issue for the “what” and a scaffolding doc for the “how” but remember that storing outdated context confuses the LLM so you’ll want to be sure and prune context docs as they diverge from the reality of the codebase. I like to put scaffolding.md files in /guidance directory and /temp subdirectory if they’re transient or /docs subdir if they’re permanent.

3. Master Context Management

Three slash commands that you need to know:

/context - A visual representation of what Claude currently has loaded. It’s an eye-opener to see how your context window is currently allocated. This gives you the breakdown by what’s consuming most context by category and as well a granular view of which particular MCP’s are eating up context.

/clear - Nuclear option. Wipe everything and start fresh. Use liberally between features.

/resume - Pick up where you left off. Essential for multi-session work or when your IDE crashes and you lose context in the middle of developing a feature.

The mental model: Claude’s context window is like expensive real estate: you want to get the most out of every square foot and protect it at all costs. Every unnecessary file loaded is stealing space from your actual work.

4. Token Budget Management

If you’re using a Claude Pro or Claude Max subscription your usage quota governs how long you can work before you get temporarily frozen. If you’re on the API-based billing you’re paying a la carte so this directly affects your total bill:

Use CLIs instead of MCPs whenever possible. The GitHub CLI is more token-efficient than the GitHub MCP. Same with Vercel, Turso, Stripe and most other services. To the extent you can you should be using CLI’s instead of MCP’s when a comparable CLI solution exists.

Disable auto-compact. It sounds helpful, but it’s just eating up about 20% of your buffer. Better to manually manage context than let the system compress your important context away.

Create context summary docs. Instead of letting Claude read your entire filesystem every time, maintain a PROJECT_CONTEXT.md that summarizes the current state. Point Claude there first and it saves gobs of tokens because it doesn’t have to ingest the entire file stystem to understand the codebase.

Clear context after each feature. Don’t let the cruft accumulate. Finished a feature? /clear before starting the next one.

Monitor your usage: Run npx ccusage@latest to see token consumption by day. Pro tip: you can update your CLAUDE.md file with instructions to calculate the total token expenditure by feature and log that to the github issue when you close out each issue. NOTE: the dollar figures shown by this command are the a la carte API-based usage pricing. If you’re on a subscription this is not what you’re actually paying (good way to value your subscription and see if you’re getting your money’s worth).

5. Give Maximum Autonomy with MCPs and CLIs

The goal is disinter-mediate the interaction whenever possible and give Claude Code agency to operate on your behalf across systems without you being the relay middleman constantly.

Here’s my stack:

MCPs I use:

• chrome-devtools - Let CC open browser windows, inspect elements, debug until acceptance criteria are met

• context7 - Live documentation lookup without leaving the session

• n8n - Workflow automation integration

CLIs I configure:

• Turso - Database operations

• GitHub - Repository management

• Vercel - Deployment and logs

• Stripe - Manage ecommerce, check logs

The magic is when Claude can: check production logs → identify the bug → fix the code → verify the fix → deploy and all without you having to be involved in each step.

6. Pre-Authorize Actions to Avoid Interruptions

Nothing kills flow like Claude stopping every 30 seconds to ask “Can I run this command?”

Option 1: Configure .claude/permissions.json Define what actions Claude can take without asking. This gives granular control over which commands, which directories, which operations are pre-approved.

Option 2: Launch with claude --dangerously-skip-permissions Full autonomy mode. Claude does whatever it thinks is right (equivalent to “Yolo Mode” in Cursor).

Option 3: Launch with claude --permission-mode acceptEdits A slightly dialed-back version of the above where it doesn’t have full permissions but auto-accepts many of the approval steps on its own.

⚠️ Warning: Giving it full autonomy carries risk. Only use with repos you trust completely and running in sandboxed environments. A malicious repo could use prompt injection to exfiltrate data or install malware. This risk can be mitigated by sandboxing your CC instance (more on this at the end).

7. Write an Optimal Claude.md

Your CLAUDE.md file is a master prompt that runs on every interaction. This is a powerful file because it includes directives that shape everything in the project.

What belongs in CLAUDE.md:

• Project architecture overview

• Key conventions and patterns

• Common gotchas unique to this codebase

• Links to important docs and supplementary guides

• Your preferred coding style

Progressive disclosure: Don’t cram everything into the top level. Use includes or references to deeper docs that Claude can pull in as needed. This “just-in-time context” is called “progressive disclosure” and is another huge context-saving tip.

Claude.md vs. .clauderules:

• CLAUDE.md = project-specific context

• .clauderules = personal preferences that apply across all projects

Keep them distinct. Your rules travel with you. Project context stays with the project.

8. Escalate Thinking When Needed

Claude has different thinking modes. Use them strategically:

• Default - Fine for straightforward tasks

• “Think” - Pause and reason before acting

• “Think hard” - More deliberate analysis

• “Ultrathink” - Maximum reasoning depth for complex problems

Hat tip to my friend Marc Johnson for introducing me to these modes.

Pro Tip: The PAL MCP server lets you create a “consensus advisory board” - you can have a little virtual round table of Grok, Claude, OpenAI, Gemini, Ollama and other models debating architectural approaches. Five heads are better than one!

9. Run Claude Code Inside Cursor

Best of both worlds.

Cursor gives you the IDE experience: file navigation, syntax highlighting, visual diffs, easy manual edits.

Claude Code gives you the brain: superior reasoning, better context management, more capable tool use.

Run CC as your terminal within Cursor. You get Cursor’s interface with Claude’s intelligence. The combination is more powerful than either alone.

10. Extract Learnings Across Projects

As you develop and resolve bugs, learn key findings and make progress you should seek to extract and distill key learnings into markdown files that can be portable across projects.

Maintain two files that travel with you:

dev-culture.md - Your development philosophy. Patterns you prefer. Conventions that work for you. The “way you like to work” that Claude should respect.

mistake-patterns.md - Things that have gone wrong before. Common pitfalls Claude falls into. Errors you’ve corrected multiple times. Next time, Claude can avoid them before they happen.

These become institutional memory. It’s like the raw nutrients extracted from the fruits of your labor and converted into a portable serum that you can inject into future projects. Instead of the typical downward spiral of entropy that people report in working with these AI’s you get a positive upward spiral of increasing effectiveness with this “bottled judgement.” This is the grail as your system becomes like a team that’s getting more capable over time and more adapted to how you work.

BONUS: The Security Sandbox

Claude Code can do real damage if it goes off the rails. You hear stories like this one where CC decides to delete one’s entire home directory. You also have supply chain attacks that can target the MCP’s and dependency libraries and wreak havoc, not to mention prompt injection attacks where it can sabotage your system purely by reading malicious instructions in the repo code.

My setup on Mac:

1. Create a separate user account just for Claude Code work

2. Use Fast User Switching to move between accounts

3. Don’t log into sensitive accounts (email, banking, cloud consoles) from the sandboxed user account

4. Keep your sensitive data under your main admin account and never run CC there

This constrains the blast radius. If Claude goes rogue and starts deleting things, it can only delete things that user can access.

More friction for working? Yes. But I’d rather introduce a little friction and have peace of mind that the worst CC can do is nuke the AI user account and file system rather than access files in my main account and/or impersonate me and take over browser sessions where I’m logged into sensitive accounts.

The Overarching Lesson

All of these tips share a common theme: learn to act like the playmaker, not the quarterback.

Your job is to:

• Set up the environment for success

• Provide the right context at the right time

• Give Claude the autonomy to work

• Capture key learnings for next time to shape things

The better you get at being the play maker, the better Claude can be at winning games on the field as your quarterback.

What tips have you discovered? Reply to this email—I’m always looking to improve my workflow.

About Build School: I teach non-technical founders to ship production MVPs in 30 days using AI coding tools. If you want hands-on guidance applying these techniques, check out our next cohort or take my self-serve video course and work at your own pace.

The Reality:

• This is the first domino that needs to fall for things to work. Get this wrong and it blocks everything else and leads to frustration.

• Getting SSH keys working, WSL on Windows, GitHub authentication - these “simple” setup steps consumed more time than expected.

• Doing this at an in-person kickoff event was very helpful as we were able to bust through most hurdles and everyone left with ability to begin working.

What We Learned:

• Setup is boring but critical - if your foundation is broken, it blocks everything else.

• Windows users need WSL (Windows Subsystem for Linux) set up first and this has its own challenges as Toby found.

• Don’t skimp on the setup checklist, even if it’s drudgery

The Fix:

• Made environment setup a mandatory first session

• I distilled all the learnings from setup challenges into this lesson which is now the 2nd step in the video course. Toby made this comprehensive setup guide for WSL and Frame0 for a Windows user.

Takeaway: The unglamorous work of getting your tools configured properly is the bedrock of everything that follows so it’s worth taking this part slowly to get it right. Once you can get Claude Code working you’re pretty much in the clear as it helps with tedious technical steps like this but you have to get over that first technical hurdle. Fortunately these steps and caveats are all now well-documented in that lesson linked above.

Our small but mighty crew working during one of the Friday cowork sessions

Lesson 2: Start Visual, Not Technical

The Surprise:

• Students who started with Frame0 mockups (a free web-based Balsamiq-like tool) made faster progress than those who dove straight into code

• Imran did comprehensive Frame0 mockups for all screens and spent extra time on this step but this design-first approach gave him clarity on exactly what to build for his admin interface.

What We Learned:

• Non-technical founders think best in terms of UX, not in code

• Having visual mockups makes it easier to communicate with Claude Code: “Make this screen look like this mock”

• The “wireframes → prototype → Frame0 → build” flow became our standard process

• Students proposed alternative tools (UXPilot.ai) showing the visual-first approach resonated however I will continue to teach Frame0 as it has this free open source MCP server which makes it possible for Claude Code to act as your UX designer

The Methodology:

1. Review wireframes.md from Confabulator

2. Use Claude to generate prototypes from PRD

3. Generate screens with Frame0 MCP

4. Tweak in Frame0, save to /confabulator/mocks

5. Give Claude Code the mocks: “Build these screens”

Takeaway: When you can see it, you can build it. Get a “meeting of the minds” with Claude on the screens of your app before you start building anything. This reduces false starts, code debt and headaches from having to backtrack and make changes once you’ve begun building.

Lesson 3: The Pivot is a Feature, Not a Bug

The Story:

• Louise started with Coachnova (coaching platform), pivoted to dog walking app mid-course but came back to Coachnova once she & Nick partnered up

• Nick’s original idea got invalidated, switched to language learning tool and shipped the fastest.

• Rita iterated on her value prop and “flintstoned” the case study categorization manually via Claude Desktop on her first few before automating things.

What We Learned:

• The Confabulator → Frame0 → rapid iteration workflow makes pivoting cheap

• Traditional development makes changing direction expensive (sunk cost fallacy kicks in)

• To the extent you can reduce switching costs and make pivoting more frictionless the cost of experimenting goes to nearly zero and you can iterate faster.

• With AI tools, you can rebuild your entire app in hours, not months compressing the iteration loop to the point where you can be on a zoom call with a prospect making tweaks and pushing to production during the course of a call.

• The students who embraced changing direction based on input from prospects ended up with stronger products.

Why This Matters:

• Your first idea is probably wrong - and that’s fine. It’s a matter of breaking analysis paralysis and just moving forward with something that then gives you the excuse to talk with prospects and incorporate learnings from those conversations to dialing in the product.

• The goal isn’t to build your original idea perfectly; it’s to build something that earns you the right to have substantive conversations with prospects so you can learn and iterate.

• The cohort format gave everyone permission to change direction without feeling like failure.

Takeaway: The ability to pivot quickly is a superpower. Don’t fall in love with your initial idea or you’ll defend it in the face of contrary evidence. Instead fall in love with the problem and the discovery / pivot process to unearth and attack it.

Lesson 4: Accountability > Instruction

The Pattern:

• Nick showed up to every session, asked questions, kept building and had a completed MVP 2wks in (and that was after spending the first week on an idea that didn’t work)

• “Ninety percent of success in life is just showing up.” - Woody Allen. Students who missed sessions or “hadn’t done anything since last week” fell behind. Accountability and showing up to calls yields a virtuous cycle.

• The group dynamic created positive peer pressure: “Everyone else is shipping, I should too.”

What We Learned:

• The live troubleshooting sessions mattered more than the recorded lectures

• Having Kelly share his PadelMaps.org success story on Day 1 set the tone: “This is possible” - equivalent of breaking the four-minute mile and inspiring the cohort that it can be done.

• The format worked: Mon/Wed office hours + Friday in-person co-working

• Students proposed tools (Gummy Search, 2chat.io) to each other. As a group we cast a wide net of awareness in a space that’s evolving quickly so it’s yet another perk: being able to unearth useful tools by having broad awareness via others.

The Office Hours Magic:

• Real-time debugging (Toby’s quota limit issues, Rita’s API integration)

• Watching others solve problems taught as much as solving your own

• Social proof: “If they can do it, I can do it”

What Didn’t Work:

• Expecting significant progress between check-ins. Everyone in the group had a full-time job and/or family commitments and it’s just not realistic to think that it’s possible to commit multiple hours per day to working on their project.

Takeaway: What’s missing for most people is not the knowledge/instruction. It’s the accountability, peer motivation, and someone to unstick you when you’re blocked. Our cadence of M/W office hours and Friday in-person cowork was the perfect mix for this.

Lesson 5: Ship Ugly, Ship Early, Ship Often

The Success Story:

• Nick essentially had his iOS app done by Week 2 (Nov 14)

• He shipped incomplete features, tested them, iterated

• Meanwhile, some students were still “refining their foundational docs”

What We Learned:

• Perfectionism kills momentum. I said this repeatedly throughout the course but “Don’t let perfection be the enemy of shipping.”

• The students who deployed to Vercel early (even with bugs) made faster progress

• “Comfortable with the unknown” became a mantra - trust Claude Code even when you don’t understand every line.

• The database lesson: Build with dummy data first, add real database later.

The Workflow That Emerged:

1. Confabulator → foundational docs

2. Mockups → basic screens with hardcoded data

3. Deploy to Vercel (even if it’s borked)

4. Add database

5. Iterate based on user feedback

The Mindset Shift:

• From: “I need to understand everything before I build”

• To: “I’ll build, test, and figure out what I need to know as I go”

The “Checkpoint” Technique:

• Commit early, commit often

• Each commit is a save point - you can always /rewind or absolute worst case nuke your installation and pull the last known-good version from Github.

• This gave students confidence to experiment without fear of breaking everything.

Takeaway: The flawed app you ship today beats the perfect app you’ll launch “someday.” Get it live, get feedback, get better. I am planning to add a “firedrill” step early on in the next cohort where we intentionally break things, throw away the code and pull down a pristine copy from github so students internalize how proper Github habits make you bulletproof. That confidence to develop with abandon will be priceless and liberating.

Conclusion: What I’m Changing for Cohort 2

What’s Staying:

• Design-first approach (Frame0 mockups before coding)

• Monday/Wednesday/Friday rhythm

• Inspirational guest speaker on Day 1 (Kelly’s testimonial was gold - likely invite students from Cohort 1 back as alumni to inspire Cohort 2)

• Keep small cohort size (5-6 students max)

What’s Changing:

• Better Windows setup documentation (WSL guide upfront)

• Frame0 and Frame0 MCP in initial setup (not added later)

• Material now taught via the self-paced video course and office hours used for answering questions vs. teaching concepts

• More explicit “checkpoint” rituals (commit after every session)

• Standardized database approach from Day 1 (SQLite → Turso path)

The Big Lesson: Five students, five working apps, 30 days. These tools allow you to be a product manager and leverage AI as your engineering team - this is the future of building software even if you already know how to code. You can find all student demos from graduation night here. If you want to be part of Cohort 2 starting Jan 12th applications are now open. Or if you’re a self-starter and don’t need the cohort-based accountability component feel free to take the course and work independently at your own pace. Whatever your style we have an option to support you. The only question is “what will you build?”

Subscribe now

If you do one thing this year, learn to vibecode

The future of work is uncertain. You’ve heard about massive layoffs - 800k+ layoffs in the first seven months of 2025 in the US alone. Progressive companies like Zapier announced that they are “AI-first” and require that 100% of new hires have proficiency with AI in their role. In an environment where big companies openly use AI to justify cutting “replaceable” roles, the way to become in-expendable is to be the person who can wield AI, automation, and vibecoding to create value, not just knowledge to perform a narrow, automatable task.

What is vibecoding?

“Vibecoding” is the process of building software using plain english as your programming language. You can pick up a tool like Bolt.new or Lovable.dev and in a matter of minutes build a functional prototype application that works without knowing how to program. This method of building software promises to give superpowers to the layperson with the ability to create software without having to spend years learning how to write code.

It’s attractive - even seductive - the idea that you can generate an app in a matter of minutes. People have built internal tools that saved their teams countless hours and even launched side businesses that earn 5-figure MRR without knowing how to code. The problem is this utopian vision of vibecoding your way to riches and financial freedom tends to break down as soon as your application gains paying customers and it needs to be supported and extended with new features. Vibecoding is fantastic for prototyping but in its “shoot from the hip without a process” variant is inadequate for running production software. We need an approach that’s more deliberate and bulletproof to build production software. Fortunately one exists and I’m now teaching it.

Why this is important

A few examples of AI cannibalizing jobs in the corporate environment:

• IBM: Around 8,000 employees laid off in 2025, largely from HR, with the company stating those roles were being replaced by an internal AI chatbot (“AskHR”) while they rehire into software and data roles.

• Intel: Announced over 21,000 job cuts (nearly 20% of its workforce), tied to a shift in focus toward AI chip manufacturing and away from other units.

• Microsoft: More than 15,000 cuts in 2025, including 9,000 roles in gaming and cloud, framed as simplification and reinvestment in AI; management has explicitly linked productivity gains to tools like GitHub Copilot reducing the need for certain support layers.

• Meta & Google: Both have trimmed staff in specific divisions (e.g., Reality Labs at Meta; platforms/devices at Google) while simultaneously announcing increased investment in AI research and AI-powered product features.

Guess who the people are who are not getting let go?

The ones who learn to embrace these technologies and use them to amplify their effectiveness & productivity.

Learning how to vibecode an application is a double-whammy in that it:

1. Makes you less expendable and more desirable as an employee at a day job.

2. Gives you a superpower to start a revenue-generating side hustle that can provide a supplementary income stream and give you greater negotiating leverage.

So why doesn’t everyone learn this?

Tools like Lovable.dev and Bolt.new are super accessible and easily picked up by non-technical folks. The problem is they fall short when it comes to building production-grade software applications. Tools like Cursor, Claude Code, Windsurf, Anti-gravity, Codex and Copilot are the second tier, more-sophisticated implements one needs to accomplish this however there’s still a non-trivial technical barrier to overcome in using them. One needs to configure SSH keys, gain some basic proficiency with using the Linux command line, learn some basics of Git and Github, MCP’s, etc.

There has been no straightforward path (until now) that hand-holds the average non-engineer across this technical chasm by delivering just the minimum effective dosage of instruction with concepts one needs to know to gain proficiency with these tools. This gap is just wide enough to preclude 99% of people from using these incredibly-powerful tools.

Enter Vibecode Lisboa

I started this group three years ago in Lisbon in an attempt to close this gap.

It pre-dated the recent GenAI tools that have sprung up in the past year and was originally called “Nocode Lisboa” and centered around using tools like Bubble.io, Webflow and Adalo for building software as a non-technical person. With the advent of these recent powerful AI-based tools I pivoted the group to center on using them to take the place of Nocode. This is the way at this point. Once you grasp the basics of working with an LLM to build an application the Nocode approach seems incredibly arcane and restrictive (vendor lock-in, high fees, constrained in how fast you can iterate, none of the extensibility that MCP affords you).

As of today Vibecode Lisboa is a group with a physical presence in Lisbon, Portugal but one that welcomes participation in our online community regardless of where you are from. As a semi-retired individual it’s now my main focus and charge to help laypeople gain proficiency with these tools and get liberated from the rat race so they can comfortably create whatever it is they’re born to create on their own terms.

What will you build?

As we close out 2025 I invite you to take this thought exercise: imagine forward one, two, three years with your current work trajectory given your current skill set and changing nothing. What do your days look like? What types of work are you doing and how stable is your footing?

Now imagine your path with the capability to create fully-functional web and mobile apps in an afternoon. What can you build with the specific domain knowledge and judgement you’ve amassed over a career and a life of all the exposure to ideas and opportunities that are uniquely yours? What would it be like to emerge as the leader in your organization who figures out how to leverage these tools productively and levels up your team? How does that confidence feel once you’ve mastered the basics enough to create a side hustle which can provide for you and your family even if your corporate job gets cut? How much negotiating leverage does that give you next time you’re up for promotion in your day job? And what will you do with the hours you win back in your daily life having been able to automate and delegate drudgery via these tools?

2026 is the year to become proficient with GenAI tools and I will teach you how. My name is Sean Tierney and I am teaching people like you how to employ this stuff productively. Take my online self-serve course or apply for our next cohort and take the first definitive step to gaining proficiency with the tools that represent the greatest leverage potential of our lifetimes. I look forward to meeting you.