Curriculum & Syllabus

VibeShift — Cohort 1

A 3-hour, hands-on Claude Code workshop for people who already build things at work.

You bring one concrete idea from your job. We build it with Claude Code, coaches in the room, and your actual work as the material. You leave with something deployed to a real URL and a workflow you can repeat on Monday. This page is the syllabus — forward it to your manager if you need to expense the registration.

1.At a glance

2.Pre-work

About 30 minutes total. Knock these out before you arrive so we can use the workshop time for building, not setup. If pre-work isn't done by the day of the session, we'll bump you to the next cohort — the workshop only works if everyone starts at the same line.

Required (~30 min)

• Sign up for Claude Pro — claude.ai/login?plan=pro ($20/month). The free plan does not include Claude Code; Pro is the floor.
• Install Claude Code. Easiest path on macOS is the desktop app at claude.com/download. Terminal-comfortable folks can use the CLI: curl -fsSL https://claude.ai/install.sh | bash. Either way, run claude once and log in with your Pro account. Setup docs: code.claude.com/docs/en/setup.
• Sign up for Cloudflare (free tier) — dash.cloudflare.com/sign-up. Verify the email they send. No credit card needed.
• Come with one concrete small thing you want to launch — not a spec, not a Notion doc, a real idea you can describe in one sentence.

Optional (only if the terminal is your thing)

• Install Node.js — brew install node or nodejs.org. Wrangler (the Cloudflare deploy tool) runs on it; we'll install Wrangler together in the room.
• Install GitHub CLI — cli.github.com or brew install gh, then gh auth login. We can deploy without it if you skip this.

3.Learning outcomes

By the end of this workshop, you will be able to:

• Use plan mode and bypass mode in Claude Code to ship faster while keeping a hand on the wheel.
• Translate a one-sentence idea into a spec the model can build against — and catch when the spec is wrong before code gets written.
• Verify AI-generated work without writing automated tests, using manual happy-path QA and screenshot feedback loops.
• Deploy a working prototype to a public URL on Cloudflare's edge using a pre-wired template.
• Recognize the common vibe-coding failure modes — conflating planning with execution, "just make it work" unsupervised runs, and accepting changes you can't explain — and steer around them.
• Repeat the spec → build → verify → ship loop on your own work next week, without a coach in the room.

4.Curriculum at a glance

Mostly doing, minimal slides. Short teach-then-do cycles so you're touching your own idea within the first 30 minutes.

1. 1. Kickoff & framing 15 min

   Three working principles for the day: planning is not execution, ask Claude what you don't know, come with a point of view. Quick go-around on what each person is building.

2. 2. AI familiarity check 15 min

   A few self-paced micro-prompts in claude.ai to calibrate the room and warm up your thinking on the idea you brought.

3. 3. Claude Code core 15 min

   Plan mode, bypass mode, feeding context (files, URLs, images, logs), and the interrupt pattern — cutting Claude off mid-plan to course-correct.

4. 4. The full workflow: spec to ship 55 min

   The core arc, taught continuously: write a spec for your idea, get Claude to agree on it, build a slice, click through it yourself, screenshot bugs back, iterate. Coaches circulate.

5. 5. Break 5 min

   Stretch, water, refill the brain.

6. 6. Build & demo 40 min

   Tour a pre-built Cloudflare Workers template — hosting, domain, deploy already wired. Wire your idea into it, deploy to a real URL, share the link.

7. 7. Office hours 25 min

   Small breakouts with a coach in each room. Stuck on deploy, prompting, or scope? Get unstuck. Already shipped? Start on v2.

8. 8. Wrap 10 min

   Recap of what you have now versus three hours ago, an invite to the post-session community, and an open mic for v2 ideas.

5.Instructor

Darlin Alberto is a technologist and consultant with 12+ years in B2B SaaS and applied AI. He built Atticus AI, a contract analyzer recognized by the Vercel AI Accelerator, and has shipped AI products across legal, health, and SEO. He runs Ascention, works with founders as a hands-on technical partner, and uses Claude Code daily. Cornell Engineering, based in NYC. The workshop is the formalized version of what he's been doing one-on-one for years — sitting next to someone, understanding their work problem, and showing them how to solve it.

6.What you leave with

• A working prototype of your idea, deployed to a real URL anyone can visit.
• Screenshots and a short demo you can share with your team or your boss.
• The Cloudflare Workers deploy template, in a repo you keep and can fork for the next idea.
• The slides and reference material from the session.
• An invite to the post-workshop community for follow-up questions and a v2.

