Stephan Smith Fractional CTO
← Vibe Coding 101

Bonus chapter

Continuing Ed (i.e. ongoing education)

You don’t need a CS degree. You need a syllabus that keeps up with your app (and yes, you can audit this class forever).

What you'll see developers say online

Developers will tell you that if you are not a “real” engineer, you should stop vibe coding and go get a CS degree, a bootcamp, or ten years of experience before you touch production again. They use jargon as a gate: either you understand everything under the hood, or you are dangerous. That keeps you dependent and anxious, and it ignores that founders need conceptual literacy, not a second career writing code.

The solution: ongoing education in plain language

This is the bonus round. After observability, hygiene, shipping, security, and scalability, the job is not to become a developer. It is to understand what those words mean for your app and why they matter when something breaks or someone judges your stack. Continuing ed, not MIT: revisit the ideas on a schedule, let the AI read your codebase and status files, and tell you what to study next. You are cementing the patterns you already captured, not starting over.

If you do this yourself

I work across 20+ codebases a year. I lose context over time, and it’s worse when I go back to something I touched two years ago. This pattern is my fast on-ramp when I need to drop back in. You stop forgetting why you set things up. You can explain tradeoffs in a meeting without bluffing. The AI keeps tutoring you on concepts and impact while you stay in the builder seat.

My Go To Prompts

Run this after the five core chapters, ideally once you have your status files in the project root. Same credibility applies: these are the prompts I use to keep non-coder founders dangerous in the right way.

1. Framing prompt

Your starting point. Run this after the five core chapters when your status files exist. The AI helps you cement what you already decided: which patterns you established and which questions to reuse so future chats do not start from zero.

Assume the role of a senior CTO and technical educator who has coached dozens of non-coder founders and vibe coders. You know the Vibe Coding 101 pillars (observability, code hygiene, CI/CD and SDLC, security, and scalability) and you teach conceptual literacy: what each idea means, how it shows up in a real codebase, and what goes wrong when it is missing. You do not push me to become a full-time developer. Hold that stance as we build my ongoing education plan. Do not change code yet. Help me see what I should understand better and why it matters for this app.

Follow-up questions you can ask

Paste these after the framing prompt. Still no files or skills created yet. They pull forward what we already established and what to carry into every future AI session.

  • Patterns we established

    Across observability, code hygiene, shipping, security, and scalability: what patterns did we already establish for this app? Read our *-status.md files if they exist. List each pattern in plain language and where it is documented.

  • Questions to remember

    What questions should I save and reuse to prompt the AI in future chats so I do not re-explain the app or lose the framing we built? Give me copy-paste prompts per pillar, tuned to this project.

  • What the AI should assume

    When I open a new chat about this codebase, what should the AI already know or ask first, based on our status files and decisions? Draft a short “start here” block I can paste at the top of future sessions.

  • What we must not forget

    What am I most likely to forget in two weeks that would make the next session sloppy or generic? Flag the decisions, tradeoffs, and “we chose X over Y” calls that belong in education-plan.md.

2. Current state prompt

Use this after the framing prompt. The AI reads your status files (if they exist) and your codebase, then maps what you already documented against what you still need to understand. No new implementation, just an honest report card on conceptual literacy.

Using your CTO educator role, review this project, including observability-status.md, code-hygiene-status.md, delivery-status.md, security-status.md, and scalability-status.md if they exist, and our codebase. For each Vibe Coding 101 pillar (observability, code hygiene, CI/CD and SDLC, security, scalability), assess my conceptual understanding: what the idea means for this app, how well our current setup reflects it, and what I would struggle to explain to an investor or senior dev. Do not make changes yet. Return a markdown table with one row per pillar. For each row include: the concept, a score from 1-5 for my current understanding, what we have in place (from status files or code), the business impact if I stay fuzzy on it, the highest-value thing to learn next (concept only, not “learn React”), and one plain-language question I should be able to answer after studying. Sort so the most urgent gaps are at the top.

Follow-up questions you can ask

Paste these after you have the table. Same chat. Short follow-ups to sharpen the syllabus.

  • Top priority

    Looking at your table, which pillar should I study first, and what is the one idea I need to understand in plain language?

  • Quiz me

    Ask me one question per pillar. Tell me if my answer is solid or hand-wavy.

  • Blind spot

    Where am I most likely overconfident because the app seems fine today?

3. Capture the Wins and Patterns

Run this when you are ready to save the syllabus. It creates education-plan.md at the project root: your continuing ed curriculum tied to this app, and sets you up to turn it into a reusable skill next.

Using your CTO educator role, create a markdown file at the root of this project named education-plan.md. Structure it as an ongoing syllabus for a vibe-coding founder: list each Vibe Coding 101 pillar (observability, code hygiene, CI/CD and SDLC, security, scalability), what it means in plain language for this app, what we documented in our status files, what I should understand better, suggested review order, and a short “explain it back to me” prompt I can use per pillar. Include a revisiting schedule (e.g. after major releases, monthly check-in). Write so future me, or the AI, can pick this up without re-reading every prior chat. Do not change application code in this step. Only create or update education-plan.md.

Follow-up questions you can ask

Paste these after education-plan.md exists. Same chat or a fresh one.

  • Update syllabus

    Take any priorities or concepts I outlined in our conversation and add or update them in education-plan.md. Keep it aligned with what I have decided I need to understand, not what a textbook says.

  • Build revisiting skill

    Using education-plan.md and our status files, draft a Cursor skill (SKILL.md for .cursor/skills/) or a project rule (.cursor/rules/) that I can invoke periodically (e.g. “continuing ed check-in”). The skill should read education-plan.md, our *-status.md files, and skim the codebase, then tell me which concepts I should study next, explain impact on this app in plain language, quiz me with one question per pillar, and never assume I need to learn to implement it myself. Output the full skill or rule file content ready to save.

What you get

If you use this, you will have an education-plan.md that ties every major Vibe Coding 101 concept to your actual app, and a skill or rule you can rerun so the syllabus stays current. You are not learning to implement everything yourself. You are learning what matters, what you already have, and what to ask the AI (or a human) next.