The 60-Minute Build: What You Can Ship, and What Breaks

Overview

The claim that anyone can now build a working digital product in an hour is broadly true, and the important question is what kind of thing you have built at the end of it.

Security testing across more than 100 large language models, covering Java, JavaScript, Python and C#, found that AI-generated code introduced risky security flaws in 45% of tests. Roughly one generation in two produced something with a genuine weakness in it.

Specific categories fared worse. 86% of generated samples failed to defend against cross-site scripting, and 88% were vulnerable to log injection — both among the most common and most exploited classes of web vulnerability.

The rate has not improved. Testing cycles from 2025 through early 2026 held at around 45% despite vendor claims of progress. That matters most for exactly the audience this technology has opened the door to: people building something public without the background to notice what is wrong with it.

What an Hour Genuinely Produces

The positive claim deserves stating clearly before the caveats, because it is real and it is a genuine change.

In a focused hour with current tools, a person with no programming background can produce a working web page, a simple browser game, a functioning form, a script that automates a repetitive task, or a draft of almost any written material. These things run. They do what was asked. A few years ago each would have required either weeks of learning or paying someone.

That is a substantial expansion of what an individual can do alone, and the people it helps most are those who previously had ideas and no route to executing them. Nothing that follows contradicts it — what follows is about the difference between something that runs and something safe to expose to other people.

45% of Generated Code Had Security Flaws

The most systematic assessment available tested code generated by more than 100 large language models across four widely used languages.

AI-generated code introduced risky security flaws in 45% of tests. This is not a measure of whether the code worked — most of it did. It is a measure of whether working code contained a weakness that could be exploited.

For a personal tool that never leaves your machine, that is a tolerable risk. For anything that accepts input from strangers, stores someone else's information, or connects to a payment system, a coin-flip probability of a security flaw is a different proposition entirely.

86% Failed Cross-Site Scripting Defence

Aggregate figures hide how concentrated the failures are. Two categories account for the worst results, and both are basic.

86% of generated samples failed to defend against cross-site scripting — a vulnerability that allows an attacker to inject code that runs in other users' browsers, enabling session theft and data exfiltration. It has been among the best-known web vulnerabilities for two decades.

88% were vulnerable to log injection, where attacker-controlled input is written into logs unsanitised, corrupting records and in some configurations enabling further compromise. These are not obscure edge cases; they are the vulnerabilities every introductory security course covers, and generated code fails at them roughly nine times in ten.

Java Failed Worst at 72%

Performance varies by language, and Java performed worst of those tested at a 72% failure rate, ahead of JavaScript, Python and C#.

The likely explanation is training data. Models learn from publicly available code, and decades of Java examples online include a great deal written before current security practices were established, or written for tutorials where clarity was prioritised over safety.

That mechanism generalises uncomfortably. A model reproduces the patterns it saw most often, and the most common pattern in public code is not the most secure one — it is the one that appeared in the most tutorials.

2.74x More Vulnerabilities Than Human Code

The direct comparison is the clearest framing: AI-generated code was found to contain 2.74 times more vulnerabilities than human-written code.

Human-written code is not secure by default either, which is worth remembering. Vulnerabilities are routine in professionally written software, and entire industries exist to find them.

What the multiplier establishes is that generated code is meaningfully worse than the already-imperfect baseline. The plausible reason is that a human writing code holds some model of what could go wrong, however incomplete, while a model producing a plausible-looking implementation optimises for resembling correct code rather than for being safe.

3-4x More Output, 10x More Findings

The most consequential statistic concerns the interaction between speed and risk, and the two do not scale together.

AI-assisted developers produce commits at three to four times the rate of their peers while introducing security findings at ten times the rate. Output roughly tripled; security problems increased by an order of magnitude.

That asymmetry is the entire risk profile of this technology in one comparison. If problems scaled with output, faster development would simply mean proportionally more review. Because they scale faster, accelerating development without proportionally increasing scrutiny actively degrades the security of what gets shipped.

