This has results for Postgres versions 12 through 18 with a CPU-bound Insert Benchmark on 24-core and 32-core servers. A report for MySQL on the same setup is here.

tl;dr

• good news
• there are small improvments
• with the exception of get_actual_variable range I don't see new CPU overheads in Postgres 18
• bad news
• there might be small regressions from new CPU overhead from get_actual_variable_range
• thanks to vacuum, there is much variance for insert rates on the l.i1 and l.i2 steps. For the l.i1 step there are also several large write-stalls.

 This has results for MySQL versions 5.6 through 9.5 with an IO-bound Insert Benchmark on 24-core and 32-core servers. The workload uses IO-bound workload. Results for a CPU-bound workload are here.

MySQL often has large performance regressions at low concurrency from new CPU overhead while showing large improvements at high concurrency from less mutex contention. The tests here use medium or high concurrency.

tl;dr

• good news
• there are few regressions after 8.0
• modern MySQL is mostly faster than MySQL 5.6.51
• bad news
• there are big regressions from 5.6 to 8.0
• results for modern MySQL would be much better if the CPU regressions were fixed
• other news
• Postgres 18.1 is mostly faster than MySQL 8.4.7 but Postgres write rates suffer from too much variance thanks to vacuum

The premise of this position paper is appealing. We know Brooks' Law: adding manpower to a late software project makes it later. That is, human engineering capacity grows sub-linearly with headcount due to communication overhead and ramp-up time. The authors propose that AI agents offer a loophole: "Scalable Agency". Unlike humans, agents do not need days/weeks to ramp up, they load context instantly. So, theoretically, you can spin up 1,000 agents to explore thousands of design hypotheses in parallel, compressing the Time to Integrate (TTI: duration required to implement/integrate new features/technologies into infrastructure systems) for complex infrastructure from months to days.

The paper calls this vision Self-Defining Systems (SDS), and suggests that thanks to Agentic AI future infrastructure will design, implement, and evolve itself. I began reading with great excitement, but by the final sections my excitement soured into skepticism. The bold claims of the introduction simply evaporated (especially about TTI), never to be substantiated or revisited. Worse, the paper left even the most basic concepts (e.g., "specification") vague. 

Still, the brief mention of Brooks' Law stayed with me. (The introduction glides past it far too casually.) Thinking it through, I came to conclude that we are not escaping the Mythical Man-Month anytime soon, not even with agents. The claim that "Scalable Agency" bypasses Brooks' Law is not supported by the evidence. Coordination complexity ($N^2$) is a mathematical law, not a sociological suggestion as some people take Brooks' Law to mean. Until we solve the coordination and verification bottlenecks, adding more agents to a system design problem will likely just result in a faster and more expensive way to generate merge conflicts. 

The "Scalable Agency" vs. The Reality

The core premise of "Scalable Agency" seems to rely on a flawed assumption, that software engineering is an embarrassingly parallel task. My intuition, and the paper's own results, suggests the opposite.

The case study in the paper tasked agents with building an LLM inference runtime. The agent-built monolithic-llm-runtime achieved 1.2k tokens/s, while a simple human-written baseline, nano-vLLM, achieved 1.76k tokens/s. The paper says that the agents successfully "rediscovered" standard techniques like CUDA graphs (I suspect this was already in training data for the LLMs), but they hit a hard ceiling. They could not propose "qualitatively new designs". They scaled volume, but not insight. This reminds me of the famous video of three professional soccer players against one hundred kids: You can add more bodies, but without shared intuition and expert judgment, numbers alone do not win real games.

The results get worse when we look at integration. When tasked with building allmos_v2 on top of an existing codebase (allmos), the agents took 35 days to produce a working system. The paper blames "deployment failures," "GLIBC mismatches," and "driver issues", but I suspect the true complexity came from the architecture itself. Allmos_v2 was not a monolith, but an integration on top of distributed pre-existing components. The agents were likely thrashing against the exponential complexity of a distributed dependency graph.

(As an aside: The paper claims the second system, monolithic-llm-runtime, took only 2 days because the agents reused a "key solutions playbook" generated during the allmos_v2 attempt. While the playbook surely helped, I suspect the monolithic architecture was the real hero here.)

