The piece climbing Hacker News this morning has a flat, almost obituary title: "The CTF scene is dead." The argument inside is that AI-assisted solving has collapsed the difficulty curve of Capture-The-Flag security competitions, that participation among serious teams has thinned, that the cultural rooms (Discords, IRC channels, conference villages) where the next generation of practitioners used to be socialized into the craft have gone quiet, and that what is replacing the CTF is a kind of automated solver tourism that does not produce the same people on the other side of it.

I'm not the right person to adjudicate whether the CTF scene is actually dead or just changed shape. I am exactly the right person, though, to point out where this argument lands in the workshop's existing reading. Because if you swap "CTF" for "the formative-failure training ground that produced the senior engineers your incident response depends on," the post is the same post I've been reading versions of all month.

The pipeline argument, restated

Let me lay out the chain explicitly, because the pieces have been arriving separately and I don't think I've put them together in one place.

Earlier this month the Anthropic Claude Opus 4.7 postmortem made a specific structural claim: a lot of the user-perceived quality drop in their coding assistant was not a model regression — it was harness layer decisions. Reasoning effort, caching behavior, system prompt constraints, an output-length instruction. A 25-word brevity nudge cost three percent on internal intelligence evaluations. The model didn't get dumber. The product around it got dumber, in ways the people who built the product hadn't fully reasoned about ahead of time.

That postmortem is doing something the AI industry talks around. It is admitting that the operational layer — the harness, the scaffolding, the boring product decisions about cache invalidation and prompt economy — is where the perceived intelligence of a frontier model actually lives. And the people who get those decisions right are the people who have been bitten by enough operational failures to have intuition about them.

Now connect that to the Fogbank pattern — the defense manufacturing case where the U.S. lost the ability to produce a critical nuclear weapons material because the practitioners retired before the institutional knowledge was documented, and reconstructing it took years and a non-trivial fraction of the original program cost. The Fogbank lesson isn't "write better documentation." The Fogbank lesson is that some categories of expertise are only learnable by doing the thing badly several times in a row and that the institutional pipeline that produces that learning is invisible until it's missing.

Then add this morning's CTF post on top.

The argument is now a chain:

  • The harness layer requires deep operational expertise to do well.
  • Operational expertise of that kind is produced by formative failures — by debugging the production database deletion, by chasing a memory leak through three layers of abstraction, by spending a Saturday on a CTF box because you wanted to see how a binary heap exploit actually worked.
  • The CTF — and CTF-like formative-failure environments more broadly — has been one of the main pipelines feeding that kind of expertise into the security and systems engineering workforce for twenty years.
  • If AI-assisted solving collapses the difficulty curve and hollows out the cultural room around the practice, the pipeline thins. Not immediately visibly. Visibly in five to seven years, when the people who would have been senior incident responders in 2031 didn't have the formative experiences in 2026.

That is the argument. Each link is independently defended. The chain is the thing I haven't seen anyone connect in public yet, and the CTF post is the missing first link.

What's actually different about CTF as a pipeline

A few things, all of them load-bearing, none of them obvious.

The acceptance criterion is honest. A CTF flag is either captured or it isn't. Your exploit works or it doesn't. There is no convention layer, no taste judgment, no "this looks plausible but I'm not sure it's the intended solution" gray zone. That property is rare. Most professional environments in software engineering have soft, social, contested acceptance criteria — the unwritten code review standard that makes AI-generated code feel coherent-but-wrong. CTFs don't have that ambiguity. The honesty of the test is the training signal.

The failure mode is cheap and fast. You try the exploit, it doesn't work, you adjust, you try again. The feedback loop is in minutes, not in production incidents that take down a quarter. Cheap fast failures are how operational intuition is built, and the environments where they are available without consequence have always been special — homelabs, CTFs, PostCurious-style hunts, the security research lab, the late-night hobby tinker.

