← All sessionsHomeSearch
AI Sprints (Live Weekend Programs)·WindSurf and Devin Sprint·2:18:49

AI Sprint: Windsurf & Devin — Day 1 (Vibe to Agentic: GitHub as Pizza, the Four Spec Concerns, and the IDE Lineage)

Dileep (KVSS Dileep) Head of Generative AI Education at Outskill; a deliberately whiteboard-first foundations session ('don't expect me to show you the tool — that you can Google; my thing is the nuances of working with agents') · Kartik Host — logistics, recordings, certificates, guidelines · Shashwat Community lead — launches Alumni Forge (the community spaces) and the first live product-showcase event in the closing segment

Session map

THE TRANSITIONTHE FOUNDATIONSTHE TOOLConversation vs specificationthe real line between vibe coding and a…GitHub as a pizza restaurantbranch, PR, merge, fork, and the hidden…Edge cases, auth, rate limits…what every spec must carryThe IDE epicVS Code's forks, the Windsurf split, an…Windsurf 2 in twenty minutesCascade, adaptive routing, and the mode…
The transitionThe foundationsThe tool
click a node — its card pops up (drag it anywhere, × to close)
Concept

The map reads left to right — the transition flow into the foundations, then into the tool. Click any node to open that idea here; every timestamp jumps into the recording.

The short version

  1. The sprint's arc in one sentence: 'I am going to take you from VIBE CODING to AGENTIC CODING.' Vibe coding is a CONVERSATION ('an informal chat where you're figuring out what you want'); agentic coding is a SPECIFICATION ('in your head it is absolutely clear; you queue the spec and sometimes a swarm of agents builds it'). Grandma's recipe vs MasterChef: grandma's 'this much, that much' always comes out decent but can't be replicated; the MasterChef spec replicates perfectly — and one missed step ruins the dish.
  2. GitHub retold as a pizza restaurant, his best analogy run: the recipe book is the repo; BRANCHES are copies given to sous-chefs so experiments never touch the main recipe; a PULL REQUEST is 'dear chef, taste my step 3'; the chef MERGES or REJECTS WITH FEEDBACK ('I like your thought process, but the pizza is getting soggy'); a FORK is the sous-chef opening his own restaurant (changes never flow back); a COMMIT is the chef's hidden copy — the video-game save point you restore when disaster ships.
  3. The four things every specification must handle — the session's engineering-101 core: EDGE CASES ('how can your app go wrong? You can't anticipate all, but you can anticipate most' — the old-oven problem); AUTHENTICATION vs AUTHORIZATION (the cinema: the ticket gets you in, the seat is what you may use; auth is for PERSONALIZATION as much as security; build it LAST); RATE LIMITS (the houseguest food quota; 'Anthropic rate-limited OpenClaw' as the live example; read the agent-friendly docs); ERROR HANDLING ('the out-of-syllabus question' — specify per-error behavior plus the mother's final exception: 'anything you don't know, ask me').
  4. The IDE lineage decoded — the missing prequel to the Antigravity masterclass: VS Code's open source spawned Cursor, Windsurf, Kiro, Trae; Google bought Windsurf's founders and core (~20 of 100) and built ANTIGRAVITY from that snapshot; Cognition (makers of Devin) acquired the remaining company, and Windsurf 2 is the Devin-integrated continuation — 'some similarities, but they try to be quite different.'
  5. The Windsurf 2 tour plants Day 2's seeds: Cascade (the agent; 'composer in Cursor, agent mode in Antigravity — everybody works the same way'), ADAPTIVE routing as the headline ('it balances quality and cost per request — $0.5/M'), the in-house SWE 1.6 fast model, Kimi K2.6 free ('very similar to Claude Code'), Claude only via your own API key — and the standing doctrine: 'I'm showing you different pizzas. Taste it, or leave it. Don't ask me which is best.'
  6. The close launches ALUMNI FORGE: five community spaces (general chat, AI Pulse, peer support, wins & showcases, opportunity hub) on the LMS, a live product-showcase series, and house rules ('what's said in the Forge stays in the Forge; no WhatsApp groups; credit people always').

The concepts

01

Conversation vs specification: the real line between vibe coding and agentic coding

'Vibe coding is a conversation. Agentic coding is a specification.' Everything else about the transition follows from that one distinction.

Vibe coding: you explain a requirement informally, the AI builds, every new feature is another chat turn — 'you don't have clarity; you're trying to get there.' The platforms named for it: Bolt, Lovable, Emergent. Agentic coding: you SPECIFY — 'in your head it is absolutely clear what you want to build. You queue the specification, and sometimes even a swarm of agents builds your app.' The kitchen version: grandma's recipe ('this much... then this much... feel it, you know when it's done') is a conversation — always decent, never replicable; the MasterChef recipe ('150 degrees, 12 minutes — not 10, not 15') is a specification — perfectly replicable, and fragile: 'any one step goes here and there, your dish is off.' Neither is 'better'; they're methods — but 'if you're trying to become an AI generalist, start making the transition.'