This mirrors the classic Common Knowledge Problem in distributed systems: for a protocol to be robust, every node must know not just the fact (distributed knowledge), but that every other node knows it (common knowledge). Agentic systems face a similar epistemic gap. "Context loading" is not equivalent to "common knowledge". Agents may ingest 100,000 lines of code instantly, but reading tokens is not the same as understanding the causal chain of changes across the system. As architectures grow (especially non-monolithic ones) the compute required to simulate downstream effects of a line change explodes exponentially. An agent may "see" the entire codebase, but without common knowledge of how, for example, a batcher change propagates through kernel fusion, regressions appear. Multi-agent systems do not escape Brooks' Law, they simply hit the wall of state-space explosion faster than humans do.

The Shell Game

In the end Self-Defining Systems remains as a blue sky vision paper that fails to improve on concrete results compared to its predecessor, the ADRS paper ("Barbarians at the Gate"). ADRS admitted to being a tool for optimizing existing codebases, tuning parameters and heuristics within a defined sandbox. SDS promises to go further, claiming the ability to design systems from scratch, but in practice it largely replays the ADRS workflow with new terminology. SDS proposes a progression ranging from Phase 1: Self-Configuring to Phase 5: Self-Managing, but admits in the fine print that "Our current methodology retains goal setting, architecture decomposition, and evaluation design as human responsibilities..." This means that we haven't actually moved the needle on design at all. We are still just doing hyper-parameter tuning with AI as the intern.

This reminds me of the Shell Game podcast, where Evan Ratliff tried to build a startup using only AI agents. (You know what a shell game means, right?)  Evan sets out to build a real company, HurumoAI, staffed almost entirely by AI agents to test if a one-man unicorn was possible by managing AI employees in a startup environment. The experiment sounds futuristic until you learn how this unravels. Spoiler alert: even with the help of a Stanford technical co-founder, Evan eventually bails out and pivots to a joke/novelty business model: AI agents that procrastinate and browse brainrot so you don't have to. 

This has results for MySQL versions 5.6 through 9.5 with a CPU-bound Insert Benchmark on 24-core and 32-core servers. The workload uses a cached database so it is often CPU-bound but on some steps does much write IO. 

Results from a small server are here and note that MySQL often has large performance regressions at low concurrency from new CPU overhead while showing large improvements at high concurrency from less mutex contention. The tests here use medium or high concurrency while low concurrency was used on the small server.

tl;dr

• good news
• Modern MySQL has large improvements for write-heavy benchmark steps because it reduces mutex contention
• bad news
• Modern MySQL has large regressions for read-heavy benchmarks steps because it uses more CPU
• other news
• Postgres 18.1 was faster than MySQL 8.4.7 on all of the benchmark steps except l.i2 which is write-heavy and does random inserts+deletes. But Postgres also suffers the most from variance and stalls on the write-heavy benchmark steps.

The most conservative way to build a career as a software developer is 1) to be practical and effective at problem solving but 2) not to treat all existing code as a black box. 1 means that as a conservative developer you should generally use PostgreSQL or MySQL (or whatever existing database), Rails or .NET (or whatever existing framework), and adapt code from Stack Overflow or LLMs. 2 means that you're curious and work over time to better understand how web servers and databases and operating systems and the browser actually work so that you can make better decisions for your own problems as you adapt other people's code and ideas.

Coding via LLM is not fundamentally different from coding with Rails or coding by perusing Stack Overflow. It's faster and more direct but it's still potentially just a human mindlessly adapting existing code.

The people who were only willing to look at existing frameworks and libraries and applications as black boxes were already not the most competitive when it came to finding and retaining work. And on the other hand, the most technically interesting companies always wanted to hire developers who understood fundamentals because they're 1) operating at such a scale that the way the application is written matters or they're 2) building PostgreSQL or MySQL or Rails or .NET or Stack Overflow or LLMs, etc.

The march of software has always been to reduce the need for (ever larger sizes of) SMBs (and teams within non-SMBs) to hire developers to solve problems or increase productivity. LLMs are part of that march. That doesn't change that at some point companies (or teams) need to hire developers because the business or its customer base has become too complex or too large.