It also explains why this matters more for beginners than professionals. A team producing three times the output with ten times the findings at least has review processes to catch some of it. An individual shipping a project alone has none.

And It Hasn't Improved

A reasonable assumption would be that this is an early-stage problem resolving itself as models improve. The testing does not support that.

The 45% vulnerability rate held across multiple testing cycles from 2025 into early 2026, despite vendor claims of improvement. Models became considerably more capable at producing working code over that period without becoming meaningfully better at producing secure code.

The likely reason is that these are different objectives. Models are optimised and evaluated on whether code works — it runs, it passes tests, it does what was asked. Security is the absence of exploitable weakness, which is not visible in whether something functions, and is not what the training signal rewards. Capability improvements do not automatically transfer to a property nobody is measuring.

Why the Risk Depends on What You Build

None of this means the hour is wasted. It means the appropriate level of caution depends entirely on what the output touches, and that distinction is easy to draw.

Low risk covers anything that stays with you: a script processing your own files, a tool that runs locally, a game nobody else plays, a static page with no forms and no user data. If it is exploited, the person affected is you, and the consequence is inconvenience.

High risk begins the moment other people are involved. Anything that accepts user input, stores personal information, handles payments, requires login, or connects to services holding your credentials. Here a 45% flaw rate means real exposure for people who did not choose to take that risk — and in many jurisdictions, legal obligations regarding personal data that apply regardless of whether you knew about them.

What to Do With Your Hour

The practical guidance follows from the risk split rather than from any general judgement about the tools.

Build the prototype. It is the right use of the technology, it genuinely works, and something running in an hour is worth more than a specification that never gets built. Use it to find out whether the idea is any good.

Then treat the gap between prototype and product as real work rather than a formality. If it will be public and handle anyone's data, it needs a security review by someone who knows what they are looking for, and 'the AI wrote it' is not a mitigation.

The most useful question to ask before publishing anything is simple: if this has a security flaw — and there is roughly a coin-flip chance it does — who gets hurt? If the answer is only you, ship it. If the answer is other people, the hour bought you a starting point, not a finished product.

Conclusion

You can genuinely build something working in an hour, and for people who previously had no route from idea to execution that is a real expansion of what is possible. The prototype is the legitimate prize here.

What comes with it is a 45% rate of security flaws across more than 100 tested models, 86% failure against cross-site scripting, 88% against log injection, and 2.74 times the vulnerabilities of human-written code. That rate did not improve between 2025 and early 2026, because models are optimised for code that works rather than code that is safe.

The asymmetry is the part to remember. AI-assisted developers ship three to four times the output and generate ten times the security findings, so speed without matching scrutiny makes things worse rather than neutral.

Which makes the decision straightforward. If the only person exposed by a flaw is you, an hour is enough. If anyone else's data is involved, an hour bought you a prototype — and treating it as a finished product is where the harm actually occurs.

Data Source and Attribution

Veracode GenAI ReportVeracode (Spring 2026 update)Help Net Security

Security failure rates, vulnerability class breakdowns, language-specific results and the comparison with human-written code come from Veracode's GenAI Code Security Report and subsequent update, covering code generated by more than 100 large language models across Java, JavaScript, Python and C#. Figures on commit rates and security finding rates among AI-assisted developers come from the same body of research. The persistence of the 45% rate reflects multiple testing cycles from 2025 into early 2026.

FactsFigs reviews, cleans, and cross-checks every source dataset before shaping it into a data story. Each visualization is created and designed in FactsFigs Design Studio — an internal tool developed and owned by FactsFigs — and is the original work of a FactsFigs author, not an AI-generated copy of any existing graphic. Individual assets within a visual may or may not be produced with AI tools, but the design of the visual itself is solely FactsFigs' own.

This content is for information only and is not security or legal advice. Anyone deploying software that handles personal data should obtain qualified security review and understand their legal obligations.

2026-07-20