I keep reading versions of the same argument.

AI is rubbish at writing code. Vibe coding is insecure. Proper developers would never trust it. We need humans because humans produce good software.

Come on.

AI-generated code is not automatically good. It is not automatically secure either. But human-written code is not automatically good or secure, and attackers are already using AI to make themselves faster.

That is the bit I think some companies are missing.

The question is not whether AI can produce bad code. Of course it can. The question is whether your engineering team is learning to use the same amplification more effectively than the people attacking it.

Tell AI precisely what secure means, then require evidence that it met the standard.

The attackers already understand the economics

In April 2026, security company Expel published an investigation into a North Korean-linked group it calls HexagonalRodent. Expel found the group using ChatGPT, Cursor and other AI tools to produce malware, fake recruitment sites, command infrastructure and campaign material.

Expel used the phrase vibe coding deliberately. The work was not elegant. It included bugs and operational mistakes. It was still effective enough to industrialise parts of the campaign.

Expel said cryptocurrency wallets holding as much as $12 million were exfiltrated over three months. That is not the same as proving $12 million was stolen. Expel explicitly noted that hardware security tokens may have limited the actual damage. The honest claim is that AI helped the attackers produce and operate malicious infrastructure at scale, not that every dollar in those wallets became a confirmed loss.

Google has documented a different and more direct warning. Its Threat Intelligence Group reported what it described as the first identified criminal actor using a zero-day exploit it believes was developed with AI. Google said the actor was preparing mass exploitation, although its intervention may have prevented the planned campaign from being carried out.

So this is no longer a theoretical conversation about whether criminals might use coding models. They are using them.

Two parallel countryside routes show how attackers use AI to discover, test, exploit and scale while defenders define, build, attack, verify, patch and monitor.
The model supplies speed and scale. The surrounding loop decides what that amplification is used for.

Two cryptocurrency stories, not one

There are two recent cryptocurrency stories that are easy to muddle together.

The first is HexagonalRodent, where Expel documented attackers using AI tools during a live malicious campaign.

The second is the 2026 COLDCARD incident. A flaw in wallet seed generation was present in affected firmware from March 2021. Coinkite warned that seeds made by affected devices could contain far less entropy than users reasonably expected. Block's technical analysis traced the problem to a random-number integration error and a limited reseed path.

Public reports offered changing estimates of funds swept from affected wallets, but the cited primary sources do not establish a final audited loss total. The article you are reading is not using those changing estimates as proof of anything about AI.

There is no evidence that the original attacker used AI.

The relevant AI lesson came afterwards. A public user reported that Claude Code traced the same defect in minutes when pointed at a historical version of the public firmware. That is an anecdotal reproduction, not an audited experiment, so I would not build the whole argument on the stopwatch. The stronger point is simpler: a serious integration flaw survived for years, and current coding agents can now help engineers inspect code paths that human review did not catch.

That does not mean AI is better than every security engineer. It means a security engineer with a capable agent has another very powerful instrument.

Defenders are finding old vulnerabilities too

Anthropic's Mythos work gives us a much better controlled example.

Anthropic reported that Mythos Preview found vulnerabilities in widely used open-source software, including an OpenBSD issue that had existed for 27 years. As of 22 May 2026, its coordinated disclosure dashboard recorded 1,596 findings disclosed across 281 projects. Some reports sent directly to maintainers may contain false positives. Anthropic said that, to its knowledge, 97 findings had been patched upstream at that point.

Those numbers need their human context.

Anthropic worked with external security firms to triage and validate findings. Maintainers still had to understand the code, assess consequences, decide priorities, create patches and release them. The AI expanded the search. Competent people converted findings into safer software.

That is exactly the model I think companies should be building.

The evidence does not support either extreme

There is also good reason not to wave away the risks of AI-generated software.

A 2026 preprint studying deployed vibe-coded applications found recurring patterns including placeholder logic, unfiltered input and exposed secrets. Better models and better prompting reduced the problems but did not remove them. That is a warning against handing consequential systems to an agent and hoping for the best.

But the existence of insecure AI-generated code does not prove that humans were producing secure software before. COLDCARD's defect lasted years. Mythos found bugs measured in decades. Every security patch is evidence that human systems also ship flaws.

The 2025 DORA research offers the framing I find most useful: AI acts as an amplifier of the organisation around it. It magnifies strengths and weaknesses.

A team with vague requirements, weak review, poor tests and no operational feedback can generate bad software faster.

A team with clear architecture, security expertise, good acceptance criteria, meaningful review and strong recovery practices can investigate more paths, test more assumptions and correct more weaknesses.

