what happened#

A regulatory clock started running. The Cyber Resilience Act's reporting obligations took effect on 11 September: 24 hours to report an actively exploited vulnerability in a product sold into the EU. The engineering consequence is not paperwork — it is that "can you tell you are being exploited, and who is authorised to file at 2 a.m.?" became a question with a legal deadline attached.

The cadences held. Go shipped in August, Postgres in the autumn as always, Java in September. None of it was surprising, which is the entire value. The piece worth re-reading is the one about what a fixed release train actually buys — predictability is a feature, and most projects that ship "when it's ready" are paying for its absence without noticing.

Nothing dramatic happened in AI, which is itself worth noting after two years where something did every quarter. The interesting work moved to where it usually does after a hype phase: the unglamorous business of making things reliable.

the quarter's actual subject#

Reading the last three months back, the theme was not any technology. It was the parts of the job that have no announcement: timeouts nobody added up, queues nobody named, dependencies nobody drew, comments that earn their place, what "done" means, and the migration that stopped at 70%.

That is not an accident of scheduling. Those are the things that determine whether a system is pleasant or miserable to operate, and they get written about far less than whatever shipped last week — because there is no launch to hang the piece on.

If there is a through-line for the quarter it is this: most of what makes software good is decided in places nobody is watching. The timeout defaults. The permissions nobody audited. The queue with no bound. The interface designed in thirty seconds that a hundred people will use for a decade.

five worth re-reading#

• "Timeouts: every one of them" (10 Sept) — the inventory, and the rule that they must decrease with depth.
• "The graph nobody drew" (14 Sept) — your real dependency list is about fifteen things, and the ones that hurt are the ones needed to start.
• "The queues you did not know you had" (1 Sept) — every fixed-size resource is a queue with a latency you did not choose.
• "The migration that never finished" (21 Sept) — name the deletion, not the migration.
• "The load-bearing comment" (4 Aug) — the four kinds that survive, and why the rest rot.

what I am watching for Q4#

• Whether the CRA reporting regime produces anything visible, or whether the first year is quiet while everyone works out the process.
• Windows 10's consumer support ending in October, and what happens to the machines that cannot move.
• Python and Node's October releases, and whether free-threading adoption has moved past the numerical libraries.
• Whether anyone ships a genuinely better interface for reviewing machine-generated code. Still the bottleneck. Still nobody's product.

Back on Friday.

what it did to my engineering#

It forced me to actually understand things. You can hold a fuzzy model of a technology in your head indefinitely and it feels like knowledge. The moment you try to explain it in a paragraph, the fuzziness becomes visible.

I have abandoned drafts because I discovered, four hundred words in, that I did not understand the thing well enough to write about it. Every one of those was more educational than the pieces I finished.

It made me check things. Writing "X is faster than Y" in public means someone will ask for numbers. Knowing that in advance changes how you form the belief in the first place.

It made me notice my own patterns. Reading two hundred pieces of my own writing back, the recurring themes are obvious to me now and were invisible while writing: verification over generation, boring over clever, measurement over intuition, and a persistent suspicion of anything that requires you to trust rather than check.

I did not set out with a thesis. It assembled itself.

It taught me to be wrong in public, which is a skill and is uncomfortable and is the only way to find out you were wrong quickly.

what I have been most wrong about#

I graded myself in December and the pattern held for the following eight months.

I am reliably right about technical trajectories and reliably wrong about adoption.

Local models got good; people did not switch, because hosted models got cheap faster than I expected. RAG got less necessary; the infrastructure repositioned instead of dying, which I have now failed to predict three separate times. Registry security controls were obviously needed; they arrived after the incident rather than before.

The lesson I keep relearning: the technology is the easy part to forecast, and the technology was never the hard part. Human and organizational behavior is where the uncertainty lives and where the consequences land.

I under-predict inertia and over-predict rationality. Almost every wrong call has that shape.

the thing about writing news#

Two hundred pieces, roughly half of them about things that happened in a specific week.

Reading them back, the ones that held up are almost never the ones that reported the event. They are the ones that used the event to explain a mechanism.

Nobody needs my summary of what a company announced. They can read the announcement. What is worth writing is: why does this shape of thing keep happening, and what does it imply for what you should do on Monday.

