I published a post with Asymmetric Research about bug classes that keep showing up in audit reports, security courses, and LLM outputs—but which aren’t actually vulnerabilities.

Topics include:

• Reentrancy (not a thing in Solana)
• Closed account discriminators (removed from Anchor years ago)
• Float non-determinism (emulated, not hardware-dependent)
• Self-transfers always succeeding (they don’t)
• Partial state commitment (transactions are atomic)
• Unchecked CPI return values (they revert automatically)

Getting these right helps everyone focus on real issues. The post explains what changed, why the old advice persists, and how the Solana ecosystem continues to evolve.

Read it on the Asymmetric Research blog

I got caught being lazy. I wanted to experiment by writing a brief, fragmented post at the end of the day. The goal was simply to explain-brag that I’d found a neat trick to get an LLM to do a post-processing step that increased its output quality somewhat.

As is my routine, I sent the rough draft through my “Style Editor” subagent. That’s when it got personal.

Here are some selected lines from the LLM’s review of my prose:

• “… reads like jargon explaining jargon”
• “tepid business-speak”
• “undermines its own point”
• “the unfinished structure introduces sloppiness (ironically)”

But this was the kicker:

### Does This Need to Be Published?

Your "Sloppy Syntax" post already catalogs LLM output problems. This post adds the *action* of fixing them, which is valuable, but ask yourself: is this additive to your existing work, or redundant?

If you proceed, make it either comprehensively practical (show the full prompt, give more examples, make it a resource) or philosophically interesting (what does the need for deslopification tell us?). The current draft falls in the exhausting middle ground that you eloquently criticized in "Bernoulli Coding."

Damn. This is a far cry from the fulsome you’re-absolutely-right style feedback I’m used to. Honestly, it stung a little.

It’s also hilarious. I was not expecting to get roasted by the machine. I was unconsciously relying on a bit of the ol’ sycophancy to get me through to the next draft.

I get that this is me playing chess against myself: I’m using my own words to critique my own words. I attempted to approximate my aesthetic preferences, programming a strange machine to tell myself when I don’t like something that I’m doing.

There’s value in ruthless self-assessment, and in coming back to a piece in a different frame of mind from the one you were in during the initial creation. “Write drunk, edit sober.”

I’m used to this way of thinking while writing or making music, but this experience was new. Instead of coming back to the work with a different mindset, I’ve approximated the critical mindset. The shock came from having that receiving the editorial feedback while I was in a lazy mode of the creative mindset.

I’m thankful for it. The Style Editor shook me out of a complacent mindset and genuinely challenged me to put more effort into writing something worthwhile.

The trick, apparently, is stating your aesthetic preferences clearly enough that the system delivers tough love on its own. I told it what good writing looks like, fed it my existing posts, and it somehow decided I needed to be called out. The harshness emerged organically, which makes it more interesting than if I’d explicitly programmed it to roast me.

I’m still entertained by moments like this. It’s fun when these things surprise you, and it’s this feeling of playful
exploration that keeps me motivated to blend LLMs into my writing and coding practices.

This week, I watched the sha1-hulud attack spread through the JavaScript ecosystem in real time. Over 830 npm packages compromised. 28,000 repositories infected. More than 11,000 unique secrets leaked, with over 2,000 still valid and publicly exposed as of November 24.

The response focused on securing accounts: enable MFA, audit dependencies, rotate secrets. Necessary, but reactive. There’s a prevention strategy that gets overlooked: stop running npm install.

The Problem

npm install pulls whatever version satisfies your semver range. Without a lockfile, you get the latest compatible version published in the last few seconds. With a lockfile, you’re still trusting that maintainer accounts haven’t been compromised, that transitive dependencies are clean, that post-install scripts aren’t malicious.

Every npm install is a bet that nothing malicious has been published since your last install. Sha1-hulud proved that bet loses.

Version Pinning as Defense

Dependency cooldowns are a valuable concept. (I encountered it on Simon Willison’s blog this week.) Wait a configurable period after a package is published before allowing it into your project. If a malicious version gets published, you have time to catch it before it reaches production.