7.FAQ

Can I expense this?

Yes — tuition is structured as a learning & development expense and most attendees do. Stripe sends a proper invoice with your name and (optional) company on it as soon as you confirm registration; that invoice doubles as a receipt. Forward this page to your manager and you have a syllabus, learning outcomes, and instructor bio in one place. If your employer ultimately declines to reimburse, see the courtesy half-refund in our Terms of Service.

Is this for people who can't code?

It's built for technical-adjacent builders — PMs, designers, founders, and operators who already make things. You don't need a CS background, but you should be comfortable using AI tools and willing to tinker. If you've played with Claude or ChatGPT but can't get past the demo stage, that's the gap this fills.

What hardware do I need?

A laptop. macOS is the smoothest install path for Claude Code; Windows and Linux work but the install steps differ. The pre-work links cover all three.

What if I have to miss it?

Refunds, transfers, and the courtesy half-refund for L&D-denied reimbursements are spelled out in our Terms of Service. The short version: if we cancel, you get a full refund; if you can't make it, we'll usually roll you to the next cohort.

8.Post-workshop

Cohort 1 is done. Below is everything you need to keep building: what we learned, what everyone shipped, the recording, and a prompt library you can copy straight into Claude.

What we learned

The biggest takeaway was simple: planning is the highest-leverage thing you can do. The people who shipped the most in three hours were the ones who spent the first 20 minutes telling Claude exactly what they wanted, what they didn't know, and what "done" looked like — before any code got written.

• State what you want, what you don't know, and what constraints exist. Claude fills gaps with assumptions. If you don't name the gaps, you don't control what it assumes.
• Stop Claude when it's wrong. Don't wait and hope it course-corrects. Interrupt, tell it what's off, and redirect. One sentence is enough.
• Start new chats when the conversation gets long. Context rot is real — Claude loses track of what matters after too many messages. Paste your spec into a fresh chat and keep going.
• Use a PRD as a reusable artifact. A short spec that travels between sessions beats a long chat history every time.
• Data integrations are deceptively hard. Scraping, authentication, and external APIs were the most common blockers. If your MVP needs live data, scope that as its own problem first.
• Design defaults look like AI slop. Purple gradients, glassmorphism, generic startup UI — tell Claude exactly what you want it to look like, or reference a specific brand or aesthetic.

What everyone built

• Home affordability calculator — shipped and deployed
• Tennis scheduling app — built locally, working prototype
• Gluten-free menu analyzer — published as a Claude artifact
• Subway tracker — prototype in progress

Have a link to share? Send it over and we'll add it here.

Recording & notes

Prompt library

Twenty ready-to-use prompts from the workshop. Click any prompt to copy it, paste it into Claude, fill in the brackets, and go.

I want to build [idea in one sentence].

