My thesis was, given how good frontier models are and will continue to be at cyber tasks, cyberwarfare will eventually become a function of whoever can expend the most compute. Asymmetric inference costs between offense and defense (Shahed to Patriot missile cost analogy) will become a defining problem in cybersecurity.

It’s crazy just how fast we went from tokenmaxxing to conserving inference spend. Enterprises are now using routers and vastly cheaper open models only a few months off the frontier. Coinbase already defaults to GLM 5.2 and Kimi 2.7 via their LLM gateway. I guess this is the natural evolution of things when major enterprises burn through their entire AI budgets in April (sorry Uber).

There’s a great mental model that I came across in a Substack article from Judith Dada in August of last year. She splits tasks into two kinds:

1. Intelligence-Hungry -> performance improves with more intelligence. These are usually creative tasks, like copywriting or research.

2. Intelligence-Full -> complexity is fixed, so performance caps out at a certain intelligence level, making SOTA models unnecessary. Judith gives the example of payroll automation, because once a system is able to pay employees accurately and on time, there is no competitive advantage to making it smarter.

I believe every enterprise security team (and every cybersecurity startup that wants to keep its margins high) will need to start asking: which cyber tasks are Intelligence-Hungry versus Intelligence-Full?

My initial assumptions:

• Threat hunting and detection engineering are Intelligence-Hungry -> These are open-ended exploration/research tasks, a bit like planning in software engineering. They require creativity and a deep understanding of the environment.

• Alert triage is Intelligence-Full -> Once an agent is able to correctly triage a type of alert, there is no added benefit to making that agent smarter. (Brand new alert types are the exception.)

• Threat intelligence is Intelligence-Hungry -> Creative pivoting and broad domain contextual analysis is needed.

• Penetration testing is Intelligence-Full -> Like in software engineering, pentest planning will probably be handled by frontier models, but the execution of specific, bounded TTPs can be cheaply handled by less intelligent models. This is already happening. Dreadnode (IQT portco!) recently fine-tuned an 8B model on synthetic Active Directory data, making it smart enough to get Domain Admin.

I’m curious where folks might differ in opinion - which of my categorizations are right/wrong?

The usual explanations are valid but incomplete. Models understand code well, open source training data is abundant, agents are good at using the terminal, and version control makes iteration and collaboration natural.

But I believe the most important factor is that coding agents have a better feedback loop than any other domain. That loop depends on two properties:

1. Verifiability with precise error attribution -> you can grade an outcome against ground truth and point to exactly where it went wrong

2. Cheap, realistic iteration -> you can run thousands of cycles in an environment that closely resembles deployment

An agent writes code, runs and tests it in a sandbox VM similar to production, and gets a ground-truth signal in seconds. When it fails, the agent can easily identify the exact line of code that caused the failure.

The Anthropic compiler experiment illustrates this well when applied to a long horizon task. In February 2026, Anthropic ran parallel agents using Claude Opus 4.6 to build a C compiler in Rust capable of compiling the Linux kernel.2 After roughly 2,000 sessions and $20,000 in API costs, the agents produced a functional 100,000-line compiler. While the code (published on Github) is a bit of a mess, it is an insanely impressive accomplishment for agents to have autonomously (for the most part) built such a complex piece of software.

The experiment worked because of a tight and accurate testing/validation loop. Nicholas Carlini at Anthropic used GCC (the de facto standard open-source compiler) as a known-good oracle. An oracle, in testing, is a trusted reference that tells you what the correct output should be.

For software validation, the test can be many things, like whether the syntax is correct, whether or not the code ran, whether it passes specific unit/integration tests, etc. But since the end goal was building a compiler, GCC was the perfect oracle. Carlini compiled most of the Linux kernel with GCC and a random subset with Claude’s compiler. Any divergence between the two outputs was, by definition, a bug in Claude’s version. Each failure pointed to a specific code path he could direct the agents to iteratively find and fix.

The loops ran in virtual machines which are similar to real deployment environments and relatively cheap and fast to spin up and iterate at scale.