For projects with serious security requirements, treat dependency updates as security events. They deserve dedicated review time and careful examination of changelogs. Staying several versions behind might actually reduce risk when attacks exploit the usual advice to patch quickly.

After the last major attack, we added explicit rules to Wormhole’s Guardian node CONTRIBUTING.md:

For existing projects, use npm ci. While npm install updates dependencies to newer versions within the semver range and might pull down a compromised package published five minutes ago, npm ci installs exactly what’s in package-lock.json.

When adding packages, pin versions. Use npm i package@version to specify exact versions. Specific versions can’t be overwritten after release, which blocks an entire class of attacks.

The same principles apply to Docker containers. Copy package.json and package-lock.json first, then run npm ci. For global packages, specify versions: npm install -g somepackage@1.2.3. Pin base images with SHA-256 hashes: FROM node:18.19.0-alpine@sha256:12345....

Building lockfile-guard

Manual discipline doesn’t scale. Developers will continue using the unsafe default workflow unless something stops them. I wanted a tool that would catch these mistakes before they reached production, so I wrote lockfile-guard.

It’s a GitHub Action that scans your repository for dangerous package manager commands. It checks Dockerfiles, markdown documentation, and shell scripts. When it finds violations, it fails the build.

The rules:

# ✅ Safe patterns
npm ci
npm i package@version
pnpm install --frozen-lockfile
yarn install --immutable
bun install --frozen-lockfile

# ❌ Dangerous patterns
npm install
npm i package
pnpm install
yarn install
bun install

The output:

✗ ./Dockerfile
  Line 15: Use 'npm ci' instead of 'npm install' for lockfile-based installations
  > npm install

✗ ./.github/workflows/deploy.yml
  Line 42: Use 'pnpm install --frozen-lockfile' to respect lockfile
  > pnpm install

Nothing advanced here, just pattern matching in files that matter. Simple tools are valuable when they encode protections that might otherwise depend on institutional memory.

Trust Is Not a Security Model

We trust that packages do what they claim, that maintainer accounts are protected, that the registry enforces security boundaries. Sha1-hulud exploited that trust. A single compromise rippled through thousands of projects in hours.

Use npm ci. Pin your versions. Audit your dependencies. Harden your CI/CD pipelines with least-privilege access. When the next supply chain attack arrives, and it will, you’ll be ready.

LLM-generated code is everywhere. The speed is seductive, the YOLO mode irresistible. Despite the horrible security problems
this entails, I also like to live --dangerously.

I’ve been thinking about whether you can vibe code complex applications and still ship secure code. Here are some lines of
thought I’ve been exploring.

Fragment 1: Linters as LLM Guardrails

The main defense is linters and static analysis tools. They’re deterministic, which matters enormously. You can integrate them into CI or commit hooks to block code that doesn’t meet standards. Better yet, high-quality tools often include suggested fixes or even auto-fix flags that can be applied directly to the codebase. With reasonably high-signal information like that, you can run the linter, have the LLM look at the output, and watch it fix its own mistakes.

Ask an LLM to code an app from scratch and run it against common linting tools. You’ll find dozens of errors. The LLM can look at those reports and fix the code it just made. Suddenly, even though it used dangerous patterns, it’s able to correct the ones we can lint for. It’s like having a sloppy chef who’ll clean up after themselves if you point at the spills.

SlopSquatting is interesting here because it’s a new bug class introduced by LLMs while also being a problem we can address via linting.

Fragment 2: The Limits of Linting

We need lint rules with high signal-to-noise ratios and suggested fixes. The more patterns we can detect and auto-correct, the better we can constrain generated code. But we get no security guarantees for unlintable problems. Logic errors, for instance, or authentication flows that span multiple files.

Linters raise the floor of quality on a codebase generated by an LLM, but vibe coding is going to remain an insecure process. The main problem is keeping context and intent across several distinct files. It’s easy to mess up an authentication system in a web app because you have to track state across user endpoints, authorization and routes, database schemas, refresh tokens, lockouts, and so on. It’s a bunch of complicated mechanisms glued together, and it’s easy to miss one line or make changes in one set of commits that undoes work in another set.