The honest nuance: 'the lines can be blurred — you could be vibe coding in Cursor and attempting agentic coding in Lovable.' The transition has three steps: get comfortable with GitHub, learn to write good specs, then learn agentic orchestration (Windsurf/Devin). And the fragility of specs is exactly why the four concerns (edge cases, auth, rate limits, error handling) exist — specification precision cuts both ways.

Worked example · from the session

His own household: 'my wife is very specific; I do wild cooking. We made a pact never to be in the kitchen at the same time' — the two methods, married.

Why it matters

It gives the course's scattered vibe/agentic vocabulary one clean test: is this a conversation or a spec?

People get this wrong

Agentic coding is vibe coding with a better model.

It's a different input artifact: a specification with edge cases, auth, limits, and error behavior — the model matters less than the clarity.

Vibe coding is a conversation. Agentic coding is a specification.
Grandma's recipe is very good — but replication is going to be tricky. Specification is replicable. And any one step goes here and there, your dish is off.
For your projects

Your batched Lovable briefs are specifications by his definition — this session is the theory under your lovable-cost-discipline batching rule.

Go deeper

In one line: Vibe coding = iterative conversation toward an unclear goal (Bolt/Lovable tier); agentic coding = queued specification executed by agents (Cursor/Windsurf/Claude Code tier); specs replicate but are fragile, so spec-writing skill (edge cases, auth, limits, errors) is the actual transition.

The share-your-app test opens the session: 'has your friend come back saying this is not working?' — the gap this sprint exists to close ()

Spec fragility is stated as a feature-cost: precision buys replication at the price of brittleness ()

Anxiety permission granted twice: 'these are optional sessions... drop off anytime' — the sprint-tier teaching contract ()

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

You're three prompts into 'make it nicer.' Which mode are you in, and what would switching cost?

Conversation. Switching means stopping to write what DONE looks like — features, constraints, error behavior — which feels slower and is cheaper by the third feature.

02

GitHub as a pizza restaurant: branch, PR, merge, fork, and the hidden-copy commit

'Can the sous-chef tear the old recipe out of the book and glue in his new one?' Every GitHub concept falls out of the wrong answers to that question.