Compare this to customer service agents where the outcomes are much more subjective. Customer service agents fail the verifiability test because there is no oracle for the right response to a frustrated human. Humans are varied and complicated! Then, there’s no way to attribute exactly what sentence in the AI customer service agent’s response caused the customer to churn or stay.

Similarly, AI sales rep agents fail the iteration speed test. The sales feedback cycle can run for months. Even if you had a perfect oracle, the loop is too slow to drive learning. There is no GCC for determining if a cold email was perfectly crafted, and even if there were, it’d probably take a multiple month sales cycle to figure out if it was right.

These are structural problems for domains involving humans. But, the oracles and simulation environments don’t have to be perfect - they just have to be good enough and fast enough to drive learning.

Verifiable, cheap and realistic loops are possible and already exist in domains much messier than code. Waymo’s simulator is a perfect example.3 Driving is chaotic and full of human pedestrians, cyclists weaving through traffic, other drivers behaving unpredictably, weather, construction, and a whole host of edge cases. Waymo has built a simulator that runs roughly 25,000 virtual vehicles covering up to 10 million simulated miles per day. The other road users in it are reactive agents like simulated pedestrians, cyclists, and drivers which respond to how the Waymo moves, calibrated against millions of miles of real-world driving data.

There of course is no ground truth like GCC is to compiling code for “did the car drive well”, but the simulator is good enough and trained on enough real world data to validate that trips can be completed safely and efficiently. The sandbox isn’t a perfect physics simulator but it is plausible enough to mimic real world behavior, and iterates fast enough and inexpensively enough to be run millions of simulated miles every day. The iterations are both verifiable and cheap.

I believe the next wave of agent progress will come from people manufacturing realistic simulations with fast iterations for domains that don’t have them yet. My guess is we will get progress from constructed oracles for narrow slices of a domain rather than full-fidelity simulations of the whole thing.

If you’re building simulation environments, constructed oracles, or fast feedback loops for messy domains, I want to hear from you!

There was a concept at Google that I always had mixed feelings about. It is called the “No Heroes” rule1, and the argument goes like this: When an individual has to do a heroic task (ex: work 18 hours straight to prevent an outage) that effort is masking a systemic and institutional gap. The right response is to fix the system so heroism becomes unnecessary. In a mature, high performing engineering org, there should be no heroes.

No Heroes is generally the correct engineering doctrine in a mature organization. But I believe it is wrong as a theory of how institutions actually get things done, and is wrong about human nature.

Charlie Munger once described Google’s headquarters as a “very rich kindergarten.” Munching on snacks in the micro-kitchen, I couldn’t help but feel I was getting soft, and that the organization itself was getting soft. No Heroes removes the veneration of going hard, which over time selects for a different kind of employee. Google is an unusual place and was a privilege to work at, but a No Heroes ethos paired with a culture of comfort gets dangerous the moment the org has to get medieval and go from 0 to 1.

Even inside Google, I was often surprised to find that one engineer happened to know everything about a system and was the major driving force behind it. Most progress, even inside large institutions, is made by one person with the drive and skill to pull it off. The xkcd “Dependency” comic about modern infrastructure resting on “a project some random person in Nebraska has been thanklessly maintaining since 2003” is a joke and also true.

This is the double-edged sword. There is a concept I came across recently called the Bus Factor. It refers to the number of people who would need to disappear (get hit by a bus) before a project loses enough critical knowledge to continue. A 2015 study found that for 64% of the top 133 GitHub projects, the Bus Factor was below 22. Heroism without institutional backing produces fragility.

I am in many ways amenable to the Great Man of History theory. It is hard to operate in the startup world without believing at least parts of it. The founder is that great (wo)man, single-handedly pulling the company, and sometimes the world, along into something generational.

Startups, and the startup mindset, are organized entirely around heroism. It is all “cracked 10x engineers” and going Founder Mode, and it really does take a uniquely visionary and gritty individual to go from 0 to 1. The cost is that 24/7 heroism is often unsustainable, and a major cause of startup death is the founder giving up. Startups need at least some institutional scaffolding so that the company can survive a key person leaving. But Brian Chesky’s vision of Founder Mode is essentially that the founder-as-hero archetype should never end, even as a startup scales up even into IPO. So in the vision of Founder Mode, the company is the founder. The founder absolutely should understand the product best, but the same instinct, taken too far, can produce tyrannical micromanagement and cults of personality.

