When juniors leave, the library remains

Nobody on your team has run a token audit in nine months and you know exactly why. The person who used to do it left in the spring. The role that would have replaced them didn't get backfilled. "We're being more selective at junior right now," went the all-hands. The work hasn't gone anywhere. It's just on the shelf.

The AI-and-design-jobs conversation has settled into a comfortable shape: designers are being sorted, not replaced. Template-pixel-pushers in trouble; strategic, systems-thinking, AI-fluent designers in growth. Job postings up at the senior end. Lenny's job market write-up has the numbers; Figma's State of the Designer has the sentiment. None of that is wrong.

The story stops at the sorting. It doesn't follow what the sorted-out people used to do.

Junior designers seeded the system. Not the first version of the design system. That was usually a senior or staff designer with a vision. The maintenance, though. The hygiene work. The audit-and-clean-up cycles that happen monthly, the new-component intake that gets triaged, the deprecated-token cleanup nobody volunteers for, the documentation pass after a quarter of features have shipped past it. That work has lived on junior calendars for as long as I've been doing this. It pays a junior to learn the system from the inside out by maintaining it. It gives them craft repetitions on a real codebase. It produces leveling artifacts they can point to in their next review. And it keeps the system not-broken.

Take that role out of the org chart and the work doesn't follow it out the door. It lands somewhere else.

So, where does it land? Three places. First, on the senior or staff designer who is now also the maintainer of the thing they used to design. Their week's deep work shrinks by some number of hours because the deprecated-color migration has to happen by Thursday. Second, on the DesignOps person, who absorbs it because that's where unowned operational work goes by default and because they can write a script for half of it. Third, nowhere. The work doesn't get done, the system rots a little each quarter, and the rot becomes visible in design quality six to eighteen months later, by which point the cause and the effect are far enough apart that nobody connects them.

Pick the bucket. None of them are good. The first costs you senior-craft hours you're paying for at senior-craft rates. The second loads more onto a function that is already, by every count, the most over-extended in design. The third is the one nobody's seeing yet because the lag is too long. None of them solve the underlying issue, which is that someone has to keep the system honest, and the org chart no longer has a slot reserved for that someone.

The 2026 hiring data is mostly right. Senior-strategic roles are growing. AI-fluent designers are in demand. The economics are real. But "senior-only design org" is a structural choice, and structural choices have consequences the hiring spreadsheet doesn't see. The pipeline that produced the next senior was, partly, this maintenance work. Some of it was the very-junior labor of doing it; some of it was the staff-level mentorship of teaching it; all of it was a context where craft repetitions happened on real surfaces. Take it out and the seniors of 2030 come from somewhere else. From companies that still hire junior, fewer each cycle. Or from a labor market where the ramp got shorter and produced fewer people who can do the work seniors used to do.

This is the part that compounds. AI gets more efficient quarter over quarter. Human craft gets developed by doing the work, repeatedly, with feedback, on real surfaces. We are removing the work and the surfaces. The line on the AI side keeps going up; the line on the human side bends the other way, slowly, in the kind of way that's hard to see in a single-quarter scorecard. Six years from now we will be hiring "senior" titles for skill sets that have lost half a decade of compounding. And we will look at the comparison, AI capability versus human output at our cost basis, and the conclusion will write itself. Because we wrote it years ago, when we stopped funding the bench.

What I keep watching, lately, is which of my friends are absorbing the maintenance work onto their own plates without saying so. They are framing it as "I just couldn't get to the documentation updates this sprint," "the icon library is in a weird state right now," "we'll catch up on the audit when things slow down." Things will not slow down. The audit will not happen. The system will get a little stranger every quarter. And the next time we hire, we will hire senior, because that is what the data says, and because the slot for the person who used to do this work is no longer in the budget.

What helps is seeing the second-order cost clearly enough to keep it in front of you when the next staffing conversation happens. Not as a position paper. Not as a slide. Clearly enough that you can spot the moment it would have been priced in, and notice what you traded for the version where it wasn't.