The news is a prompt. The mechanism is the article.

I did not know that when I started and it took about forty pieces to figure out.

on the archive#

Everything published here is still at its original URL. Nothing has been quietly edited, renamed, or removed. Corrections are marked in place.

That is a deliberate choice and it costs something — there are pieces I would write differently now, and a few I think are wrong.

Leaving them up is the point. A publication that silently revises its history is not a record, it is a marketing surface. The value of an archive is that it shows what someone thought at the time, including when that was wrong, and you can only get that by not touching it.

If you want to know whether to trust a technical writer, check whether their old pieces still exist and whether the wrong ones were corrected in the open.

on the format#

Gray background. Monospace headings. One column. No popups, no cookie banner, no newsletter modal, no autoplaying anything, no third-party JavaScript on any page.

This is not minimalism as an aesthetic. It is that every one of those things was added to a website to serve the publisher at the reader's expense, and the cumulative effect has made reading on the web genuinely unpleasant.

A page should render before you notice it loading. Text is the interface. Nothing moves unless the reader moved it.

Those are not hard constraints to meet. Almost nobody meets them, and the reason is never technical.

the next two hundred#

Same beat. Tech, developers, and the code underneath. News where the news teaches something, essays where the news does not.

More on the verification problem, because it is the defining engineering question of this period and it is nowhere near resolved. More on the craft, because the craft is what survives the tooling cycles. Fewer pieces about model launches, because they have stopped being informative.

Thanks for reading. Corrections are always welcome and get priority over everything else.

— Dom

what stuck#

Mechanical refactors at scale. The clearest win, by a wide margin. Renaming a concept across four hundred files, migrating a deprecated API, converting a pattern used everywhere. Verifiable, tedious, and exactly what the tools are good at.

The important second-order effect: refactors that were too expensive to do now happen. A codebase where cross-cutting cleanup is affordable is a meaningfully better codebase, and that is a permanent improvement rather than a productivity number.

Working in unfamiliar territory. A language you do not know, a framework you have not used, an API you have never touched. The median output in an unfamiliar domain is better than your first attempt, and reading it teaches you the idioms.

This is the use case I would defend most strongly and it is discussed least.

Test generation from a specification. Not "write tests for this function" — that produces tests that assert the implementation. But "here is the behavior, write tests that verify it" works well and it inverts the effort in the right direction.

Investigation. Reading logs, bisecting history, tracing a call path, summarizing a large diff. Parallelizable, cheap, and it saves the expensive resource, which is your attention.

Repository-level instruction files. AGENTS.md and its equivalents became standard practice, and the discipline of writing down how your project actually works improved documentation for humans as a side effect.

what did not stick#

Fully autonomous feature development. The demo works. The real version produces a plausible implementation of a subtly different feature, because the requirements that live in someone's head were never written down.

Agent fleets at high concurrency. The generation scales; the review does not. Two to three concurrent agents with one reviewer turned out to be the practical limit, and the constraint is entirely on the human side.

Orchestration frameworks. Absorbed into the models, as function-calling libraries and JSON-repair libraries were before them. The durable layer was never orchestration.

"Just describe it and it builds." For anything with design decisions, the description that is precise enough to produce the right result is approximately as long as the code, and writing it is the same work.

what actually changed about the job#

Review is the bottleneck, permanently. Generation got roughly two orders of magnitude cheaper. Verification got no cheaper at all. Everything downstream follows from that asymmetry and nothing in two years has changed it.

Tests became the primary artifact. If the implementation is cheap and verification is expensive, effort moves to specification. The teams getting the most out of these tools are the ones with strong test suites, and the correlation is not subtle.

Type systems got a promotion. Every constraint the compiler checks is verification you do not perform by reading. Teams that were ambivalent about strict typing became evangelists, and the reason is always the same: it catches the class of error generated code produces most.

Small diffs became non-negotiable. A machine can produce two thousand lines effortlessly. Accepting it is not a favor to anyone.

The skill that separates people is judgment, not speed. It always was. It is now the only thing, and the gap between engineers who can tell when output is wrong and engineers who cannot is much more visible than it was.

the thing still unresolved#

The apprenticeship problem.