The military is a great example of holding “No Heroes” and “celebration of heroes” in tension simultaneously. Individuals join as they are, and the institution forges them into a disciplined whole greater than the sum of its parts. Individuals are made interchangeable, and the institution is designed to keep functioning regardless of who fills any one role. And yet military history is overwhelmingly a history of named individuals doing heroic, extraordinary things in service of the mission. Nobody gets a Medal of Honor in a mission where everything goes to plan. We have after action reports to root out systemic failures and learn from mistakes, but we also celebrate, honor, and encourage heroic acts of service.

Heroism and institution are complementary and must be calibrated to meet the moment. Google could probably use a few more heroes (Sergey Brin getting back in the weeds to build agentic coding is a great example of this). Open source probably needs fewer heroes and more structural support, so that critical infrastructure does not rest on one burned out maintainer. Startups could use more institutional scaffolding, so founders can survive long enough to build something durable. I do not have a clean rule for which mode any given organization needs. The hard judgement call is knowing which one your organization needs more of, and when.

Most of the chatter is about speed. Speed to vuln discovery and exploitation, versus speed of patching and responding. That’s definitely a problem which needs to be solved, but I want to take this in a slightly different direction and focus on the asymmetric cost of inference.

Mythos is genuinely, concerningly capable, and my assumption is other labs will likely close the gap in 3–6 months, and open source possibly in 12 (don’t hold me to this prediction). Mythos is also rumored to be extremely large, expensive to train, and expensive to run. Now that frontier models are better than humans at offensive cyber tasks, the bottleneck stops being cyber talent and becomes industrial capacity.

As these agents run 24/7/365, cyberwarfare starts to look like a contest of which nation can sustain the most datacenters and gigawatts.

This means the defender’s response isn’t just to “use AI too”. It’s to balance out the compute cost ratio.

How much inference does it take for an offensive AI agent to go from an external-facing web app to domain admin? My (somewhat) educated guesstimate: not that high. And it’s going to take significantly more inference and compute to ingest logs from each endpoint, correlate them, get an agent to triage, and then do the remediation. From an inference standpoint, defense (as we currently do it with the SOC model) is probably more expensive out of the gate.

The analogy I like to work with is that of kinetic air defense. Patriot PAC-3 interceptors run about $4 million each, while Shahed drones cost roughly $20,000 to $50,000. Not to mention production time and industrial capacity limitations. Whoever forces the other side into the wrong side of the cost curve wins the war of attrition.

AI-enabled cyber is heading to the same place. “Can the model do it” will no longer be the question - we know it can, and if it’s can’t it’ll probably be able to in the next 12 months. The question I’m most interested in now: what’s the cost ratio, per campaign, per target, between the cheapest offensive capability and the cheapest defense that neutralizes it?

If you’re building toward structurally cheaper defensive inference - I’d love to hear from you!

Anyone who has built or worked with AI agents knows they can be superhuman yet also quite dumb. They depend on the right prompting, context management, tool calling, and task planning to function at all. Of course, there are brilliant engineers working nonstop to close these gaps, and I believe they will. But the architectural properties of LLM-based agents introduce inherent weaknesses that human attackers don’t have. Defenders should exploit them.

The MITRE ATLAS framework maps adversarial attacks against AI systems. It’s a threat model for defending your own AI. But I propose flipping it - use it as a guide for how to attack agents trying to attack your network.

A few examples:

• Prompt Injection -> Anything an attacker pipes into an LLM should be contested ground. Logs, error messages, READMEs, API responses, etc. Embed injections everywhere. Make attackers second-guess every bit of context they ingest.

• Memory and State Corruption -> Agents with persistent memory or long-running task state are especially fragile. Honeypots and canaries have always existed, but now they can be tuned to exploit how agents plan. Corrupt the planning stage, and you’ve derailed every downstream step. You’ll also be forcing agents to burn tokens chasing fake leads.

• Tool Poisoning -> Attackers living off the land rely on existing binaries. Agents trust the outputs of the tools they call. Poison those outputs (in a way that doesn’t deceive legitimate users).