The jobs that were dependent on fundamentals of software aren't going to stop being dependent on fundamentals of software. And if more non-developers are using LLMs it's going to mean all the more stress on tools and applications and systems that rely on fundamentals of software.

All of this is to say that if you like doing software development, I don't think interesting software development jobs are going to go away. So keep learning and keep building compilers and databases and operating systems and keep looking for companies that have compiler and database and operating system products, or companies with other sorts of interesting problems where fundamentals matter due to their scale.

LLMs and your career pic.twitter.com/lxu1HLF2LC

— Phil Eaton (@eatonphil) January 19, 2026

Users looking at Oracle alternatives see the limitations of PostgreSQL in terms of high availability and ask:

Will MongoDB give me the same high availability (HA), disaster recovery (DR), and zero/near-zero data loss I’ve relied on in Oracle’s Maximum Availability Architecture (MAA)?

I previously compared Oracle Maximum Availability Architecture with YugabyteDB’s built-in high availability features here. I've done the same with MongoDB, which also offers built-in high availability though Raft-based replication to quorum, but for a document-model application rather than SQL.

Oracle MAA and MongoDB

Oracle DBAs are used to a mature, integrated stack—RAC, Data Guard, GoldenGate, Flashback, and RMAN—refined for decades to work together in the MAA framework. MongoDB instead takes a cloud-native, distributed approach, embedding replication, failover, and sharding directly in its core engine rather than through separate options. While the technologies differ—MongoDB uses pull-based logical replication instead of broadcasting physical log changes—they pursue the same goals.

MongoDB vs Oracle MAA Levels

Understanding Oracle MAA Levels

Oracle’s Maximum Availability Architecture (MAA) is organized into four tiers, each building on the previous:

1. 🥉 Bronze – Backup Only: RMAN online backups, archived log retention, manual restore. RPO in minutes to hours, RTO in hours or days.
2. 🥈 Silver – Bronze + High Availability: Add Real Application Clusters (RAC) for server-level HA and limited rolling upgrades. Very low RTO for server failures but no additional database protection beyond Bronze’s backups.
3. 🥇 Gold – Silver + Disaster Recovery: Add Data Guard (often Active Data Guard) for synchronous or asynchronous failover to remote standby. With FSFO (Fast Start Failover) in sync mode, RPO can be zero, RTO in minutes.
4. 💰 Platinum – Gold + Multi-Master: Add GoldenGate logical replication for active-active writes across sites and versions. Enables global presence but requires manual conflict handling and careful design.

In Oracle’s world, HA/DR is not one thing — it’s a stack of separate licensed products you combine according to your needs and budget. The complexity and cost rise quickly as you move up the tiers.

Focus on features rather than product names, which can be misleading. For example, Autonomous Data Guard (RPO > 0, no real-time query, no rolling upgrade) in the Autonomous Database managed service differs from Active Data Guard, which provides all features of MAA Gold, but is not part of the managed service.

How MongoDB Builds HA and DR Natively

MongoDB’s availability model takes a fundamentally different approach: it is a distributed database by design, with no single authoritative copy bottleneck like a monolithic RDBMS. Replication, failover, sharding, and multi-region deployment are built in, not optional add-ons.

Key components:

• Replica Sets – Every MongoDB production deployment runs as a replica set by default.
  • Automatic leader (primary) election in 5–30 seconds if a node fails.
  • Tunable write concern for RPO control (e.g., "w:majority" for RPO=0).
  • Flow control to throttle writes when majority committed replication lag reaches a threshold to prevent secondaries from falling too far behind
• Sharding – Horizontal partitioning with each shard itself being a replica set.
  • Supports scaling out writes and reads while maintaining HA per shard.
• Multi-Region Clusters – Place replica set members in multiple regions/zones for DR.
  • Writes propagate to remote members, optionally synchronously (Atlas global writes).
• Backups & Point-in-Time Restore – Atlas offers continuous cloud backups with PIT restore. Self-managed deployments use snapshots + Oplog replay.
• Automatic Failover & Driver-Level Continuity – Client drivers reconnect automatically. Retryable writes can resume after failover without application-level intervention.
• Rolling Upgrades Without Downtime – Upgrade nodes one at a time, keeping the cluster online.