The judgment that makes a senior engineer valuable was acquired by writing a lot of code badly and then debugging it. That work is being automated. Nobody has a replacement for how the next generation acquires it, and junior hiring contracted sharply during exactly the period when the training mechanism was being removed.

I have written about this several times and I still do not have an answer beyond: deliberately do the hard part yourself sometimes, review generated code carefully as a learning exercise, and hire juniors anyway.

That is a partial answer to a structural problem and I am not satisfied with it.

the honest summary, two years in#

These tools are genuinely useful and the useful envelope is narrower and more specific than either the enthusiasts or the skeptics claimed.

They are excellent at bounded, verifiable, tedious work. They are unreliable at anything requiring judgment about what should be built. They multiply output and do not multiply throughput, because throughput is limited by review.

The engineers getting the most from them are the ones who were already good at specifying problems precisely and at telling when something is wrong. That is not a new skill and it was never evenly distributed.

Which is roughly what every previous tooling revolution did: raised the floor, moved the bottleneck, and made expertise more valuable rather than less.

the three things that actually happened#

Regulation became an engineering concern. The EU AI Act's high-risk obligations arrive in August; the Cyber Resilience Act's reporting obligations in September; post-quantum migration guidance firmed up across national agencies. For the first time in a while, compliance is showing up on engineering roadmaps rather than only in legal reviews.

Power stayed the binding constraint on compute. Interconnection queues, transformer lead times, and utility rate cases determine how fast capacity arrives. Every roadmap presented this year is downstream of a construction schedule.

The verification bottleneck did not move. Generation capability kept improving. Review capacity did not. The tooling investment continued to go into producing more code rather than into checking it, which is the wrong end of the problem and which I predicted would correct by now. It has not.

the thing I keep coming back to#

Generation got roughly two orders of magnitude cheaper. Verification got no cheaper at all.

Everything else — the review queue, the junior hiring contraction, the sudden importance of tests and type systems, the unease people cannot name about agent-written code — is a consequence of that asymmetry, and six months of watching it has not changed my read.

The skill that matters is the ability to look at plausible output and tell whether it is right. That skill is built by doing the work, and the work is being automated.

Nobody has solved this. Most of the discussion still treats it as either a non-problem or an apocalypse, and it is neither. It is an engineering and training problem with no established answer yet.

pieces I would re-read#

• "Verification is the whole job now" (8 Jan) — the argument, stated once, properly.
• "Prompt injection is SQL injection without the fix" (9 Feb) — why the analogy everyone makes stops before the part that matters.
• "Schema design is the only design that lasts" (6 Mar) — the thing you will still be living with in 2036.
• "Agent fleets in production" (27 Mar) — the honest numbers, which are much lower than the demos.
• "Idempotency is the only distributed systems concept you need" (26 May) — if you internalize one thing.

the grades so far#

In January I made five predictions. Three months in I graded one as wrong. At the halfway point:

Review tooling as a major funded category — still not happening at the scale I predicted. Funding continues to flow to generation. I was wrong about the market, and possibly wrong about the timing rather than the direction.

Repository-level agent configuration as standard practice — correct, and it happened faster than I expected. This is now table stakes for a well-maintained repository.

Power as a developer-visible line item — correct and accelerating. Regional compute price differentials are now large enough to affect architecture.

Supply chain controls with real teeth — in progress. The registry-level changes are landing and the migration is as painful as expected.

"Senior engineer" redefining around judgment — correct, uncomfortable, and nobody has a good answer for how the next generation acquires it.

what I am watching for the second half#

• The August AI Act deadline: holds, slips, or gets phased.
• Whether anyone ships a genuinely better code review interface.
• Whether the small-model tier keeps compressing the frontier's addressable workload.
• Whether junior hiring recovers, and what happens to the pipeline if it does not.

Back on Monday.

what happened#

Regulation got specific. The EU AI Act's high-risk obligations move from abstract to dated — 2 August. Post-quantum migration guidance firmed up across national agencies. The Cyber Resilience Act's reporting obligations approach. For the first time in a while, compliance work is a real line item on engineering roadmaps rather than a legal department concern.

Power stayed the constraint. Datacenter interconnection queues, transformer lead times, and utility rate cases continue to determine how fast compute capacity arrives. Nothing at GTC changed that; the roadmaps are downstream of the grid.

