AIに1時間で作らせたアプリを、公開前に全ソース監査してみた（Critical 2件）A developer audited the full source code of an app built by Claude in about one…

A developer recently documented an experiment that speaks to a growing question in software engineering: how safe is code that an AI writes for you? After using Anthropic's Claude to generate a complete application in roughly one hour, the developer performed a full manual audit of the source before shipping it to production. The review turned up two vulnerabilities rated Critical, a result that underscores why AI-assisted development still demands careful human scrutiny before anything goes live.

The account, published on Zenn, frames the exercise as a practical test rather than a benchmark. The premise is increasingly common: with modern large language models, a working prototype can be assembled in a fraction of the time it would take to write by hand. The concern the developer raises is that speed can mask risk. Code that compiles, runs, and passes casual testing may still contain flaws that only become visible when a security-minded reviewer reads through the entire codebase line by line.

Two Critical-severity issues surfaced during that review. While the post is centered on the process rather than an exhaustive vulnerability breakdown, the takeaway is that these were not minor style problems but defects serious enough to warrant blocking a release. Critical ratings typically apply to weaknesses that could allow unauthorized access, data exposure, or remote exploitation, the kinds of problems that carry real consequences once an application is publicly reachable. Finding two of them in a single AI-generated app, before any external users were involved, illustrates the gap between "it works" and "it is safe to ship."

This pattern is consistent with broader observations about AI-written code. Language models are trained on large corpora of public code, which includes both good and bad practices. As a result, generated output can reproduce insecure patterns such as missing input validation, weak authentication handling, hardcoded secrets, insecure defaults, or improper access controls. Models also tend to optimize for producing something that looks correct and runs, not necessarily something that has been hardened against adversarial use. When a developer accepts generated code without reviewing security-relevant paths, those weaknesses can pass straight into production.

The experiment sits within a wider trend often described as "vibe coding," a term popularized to capture the practice of building software mainly by prompting an AI and iterating on its output. Tools in this space have proliferated, including Anthropic's Claude Code, GitHub Copilot, Cursor, and other agentic coding assistants that can scaffold, edit, and even test entire projects. These tools have measurably increased development velocity, but the same acceleration means that unreviewed code can accumulate faster than traditional review processes are designed to handle.

The case also connects to established security tooling that remains relevant regardless of who or what wrote the code. Static application security testing, dependency scanning, secret detection, and manual code review are all standard defenses, and none of them become obsolete because an AI produced the source. If anything, the developer's account suggests they become more important, since the volume and speed of AI-generated code can outpace informal checks. Automated scanners can catch many common issues, but a human reading the code appears to remain valuable for catching logic flaws and context-specific problems that tools may miss.

For teams adopting AI coding assistants, the practical implication is straightforward: treat generated code with the same, or greater, rigor applied to human-written contributions. That likely means running it through existing security pipelines, reviewing authentication and authorization logic explicitly, checking how sensitive data is stored and transmitted, and confirming that dependencies are current and trusted. The developer's decision to audit before release, rather than after an incident, reflects a defense-oriented mindset that security professionals generally advocate.

The broader significance of the report is less about Claude specifically and more about workflow discipline. AI models will continue to improve, and future versions may generate more secure output by default. Even so, this example serves as a concrete reminder that current tools can and do produce serious vulnerabilities. The responsibility for what ships still rests with the developer, and a pre-release audit, whether manual, automated, or both, remains a prudent step before any AI-built application reaches real users.