Fragment 3: The Problem of the Missing Mind

During a security review of a complex codebase, it’s common to go in and not understand how things work. But you can usually piece together the complex features with enough time and with the implicit trust that someone got this to work well at some point. There’s some sense of order lurking behind even a chaotic codebase. It may be that no single person on the team knows how it all works, but you get the blind men touching the elephant thing. Talk to enough people, read enough documentation, and you can usually assemble the whole from the parts, even if no one person sees the complete picture.

This won’t be the case with LLM-generated code. There is no intent creating a through-line in the implementation. No original architect who made deliberate choices, no accumulated wisdom from code reviews, no debugging sessions that revealed why something had to be done a particular way. Just slop in a bucket, tokens arranged in plausible patterns. The linters catch what they can, but the ghost in the machine isn’t haunted by understanding—just by training data.

Fragment 4: Everything is Perl Now

I have a soft spot for Perl despite its shortcomings. Maybe I love it because of what other people consider its shortcomings.
It’s fun to develop your own little dialect and completely forget about it ten minutes later. It’s infamous as a write-only language because no one can read its arcane symbols or figure out what the hell anyone else is doing.

But now a ton of new code is getting generated this way. The harder you vibe, the less you read the code. I have
entire applications where I haven’t yet opened all of the files. Code gets written, not read. Vibe-coding is a continuum,
and I expect the ratio of vibe-to-artisanal code to increase as the LLMs get better and as more people get comfortable with
the tools. Everything is Perl now.

A personal collection of totally radioactive syntax often generated by LLMs.

Stale Rhetorical Devices

• Contrastive negation, i.e. any variation on: “It’s not X – it’s Y”.
• Unnecessary meta-commentary (“So here’s the question,” “here’s the interesting part”)
• “The math is simple”
• Developing ideas in essays via anaphora
• Obvious alliteration

SEO and Algorithm Gamification

• New markdown headings that interject prose that already flows well
• Posts consisting of individual sentences separated by more than one new line
• Emojis as punctuation
• Emojis in markdown headings
• Ending pieces with “The Bottom Line”; superfluous summary pontification
• Calls-to-action outside of a marketing context

Sloppy Syntax

• Em dashes (other than rare occurrences)
• Bolded text

Phrases I’d never use

• AI assistant
• pair programmer

Like much of the gaming world lately, I’ve been playing a lot of Arc Raiders. The game is
described as PvPvE: Player vs. Player vs. Environment. Players explore a shared
post-apocalyptic landscape to scavenge rare materials. They can cooperate or attack
each other, stealing whatever loot their opponents have collected. But patrolling these
abandoned space ports and half-buried cities are killer robots, who attack everyone
regardless of alliance or intent.

The field of computer security works the same way, but most people think of it as
exclusively Player vs. Player: will the security engineer outsmart the hacker, or vice-versa?
We define our philosophies as white hat or black hat and describe our activity as
red or blue teaming.

But security work also has a PvE element. When securing systems, we struggle not just against
agents with opposed intentions, but against the environment itself. The computers are trying to
kill us. We don’t need to ascribe intent here; it’s observable from their behavior.

This makes sense when you realize that computer security is, for the most part, a subset of software quality. It shouldn’t be
possible to hack software of the highest quality. (Social engineering and wrench attacks
sidestep the software entirely, so they don’t count.)

Problems like denial-of-service, technical debt, or poorly-designed software are indistinguishable
from “real” security bugs. Unreliable, calcified systems are extremely difficult to secure because
it’s not always possible to test their behavior and prove their security properties.

The history of computing is full of these environmental failures. Early networks weren’t encrypted
because they assumed trusted users on trusted infrastructure. Multi-user operating systems shipped
without password protection because designers couldn’t imagine adversarial access. The environment
changed, but the systems couldn’t adapt without heavy intervention.

The same pattern plays out in modern systems. Flashloan attacks in Solidity weren’t possible until
DeFi protocols composed in ways the original developers never anticipated. Invariant-based design
could have prevented this—not by predicting flashloans specifically, but by encoding constraints
that hold regardless of the execution environment.

