Andreessen Horowitz ran a chart this week that I haven’t stopped thinking about.
Using Revelio Labs data, it shows that since January 2025, tech job postings have been asking for more years of experience and listing fewer preferred skills. Both movements are in the range of 5-10%. Small. But they move together, and they’ve held for over a year and a half.
The roles driving it are data work, systems work, and Java.
a16z’s interpretation is worth quoting in spirit: when you’re working on a new frontier, the skills you need haven’t been defined yet. So the thing you hire for is the ability to figure it out as you go.
I want to take that seriously rather than treat it as a slogan, because from where I sit it describes something concrete.
Nobody knows what “good” looks like yet
Most of my work is quality assurance and software auditing, a lot of it with startups building on AI-generated code. That last part matters.
A skills list is a bet that the problem is stable. “Knows Cypress.” “Five years of Selenium.” “Comfortable with Postman.” Those are useful when the shape of the work is known and the question is whether you can operate the machinery.
The shape of the work is not currently known.
When a team is generating large volumes of code from prompts, the old assumptions break in ways that don’t show up in a job description. Code review stops being a bottleneck you optimise and becomes the entire game. Test coverage numbers start lying to you, because a model will write tests that pass against its own misunderstanding of the requirement. Consistency across a codebase goes up while coherence goes down: everything looks like it was written by the same competent stranger, and no one on the team can tell you why a particular decision was made.
There is no certification for that yet. There will be. It doesn’t exist today.
What experience actually buys
I’d argue “experience” is the wrong word for what employers are reaching for. What they want is calibrated judgement, and years are just the cheapest available proxy for it.
In practice it shows up as a handful of unglamorous instincts:
- Knowing what to worry about. A model can generate a thousand test cases. Deciding which twelve failures would actually cost the company money is a different act entirely, and it depends on understanding the business, not the framework.
- Reading a spec and noticing what isn’t in it. The most expensive defects I’ve found were never bugs. They were requirements that everyone had interpreted slightly differently, and the code faithfully implemented one of those interpretations.
- Being suspicious of things that look fine. AI-generated code has a particular quality: it is plausible. It reads well. It has sensible variable names and tidy structure. Plausible code that is subtly wrong is harder to catch than obviously bad code, and the only reliable defence I know is a reviewer who has been burned before.
- Knowing when to stop testing. Under-testing ships defects. Over-testing burns a runway that a startup doesn’t have. Getting that boundary right is close to pure judgement.
None of these are skills in the sense a job posting means. They’re the residue of having done the work and got it wrong a few times.
The audit angle, and why the clock matters
There’s a second chart in that same a16z piece that deserves attention from anyone in security or assurance.
The share of vulnerabilities exploited on or before the day of disclosure has climbed sharply, and the window between a vulnerability being found and being exploited has collapsed to about a day at the median. The exploit survival curve, which a few years ago still had half of exploits usable after six weeks, now runs to zero at around six weeks.
Put those two charts next to each other.
Code is being produced faster than ever, by tools that are confident and fast and not accountable. And the time you have to catch a problem before someone else finds it is shrinking towards nothing.
That is an argument for verification as a first-class function, not a stage at the end of the pipeline. It’s also an argument for people who can look at a system and form a fast, decent hypothesis about where it’s weakest, because there increasingly isn’t time for the thorough version.
The part that bothers me
If the market is pricing experience over skills, the door for junior engineers gets narrower. That’s already visible in entry-level hiring numbers, and it isn’t a good outcome for anyone, including the companies doing the hiring, who will want senior engineers in five years.
I don’t think the answer is more credentials. A certificate is a skills claim, and skills are precisely what the market has started discounting.
The answer, as far as I can tell, is reps. Specifically, reps of a certain kind: real systems, real consequences, and someone experienced looking over your shoulder afterwards to tell you what you missed.
Experience is usually measured in years because years are easy to count. What actually accumulates is decisions made under uncertainty, followed by feedback. A junior engineer who has shipped, broken something, diagnosed it, and been reviewed properly forty times has more of the useful thing than someone who has held a title for six years and been carefully insulated from consequence.
That gap is compressible. Not to zero. But a lot of what gets called “you only learn this on the job” is really “nobody has bothered to teach this deliberately.”
One caveat
The shift in the data is 5-10%. That is real but modest, and a16z is careful about not overclaiming, so I will be too. Some of the change is aging-in-place and remote work widening the candidate pool, not AI.
And the piece makes a point I think is right: this is probably temporary. Once implementation matures, new skills get named, tooling standardises, and the skills-to-experience ratio swings back. The teams that will be defining those skills are the ones doing the work now and paying attention to what actually goes wrong.
Which is, in the end, another argument for being in the room while it’s messy.
Original chart and analysis: a16z, Charts of the Week: Experience > Skills
Rafaela Azevedo 