• Context Window Flooding -> What if we weaponized the “Lost in the Middle” problem? LLMs reliably lose track of information buried in long contexts. Flood the zone.

• Corrupt the Validation Loop -> Well-built agents usually have self-checks, such as running tests or validating against initial requirements. If tests pass, an agent usually thinks it’s all good and moves on to the next task.

You may notice that much of this centers around deception! More on that in a future piece.

I believe the future of cyber defense is not to replicate the existing SOC structure with AI agents. It’s to build solutions that asymmetrically impose costs on attackers, however they evolve.

Now is not the time to mope about how AI-enabled attackers are going to go so much faster, and find so many more vulns, and move at such scale - we know they will. Agents introduce a whole class of vulnerabilities that humans don’t have. The goal isn’t perfect deception or stopping agents completely. It’s about impeding every step and imposing costs, making agentic attackers distrust their own decisions at every stage of the kill chain.

—

If you are building solutions to attack AI agents (for defense), I want to hear from you!

As a former professional software engineer, it’s insane just how much the profession has changed in the past 2 years, and especially in the past few months. 2 years ago I was still hand-coding with VSCode, augmented with a little line completion. 1 year ago I was using Cursor with GPT 4.5, letting it a file or two at a time, reading and reviewing all code the AI produced. Today I’m a whole lot more hands off.

It’s gone from me only trusting AI to complete single lines of code, to me trusting AI to write functions, to me trusting AI to write files, to me trusting AI to write entire features (and getting AI to review the code also).

I’ve been experimenting heavily with (semi) long-running coding agents lately, and my current max is around 5 concurrent agents. There are two big bottlenecks:

• My own mental context window. I could be using an orchestrator agent with a kanban board to manage those agents, but I actually want to be hands on with the business logic. After 5 agents, I can no longer keep track of what’s going on. Possibly a skill issue.

• My current codebases aren’t big enough for that many agents to work discrete features without bumping into each other and causing merge conflicts.

My current setup

Given the speed of changes in the devtools ecosystem, I’ve been tweaking my coding setup weekly. This is my current setup as of April 2026:

• Conductor for managing agents (free)

  • As much as I like iTerm + Tmux, Conductor is a level up for managing agents. The sandboxing makes it much easier to manage multiple sessions. I would find it much much harder to manage multiple agents if not for Conductor.

• Claude Code (Opus 4.7) – Max Plan 5x ($100 per month)

  • It’s great - I don’t have much to add about Claude Code that hasn’t already been written.

  • Claude Design is shockingly good also. Highly recommend. I’m no designer, but I’ve been using it a lot ever since it came out.

• Codex (GPT 5.4) – ChatGPT Plus Plan ($20 per month)

  • I use a mix of both Claude Code and Codex. I originally started using Codex because I had been hitting Claude Code usage limits (I’m on the Max 5x plan), but then started to actually like it. Claude Code is still my primary coding agent, but I still use Codex to review the code that Claude Code produces. I don’t have strong opinions about the pros and cons of Codex versus Claude Code. I find them to be borderline interchangeable.

• Gstack setup for Claude Code (free, thanks Garry Tan)

  • I opted to use Gstack rather than building out many of my own Skills because I’m probably not going to put in the cycles to maintain them just for myself, and I’m personally probably better off deferring to the best practices built up by the community.

  • Gstack forces clarifying questions upfront. I wish this was the default for coding agents - force more clarifying questions, so that the agents don’t try to overcomplicate every feature.

  • The /office-hours skill pretty neat.

  • Gstack adds a lot of input tokens into the context window. Sometimes the features are a bit overkill for me, and I only use a handful of the skills.

  • Claude Design removes the need for a lot of the Gstack design skills.

• If I’m using local models, I’ve been using Ollama and mainly Qwen 3.5 9b and Gemma 4. I rarely use local open source models though because they’re too dumb for most of my use cases, and too slow running on my Macbook.

Is the code quality any good?

As for the quality of the code actually generated, it’s not terrible. I still toss out a significant amount of code, and refactor frequently, but it’s all workable. I rarely if ever find myself editing code by hand, which is pretty different from one year ago, back when I was using Cursor.