This means that what takes three separate licensed Oracle products to achieve in Platinum is, with MongoDB, simply a topology decision you make when deploying the cluster.

Key Takeaways

• Oracle MAA levels are additive—Bronze, Silver, Gold, and Platinum. Each higher tier requires extra products and adds complexity for on‑premises deployments, and not all tiers are available in managed services. They are very mature for enterprises, but you should not underestimate the operational cost.
• MongoDB provides built-in HA and DR. Replication, failover, sharding, and multi-region deployments are topology settings that simplify operations. However, configuration still matters: consistency is tunable per application, and settings must align with your infrastructure’s capabilities.
• RPO and RTO targets achievable with Oracle Platinum are also achievable with MongoDB. The main difference is flashback capabilities, so you must tightly control production access and ensure all changes are automated and tested first in pre-production.
• MongoDB rolling upgrades eliminate downtime for routine maintenance—a major change from traditional monolithic upgrade windows. Avoid running outdated versions, as was common with legacy databases.
• Global write scenarios are possible in both, but MongoDB’s sharded architecture can automatically avoid conflicts (ACID properties over the cluster, causal consistency)

Three years ago, I wrote a post titled "Getting schooled by AI, colleges must evolve". I argued that as we entered the age of AI, the value of "knowing" was collapsing, and the value of "doing" was skyrocketing. (See Bloom's taxonomy.)

Today, that future has arrived. Entry-level hiring has stalled because AI agents absorb the small tasks where new graduates once learned the craft.

So how do we prepare students for this reality? Not only do I stand by my original advice, I am doubling down. Surviving this shift requires more than minor curriculum tweaks; it requires a different philosophy of education. I find two old ideas worth reviving: a systems design mindset that emphasizes holistic foundations, and alternative education philosophies of the 1960s that give students real agency and real responsibility.

Holistic Foundations

Three years ago, I begged departments: "Don't raise TensorFlow disk jockeys. Teach databases! Teach compilers! Teach system design!" This is even more critical today. Jim Waldo, in his seminal essay On System Design, warned us that we were teaching "programming" (the act of writing code) rather than "system design" (the art of structuring complexity).

AI may have solved the tedious parts of programming but it has not solved system design. To master system design, students must understand the layers both beneath and above what AI touches. Beneath the code layer lie compilers and formal methods. Compilers matter not so students can build languages, but so they understand cost models, optimization, and the real behavior of generated code. Formal methods matter not to turn everyone into a theorem prover, but to reason about safety, liveness, and failure using invariants. When an AI suggests a concurrent algorithm, students must be able to sense/red-flag the race conditions.

Above the code layer lies system design. As Waldo observed, the best architects are synthesizers. They glue components together without breaking reliability, a  skill that remains stubbornly human. System design lives in an open world of ambiguity, trade-offs, incentives, and failure modes that are never written down. This is why "mutts" with hybrid background often excel in system design. Liberal arts train you to reason about systems made of humans, incentives, and the big picture. Waldo's point rings true. Great system designers understand the environment/context first, then map that understanding into software.

Radical Agency 

My original post called for flipped classrooms and multi-year projects. These still assume a guided path. We may need to go further and embrace the philosophy of the "Summerhill" model, where the school adapts to the learner, rather than the learner fitting the school. In an age of abundant information, the scarce resource is judgment. Universities must stop micromanaging learning and start demanding ownership. The only metric that matters is learning to learn.

Replace tests with portfolios. Industry hires from portfolios, not from grades. Let students use AI freely, you cannot police it anyway. If a student claims they built a system, make them defend it in a rigorous, face-to-face oral exam using the Harkness method. Ask them to explain, how the system behaves under load, under failure, and at the corner cases. 

In 2023, I argued for collaboration and writing. In 2026, that is the whole game. Collaboration now beats individual brilliance. Writing is a core technical skill. A clear specification is fast becoming equivalent to correct code. Students who cannot write clearly cannot think clearly. 

I also argued for ownership-driven team projects. To make them real, universities must put skin in the game. Schools should create a small seed fund. The deal is simple: $20,000 for 1% equity in student-run startups. The goal is not financial return (which I think will materialize), but contact with reality. Students must incorporate, manage equity, run meetings, and make decisions with consequences.