Stephan Smith Fractional CTO
← Vibe Coding 101

Chapter 3 of 5

Ship Updates Safely (i.e. CI/CD or SDLC)

You need a test version, a live version, and a clear way to ship without everything on the fly.

What you'll see developers say online

Developers will tell you CI/CD is for big multi-team products, not vibe coders. You’re shipping on the fly: code may not be tracked, no structured path from test to live. When a bug hits, there’s no trail. Outside stakeholders flag that first as a reason to dismiss your work: this isn’t real software, and it will fail when something goes wrong in production.

The solution: CI/CD in plain language

Shipping safely sounds like jargon: CI/CD, SDLC, deliverability. Ignore the alphabet soup. It’s structure: a version you test, a version clients see, and a clear way to get code from one to the other. Set that up and a code review stops looking like “just vibe coded.” People assume CI/CD is for big multi-team products, not vibe coders. If you want to ship safely, it’s a good fit now. Every manual deploy is another chance to mess up. Let the computer handle build and deploy, systematic, logged, visible.

If you do this yourself

Commits and deploys become repeatable. You’re not guessing what went live or when.

Developer perspective

How you deliver code matters. Vibe-coded apps often skip the basic patterns teams use to keep releases stable, and developers are right to flag that.

What to do

Most vibe coders skip code tracking because GitHub feels complicated. It’s free. A good AI prompt plus a few settings gets you solid version control, and GitHub can do the shipping work. POC first is fine; once you have one to three customers, you need “when I ship, it ships and it works.”

If you skip this

Code may not be tracked. Bug hits, no trail, everything on the fly. Outside stakeholders flag that first as a reason to dismiss your work.

My Go To Prompts

I review codebases all the time. I’m a battle-tested CTO. I’ve built startups. Here are three prompts I use every day. These aren’t theoretical. They’re the actual prompts I run, tune, and build skills around.

1. Framing prompt

Your starting point. SDLC and CI/CD sound like patterns that take decades to learn, but they are patterns you can follow step by step. This tells the AI who to be so the rest of the conversation stays grounded in how you ship today and what fits your stage, not alphabet-soup enterprise process.

Assume the role of a senior engineering leader who has designed software delivery and CI/CD for dozens of products from solo founders to multi-team releases. You know the SDLC patterns teams spend years learning: version control, test vs production environments, automated builds, and a clear path from commit to live. You also know how to right-size those patterns for where a vibe coder actually is, not a fictitious goal in the future. Hold that stance as we assess how this app ships today. Do not change anything yet. Help me see what a serious reviewer would expect and what we can adopt without twenty years of experience.

Follow-up questions you can ask

Paste these after the framing prompt to tease out what shipping safely means for your app. Still no setup or code changes.

  • Priority

    Why is a clear shipping path the highest priority for my app right now before more features?

  • If you skip

    What happens if we keep shipping on the fly? What breaks, what trail do we lose, and when would a stakeholder or senior dev use that against us?

  • SDLC building blocks

    Walk me through the core SDLC/CI/CD building blocks (Git repo, branches, environments, build, deploy) in plain language. For my app, where would each matter first and where would it be overkill?

  • Right-size it

    I may only have a main branch and one live site today. What is the minimum shipping pattern that still looks professional, and what should we explicitly not build yet?

2. Current state prompt

Use this after the framing prompt. You are not asking the AI to set up GitHub or deploy anything yet. You are building a picture of how you ship today and what is missing. That stops random tooling changes and helps you learn what SDLC actually means for your app. Expect a table you can read and push back on with follow-up questions.

Using your senior delivery role, review what we have built so far, our code, stack, hosting, and how we get changes live today. Give me an overview of our current shipping posture: what is tracked, what is automated, and what would worry someone in a delivery review. Do not make changes yet. Return a markdown table with one row per core delivery area (version control and repo, branch strategy, dev/test/production environments, CI build pipeline, CD and deploy automation, visibility into what is live, rollback or recovery, manual steps still in the loop). For each row include: the area, a score from 1-5 for where we are today, highest value / lowest effort / highest impact (rank or note), a plain-language sentence on why it matters, and one question I should ask next to go deeper. Sort the table so the best next conversations are at the top.

Follow-up questions you can ask

Paste these after you have the table. Same chat, still no setup or code changes. They push into the details a senior reviewer would ask before trusting how you ship.

  • Version control

    Is our code in a Git repo with a clear history, or are we editing live / copying folders? Score it and tell me what we lose if a bug hits tomorrow.

  • Test vs live

    Do we have a version we test before clients see changes, or does everything go straight to production? Map what we have and what breaks first if we ship the wrong thing.

  • GitHub Actions

    Are builds and deploys automated with something like GitHub Actions, or manual steps only you remember? Where would automation earn its keep first for this app?

  • Branch strategy

    Is main-only enough for our stage, or do we already need feature branches, preview deploys, or a staging environment? Be specific to our customer count and release pace.

  • Deploy trail

    If someone asks “what went live and when,” can we answer in under a minute, or would we be guessing? What would a due diligence review flag?

  • If we skip it

    For the lowest-scored rows in your table, what happens if we skip them for the next 30 days: what gets harder to fix, and when would this look like “not real software”?

3. Capture the Wins and Patterns

Run this when you are ready to save what you learned. It creates a markdown file in your project root so the next shipping conversation picks up where you left off. You are not re-explaining your deploy setup from scratch every time.

Using your senior delivery role, create a markdown file at the root of this project named delivery-status.md. Document what we found in this conversation: how we ship today, scores if we used them, what we set up or agreed to (GitHub repo, GitHub Actions, environments, branch rules), patterns and priorities for going forward, and when the codebase is complex enough to add branches or staging. Write it in plain language so that in future chats about shipping or CI/CD you read this file first and treat it as the starting context. Do not make code changes in this step, only create or update the file.

Follow-up questions you can ask

Use this if you decided on new patterns or priorities after the file was created. Same chat.

  • Update priorities

    Take any patterns or priorities I outlined in our conversation and add or update them in delivery-status.md. Keep the file aligned with what I have decided matters for how we ship.

What you get

If you use this, you will have a shipping pattern that matches where your app is today, not an enterprise SDLC checklist you will never finish. You will know how code gets from your machine to live, and you can explain it without twenty years of experience. That turns off the “you’re just deploying on the fly” concern.