The restaurant: the repo is the recipe book; the chef is the maintainer. Sous-chefs don't edit the master recipe — each gets a COPY (branch A1, A2, A3) and experiments freely: 'working on the copy doesn't affect the main recipe... the main pizza keeps getting made for customers while the sous-chefs experiment.' When a change proves out, the sous-chef ASKS — 'dear chef, I made this change to step 3, taste it yourself' — a PULL REQUEST; the chef tastes and MERGES, or REJECTS WITH FEEDBACK ('I like your thought process, but the pizza is getting too soggy' — the good chef's rejection carries the reason). A FORK is the sous-chef opening his own restaurant with a copy of the recipe: changes never flow back automatically, though a kind chef may later offer his improvements ('you might accept, you might not'). A COMMIT is the chef's hidden copy — the saved-game checkpoint: 'anytime disaster happens, I go back to my previous commit and restore... you died at level 4, you come back to level 4, not level 1.'

The purpose is stated plainly: 'right now the AI will do all of this for you — I'm explaining the concept so you understand what is happening behind the scenes,' because agentic coding lives in branches, PRs, and commits whether you see them or not.

Worked example · from the session

The three-sous-chefs disaster that opens it: steps 3, 5, and 7 all changed without telling the chef — 'chaos, disaster, mess' — the un-versioned collaboration everyone intuits is wrong.

Why it matters

It's the corpus's best client-facing explanation of version control — teachable to anyone who has shared a kitchen.

People get this wrong

GitHub is for teams; solo builders can skip it.

The solo builder IS all three sous-chefs plus the chef — branches protect the working app from your own experiments, and commits are your only undo across sessions.

GitHub as a pizza restaurant Main branch the master recipe Your branch your test kitchen Pull request “taste this?” Merge recipe updated Fork open your own place Branch to experiment, PR to propose, merge to adopt — fork when you want the recipe for yourself
The pizza-restaurant model of branch, PR, merge, and fork
Working on the copy doesn't affect the main recipe. The main pizza keeps getting made for the customers while the sous-chefs keep experimenting.
Our chef is a very good chef. He will reject with feedback: I like your thought process, but the pizza is getting too soggy.
Anytime disaster happens, I can go back to my previous commit and restore. You died at level 4 — you come back to level 4, not level 1.
For your projects

Your snapshot ritual (validate --snapshot) is a commit in his terms — the hidden copy you restore against. Worth borrowing the save-point language in your plain-English reports.

Go deeper

In one line: GitHub via the restaurant: repo=recipe book, branch=sous-chef's copy, PR=taste-request, merge=recipe updated, reject-with-feedback=quality gate, fork=new restaurant (one-way), commit=hidden copy/save point for disaster recovery; agents operate these mechanics for you, but the mental model stays yours.

Reject-with-feedback is presented as chef-craft, not bureaucracy — reviews teach ()

Fork vs branch is a question of restaurant membership: same restaurant returns to main; new restaurant never does ()

'I can merge many times, but I commit only when I'm sure I've reached a milestone' — commit discipline in one line ()

Worktrees explicitly deferred to Day 2 — 'a subtle difference, I don't want to confuse you' ()

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Your vibe-coding tool shows 'checkpoints.' What are they in restaurant terms?

Commits — hidden copies of the recipe. Restoring a checkpoint is the chef tearing out the soggy changes and reinstating the saved version.

03

Edge cases, auth, rate limits, error handling: what every spec must carry

'What are the different ways my pizza can go wrong?' Preemptive care — the four sections your specification needs before any agent starts building.

EDGE CASES — the boundary where cooked becomes burnt: 'your recipe works in your new oven; your friend's old oven overheats — pizza spoiled.' You cannot anticipate all edge cases ('the room agreed: 0% confidence in a foolproof recipe'), but 'most of them you can' — the iPhone-SE-through-original spread for a mobile app — and mapping the common ones is what separates engineering from hoping. AUTHENTICATION vs AUTHORIZATION — the cinema: the ticket (authentication) gets you in; the seat class (authorization) is what you may use. The under-taught point: auth exists for PERSONALIZATION as much as security ('how does the app know you're on page 27?'), local storage dies with crashes and deletions, and the workflow rule is BUILD AUTH LAST — 'make it the last feature before you hand it to a user, so you're not logging in every test cycle.' RATE LIMITS — the houseguest quota ('only two pieces of pizza for you; the rest is for the guests'): APIs throttle per tier even when paid, the live example being 'Anthropic rate-limited OpenClaw'; and documentation has become AGENT-FRIENDLY — ElevenLabs' copy-page/open-in-Claude buttons mean 'this is what your agent reads, not you.' ERROR HANDLING — the out-of-syllabus question: specify behavior per known error ('error 1 do this, error 2 do this'), give users useful invalid-input messages instead of blank screens, and close with the mother's final exception: 'anything you don't know how to act — ask me.'

Worked example · from the session

The summary couplet he lands: 'edge cases are where things COULD go wrong; error handling is what to do WHEN they go wrong.'

Why it matters

These four sections are the difference between a spec that replicates and a spec that shatters — the fragility antidote for the MasterChef method.

People get this wrong

Authentication is a security checkbox to add early.

It's a personalization system that adds test friction — design it in the spec, build it last, and know the difference from authorization (the ticket vs the seat).

You cannot anticipate all the edge cases, but most of the edge cases you can. And if you can, you will build a good application.
Everybody says security. The main reason you need authentication is personalization.
Your mother has put a rate limit on your food.
This is what your agent reads, not you. Every documentation has become agent-friendly — it is no longer human-friendly.
For your projects

The rate-limit houseguest analogy and the cinema auth split are client-meeting language worth lifting whole.

Go deeper

In one line: Spec completeness = mapped common edge cases + auth/authorization design (personalization-aware, built last) + rate-limit awareness for every external API (read the agent-facing docs) + per-error handling with a human-escalation default; the preemptive-care layer of agentic coding.

The 'anticipate most, not all' stance keeps edge-case work finite and honest ()

Auth-last is a friction rule, not a security rule — testing velocity first, lockdown before handoff ()

Rate limits bite paid tiers too — 'just because you're paying doesn't mean you can use it directly' ()