It's still very much a work in progress and I fully anticipate changing things as the space evolves on a daily basis.

On the Jane Street trading floor, every algorithm had its own sound. Walking the floor was said to be like being in an arcade, a cacophony of soundbites constantly going off, each corresponding with an issue that needed to be addressed. Traders didn’t just look at dashboards; they experienced rhythms and could identify when something was going wrong, not just from looking at a monitor, but by hearing it in real time.

I love a good pewpew map, even though they’re usually pretty useless and completely inaccurate representations of threats. But what if we applied the Jane Street concept more seriously to the SOC?

Imagine if every detection rule had its own sound. You would hear it every time it fired. (A badly tuned detection rule would immediately become unbearably annoying – a great motivator for reducing false positives.) An analyst would know their network was being attacked not by squinting at a Splunk dashboard, but by the specific sonic sequence of a kill chain unfolding in the room around them. 

Consider if you could taste the bitterness of Kerberrosting, or hear the rhythm of SMB enumeration in progress. While this sounds absurd on the surface, I would posit that it is more absurd that we have compressed all threat detection into a 2D screen, ignoring all senses beyond sight, ignoring the full human nervous system’s analytical capabilities, and hampering our ability to develop intuition quickly.

A couple of years ago, I worked as a deckhand on the Götheborg of Sweden, an exact wooden replica of an 18th-century East Indiaman tall ship. My time on the ship reminded me how many English phrases are maritime metaphors. Now, when someone says “all hands on deck”, I can physically feel myself awoken from my hammock and rushing to get on deck in the cold and wind to push a capstan along with 10 other crewmates, just to tack. I don’t conceptually just know the phrase. I know how it feels. Experience is a deeper level of understanding. With a multisensory SOC, an analyst’s understanding of an attack would go from conceptual to experiential. This is the same reason hospital monitors beep, and airplanes have stall horns.

I think a lot about what it means to be a good analyst and how we develop the next generation to be even greater. In the book Thinking, Fast and Slow, author Daniel Kahneman provides an anecdote about how the Israeli military conducted interviews. There would be checklists to follow, but the best interviewers would follow the list, then close their notebooks and stop, sensing how they felt in their gut. This combination of process and an educated gut was where they found the best judgments were made.

The AI native SOC is coming. Detection, triage, and most tier-one analysis will soon (if it hasn’t already) be fully automated by agents. If we don’t intentionally train the next generation of cybersecurity professionals, we’ll wake up in a decade wondering where all the mid-level talent went. 

So how do we build up gut-level experience in the next generation of cybersecurity professionals? I believe it will be through building something like a Multisensory SOC. A system that unlocks the full human sensory analytical capacity and compresses the timeline for turning conceptual knowledge into experience.

As models continue to improve, meeting and exceeding human capabilities in cybersecurity (just look at Anthropic’s Mythos Preview), I increasingly believe the only moat for humans is to lean into being human. It’s our feelings, it’s our intuitions, it’s our gut, the things AI will (hopefully) never be able to replace.

—

I’m increasingly interested in people who are building things to unlock multisensory experiences, bringing about the physical manifestation of the digital. If you’re building in this space, I want to hear from you.

—

Footnotes:

1. Shoutout to my friend Sam for originally giving me the idea about Jane Street. This post is inspired by his white boarding.

2. Going Infinite by Michael Lewis has a great recounting of the Jane Street trading floor

3. My Thinking, Fast and Slow anecdote is an extremely boiled-down summary. I highly recommend reading the book.

4. A sound-based network monitoring system was tested in 2000 by two researchers (Michael Gilfix & Alva Couch) at Tufts University. They called it “Peep: The Network Auralizer”. It never got beyond the experimental phase.

If you delete a file on macOS and empty the Trash, your Mac still remembers exactly what it was called and where it lived.

.DS_Store files are one of my favorite forensic artifacts. They're niche, kind of weird, and pack a surprising amount of forensically useful information.

To most of my software engineer friends, ".DS_Store" is just a line you put in your .gitignore. Under the hood, there's a lot more going on if you know what you're looking for!

