The Programmer Competency Matrix, 2026 edition

The 2008 matrix said a level-1 programmer was a “VSS and beginning CVS/SVN user”. If you know what VSS is, you’re probably trying to forget. Rereading it, the rows that aged are the ones that named tools, and the rows that held up are the ones that described judgment. That turned into the rule for this update.

The other hard question wasn’t what had changed since 2008. It was whether a row like “source control” still means anything when an agent runs git for you. It does, but it isn’t the whole story anymore, so this update comes with a second matrix.

Programmer Competency Matrix, updated for 2026
AI Agent Competency Matrix, new
The 2008 original, kept as it was, so old links and citations still work

What held up

The scale. 2ⁿ, n², n, log(n) was a nerdy joke in 2008 and it still works: each level is a different order of magnitude of effectiveness, not a small step up. So does the idea that the levels are cumulative. You don’t get to be log(n) at databases without knowing what a transaction is.

Most of the rows survived with light edits. Data structures, algorithms, systems programming, problem decomposition, error handling, requirements: the people who were good at these in 2008 are still good at them, and it still shows up within ten minutes of an interview.

Communication held up best. In 2008 I wrote that it was underrated and that I’d seen projects fail because programmers couldn’t understand the intent of what they were told. Now so much of the job is written – pull requests, design docs, chat threads, and prompts to agents – that it matters more, not less.

What aged

Anything with a product name in it. VSS, CVS, VS.Net, “has written custom macros” for the IDE, Scott Hanselman’s power tools list, “has downloaded the alpha preview/CTP”. The book list mostly survived, though Designing Data-Intensive Applications and A Philosophy of Software Design earned a spot.

Some of it was just me in 2008: “has his own library” assumed every programmer was a he, and I said at the time that the matrix was biased against web developers. I’ve tried to fix both.

What’s new

The 2008 matrix had 32 skills. This one has 43. The new rows cover the things that were someone else’s job in 2008 and are now everyone’s:

Distributed systems. Every non-trivial app is one now, whether it admits it or not.
Test strategy, separate from writing tests: what not to test, and how to keep the suite fast enough that people trust it.
Security, from “trusts all input” to finding and exploiting bugs yourself.
Infrastructure and operations: cloud, infrastructure as code, observability and incident response.
Data and ML, including knowing when a heuristic beats a model.

There’s one row for working with AI coding agents. One row wasn’t enough, which is why there’s a second matrix.

Why a separate matrix for agents

Working well with coding agents is a real skill set, and it doesn’t map onto the old rows. People who are excellent programmers can still be bad at it, and the failure modes are new: 100-file PRs nobody can review, tests that only test the mocks, instruction files that have drifted from the code and now mislead the agent.

The AI matrix has 13 rows in five groups: directing the work, verifying it, making your setup compound over time, running agents as a system, and keeping your own skills. Tool names live in the notes under each row, never in the cells. I learned that one from VSS.

`log(n)` isn’t maximum autonomy

The easy way to build an agent matrix is to make level 3 “lets the agent do everything”. Most of the maturity models I read went that way, and I think it’s wrong. The person you want isn’t the one who delegates the most. It’s the one who can tell a throwaway script that should run unattended from an auth change that needs reading line by line, and can explain why.

So the top level of the autonomy row is calibration: picking the right amount for the task, and changing the codebase so more work becomes safe to delegate. Swarmia’s levels of autonomy make the same point: higher isn’t better.

There’s also a valley in the middle. Almost everyone goes through a honeymoon with these tools, and the next step isn’t using them more. It’s learning to distrust the output. The verification row rewards that.

What the data says

Less than the hype, and less than the skeptics would like.

METR’s 2025 study of experienced open-source developers found they were 19% slower with AI tools, while believing they’d been sped up. Their 2026 follow-up suggests things have improved, but METR calls its own data unreliable: developers who didn’t want to work without AI declined to take part.
A Harvard working paper on Jellyfish data (Chen & Stratton, not yet peer reviewed) found that adopting agents raised PRs by 23% but had no significant effect on completed issues. Review time per PR went up 49%. Generating code got cheap; reviewing it didn’t.
Anthropic’s skill-formation study found that junior engineers learning a new library with AI help scored lower on comprehension (50% vs 67%), with no significant speed gain. The ones who used the AI to ask questions rather than write the code did fine.

That last one is why the AI matrix has a row for keeping your own skills. Of everything in it, that’s the row I’d most want a junior to read.

Use it, argue with it

Same caveat as 2008: this is a rough guide, not a scoring rubric, and nobody is log(n) at everything. If a row is wrong or something important is missing, tell me. Last time it took eighteen years to come back to it; I’d like this one to keep up.