Agent-friendly docs are a real shift: format-for-machines documentation is what your agent actually ingests ()

The quirky-error-page vs blank-screen contrast: handled errors communicate; unhandled ones vanish ()

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Which of the four concerns does the mother's 'final exception' implement?

Error handling's catch-all: any situation outside the specified cases escalates to the human instead of freezing — the ask-me default every agent spec should end with.

04

The IDE epic: VS Code's forks, the Windsurf split, and where Antigravity actually came from

'Let me tell you the Odyssey, the Iliad, the Mahabharata of IDEs.' One acquisition story explains two products the course teaches separately.

In the beginning: VS Code, open source — so people forked it into companies: Cursor, Windsurf, Kiro (Amazon), Trae (ByteDance). Then the split that created two lineages: Google 'purchased the founders with the core team' of Windsurf (~8-20 of 100 people, with the IP as of that date) and built ANTIGRAVITY from that snapshot. The remaining ~80 people kept building Windsurf — until COGNITION, makers of the autonomous agent DEVIN, acquired the company: 'Windsurf became Windsurf 2 with Devin integrated — a convergence.' So Antigravity and Windsurf 2 are siblings from one codebase, diverging on purpose: 'there are similarities, but they try to be quite different from each other.'

The teaching stance that frames every tool session: 'I'm showing you different types of pizza. Taste it and decide. Don't ask me which pizza is best — I'll tell you how this one differs from that one. Take it, taste it, or leave it.'

Worked example · from the session

The practical echo: features converge ('skills, MCP servers — everybody has the same features; the ORCHESTRATION is different') — lineage explains the family resemblance the Antigravity masterclass observed.

Why it matters

It's the missing prequel that makes the tool landscape legible: who forked whom predicts which skills transfer.

People get this wrong

Antigravity is Google's from-scratch IDE.

It's built from Windsurf's acquired core and IP snapshot — the sibling rivalry with Windsurf 2 is a fork of a fork of VS Code.

I'm showing you different types of pizza. Take it, taste it, or leave it. Don't ask me which pizza is best.
For your projects

The acquisition story is also a market lesson for clients: today's tool may be tomorrow's two tools — harness portability (s20) is the insurance.

Go deeper

In one line: IDE lineage = VS Code (open) → forks (Cursor, Windsurf, Kiro, Trae) → Windsurf splits: core team + IP snapshot → Google's Antigravity; remaining company + Devin → Cognition's Windsurf 2; siblings differentiated by orchestration, not features.

Acqui-hire vs acquisition distinguished in plain terms — the people went one way, the company another ()

Devin enters the corpus here: the autonomous-agent lane that Day 2 demonstrates ()

The taste-the-pizza doctrine is a standing anti-ranking policy across all his tool sessions ()

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why do Antigravity and Windsurf 2 feel similar despite being competitors?

Same parent codebase at the split point — the differences live in post-split orchestration choices, which is exactly where to focus a comparison.

05

Windsurf 2 in twenty minutes: Cascade, adaptive routing, and the model price ladder

'Adaptive: $0.5 per million tokens. It balances quality and cost — based on the input, it decides which model answers.' Routing as a first-class product feature.

The tour, planted for Day 2's build: Windsurf 2 looks like every VS Code descendant ('everyone is based out of Visual Studio Code only... mostly like Antigravity'); the agent is CASCADE (Cmd+L — 'like Composer in Cursor, agent mode in Antigravity; everybody works the same way'). The distinguishing feature is the MODEL MENU as a price ladder: ADAPTIVE at ~$0.5/M auto-balances quality and cost per request ('a Windsurf feature — don't think adaptive exists in Antigravity'); SWE 1.6 FAST is the in-house coding model at the cheap end; Kimi K2.6 rides the FREE tier ('very similar to Claude Code — you don't have to worry'); DeepSeek sits mid-ladder; Claude Opus tops it and requires YOUR OWN API key ('they don't have an integration — you connect the key'). Setup is conversational end to end: 'make a simple repo in GitHub... I am a non-technical person, help me connect' — repo created by asking. Arena (model-comparison) is teased for Day 2, alongside worktrees, Devin, and the Superplexity build against an existing codebase — 'from scratch everything looks hunky-dory; picking up existing code is where things break.'

Worked example · from the session

The name of the build carries the ambition: SUPERPLEXITY, 'an advanced version of Perplexity... I might not finish it, but I'll get it to good shape.'

Why it matters

