Coverage of software-engineering cross-cutting concerns (rows) across the SDLC phases (columns),
when work is driven purely by vibe coding — conversational prompting of an LLM with output accepted on
the strength of it appearing to work, rather than on the strength of it being verified.
The dense band of coverage sits in one column. Vibe coding is genuinely strong at
Implementation — and at debugging, scaffolding and documentation within it. Almost everything else is amber or red.
Amber is the dangerous colour, not red. A red cell is a visible absence. An amber cell is
output that looks like an artefact of engineering — a test suite, a pipeline, a threat-model paragraph — produced
without the verification that gives it its value.
Governance concerns are almost uniformly red. Compliance, traceability, licensing, privacy,
resilience and cost have no natural prompt-shaped entry point; nobody asks for them, so they never appear.
Everything right of Deployment is a gap. Operations, incident management and retirement
are where systems spend most of their life and where vibe coding contributes least.
Reasonable conclusion: vibe coding is an accelerator inside the Implementation phase,
not a substitute for the lifecycle around it. It is well matched to prototypes, spikes and throwaway tools;
poorly matched to anything with users, data, regulators or a maintenance horizon.
Build this page yourself
This page was generated with Claude (Opus 4.8):
"Give me a top level bullet point list of the Software Development Lifecycle (SDLC)"
"Give me a top level bullet point list of cross cutting aspects (eg version control, release management, debugging) of Software Development"
"Draw a table with the SDLC points on the X-Axis and the cross-cutting aspects on the Y-Axis. Indicate the cells are partially or fully satisfied by vibe-coding. Write the table as a HTML table in to a standalone file: `vibe-coding-vs-software-engineering.html`."