You know that friend who cooks without a recipe and it usually turns out fine — until the night they give everyone food poisoning? Now imagine you hand them a checklist: wash the chicken separately, check the internal temp, don't reuse the cutting board. The food doesn't become restaurant-grade, but the salmonella risk drops sharply. That's the mechanism here. Vibe coding — prompting an LLM to generate an entire web application from natural language — works like cooking without a recipe. This paper asks: does appending a security checklist to the prompt actually reduce the number of vulnerabilities in the output? The committed claim: appending explicit security requirements to otherwise identical natural-language prompts reduces the number and severity of vulnerabilities in LLM-generated web applications. The security-aware variant (B) produced 24 confirmed findings versus 51 for the baseline (A) across six functionally distinct web applications — a 53% reduction — and contained zero Critical or High severity issues. The most severe remaining finding was caught only by manual testing, not automated tools. The experimental design is a twin-prompt A/B structure. Six applications, each generated twice: once with a plain functional prompt, once with the same prompt plus an appended security-requirements section. All twelve programs came from the same agentic coding assistant, same model version, single non-iterative generation round. Analysis used four layers: static analysis, dependency scanning, dynamic testing, and manual review. Of 85 candidate findings, 75 were confirmed — a 88% confirmation rate that suggests the analysis pipeline isn't wildly over-reporting. Here's where your bullshit detector should activate: n=6 applications, each generated exactly once. The author knows this and says it plainly — these are descriptive observations, not statistically established effects. There's no repeated sampling, no confidence intervals, no cross-model comparison. A single lucky generation run could explain the entire delta. The paper is honest about this limitation, which is refreshing, but it means the headline number (51 vs 24) carries essentially zero statistical weight. It's a signal worth investigating, not a result worth citing. The ladder question is tricky because this isn't competing against a named SOTA method — it's testing a prompt-engineering intervention. The closest prior art is the growing body of LLM code security audits (papers examining GitHub Copilot output, ChatGPT-generated code vulnerabilities), but those mostly measure baseline vulnerability rates without testing the security-prompt intervention. This paper's contribution is the twin-prompt design itself — same app, same model, only the security appendix differs. That's a cleaner experimental setup than most LLM security studies, even if the corpus is tiny. The validation regime is the weakest link and the strongest simultaneously. Four independent analysis techniques (static, dependency, dynamic, manual) is genuinely thorough for a preliminary study. But the author is grading their own homework — same person wrote the prompts, generated the code, and analyzed the output. No independent replication, no pre-registration, no blinding. The 88% confirmation rate (75/85) suggests care in filtering false positives, but selection bias in which applications were chosen and which findings were pursued is impossible to rule out. The successor experiment the authors didn't run — and explicitly say they're scaling toward — is repeating the pipeline across multiple models and multiple generation runs per prompt. My honest read: this is (c), saving it for the next paper. The CECIIS 2026 conference presentation is the pilot; the multi-model scaled version is the real study. The single-model, single-run design isn't a budget constraint — it's a deliberate scoping choice for a conference paper that establishes the methodology before investing in the expensive version.