Same AI. Different loop.

What the evidence table actually says

Case What is supported AI attribution Boundary
HexagonalRodent Expel observed ChatGPT, Cursor and other AI tools used for malware and campaign infrastructure. Confirmed by incident investigators Wallets holding up to $12m were exfiltrated; that is not a confirmed stolen-funds total.
Google zero-day case Google identified a criminal actor using a zero-day it believes was developed with AI. Assessed by Google Google said its proactive counter-discovery may have prevented the exploit's use; details remain limited.
COLDCARD A seed-generation defect affected firmware released in 2021; affected seeds remained at risk when Coinkite issued its 2026 advisory. Unsupported for the original attacker One later public AI-assisted reproduction was anecdotal and unaudited, not attacker attribution.
Claude Mythos Anthropic used the model to find vulnerabilities; external firms triaged one route, while Anthropic sent other untriaged reports directly to maintainers at their request. Confirmed defensive research Finding a candidate is not the same as validating, prioritising or safely patching it.

Secure does not fit inside one prompt

I have said before that you can tell AI to produce secure software. I want to make that more precise.

You have to tell it what secure means for this system.

Who is allowed to authenticate? What may each role do? Where may the data live? Which secrets must never reach logs? What happens when a dependency is compromised? Which failures must stop the release? How do you recover corrupted data? Who can roll back? What evidence proves the controls worked?

A frontier model may know hundreds of security patterns. It cannot infer your complete business context, threat model, legal boundary and appetite for failure from the instruction, "Make it secure."

NIST's Secure Software Development Framework treats secure development as an organisational system: prepare the organisation, protect the software, produce well-secured software and respond to vulnerabilities. CISA's Secure by Design guidance similarly places responsibility on producers to build security into products rather than shifting the burden to customers.

AI does not remove that work. It gives the work more leverage.

The secure agentic development loop

This is the practical model I would use.

  1. Define the threat model. Name the data boundaries, likely attackers, critical assets and consequences of failure.
  2. Write testable security criteria. Turn words such as secure, private and authorised into checks with pass and fail conditions.
  3. Build with least privilege. Give the implementation agent only the files, credentials, tools and network access it needs.
  4. Attack the work separately. Give a different agent a red-team role inside a sandbox, with an explicit scope and stop-line.
  5. Run deterministic gates. Use tests, dependency checks, secret scanning, static analysis, fuzzing and authorisation tests. A model saying "looks good" is not a release gate.
  6. Require competent review. Consequential code and architecture need someone who understands the domain, the system and the failure modes.
  7. Release for recovery. Deploy with rollback, monitoring, immutable evidence and a tested route back to safety.
  8. Learn from escaped defects. Feed incidents, near misses and review findings back into requirements, prompts, tests and evals.
An eight-stage secure agentic development loop covering threat modelling, acceptance criteria, least privilege, sandboxed red teaming, deterministic gates, competent review, monitored release and learning.
AI can work around the loop. The organisation remains responsible for the standard, the authority boundaries and the release decision.

Do not fire the developers. Train them.

If I were leading a software organisation now, I would not be working out how quickly I could remove the engineers.

I would be working out how quickly every engineer could become excellent at working with AI.

Give teams approved tools. Give them enough token budget to do serious work. Give them protected time to experiment. Run a weekly engineering session where people share prompts, agent patterns, failed approaches, security findings and useful tests.

Keep security expertise inside development, not as a ceremonial check just before release.

Then measure outcomes that matter: vulnerabilities escaping into production, change-failure rate, review burden, remediation time, cost per accepted change and whether recovery tests actually work.

I can personally burn through a top-tier $200 AI allowance in two or three days when I am doing intensive agentic development. That is not a universal pricing benchmark. It is a reminder that model and token spend is becoming engineering capacity, not merely another software-seat cost.

The teams using these tools well will do much more. You may not see the difference in a single afternoon. You will see it after a few months, when one organisation has better tests, better procedures, faster remediation and a deeper shared understanding of how to work with its agents.

The race is already under way

Attackers do not need AI to be perfect. They need it to make discovery, experimentation and scaling cheaper.

Defenders should demand more because they are responsible for what they ship. But demanding more is not an argument for refusing the tool. It is an argument for building a better operating system around it.

AI will not make your software secure by magic.

It can make a disciplined engineering team much more capable.

The hackers are already learning that lesson. Your developers should be too.

Sources and notes

Evidence checked against publicly available sources through 8 August 2026. Public cryptocurrency-loss estimates were still developing; the cited primary sources do not establish a final audited COLDCARD loss total.