Agent tooling consolidated on conventions. Repository-level instruction files became standard practice. The delegated-agent product shape stabilized across vendors. The bottleneck stayed where it was: review.

The web platform quietly finished a decade of work. Container queries, :has(), popover, anchor positioning, view transitions — all baseline. The amount of JavaScript that can now be deleted from a typical application is larger than most teams realize.

the three pieces I would re-read#

"Verification is the whole job now" (8 January) — the argument that generation got two orders of magnitude cheaper and verification got no cheaper at all, and that everything else follows from that.

"Prompt injection is SQL injection without the fix" (9 February) — why the analogy everyone makes stops exactly before the part that matters, and what architecture actually holds.

"Schema design is the only design that lasts" (6 March) — your code gets rewritten, your schema does not.

the thing I got wrong#

In January I predicted review tooling would become a major funded category this year. Three months in, the funding is going to agent generation rather than agent review, which is the opposite of where the bottleneck is.

Either I am wrong about the bottleneck or the market is slower than I expected. Given that every practitioner I talk to names review as their constraint, I think it is the second, and I think it corrects.

what I am watching for Q2#

• Whether the August AI Act deadline holds or slips.
• Whether npm's publishing controls actually land and what breaks.
• Whether anyone ships a genuinely better code review interface.
• Node 26 and whether the no-build-step workflow becomes the default.
• Whether the small-model tier keeps compressing the frontier's addressable workload.

Back to normal programming on Wednesday.

Here are five changes to how software actually gets made. I will grade these in December.

1. Review tooling becomes a real product category#

The bottleneck moved to verification in 2025 and the tooling did not follow. We are still reviewing machine-generated changes with an interface designed in 2008 for occasional human contributions.

What has to exist: review surfaces that show intent rather than only diff. Which invariants does this change preserve? What did the author consider and reject? Which tests exercise the changed path, and did any of them exist before this change?

Some of that can be generated. Most of it is a UI problem nobody has solved because the pain only became acute in the last eighteen months.

Watch for this to be one of the most-funded developer tooling categories of the year.

2. Repository-level agent configuration becomes standard practice#

AGENTS.md, CLAUDE.md, .cursorrules, and their cousins converged on the same idea in 2025: the repository tells the agent how to work in it. Build commands, test commands, conventions, things not to touch.

In 2026 this stops being an optional nicety and becomes part of the definition of a well-maintained repository, the way a README and a CI config are. New projects will have one from the start. Onboarding docs and agent instructions will merge, because they are the same document with a different reader.

The second-order effect is good: writing down how your project actually works helps humans too, and a lot of teams will document things properly for the first time because a machine needed it.

3. Power becomes a line item developers think about#

Not in an abstract climate sense. In a "which region, which instance type, what does this cost" sense.

Electricity prices in datacenter-dense regions rose through 2025 and the rate cases are ongoing. Cloud pricing follows. Regional price differentials for compute are going to become large enough that they affect architecture decisions, the way egress pricing already does.

Expect "run the batch job in the cheap region overnight" to go from a sustainability talking point to a cost-optimization default.

4. The supply chain gets a real control, not another dashboard#

Four significant npm incidents in 2025, ending with a self-propagating worm. The registry-level controls — mandatory trusted publishing, restrictions on long-lived tokens, install-script defaults — are coming, and they will break workflows.

That breakage is the point. The ecosystem has been asking maintainers to be individually unphishable for a decade, and it has not worked, because it cannot.

Expect a painful migration and a meaningfully safer ecosystem at the end of it.

5. "Senior engineer" quietly redefines around judgment#

The mechanical parts of the job — writing the code, remembering the API, finding the bug in a file you can see — got substantially cheaper. What did not get cheaper: knowing what to build, knowing when something is wrong, knowing which complexity is worth it, and being able to say no with a reason.

This has always been what seniority meant. It is now what it only means, and the gap between people who have it and people who were fast typists is going to become uncomfortable to talk about at promotion committees.

The related problem, which nobody has solved: the traditional path to developing that judgment was doing the mechanical work for several years. If juniors do not do that work, where does the judgment come from?

I do not know. It is the most important open question in the profession right now and almost all the discussion of it is either dismissive or catastrophizing.

what I am not predicting#

