The new SDLC with vibe coding: how AI is redefining software delivery
AI assistants write a lot of the code now. That does not delete the software lifecycle — it moves the hard part. The plan, build, test, deploy, operate loop is still there, but where you spend your hours, and what you are on the hook for, has quietly changed.
New to cloud? CAMPUX is a free, build-first course. Start here →
The new SDLC with vibe coding shifts the developer's job from writing every line by hand to guiding, prompting, and reviewing code produced by AI assistants. The stages stay the same — plan, build, test, deploy, operate — but CI/CD, automated testing, and security scanning become the safety nets that make AI-generated code trustworthy. Everything below is a longer walk through what that actually means when you sit down to ship something.
What "vibe coding" actually is
The phrase started as a half-joke and stuck. Vibe coding is what happens when you stop typing every line and start describing what you want to an AI assistant, then react to what it hands back. You write a sentence — "give me an endpoint that lists a user's orders, paginated, newest first" — read the draft, notice it forgot to check that the user owns those orders, ask for the fix, and keep going. The rhythm is prompt, read, correct, prompt again.
The important word is react. You are not staring at a blank file anymore; you are staring at a plausible draft and deciding whether it is any good. That sounds easier, and for the first ninety percent of a feature it often is. The trouble is the last ten percent, where the draft looks finished but is subtly wrong, and where all the accountability lives. More on that below — first, where this fits in the lifecycle you already know.
The SDLC didn't disappear — the bottleneck moved
There is a tempting story that AI collapses the whole software development lifecycle into a chat window. It does not. You still plan what to build, build it, test it, deploy it, and operate it in production. Skip any of those and you get the same failures teams have always gotten. What changed is not the shape of the loop — it is which stage eats your day.
For decades the slow, expensive step was build: turning a clear idea into working code took most of the calendar. Assistants compress that step hard. A first working version arrives in minutes. But the total work did not vanish; it sloshed downstream. Now the pressure is on deciding what to build (because you can build the wrong thing much faster) and on verifying what got built (because you did not write it and cannot assume you know how it behaves). Here is the same lifecycle, seen from the old way and the new one.
| Traditional hand-written SDLC | AI-assisted / vibe SDLC | |
|---|---|---|
| Where time goes | Mostly in the build stage — typing, wiring, looking up APIs, debugging syntax. | Mostly in framing the problem and reviewing output — the typing is fast, the judging is slow. |
| Who writes the first draft | The developer, line by line, holding the design in their head as they go. | The assistant, from a prompt; the developer reads it cold and has to reconstruct the intent. |
| What the human owns | Every decision, because every line passed through their fingers. | Every decision still, but now over code they did not type and must actively inspect. |
| Biggest risk | Slow delivery; features take longer than the business wants. | Fast delivery of plausible-but-wrong code that nobody read closely. |
| The safety nets | Helpful — tests and review catch human slips. | Load-bearing — tests, review, and scanning are the only thing standing between a draft and production. |
Read that last row twice. In the old world your pipeline was a seatbelt: good to have, occasionally the thing that saves you. In the new world it is the brakes. Take it out and the car still moves — that is the danger.
Where the human's job goes: guide, review, own
If the assistant does the typing, what are you for? Three things, and they are the parts of the job that were always hardest.
Guide. An assistant is only as good as the problem you hand it. Vague prompt, vague code. The skill that used to be "know the syntax" becomes "state the requirement precisely" — what the input looks like, what counts as correct, which edge cases matter, what the thing must never do. You are writing a spec in conversation, and a sloppy spec produces confident nonsense.
Review. This is the big one. Reading code you did not write, and judging whether it is correct, is harder than writing code you did. The assistant will hand you something that compiles, runs on the happy path, and quietly mishandles an empty list, a timezone, a permission check, or a race. You have to catch that. If you cannot read the code well enough to find the bug, you cannot safely use the code — which is exactly why "should I still learn to code" has an obvious answer, and I wrote a whole note on why you still learn to code even when AI can write it.
Own. When the feature breaks at 2 a.m., no one pages the model. Your name is on the commit. Accountability did not move to the assistant and it never will, because accountability is a human thing — it is the willingness to stand behind what ships. The assistant is a fast, tireless, occasionally wrong junior who leaves the moment the code is written. You are the senior who has to sign it.
The assistant writes the draft. You are still the one who has to be right.
Why CI/CD, tests, and scanning are the safety nets
Human review is necessary and it is not enough. People get tired, they skim, they trust a clean-looking diff, and a person reviewing forty AI-generated files an hour will miss things. The fix is not "review harder" — it is to make the machine check what the machine wrote. That is what a pipeline is for, and it matters more now than it ever did.
Walk the gates in order. Automated tests pin down behavior: if the assistant's code passes a test that actually asserts the right thing, you have evidence, not a vibe. The catch is that assistants happily write the tests too, and a test that only checks the happy path proves nothing — so the human's job includes making sure the tests test something real. CI runs those tests on every change, so a regression shows up in minutes instead of in production. Security scanning — dependency checks, static analysis, secret detection — catches the classic AI failure mode, where the model reaches for an outdated library or a pattern that looks fine and quietly opens a hole. CD then ships only what cleared every gate, the same way for every change, so a good deploy is boring and repeatable rather than a held breath.
The through-line: when a human wrote the code, you trusted the author and the pipeline backed them up. When a model wrote it, you trust nothing until the pipeline says so. The gates carry the weight now.
Treat every line the assistant writes as code from a stranger who is often right and never accountable. You would not merge a stranger's pull request without reading it, running the tests, and scanning it. Hold AI output to exactly that bar — no lower because it came fast, no higher because it looked confident.
The honest risk: vibe coding without guardrails
Here is the part the demos skip. Vibe coding with no tests, no review, and no scanning is one of the fastest ways to put a bug in front of real users that our industry has invented. The reason is psychological as much as technical: the output reads as finished. It is well-formatted, it is confidently commented, it runs the first time you try it. Every signal your brain uses to judge "is this done" fires green, and none of those signals actually checked whether the logic is correct.
So the code that looked right ships, and the empty-list case, or the missing authorization check, or the off-by-one in the pagination, waits in production for the one user who hits it. Nobody was negligent in the usual sense — someone just trusted a draft because it looked like a finished thing. That is the trap, and the only reliable way out is to refuse to let unreviewed, untested AI code reach production, no matter how good it looks. Speed without the gates is not speed; it is deferred cleanup, plus an incident.
How a cloud/infra engineer fits into this
If you are on the cloud or infrastructure side, this shift is squarely your table, because the safety nets I keep pointing at are things you build and run. The pipeline that runs the tests, the environment that ships the deploy, the scanning stage, the rollback that saves the day — that is platform work. As application developers lean harder on assistants to produce code faster, the demand for solid pipelines, good test infrastructure, and enforced security gates goes up, not down. Somebody has to make the safety net real.
It also reshapes your own daily work. Infrastructure as code, deploy scripts, monitoring queries, glue between services — an assistant will draft all of it, and the same rules apply: you guide it, you read it, you own it. The extra weight on your side is that a bad line of infra code does not break one feature, it can break the platform every other team stands on. That is why the fundamentals of scripting and automation still earn their place, which is the whole point of Class 25 on scripting for cloud engineers — you cannot safely review what you could not have written. And if you are trying to picture which of your tasks the assistants actually absorb, I mapped that out in a separate note on which cloud tasks AI automates.
None of this is a story about the machine taking the job. It is a story about the job moving up a level — from producing lines to judging systems, from typing to owning. The people who do well are the ones who can read code critically, build the gates that catch mistakes, and stay accountable for what ships. That skill set was valuable before the assistants arrived. It is just harder to fake now.
Questions people also ask
What is vibe coding in software development?
Vibe coding is writing software by describing what you want to an AI assistant and steering the code it produces, rather than typing every line yourself. You prompt, read what comes back, correct it, and prompt again. The developer's attention shifts from syntax to intent, judgement, and review, while the assistant handles the mechanical typing.
Does vibe coding replace developers?
No. It changes what the developer spends time on. The AI writes drafts fast, but someone still has to decide what to build, judge whether the output is correct, catch the security and edge-case problems, and own what ships. Those are the harder parts of the job, and they stay with the human. Vibe coding moves the bottleneck rather than removing the person.
Is AI-generated code safe for production?
Only after it passes the same gates you would put in front of any code. AI assistants confidently produce code that looks right but hides bugs, insecure patterns, and outdated APIs. Automated tests, code review, and security scanning in the pipeline are what turn a plausible draft into something you can trust in production. Without those gates, AI-written code is not safe to ship.
What skills matter most in an AI-assisted SDLC?
Reading and reviewing code, understanding systems well enough to judge whether an answer is correct, writing clear requirements, and building the pipelines and tests that catch mistakes. Knowing how CI/CD, automated testing, and security scanning fit together matters more than raw typing speed, because your value is now in guiding and verifying, not just producing lines.