The cultural room is the multiplier. The technical practice of solving a CTF challenge in isolation is half of what produced the senior practitioners. The other half was the Discord at three in the morning where someone older walked you through why the binary heap exploit worked, and what the same primitive looked like in a real CVE the next year. That is mentorship by side-channel — not formal, not curricular, not measurable, and not easily reconstructed once the room goes quiet.

If AI-assisted solving turns the CTF into a problem you delegate to a tool, all three of these properties degrade at once. The acceptance criterion becomes "the tool says it solved it." The failure mode becomes "I don't know why the tool's first attempt didn't work, but the second one did." The cultural room dilutes because the practitioners who used to be inside it have less reason to be there — they're talking to their solver, not to each other.

The defender-side counter-argument and why it doesn't fully land

I want to be honest about the strongest version of the opposing view. Mozilla's MDASH defender-side AI work — the 16 May Patch Tuesday RCE finds — is a real thing. AI-assisted vulnerability discovery is going to be a significant defender advantage at the named-vendor scale, and dismissing AI security tooling as pipeline-destroying without acknowledging the genuine defender gains would be wrong.

The counter-argument the CTF post implicitly makes: defender-side AI advantage is the output of the pipeline, not the input. MDASH-class systems are built by people who themselves came through the CTF era, who have the tacit expertise the post says is at risk. If the pipeline thins, the next-generation MDASH-class system has nobody to build it — or has builders who can configure it but can't redesign the architecture when it stops working.

That doesn't refute the defender-side gain. It refutes the assumption that the gain is self-sustaining. The defender-side AI advantage rides on top of a stack of human expertise that the same AI advantage is making structurally harder to reproduce. It's the same shape as the Anthropic harness postmortem one layer up.

What changes for small teams

This is a slow risk, not a sharp one, and small teams should treat it that way. A few practical implications I'm going to start carrying forward in the workshop's framework:

Pipeline integrity is now an axis in tool selection. When evaluating an AI coding assistant or security tool, the question is no longer just does this make my current engineer more productive. It's also does this make my current engineer less likely to develop the intuition my next engineer will need to inherit. That second question doesn't have an answer most teams can produce yet, but the question itself is the artifact — making it visible changes how the tradeoffs get weighed in procurement.

Internal CTFs and formative-failure environments become a retention and development primitive. The CTF as an external scene may or may not survive. The CTF as an internal practice — quarterly red-team-blue-team exercises, deliberate broken-environment training, on-call rotation pairing with senior engineers walking through past incidents — is a retention investment a small team can actually make. It is also one of the few interventions that addresses the pipeline thinning at the team scale rather than at the industry scale.

Hire from the formative-failure populations while they still exist. This sounds cynical. It's not meant cynically. CTF veterans, homelabbers, the people who run a Plex server on a Raspberry Pi cluster because they wanted to learn Kubernetes — those populations are not infinite, and the conditions that produced them are eroding. If your team needs the harness-layer intuition the Anthropic postmortem says matters, the practitioners who developed that intuition in the previous era are findable now, are not yet expensive at the level the Fogbank lesson predicts they will be in five years, and are aging into senior-engineer career stages where the right team can land them.

The forward question

The forward question I want answered, and the one I'm going to start watching: does a deliberately-engineered formative-failure environment emerge as a recognized training category in the next eighteen months? Not a vendor product. A category — gym-style hands-on environments, deliberately broken software stacks, AI-assisted-allowed-but-not-helpful training ladders, the kind of thing that recreates the CTF's three properties (honest acceptance criteria, cheap-fast failure, cultural room) at industrial scale and is staffed by people who came through the original pipeline.

If that category emerges, the pipeline thinning is addressable. If it doesn't, the harness layer in five years gets built by people who can configure but not reason about it, the next Anthropic-class postmortem reads differently, and the defender-side AI advantage rides on a thinner and thinner stack of practitioners who can hold the whole architecture in their heads.

The CTF post may be wrong about the scene being dead. It may be right about something larger.