Anything about AGI. Anything about a specific model beating a specific benchmark. Anything about a company's valuation.

Those get all the attention and none of them change what you do on Tuesday.

the year in one paragraph#

An open reasoning model under an MIT license repriced the sector in January. Reasoning became a runtime dial rather than a model choice. Coding agents went from research preview to standard tooling in about six months and made code review the bottleneck. The npm ecosystem got a self-propagating worm. Two of the largest infrastructure providers had multi-hour outages caused by config, not code. Python removed the GIL, optionally. Rust shipped its largest edition. The frontier models converged and the competition moved to price and distribution.

the three things that will still matter in 2030#

1. Reasoning as a controllable runtime parameter.

The most durable technical idea of the year. Every provider independently arrived at the same design: the caller decides how much the model thinks, per request.

This is durable because it reflects something true about the problem — the appropriate amount of computation is a property of the task, not the model, and only the caller knows the task. Interfaces that reflect true structure survive. Interfaces that reflect an implementation detail do not.

2. The agent-review bottleneck.

Generation throughput increased dramatically. Verification throughput did not. That gap is the central engineering problem of the next several years, and nobody has a good answer.

Everything downstream follows from it: how teams are structured, what tests are for, what "code review" means, whether we build systems we understand or systems that pass tests. This is not a tooling problem that gets solved with a better diff viewer. It is a fundamental asymmetry between producing and checking, and it shows up in every field where automation outpaced verification.

3. Supply chain trust has no technical fix yet.

Four significant npm incidents this year, escalating in sophistication, ending with a worm. Every one exploited the same structural fact: install-time code execution plus long-lived publishing credentials plus a dependency graph nobody designed.

The controls that work — trusted publishing, no install scripts, version cooldowns, phishing-resistant auth — are known and unevenly adopted. The ecosystems that are structurally safer got that way by design decisions made years ago that cannot be retrofitted cheaply.

This gets worse before it gets better, and it is a solvable problem that we are choosing not to solve at the speed it requires.

the things that felt big and were not#

Model benchmark leapfrogging. Every launch claimed the frontier. The differences were within evaluation noise for most real tasks. The benchmark discourse consumed enormous attention and predicted very little about what was useful.

Agent frameworks. Most of the orchestration layer got absorbed into the models, exactly as function-calling libraries and JSON-repair libraries were absorbed before. The durable layer was never orchestration.

The browser wars, round two. Everyone shipped a Chromium fork with a model in it. That does not diversify the engine landscape; it diversifies the UI on top of one engine.

the things that felt small and were not#

LLD as the default linker in Rust. A default change delivered a build-time improvement to everyone at once that documentation had failed to deliver for years. The general lesson — defaults are the highest-leverage thing a toolchain ships — applies far beyond Rust.

Template strings in Python. A one-character syntax change that makes the safe path as easy as the unsafe one. If library adoption follows, an entire category of injection vulnerability becomes hard to write. Security features that depend on diligence fail; security features enforced by the type system work.

Context editing and memory tools. Unglamorous plumbing that determines whether long agent runs succeed. The context window was never the constraint. Goal retention was.

the thing I want to say going into next year#

The most valuable skill in 2025 was not prompting, and it will not be in 2026 either.

It was the ability to tell whether something is correct. That skill was always valuable and it was previously bundled with the ability to produce the thing. The bundle has come apart. Producing is cheap now. Checking is not, and checking is what everything rests on.

Every argument this year about what AI does to engineering eventually reduces to that. The people who are getting enormous leverage out of these tools are, without exception, the people who can tell when the output is wrong.

That is not a comforting conclusion for anyone hoping the tools eliminate the need for expertise. It is the actual state of things, and it is worth building your career around.

See you in January.

1. "Local models become the default for routine developer work"#

Written in January. Partially right, wrong on scale.

Local models got much better and much easier to run. The tooling is excellent. A 14B model on a laptop is genuinely useful for the work I said it would be useful for.

What I got wrong: adoption. The default did not become hybrid. It became "frontier API for everything," because the frontier models got cheap enough fast enough that the cost argument for local largely evaporated for individuals.

The privacy argument held and drove real adoption in regulated industries, which is what I said. The convenience argument lost, which I underweighted.