Adaptive routing productizes the cheap-model doctrine the Hermes sprint taught by hand — the router chooses the 80-percent model for you.

People get this wrong

The IDE choice determines your model quality.

Every descendant runs every model class; what differs is routing, pricing tiers, and which frontier models need your own key.

For your projects

The 'help me connect, I am non-technical' setup pattern is the same legitimate move Dileep used in the Hermes sprint — worth normalizing in your own client training.

Go deeper

In one line: Windsurf 2 = VS Code-descended agentic IDE with Cascade as the agent and a priced model ladder (adaptive auto-routing ~$0.5/M, in-house SWE 1.6 fast, free Kimi K2.6, BYO-key Claude Opus); conversational GitHub setup; differentiation via orchestration and routing, not features.

Free-tier honesty shapes the demo: he plans around what learners can replicate without paying ()

The BYO-Claude-key detail is a routing-economics tell: frontier intelligence is a bolt-on, not the default ()

Existing-codebase work named as the real test — the scenario 'we typically don't show' — scheduled for Day 2 ()

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

When would you override adaptive and pin a model?

Stringent planning across repositories — his own example: 'a very stringent plan requiring a lot of thinking, that's when you might use Claude' — judgment steps pin frontier; the rest rides the router.

Every concept, three clicks deep

The same concepts as a quick reference: the closed row is the glance, open is the study card, and every timestamp jumps into the recording.

01Conversation vs specification: the real line between vibe coding and agentic codingVibe coding = iterative conversation toward an unclear goal (Bolt/Lovable tier);

Vibe coding = iterative conversation toward an unclear goal (Bolt/Lovable tier); agentic coding = queued specification executed by agents (Cursor/Windsurf/Claude Code tier); specs replicate but are fragile, so spec-writing skill (edge cases, auth, limits, errors) is the actual transition.

The share-your-app test opens the session: 'has your friend come back saying this is not working?' — the gap this sprint exists to close ()

Spec fragility is stated as a feature-cost: precision buys replication at the price of brittleness ()

Anxiety permission granted twice: 'these are optional sessions... drop off anytime' — the sprint-tier teaching contract ()

02GitHub as a pizza restaurant: branch, PR, merge, fork, and the hidden-copy commitGitHub via the restaurant: repo=recipe book, branch=sous-chef's copy, PR=taste-request, merge=recipe update…

GitHub via the restaurant: repo=recipe book, branch=sous-chef's copy, PR=taste-request, merge=recipe updated, reject-with-feedback=quality gate, fork=new restaurant (one-way), commit=hidden copy/save point for disaster recovery; agents operate these mechanics for you, but the mental model stays yours.

Reject-with-feedback is presented as chef-craft, not bureaucracy — reviews teach ()

Fork vs branch is a question of restaurant membership: same restaurant returns to main; new restaurant never does ()

'I can merge many times, but I commit only when I'm sure I've reached a milestone' — commit discipline in one line ()

Worktrees explicitly deferred to Day 2 — 'a subtle difference, I don't want to confuse you' ()