Why do these environmental failures keep happening? Because the environment actively fights you.
Brittle code, legacy systems, poor abstractions, missing tests—a codebase with little in the way of test coverage
or proactive assertions of invariants can’t be refactored safely. A system built on fragile assumptions breaks under novel inputs. A service with ten dependency layers fails in ways no one can predict. These aren’t just obstacles
to security work. They are security problems.

Yet this isn’t how most people think about security, because environmental issues are less obvious
and sexy than a major compromise. It also doesn’t fit well into the offensive security mindset oriented
toward time-boxed evaluations: pentests, code audits, contests, and bug bounties. These
problems are more like a disease that slowly spreads and only becomes visible when it’s
already lethal.

The PvPvE frame lacks the narrative drama of hacker-versus-hacker showdowns, but it better
explains the actual work. You’re not just fighting attackers. You’re fighting the computers themselves.

And if you ignore the environment, you’re already halfway to losing the game.

The middle ground in software development is dead.

After a decade of building systems, reviewing code, and hunting vulnerabilities, I’ve found myself writing software in exactly two modes. There’s the fortress: ultra-secure, thoroughly tested, peer-reviewed, and bulletproof. Then there’s the sketch: completely disposable, built for speed, meant to break.

This approach eliminates the exhausting middle tier where projects hover in development purgatory. Those half-robust side projects that might work, might scale, might be worth the CI setup and security audit. The ones that consume mental energy without clarity of purpose.

The Two Extremes

Fortress Mode applies to anything handling sensitive data or critical workflows. These projects get the full treatment: linters cranked to maximum sensitivity, comprehensive test suites, security reviews, and deployment pipelines. Every dependency is audited. Every function is documented.

This rigor exists because most software frustrations stem from cutting corners. Web apps that constantly break, services that leak data, systems that crumble under load. When something matters, it deserves relentless attention.

This is how I code for work, or in any situation where someone is counting on me to do something properly.

Sketch Mode covers scripts, proof-of-concepts, and experimental tools. Here, I deliberately turn off the security reviewer part of my brain. No Rust type system enforcement, no memory safety concerns, no linting. The goal is pure velocity: get the idea out of your head and into working form.

These tools exist to answer a simple question: is this concept worth pursuing? Most aren’t. They’re incomplete, abandoned after the initial burst of curiosity, or require significant rework to become truly useful. Starting with heavy tooling would kill the experimentation entirely.

This goes all the way down to language choice. I won’t vibe-code Rust, and I won’t try to write secure, reliable software
in an interpreted language. Getting clear on the actual use of the software allows one to play to the respective
strengths of the tools used to build it.

The Excluded Middle

Even though both of the above approaches are extreme in their own ways, it’s actually the mid-tier projects that I find
most exhausting to work with. Fortress-style should be lovely to read and should work every time. Sketch mode code
should never, ever be read and is almost something close to an aesthetic, playful experience than to something like
engineering.

Most of the software out there isn’t truly fortress-grade or unapologetically sketchy. Instead, it’s fragile code pretending to be robust—a proof-of-concept stretched far past its expiration date. Most software should be thought of as
slop until proven otherwise, just because doing things right ends up being beyond the interest, ability, or resources
of most people and organizations. Maybe all of the LLM-generated code will make more people realize and/or admit this.

Putting Out Slop

I treat the sketch projects like hazardous materials, clearly labeled from the start. The README gets a prominent warning: “This is vibe-coded software. Use at your own risk.” No security guarantees or reliability promises, just an idea I had that someone
else might find interesting too.

More broadly, I’m sympathetic to the idea of FOSS as a gift economy
rather than as an open-ended service contract. If I was stuck in that mindset, I wouldn’t be able to make and share these
projects knowing that they almost certainly have ridiculous problems as well as security issues. It’s not even so
much that I’m genuinely worried that someone will get hacked because of something that I wrote, but more that
it takes more mental energy to write code securely, and that’s not the point of these projects.