Grade: C+. The technology went where I said. The behavior did not.

2. "The moat is distribution and serving efficiency, not model quality"#

Written in February. This held up well.

Model capability converged. Every frontier lab shipped comparable models. The differentiation moved to price, latency, integration, and distribution — exactly as predicted, and faster than I expected.

Google putting a frontier model into Search on launch day is the clearest demonstration. No competitor can do that.

Grade: A−.

3. "Delegated agents make review the bottleneck"#

Written in May. Correct and I understated it.

This is now the dominant complaint from every team using coding agents seriously. Throughput on generation went up several fold. Throughput on review did not move.

What I did not anticipate: the second-order effect on review quality. It is not just that review is slower — it is that reviewers under queue pressure approve things they have not fully understood, and the defect rate is showing up in ways that are hard to attribute.

Grade: A, with the caveat that I was not pessimistic enough.

4. "RAG infrastructure is solving a temporary problem"#

Written in March. Too confident, partially wrong.

Long context did get better and cheaper, and a lot of naive RAG did get replaced by just putting the documents in the prompt. That part was right.

What I got wrong: retrieval did not go away, it moved. The interesting systems now do retrieval as a tool the model calls rather than as a preprocessing step. The vector database did not die; it became something the agent queries.

That is a substantially different outcome than "the category is temporary," and I should have seen it because the same pattern — capability absorbed into the model, infrastructure repositioned rather than eliminated — had already happened twice.

Grade: C.

5. "Nvidia's roadmap slide is the real announcement"#

Written in March. Right, and the power framing was the useful part.

Power as the binding constraint became the consensus view over the year. The unit of AI infrastructure discussion is now gigawatts. Utility rate cases about datacenter interconnection are a live political issue in multiple states.

Grade: A.

6. "The npm ecosystem will have a self-propagating worm"#

Written in February, in a piece about supply chain risk. I hate being right about this one.

It arrived in September. The mechanism was exactly the one everybody had described: steal credentials on install, use them to publish, repeat.

The prediction was not clever. Every precondition was public. What I got wrong was the timeline — I expected it to take longer, because I assumed the registry would ship stronger publishing controls first. It did not, until after.

Grade: A on the call, F on the assumption that anyone would act in time.

the pattern in my errors#

Looking at the three I got wrong, they share a shape: I was right about the technology and wrong about the behavior.

Local models got good; people did not switch. RAG got less necessary; the infrastructure adapted instead of dying. Registry controls were obviously needed; they arrived after the incident rather than before.

The lesson I am taking into next year: technical trajectories are much more predictable than adoption, and adoption is where the money and the consequences are. When I feel confident, it is usually because I am reasoning about the technology, and the technology was never the hard part.

Here is the year, and what it means for the next one.

the releases that mattered#

DeepSeek R1 (January). MIT license, published training methodology, distilled variants that ran on consumer hardware. The RL-on-verifiable-rewards recipe was reproduced widely within weeks.

Qwen3 (April). Eight models, Apache 2.0, MoE variants with excellent quality-per-active-parameter, 119 languages.

Kimi K2 (July). A trillion parameters, open weights, tuned for agentic tool use, with a genuinely novel training stability contribution.

gpt-oss (August). OpenAI's first open weights since 2019, Apache 2.0, with a 20B variant that runs on a laptop.

Plus continuous releases from Mistral, Zhipu, MiniMax, Meta, Microsoft, Google, and a long tail of fine-tunes.

where the gap actually is#

The frontier-to-open gap held at roughly six to twelve months all year. That stability is the most important finding, because it means open weights are not converging on the frontier and are not falling behind — they are trailing at a fixed distance.

But "six months behind" undersells the practical position, because the gap is not uniform:

Nearly closed: code completion, summarization, extraction, classification, translation, structured output, straightforward tool use. For these, a good open model is not meaningfully worse than a frontier model, and it costs a fraction.

Meaningfully behind: long-horizon agentic work, complex multi-step reasoning, instruction following over many turns, reliability at the tail. This is where frontier models earn their price.

Not comparable: anything requiring the surrounding infrastructure — enterprise support, uptime guarantees, safety tooling, indemnification. Open weights give you the model and nothing else.

what changed structurally#

