Vibe hacking: how attackers are weaponizing AI coding assistants

The term getting used for it is vibe hacking: an attacker describes what they want in plain language, and a coding assistant writes the working exploit, phishing kit, or evasion wrapper. No deep language expertise required, no manual debugging of shellcode. Just iteration, in the same conversational loop a developer would use to ship a feature.

This is not a new attack technique. It is an old set of techniques with the skill floor removed.

Where it shows up first

Phishing kits are the clearest early example. An attacker no longer needs to hand-write a convincing login page or write copy that survives a native speaker’s read-through. The assistant generates both, and regenerates them instantly when a target’s spam filter catches on. The same applies to malware variants: instead of one payload trying to dodge a signature, an attacker can generate dozens of functionally identical variants with different code shape, each one a slightly different signature.

Business email compromise is the other obvious beneficiary. Convincing, context-aware pretext emails, adapted to a specific company’s tone and org chart scraped from public sources, can now be produced in the time it used to take to draft one generic template.

The defender’s mistake

The instinct is to treat this as a bigger version of the same problem: more phishing emails, more malware samples, same controls, just turn up the volume. That undercounts what changed. The bottleneck used to be attacker skill and time. Both have been substantially removed. A team that could previously assume a low-skill attacker would make a detectable mistake somewhere in the kill chain can no longer assume that.

Signature and hash-based detection is the control that degrades fastest under this shift, because it depends on exactly the kind of static artifact that AI-assisted variant generation is good at avoiding.

What actually helps

• Weight detection toward behavior, not artifacts: process lineage, unusual outbound connections, and credential use patterns hold up better than hash matching against a moving target.
• Assume phishing content will read as fluent and well-targeted. Put the control on the click and the login, not on catching bad grammar.
• Tighten the basics that were never about attacker skill in the first place: MFA that resists phishing, least-privilege access, and fast patching. None of that gets easier or harder because the attacker used an AI assistant.
• Treat unusual authorization requests, especially anything resembling a BEC-style payment or credential change, as a process problem to verify out of band, not a content problem to spot by tone.

The part that does not change

An AI assistant makes an attacker faster and more fluent. It does not give them a way around multi-factor authentication that resists phishing, and it does not make a patched system exploitable. The fundamentals hold up. What has changed is how much you can rely on an attacker being slow, sloppy, or identifiable by their code style. Plan defenses around the technique working well, not around the attacker being bad at their job.