Keeping these two mindsets totally separate has felt deeply liberating. I hope others do the same, so that we can
all be a little bit more clear about what we’re getting ourselves into when we run something off of GitHub.

Vibe-coding sessions can go awry in many ways. One way is for the agent to offer to install a weird package. It will frequently pull an obscure GitHub repo over an official SDK. AI training data is biased toward whatever packages were popular or well-documented during training, not necessarily what’s safe or well-maintained.

This happened to me recently: I was trying to connect Go with OpenAI when the agent suggested installing an unofficial implementation over OpenAI’s own SDK. Nothing obviously wrong with that particular package, but it got me thinking about how this could be prevented. We’re automating ourselves toward new vulnerabilities. As we allow these tools to become more autonomous, we need defenses that work automatically too.

So I added a new slopsquat directory to Scary Strings that tracks risky packages.

My immediate motivation is to use it to track and prevent strange packages that AI tools suggest in the wild,
though of course it is also simply a collection of weird libraries that go against sensible defaults.

Developers can then wire this list into their package managers (like depguard in Go) to automatically reject these suggestions before they make it into production.

Using this list to block packages in CI protects against both human mistakes and AI agents running wild. Whether you’re a dev who is too busy to investigate every package, or an autonomous agent in full YOLO mode, the safety net catches both.

The browser has been the everything app for a long time, and much hype surrounds the idea of automating browser use with LLMs. But in the age of AI agents, the CLI + LLM combo could be the superior choice for getting anything done.

Anthropic announced their new Piloting Claude for Chrome feature today, unleashing Claude into the wild web where it will click, scroll, and type its way through the digital maze we’ve built around our simplest tasks.

Browser automation leaves me cold. Every browser tab feels like a small defeat, a task that I couldn’t solve in a simple, repeatable way. Where possible, I will always reach for the command-line first so that I can make the most out of my programming
skills and the speed that comes with adroit keyboard navigation.

That said, that’s not most people’s experience, so the wider appeal of browser automation is obvious. And unfortunately
there’s not a good CLI-based solution for most “real life”, non-coding domains: filing taxes, ordering groceries, booking appointments, managing subscriptions.

These tasks are trapped behind interfaces designed for human eyeballs, which makes their execution extremely inefficient.

Consider what we’re actually asking LLMs to do. Navigate to TurboTax, wait for the page to load, dismiss the promotional popup, click through the cookie consent dialog, find the right form field among dozens of others, enter data, wait for validation, handle inevitable JavaScript errors, and repeat this dance hundreds of times.

Then, of course, are the massive security implications of giving AI agents access to our browsers.

All this to say: we’re solving the wrong problem with the wrong tool.

Instead of teaching AIs to navigate human interfaces, what if we built machine-readable interfaces for the tasks that matter?

Text-based interfaces play to LLM strengths rather than their weaknesses. Instead of parsing visual layouts and guessing click targets, they could process structured data and generate precise commands. An AI that struggles to find the “Submit” button on a cluttered webpage could effortlessly compose complex command pipelines.

Consider the UNIX philosophy applied to daily life. grocery-order --store=whole-foods --list=weekly.txt --delivery="Tuesday 6pm".
Recurring deliveries could be done with a cronjob. Workflows could be shared with family and friends: along with recommending a recipe, you could share the script that places a delivery order for all of the ingredients. No stock photos of produce, no upselling widgets, no loading spinners. The same could be done for filing taxes, booking appointments, and so on.

This could do a lot to educate people about programming and help them to feel more empowered too. Instead of losing
all of one’s know-how each time a GUI undergoes a rework, scripting knowledge could accumulate and compound. The whole
consumer world could be converted into script-kiddies, and some of them would graduate into full-fledged hackers.

Given that innumerable person-hours and lines of code have been devoted to making the web functional
for commerce, I don’t know if any of this will come to pass. It would mean a huge shift in how people think
about using their computers. For companies it might be more difficult to deploy the dark arts of advertising and surveillance
outside of the browser context, and this alone might ensure that the CLI-based future does not come to pass.

But as for sheer efficiency, composability, and ease-of-use, I think there’s an excellent argument to be made
for shifting the paradigm.