Licensing got genuinely permissive. Two years ago "open" meant a research license with a prohibited-use list. Now the frontier of open releases is Apache 2.0 and MIT. That is a real change and it removed the legal review that was blocking adoption.

The runtime story got boring. Ollama, llama.cpp, vLLM, MLX, LM Studio. One command. An OpenAI-compatible endpoint. The friction that kept open models in the enthusiast category is gone.

Hosting became competitive. Multiple providers serve open models at prices well below frontier API rates, with real SLAs. You can use open weights without running anything.

The center of gravity moved east. The most capable, most permissively licensed open releases came predominantly from Chinese labs. That is a strategic fact with policy consequences that are being worked out loudly and mostly unproductively.

the practical architecture for next year#

The shape that makes sense:

• Open weights, self-hosted or on a cheap provider, for high-volume, well-defined tasks. Classification, extraction, embedding, first-pass drafting.
• Frontier API for the hard tail: planning, complex reasoning, anything customer-facing where a bad answer is expensive.
• A router deciding between them, with the escalation rate instrumented.
• Your own eval set in your own repository, run against every candidate.

That is not a hedge. It is what the cost and capability curves actually imply.

the prediction#

The gap holds at roughly six to twelve months through next year. Open weights absorb an increasing share of production workload by volume while frontier models keep the high-value tail.

The interesting question is not capability. It is whether the labs currently releasing weights continue to, and that is a business decision that could change in either direction with one quarter's strategy review.

Download the ones you care about. They cannot be un-released.

The response was enormous. It is worth asking what stuck.

what actually improved#

Software bills of materials went from nothing to standard. SPDX and CycloneDX are real formats with real tooling. Most large vendors produce them. US federal procurement requires them. That is a genuine change and it happened fast by industry standards.

Dependency scanning is now default. GitHub, GitLab, and every major CI platform ship it. Most organizations have some visibility into their transitive dependency tree, which very few had in 2021.

Response times improved measurably. Organizations that took weeks to identify affected systems in 2021 now take hours. That is the single most valuable change, because time-to-inventory is the binding constraint in any of these events.

Funding for critical open source increased. Not enough. More than before. Several foundations and corporate programs exist that did not.

what did not improve#

Alert volume made everything worse. A typical application now generates hundreds of dependency alerts. The overwhelming majority are irrelevant — the vulnerable code path is not reachable, the component is not exposed, the "vulnerability" is a denial of service in a build-time tool.

Teams triage this by ignoring it. That is a rational response to a firehose of noise, and it means the one alert that matters gets ignored with the rest.

VEX — Vulnerability Exploitability eXchange — exists to solve exactly this, by letting a vendor state "we ship this component and we are not affected, here is why." Adoption is thin. Producing accurate VEX statements requires knowing your own code deeply, which is expensive, and there is no market pressure forcing it.

Reachability analysis is still not standard. The question that matters is not "do you include this library" but "does your code call the vulnerable function along a path an attacker can trigger." Tools that answer this exist and are not widely deployed.

Maintainer funding is still broken. Log4j was maintained by a handful of volunteers. Four years later, the number of critical projects with one underfunded maintainer is not meaningfully lower.

what I would actually do#

If your organization did the post-Log4Shell work and now has a dashboard nobody reads:

1. Rank by reachability, not by CVSS. A critical CVE in code you never call is lower priority than a medium in your request path. If your tooling cannot tell you which is which, that is the tooling gap to close.

2. Know what is internet-facing. The inventory question that matters is not "what do we depend on" but "what do we depend on in a service an attacker can reach." That is a much shorter list and it is the one to keep current.

3. Practice the drill. Once a quarter, pick a random dependency and answer: where do we use it, which versions, which services, how fast can we patch. If that takes more than an hour, that is your actual finding.

4. Fund something. Pick the three open source projects your business most depends on and send money or engineering time. This is more effective per dollar than most security spending and almost nobody does it.

the honest assessment#

We got much better at inventory and barely better at prioritization. We can now tell you every vulnerable component in your stack within an hour and we still cannot tell you which three matter.

The next Log4Shell will be found faster and patched faster. It will also arrive in an environment with ten times the alert volume, and the teams that have been trained by four years of noise to ignore alerts will ignore it a little longer than they should.

That is progress with a catch, which is the usual kind.