The Engineer

The one field that would have made the route invalid

Route Origin Validation checks exactly three things: the prefix, the ROA's maxLength, and the origin AS. That is the whole algorithm. If the covering ROA for 162.55.0.0/16 permits more-specifics through a loose maxLength, a forged-origin /24 carved out of that block is valid by construction. RFC 9319's minimal-ROA guidance is one line: set maxLength equal to the prefix length you actually announce. That one registry field would have made this announcement RPKI-invalid. It is a portal config change, not a protocol upgrade, and almost nobody audits it.

The propagation half is more boring still. Longest-prefix-match wins unconditionally on every network that accepts the route, so there is no AS-path length to compare and no local-pref to negotiate. AS6204 propagated a customer announcement its filters should have dropped. ASPA, the draft extension that would have flagged an implausible provider relationship, is barely deployed. BGPsec remains theoretical. An actor with an ASN and one willing transit provider is not a nation-state capability level.

What each control actually validated

One green row, and it sits at the application layer. That is the engineering lesson: every network-layer and PKI control in the chain authenticates a location, and the thing you actually care about is a byte sequence.

The absence of traffic was the alarm

Virtualizor cannot quantify impact. The hijacked requests terminated on attacker infrastructure and never reached the vendor, so its logs are empty by construction. Nobody was watching for the silence. A volume-drop alarm on update and download endpoints, plus a Certificate Transparency watch on domains you own, is the difference between 33 hours and minutes. Virtualizor is the control plane hosting companies use to manage customer VPS fleets, so the blast radius lands in other people's infrastructure.

TLS proves you reached the right IP. Only a signature proves you got the right bytes, and for 33 hours the right IP belonged to the attacker.

Three things being exploited in the same window

• JFrog Artifactory CVE-2026-82329, an auth bypass to admin, went from patch to in-the-wild exploitation in three days per WatchTowr. Patch first, then hunt: new admin tokens, permission changes, anomalous uploads over the last two weeks.
• Langflow CVE-2026-0768 is under active exploitation to lift OpenAI and AWS keys off AI orchestration hosts, with no patch available. The only moves are removing exposure and rotating every credential those hosts held.
• AWS root password spraying against 150+ organizations has been running since July 24 from a list of valid root email addresses.

Fail-closed signature verification has a bill attached, so budget for the operational cliff. A fail-closed client plus a botched key rotation is a fleet-wide outage. That is exactly where TUF's key-rotation and freeze-attack handling starts earning its complexity, above a certain fleet size.

Where the bend point actually lands

An A100 does roughly 312 TFLOPs of BF16 math and moves about 2 TB/s out of HBM. That is an ops:byte ratio near 156. Decode is a matrix-vector multiply against BF16 weights: 2 FLOPs per 2-byte weight per sequence, so arithmetic intensity is approximately the batch size. Decode stops being memory-bound near 150 concurrent sequences. Below that the tensor cores idle.

That bend is theoretical and it belongs to no real workload. KV-cache reads add memory traffic scaling with batch × context length, so long-context traffic hits the memory-capacity wall well before batch 150. Copying max_num_seqs from a blog post either leaves free throughput on the floor or buys a tail-latency regression. The defensible number comes from a sweep on the model, the GPU, and a replayed prompt-length distribution.

Three strategies, one axis

Static, dynamic and continuous batching differ on exactly one thing: when batch membership freezes. Static freezes before the run. Dynamic freezes on a timer or size limit. Continuous re-decides every forward pass. Dynamic batching shortens the wrong wait. It caps queue-entry latency and does nothing about the straggler. A request that finishes at t=7 still holds its slot until the slowest member of its batch exits at t=12. Only iteration-level scheduling drops the assumption that a batch runs to completion as a unit.

Every serious engine ships that primitive now, under different branding. vLLM, SGLang and TGI call it continuous batching. TensorRT-LLM calls it in-flight batching. LMDeploy calls it persistent batching. A deck claiming a scheduling advantage should be checked against the scheduler, not the label.

The preemption counter that gets misread as a capacity request

Under continuous batching, concurrency is capped by the KV-cache pool, and every active sequence's cache grows with each token generated. On a 40GB A100 with a 13B model resident, only a handful of long sequences fit at once. When the pool exhausts, the scheduler evicts a running request and recomputes its prefill later. On the dashboard this looks like a GPU out of headroom; it is the same prefill billed twice, with unpredictable latency degradation attached.

If preemption counters and KV-cache utilization aren't on the same panel as p99 latency, someone will file a GPU capacity request to fix a scheduler-tuning problem.

Chunked prefill trades TTFT for inter-token latency

