Most vibe coding guides are written by people who forgot what it felt like to not know anything. This one is different.
Part II of Matt Blumberg’s five-part series on vibe coding for non-coders was written with Andrew Winston, who built and shipped a real product called Context Coach as a genuine non-engineer, recently enough to remember every place he got stuck. Matt supplies the structure. Andrew supplies the fresh scars and the real setup list as a worked example.
One caveat up front: tools, prices, and signup flows change fast. The specific how-tos in this series are current as of writing. The reasoning behind them is the part that will stay useful longer.
️ Two setups, two different jobs
The core insight of this piece is that you’re not setting up one thing when you start a vibe coding project. You’re setting up two things that do different jobs:
- A Claude Project for design and thinking
- A Claude Code session for building
Conflating the two is one of the most common places non-engineers get confused early on. The Project holds your standing context. The Code session is where the actual work happens. Keeping them separate keeps each one focused.
What belongs in your Project instructions
The Project instructions are the standing context that makes every later session cheaper to run. You write them once and they inform every conversation that follows. According to Blumberg and Winston, a solid set of Project instructions should include:

- Who you are, and specifically that you’re not technical
- What the thing is in two sentences, and who it’s for
- Where the code lives
- The key files and what each one does
- Where it’s hosted
- The stack in one line
- How you work (your preferences, your rhythm, how you like to be asked questions)
- What’s currently in flight
That last item matters more than it looks. Telling the AI what you’re actively working on means you don’t spend the first five minutes of every session re-explaining where you left off.
Why the co-author setup works here
The decision to write this part with Andrew rather than just about non-engineers is what makes the framing credible. Matt runs a Linux server and has long since forgotten the beginner experience. Andrew shipped Context Coach recently enough that the friction points are still fresh.
This is the structural problem with most technical documentation: it’s written by people who have automated away the pain. A guide written with someone still feeling that pain is a different kind of useful.
What’s next
Parts III through V of the series will continue the pattern: durable reasoning paired with current how-tos, grounded in Andrew’s actual build experience with Context Coach. If you’re a non-technical founder or indie hacker thinking about shipping your first AI-assisted project, this series is worth following from the beginning.