Problem: [who has this problem and why it hurts]
User: [specific person — not "everyone"]
Outcome: [what the user can do after that they can't do now]
Time: I want a working prototype in [X hours].

Give me your honest read: is this buildable in that time? If not, what's the smallest version that is?

Here's my idea: [paste your pitch or one-liner]

Poke holes in it:
1. What assumptions am I making that are probably wrong?
2. What parts sound simple but are actually hard?
3. What would break first if a real person used this?
4. What's the smallest version that's still useful?

Be blunt. I'd rather cut scope now than hit a wall later.

Act as a skeptical CTO reviewing a prototype pitch.

Idea: [idea]
Build time: [X hours]
Tools: Claude Code, deploying to [Cloudflare / Vercel / local]

Tell me:
- What's unrealistic about this scope
- What I should cut
- What the MVP should actually be (features only, no nice-to-haves)
- The top 2-3 technical risks that will block me

No encouragement. Just the cuts and the risks.

I have [X hours] to build and deploy a prototype.

Idea: [idea]
Stack: [stack if known, or "you pick, keep it simple"]

Given this time constraint:
1. What is the absolute minimum version I can ship today?
2. What features get cut?
3. What's the demoable output -- what does someone see when they open it?

Optimize for working and demoable, not polished.

Write a 1-2 page PRD for this idea. Nothing else -- no code, no prototype.

Idea: [idea]
User: [who]
Problem: [what]
Time constraint: [X hours to build]

Include:
- Problem statement (2-3 sentences)
- Target user
- Core user need (one sentence)
- MVP scope: what's in, what's explicitly out
- Key features (max 5)
- Technical constraints or unknowns
- What "done" looks like -- how do I know it works?

Keep it tight. This is a build doc, not a pitch deck.

Here is my PRD: [paste PRD]

Use this as the source of truth. Before writing any code:
1. Create a step-by-step implementation plan
2. Flag anything in the PRD that's ambiguous -- ask me before assuming
3. Keep scope narrow -- if something isn't in the PRD, don't build it
4. Order the plan so I have something working and visible as early as possible

Do not write code yet. Just the plan.

Use this repo as the starting point: [repo URL or path]

I'm deploying on [Cloudflare / Vercel / Railway / local only].

Adjust the implementation plan to:
- Use what's already in the repo -- don't replace things that work
- Match the existing stack (framework, language, config)
- Skip setup steps that are already done
- Flag anything missing that I need to install or configure

I'm building [idea].

What I know:
- [thing you're confident about]
- [another thing]

What I don't know:
- [gap in your knowledge]
- [another gap]

Don't make assumptions in the areas I don't know. When there are choices, explain the tradeoff in one sentence and recommend the simplest option. Ask me before picking anything complex.

Constraints for this session:
- Ship today, not next week
- Keep it lightweight -- no unnecessary dependencies
- Avoid external integrations unless absolutely required
- Avoid paid services
- Working beats polished
- I need something I can show someone by the end

If anything you're about to do doesn't serve these constraints, stop and ask me first.

Do not use generic AI app styling.

Avoid: purple/blue gradients, glassmorphism, generic "modern SaaS" look, placeholder logos, stock-photo energy.

Instead, use this direction:
- Style references: [brand, site, or aesthetic -- e.g. "Craigslist simplicity" or "Bloomberg terminal" or "Japanese convenience store signage"]
- Colors: [specific colors or "you pick, but make it feel like ___"]
- Tone: [playful / serious / minimal / dense / warm / cold]

The design should feel like a specific person made it, not a template.

Stop.

You're going in the wrong direction.

The goal is: [what you actually want]
What you're doing wrong: [what Claude is building or doing that's off]

Back up. Propose the simplest correct next step -- one step, not a plan.

Pause. What are you doing right now?

Is it necessary for the MVP? If not, stop and tell me what you'd cut to get back to the shortest path to done.

This is broken and I don't know why.

[paste error message, screenshot description, or what you're seeing]

Add logging at each step so we can see exactly where it fails. Then diagnose and fix. Keep the fix minimal -- don't refactor, just fix.

Here's what I'm seeing: [paste logs / error / screenshot]

Tell me:
1. What's actually happening (not what should be happening)
2. What the root cause most likely is
3. The smallest fix to try next

Don't refactor. Don't improve. Just fix.

Deploy this to [Cloudflare Workers / Vercel / Railway].

If anything is missing from my setup, tell me exactly what to do -- specific buttons, commands, or config values. No general advice.

Keep the deployment as simple as possible. If there's a simpler deploy path than what we planned, use that instead.

Create a Claude artifact that does this: [what it does]

The user should be able to:
- [input -- e.g. "upload a photo of a restaurant menu"]
- [output -- e.g. "get back a list of gluten-free options with explanations"]

Keep it self-contained. No external APIs. It should work the moment someone opens it.

I need data for this project: [what you're building and what data it needs]

Find the best available sources. For each one tell me:
- What it provides
- Cost (free / freemium / paid)
- How reliable it is
- Setup complexity (1-5, where 1 is "just call the API")
- Whether it works for an MVP

Prioritize: free, easy setup, no scraping, no legal risk. I can upgrade later.

Starting fresh. Ignore anything from previous conversations.

Here's where the project stands: [paste your PRD, plan, or current state]

This is the source of truth. Pick up from here. Don't revisit decisions already made -- just move forward.

We're stopping for today. Create a worklog I can use to pick this up later.

Cover:
- What we built (be specific -- files, features, URLs)
- Decisions we made and why
- What's working
- What's broken or unfinished
- Recommended next steps in priority order

Write it so someone with no context could read it and keep going.

Based on today's work, what changed from the original plan?

Update the PRD/spec to reflect:
- What we cut and why
- Technical constraints we discovered
- Decisions we made that affect future work
- What to do next, in priority order

Mark anything that's a guess vs. confirmed.