Continuous batching created a new artifact. A joining 32K-token prompt is one compute-heavy pass that every active decode waits behind, so output pauses mid-sentence. Long context is a multi-tenancy fairness problem as much as a memory problem: one tenant's giant prompt taxes every co-tenant's inter-token latency. Chunked prefill splits that prompt across several passes, each extending the KV cache. The attention math is unchanged, because later chunks attend to what earlier chunks wrote. The first token simply arrives after the final chunk. Prefill is compute-bound and decode is memory-bound, so a batch containing both uses both halves of the chip.

• Smaller chunks give the scheduler more chances to interleave decodes, so fewer inter-token spikes, at the cost of GPU utilization and the attention overhead of re-reading earlier chunks' KV entries.
• Larger chunks make prefill more efficient and improve time-to-first-token, at the cost of longer gaps for in-flight requests.

vLLM V1 defaults to --max-num-batched-tokens 8192. SGLang exposes --chunked-prefill-size, with -1 to disable. Tune smaller for streaming chat, where inter-token latency is the metric. Tune larger for agent tool-call chains and batch summarization, which live on TTFT. The default is a compromise neither workload asked for. Keep the fixed-output tier — embeddings, classifiers, rerankers — on Triton with preferred_batch_size; those requests all finish at nearly the same step, so static and dynamic batching give up nothing there.

Stage boundaries are the engineering

Vercel runs three narrow agents on the AI SDK: one reproduces the bug, one applies the fix, one reviews the fix. Flue runs separate agents for research, design, implementation and initial review. Astro kept pull requests open and rebuilt intake around auto-triage. These pipelines work because each stage emits a machine-checkable artifact. The reproduce agent emits a failing test. Deterministic, cheap to validate, and it doubles as the acceptance criterion for the fix agent. The fix agent emits a diff that either turns that test green or doesn't. The review agent checks the diff against that criterion. The human owns one decision.

The model didn't get better; the failures just became detectable at each hop. Same reliability argument that justifies breaking a fat service into checkpointed steps.

Trust is a per-config score

Vercel's Grammel describes the authorization model plainly: trust accrues when "a very specific agent with a very specific prompt" has a history of success on "a certain category of bugs." That is empirical per-configuration trust, keyed on (agent config hash, prompt version, bug class). Nobody has published theirs. That absence is the whole gap between the blog post and a production system. The deployment shape is worth reading too: a UI, a web app, an API, an execution space and sandboxes, GitHub-synced, with a custom-built console. That is a symptom of Vercel's headcount, not a requirement of the pattern. GitHub Actions plus issue forms plus a webhook handler gets a v0 with zero net-new services.

The cheapest quality lever is a critic that can't see the code

A coding agent reviewing its own work sees its own code, its past decisions, and its rationale. That is context contamination, a process problem rather than a capability gap. The fix is a process boundary. Invoke the critic in a fresh context. Hand it only the rendered artifact. Withhold code and prior critiques. And keep the passing threshold out of the critic's own prompt so it cannot Goodhart the number that unblocks the pipeline. Ranking the artifact against four professional references beats asking "is this good?". Relative ranking has far lower run-to-run variance than absolute scoring.

Economics reported alongside the published pattern: the frontier critic consumed under 10% of output tokens while a cheaper model did implementation, against roughly 2x cost if the frontier model had done the work itself. Two caveats. A screenshot-fed critic is image-token heavy on input, so measure dollars, not token share. And the loop as specified has no termination guarantee: a badly calibrated critic never awards a pass, and the agent burns tokens trying to please it. That needs max_iterations, a per-run dollar ceiling, epsilon-convergence bail-out, and a dead-letter path to a human.

Where the sources disagree

Vercel reports a third of merged pull requests agent-authored. Reuters, working from scores of internal documents, reports Meta scrapped the aggressive phase of Project OT, drafted in January and exploring team cuts of up to 60%, because agents "wrote code but missed product results." Both can be true, and together they say code generation is decoupled from outcome delivery. A merged PR is only evidence that a diff landed. Track reopen-rate-within-30-days and production escape rate, not queue depth.

Code authoring got cheap. Verification is the bottleneck now, and the pipelines that work decompose until every stage emits an artifact a machine can check.

If you consume these packages

The upstream escalation path is closing too. Flue converts external pull requests to issues or discussions; tldraw auto-closes them, justified on contribution norms and "the changing landscape around code security." "Fork it, fix it, send a patch upstream to unblock us" is no longer a reliable play. Budget for two replacements: spec-quality issue writing as a real skill, since a well-specified issue is now the input format that produces code, and a maintained local patch workflow with a named rebase owner for anything on the critical path.