03Edge cases, auth, rate limits, error handling: what every spec must carrySpec completeness = mapped common edge cases + auth/authorization design (personalization-aware, built last…

Spec completeness = mapped common edge cases + auth/authorization design (personalization-aware, built last) + rate-limit awareness for every external API (read the agent-facing docs) + per-error handling with a human-escalation default; the preemptive-care layer of agentic coding.

The 'anticipate most, not all' stance keeps edge-case work finite and honest ()

Auth-last is a friction rule, not a security rule — testing velocity first, lockdown before handoff ()

Rate limits bite paid tiers too — 'just because you're paying doesn't mean you can use it directly' ()

Agent-friendly docs are a real shift: format-for-machines documentation is what your agent actually ingests ()

The quirky-error-page vs blank-screen contrast: handled errors communicate; unhandled ones vanish ()

04The IDE epic: VS Code's forks, the Windsurf split, and where Antigravity actually came fromIDE lineage = VS Code (open) → forks (Cursor, Windsurf, Kiro, Trae) → Windsurf splits: core team + IP snaps…

IDE lineage = VS Code (open) → forks (Cursor, Windsurf, Kiro, Trae) → Windsurf splits: core team + IP snapshot → Google's Antigravity; remaining company + Devin → Cognition's Windsurf 2; siblings differentiated by orchestration, not features.

Acqui-hire vs acquisition distinguished in plain terms — the people went one way, the company another ()

Devin enters the corpus here: the autonomous-agent lane that Day 2 demonstrates ()

The taste-the-pizza doctrine is a standing anti-ranking policy across all his tool sessions ()

05Windsurf 2 in twenty minutes: Cascade, adaptive routing, and the model price ladderWindsurf 2 = VS Code-descended agentic IDE with Cascade as the agent and a priced model ladder (adaptive au…

Windsurf 2 = VS Code-descended agentic IDE with Cascade as the agent and a priced model ladder (adaptive auto-routing ~$0.5/M, in-house SWE 1.6 fast, free Kimi K2.6, BYO-key Claude Opus); conversational GitHub setup; differentiation via orchestration and routing, not features.

Free-tier honesty shapes the demo: he plans around what learners can replicate without paying ()

The BYO-Claude-key detail is a routing-economics tell: frontier intelligence is a bolt-on, not the default ()

Existing-codebase work named as the real test — the scenario 'we typically don't show' — scheduled for Day 2 ()

Tools referenced

ToolCoverageMomentContext
WindsurfdemonstratedWindsurf 2 tour: Cascade, adaptive routing, SWE 1.6 fast, free Kimi K2.6, BYO Claude key; Arena/worktrees/Devin deferred to Day 2
AntigravityexplainedOrigin story: built from Windsurf's acquired core team and IP snapshot
VS CodeexplainedThe open-source ancestor of the entire agentic-IDE family
GitHubexplainedThe pizza-restaurant recap: branch/PR/merge/reject-with-feedback/fork/commit; repo created conversationally in the demo
Kimi (Moonshot)explainedK2.6 on Windsurf's free tier — 'very similar to Claude Code'
ElevenLabsexplainedThe agent-friendly documentation exhibit: copy-page, open-in-Claude/ChatGPT/Cursor buttons
Devin (Cognition)mentionedThe autonomous agent whose maker acquired Windsurf; demonstrated Day 2
CursormentionedFellow VS Code fork; Composer named as Cascade's counterpart
Kiro (Amazon)mentionedNamed in the fork family
Trae (ByteDance)mentionedNamed in the fork family
DeepSeekmentionedMid-ladder pricing slot in the model menu
Claude CodementionedPrior sprint referenced; Opus available in Windsurf only via BYO API key
LovablementionedNamed in the vibe-coding conversation tier with Bolt and Emergent — descriptive, not dismissive
BoltmentionedVibe-coding tier example
EmergentmentionedVibe-coding tier example
ReplitmentionedReplit Auth named as a managed authentication lane
SupabasementionedAuth via edge functions — 'don't ask me what an edge function is, for now just take it'
OpenClawmentionedThe rate-limit case study: 'Anthropic rate-limited OpenClaw'
PerplexitymentionedThe benchmark Superplexity aims to advance

Action items

Resources mentioned

Resources
  • docSuperplexity plan
  • docAlumni Forge launch
  • docElevenLabs agent-facing docs
  • docRecordings + certificates

Extraction notes

This page was built from an auto-generated transcript, which garbles product and people's names. Those were corrected silently in everything above and logged here for transparency. The warnings flag claims that were true on the recording day but change fast.

Transcript corrections applied

The transcript saysThe trainer actually means
WinSoft / WinSurf / Windsors / winds ofWindsurf
Devon / DevynDevin (Cognition's autonomous coding agent)
white coding / wipe coding / pipe coding / wild codingvibe coding (and once, his own 'wild cooking' pun)
agent decoding / agentic decodingagentic coding
Versus CodeVS Code
Tre by ByteDanceTrae (ByteDance IDE)
Kiro by AmazonKiro
Corporation with DevonCognition (with Devin)
SWE 1.6 fast / SWA 1.6Windsurf's in-house coding model (as-heard version)
Kimi 2.6 / Kimi k 2.6Kimi K2.6 (as-heard version)
GBT 5.5GPT-5.5 (as-heard)
LevelLabs / ElevenLabs APIElevenLabs
super base / SuperBaseSupabase
open clock / open clogOpenClaw
superplexitySuperplexity (the sprint's build target — as-named)
Sashwat / Saswat / Shashwat / Harish (once)Shashwat (community lead; 'Harish' is a mis-hearing of his thanks to Dileep)
IT production (chef doesn't worry about)IP protection
LMEI 4 gs / alumni for / Illumina forgeAlumni Forge
Gajin / Mento(not present this session — Ghajini/Memento belong to the Hermes sprint)
fifteenth May 2026the product-showcase date — dates this session to ~mid-May 2026

True on recording day — verify before relying