Quick backgrounder: the .DS_Store (Desktop Services Store) file is a hidden binary that macOS Finder creates in every directory you open. It stores display preferences, icon positions, window size, view mode, sort order and uses a proprietary format and stores records in a B-tree.

Lots of awesome reverse engineering work was done over a decade ago on the file type by Mark Mentovai and Wim Lewis and I wouldn't have understood how it works without first reading their posts.

Why should forensic investigators care?

• The .DS_Store file's existence proves someone browsed that folder in Finder

• Filenames persist in .DS_Store even after the files are deleted until the system reboots (I still need to do a bit more testing on how long the deleted files last - it may depend on macOS version)

• Trash put-back records store where trashed files originally came from, surviving even after the Trash is emptied

• Timestamps and file sizes are recorded at the time Finder indexed them

• If someone deletes a sensitive file and empties their Trash, the .DS_Store in ~/.Trash can still tell you what the file was called and exactly where it lived before deletion

Writing a .DS_Store parser

Without being properly parsed, the .DS_Store file is pretty useless. I built “ds-store-parser” (with help from Claude Code, of course!) to turn the .DS_Store binary into accessible and useful forensic information.

It's a Python CLI tool using only the standard library, Python 3.10+. It reads the raw binary, decodes the record types, and outputs clean CSV or JSON. One row per file, with human-readable columns for everything (while maintaining the raw data). I validated it against 368 real .DS_Store files from my MacBook.

Next time you push to GitHub, make sure you’re not adding a .DS_Store file! It is quietly leaking your directory structure and filenames to anyone who knows how to parse it.

Check out the parser on my Github: https://github.com/jonathanlooi/ds-store-parser

Your Mac (sort of) keeps a record of every file you’ve downloaded from the internet.

It’s stored in a SQLite database called Quarantine Events V2 (located at ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2).

But why is macOS collecting all this information in the first place?

Mac uses this database to warn users before opening potentially malicious files downloaded from the internet. It’s the feature that gives you the notifications asking: “[downloaded app] is an app created by the app [source app]. Are you sure you want to open it?”

macOS has had a quarantine system since Leopard (10.5). Gatekeeper, the built-in security feature that verifies that a downloaded app is from an identified developer (code signing) and has been submitted to Apple for malware scanning (notarization), builds on top of this quarantine system. When a quarantine-aware app like Safari, Chrome, or Mail downloads a file, macOS stamps it with a com.apple.quarantine attribute and logs the event in the QuarantineEventsV2 database.

The database schema includes: a UUID, timestamp, agent name (downloading application), bundle identifier, download URL, origin URL (the referring page), sender name/address (for email attachments), and a type number.

Notably absent is the actual filename. There is no column for it. The UUID ties to the extended attribute on the file, but once the file is deleted, that link is broken. You cannot recover the filename from this database alone. In practice, many fields are frequently empty. I queried my own Mac and reliably got timestamps and agent names. Origin URLs were populated for some entries, absent for others. Sender fields were almost never populated. Also, keep in mind that timestamps use Cocoa epoch (seconds since Jan 1, 2001). Add 978307200 to convert to Unix epoch.

So what is QuarantineEventsV2 actually good for?

• Corroboration. Cross-reference quarantine timestamps with browser history, FSEvents, or Unified Logs to build a more complete timeline.

• Agent name analysis. LSQuarantineAgentName reliably identifies the downloading application. AirDrop transfers show up as sharingd.

• Persistence. macOS never cleans this database, even after files are deleted, Trash is emptied, and browser history is cleared.

Since this is just a SQLite database, you don’t need a custom parser! And for forensic workflows at scale, Velociraptor’s MacOS.System.QuarantineEvents artifact and Plaso’s ls_quarantine plugin already handle the parsing and timestamp conversion.

Try this on your own Mac:

sqlite3 -header -column ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 “SELECT datetime(LSQuarantineTimeStamp + 978307200, ‘unixepoch’) as download_time, LSQuarantineAgentName, LSQuarantineDataURLString FROM LSQuarantineEvent ORDER BY LSQuarantineTimeStamp DESC LIMIT 20"