← The Vault
Building5 min read

5 videos that turn vibe coding into vibe engineering

Everyone knows how to vibe code. These five talks are how you engineer with AI instead. All five links up top, then what to change in how you work with Claude Code, Codex or Cursor after each one.

Links first, in the order I'd watch them. Under each one is what it covers and what to change in your own setup afterward.

1. Karpathy: you own the spec, the agent writes the code

Karpathy went from writing most of his code by hand to handing most of it to agents in a few weeks at the end of 2025. In this talk he splits that world in two. Vibe coding lets anyone build something. Agentic engineering is the professional version: directing agents that make mistakes while keeping the code correct, secure and maintainable. He treats the model as a new kind of computer, where what you put in the context window is the program.

  • Write the spec before the agent writes code. Have it interview you, save the answers to a file, and read that back before anything gets built.
  • Give it a way to check its own work: tests, a type check, a script that runs the feature. Agents are strongest where the result can be checked.
  • Read the diffs. If you can't explain what the agent changed, you don't own that code yet.
Prompt: spec first
Before you write any code, interview me one question at a time until you can write a spec for this feature: what it does, what it must not break, and how we'll know it works. Save it to SPEC.md, then stop and wait for my OK.

2. Pocock: small skills that load at the right time

Pocock grades a skill on four things. The trigger is when it loads. The structure is the steps it follows, with reference material kept separate. Steering is the handful of words that actually change what the model does. Pruning is cutting what no longer does anything. He compares his own skills repo with obra/superpowers along the way.

  • Take the long prompt you paste every week and make it a skill: a SKILL.md with a one or two line description of when to use it. The description sits in context all the time, so lead with the word you'd use when asking for it.
  • Keep the steps in SKILL.md and move reference material into separate files the skill points to. The agent only opens them on the paths that need them.
  • End every step with something the agent can check, so it knows the step is done.
  • Prune on a schedule. Cut lines the model would follow anyway, anything said twice, and fixes for problems the current model doesn't have. Run the skill after each cut.
  • My addition: when a step has to come out the same every time, make it a script in the skill's folder and have the skill run it. The folder method guide below does this for a whole agent.

3. Cherny: delete most of your prompt

Diana Hu interviews Boris Cherny, who created Claude Code and runs it at Anthropic. His team cut about 80% of Claude Code's system prompt for the newest models. A lot of that prompt was correcting things older models got wrong, and the new models did better with it gone. The other thread through the talk: give the model a hard goal and a way to check its own work, and that matters more than how you word the prompt.

  • Open your CLAUDE.md, AGENTS.md or Cursor rules and delete everything you added to fix an older model. Work with it for a day. Add a line back only when the same mistake happens twice.
  • Drop the ALWAYS, NEVER and MUST shouting. New models follow instructions more literally, and the emphasis makes them overdo it.
  • Before a long task, tell it how to check the result: the test command, the page to open, the output to compare against.
Prompt: audit your instructions
Read CLAUDE.md. For each line, tell me whether you would already do this without being told. List the lines you think we can delete and the ones worth keeping, with one sentence each on why. Don't edit anything yet.

4. Context engineering: only the tokens it needs

Lance Martin works on agents at LangChain, and this is an hour on what goes into the context window and what stays out. Agents make dozens of tool calls per task, and the output piles up until the model loses track. He groups the fixes into offloading context to files, reducing it with summaries and pruning, retrieving only what the task needs, isolating work in separate agents, and caching what doesn't change.

  • Stop pasting logs, docs and whole files into the chat. Save them to a file and let the agent search them for what it needs.
  • Keep a plan or todo file the agent updates as it works, so the goal stays in front of it in a long session.
  • Start a fresh session for each task, or compact, before the context fills up with dead ends. In Claude Code that's /clear and /compact.
  • Send research to subagents so only their summary comes back. Keep the edits in one thread so two agents don't make conflicting decisions.
  • Keep CLAUDE.md and your tool list short and stable. An unchanged start to the prompt gets cached, which is cheaper and faster, and every tool you switch on is one more thing for the model to choose between.

5. Error analysis: read your failures before you write evals

This one is from Andrew Ng's deep learning course in 2017, before any of this existed. A cat classifier is wrong 10% of the time and someone wants to spend months fixing dog photos. Ng pulls about 100 of the mistakes, looks at each by hand, and tallies the causes in a spreadsheet. If only 5 of the 100 are dogs, fixing dogs perfectly takes you from 10% to 9.5%. New categories get added as you spot them.

Hamel Husain and Shreya Shankar run the same loop on LLM apps. Read real runs, write down what went wrong, group the notes into categories, count them, and write automated checks for the biggest ones. Most people skip straight to the checks, and then they test for problems they guessed at.

  • Log every run of your AI feature: the input, the output and the tool calls.
  • Read 50 to 100 runs yourself. Write one line on the first thing that went wrong in each, since one early mistake causes the rest.
  • Group the notes, count them, and fix the biggest category first.
  • Turn each category into a check that runs on its own. Use a script when code can check it, like valid JSON, a word count or a number that matches the source. Use an LLM judge with a pass or fail question when it can't.
  • Keep the inputs that failed as test cases, and run every check again when you change the prompt or the model.
Prompt: first pass of error analysis
Here are logged runs of [feature] in [file]. For each run, write one line on the first thing that went wrong, or "ok". Then group the problems into categories, count each one, and show me a table sorted by count. Don't propose fixes yet.

Where to go next

Keep reading

Building7 min

The folder method: one AI agent that survives every model update

The full guide from the video. Skip the 300 agents. Use the one you already have, give it a map and one folder per job, and write the proof before the playbook, so a new model costs you a few lines instead of a week. Starter folder and all five prompts included.

Read it
Building5 min

6 Claude Code habits that stop it from getting dumber

The full guide from the video. Commit after every task, plan before you prompt, start a fresh chat for each task, cut your CLAUDE.md in half, have one agent review another, and make Claude prove its work. Every prompt is ready to copy.

Read it
Building7 min

1,000 hours of vibecoding: everything I learned, start to finish

The whole path from app idea to paying users, in order. The PRD, the plan, the build loop, the hacked and sued audits, deploying, and marketing, with every prompt ready to copy and every tool linked.

Read it

Want yours built?

Two minutes of questions, and our first call starts with the work instead of an intro.

Tell me about your app