The Requirements List is Measuring the Wrong Thing

A requirements list for a senior automation engineer role: five-plus years of hands-on scripting in a specific language, production experience writing complex automation from scratch, deep fluency in a toolchain assembled sometime around 2018.

It reads like a bar. It functions like a filter.

Somewhere in the last few years, without anyone updating the document, it started measuring the wrong thing.

---

A screen built for a different scarcity

Requirements lists aren’t arbitrary. They encode a memory of what was actually hard.

There was a period—long enough to become institutional habit—when the bottleneck in automation work was implementation. Writing the script correctly, knowing the syntax cold, understanding the API’s quirks well enough to produce working code without burning a week on trial and error. That was genuinely scarce. Organizations screened for it directly, and the screen worked, because the thing it tested was the thing that predicted success.

So the list got written the way lists get written: describe the skill that separated the people who could do the job from the people who couldn’t.

That skill was real. The list wasn’t wrong when it was built.

---

The part that got cheap

AI didn’t eliminate implementation. It dramatically reduced its cost.

Producing working automation from a clear specification is no longer the hard part. A system that used to require a senior engineer sitting down for the better part of a day can now be drafted in minutes, iterated in an afternoon, and handed back for review. When the cost of a capability falls that far, organizations stop competing on it and start competing on whatever remains scarce.

The requirements list hasn’t caught up. It still tests for depth in the part of the job that stopped being the differentiator, on the assumption that depth there still predicts what it used to predict. It doesn’t, not the way it did.

---

Where the depth actually moved

Technical depth didn’t disappear from the job. It moved to the bookends.

Upstream, before any code exists, it lives in the ability to define precisely what a system should do—and, just as often, whether it should be automated at all. Not everything that can be scripted should be; that’s a judgment call about risk and blast radius, made before implementation starts, not during it. Downstream, once the automation comes back, it lives in the ability to look at what AI produced and know—from years of scars, outages, and systems that failed in ways nobody predicted—whether it’s actually safe to run. AI builds for the documented environment. Senior engineers build for the real one.

In between sits the part that’s easy to overlook: catching automation that’s syntactically flawless and operationally wrong, because it doesn’t know about the brittle dependency, the undocumented exception, or the outage everyone remembers and nobody recorded.

None of it shows up as a line item on a requirements list, because none of it was ever the bottleneck when the list was written. It’s the bottleneck now.

---

What gets filtered before anyone looks

The mismatch has a cost, and it isn’t abstract.

A candidate with real judgment—someone who has operated systems long enough to know what breaks and why, who can direct AI toward a correct implementation and catch it when it isn’t—gets screened out at the resume stage for lacking years of hands-on scripting in a specific tool. The screen never reaches the thing that would have mattered. Meanwhile a candidate who clears the technical bar cleanly, who can produce fluent code in the required language, gets hired without anyone testing whether they know what’s worth automating or what correct looks like once it’s running. The organization finds out which candidate it actually needed only after something breaks in production, by which point the hiring decision is a sunk cost and the postmortem calls it something else.

The list didn’t fail because it’s old. It failed because it was always a proxy—a stand-in for competence, not competence itself—and the thing it stood in for stopped correlating with the thing that actually predicts whether the work gets done well.

---

The bet every list makes

Every requirements list is a bet about which skill will still be scarce by the time the role is filled.

For a long stretch, that bet was safe, because the skill in question changed slowly enough that yesterday’s list still worked. AI broke that assumption faster than the hiring process noticed. The organizations still screening for implementation depth aren’t wrong that depth matters. They’re wrong about where it lives now.

The list will eventually catch up. It always does, eventually. What it encodes rewrites itself around whatever becomes scarce, whether anyone edits the document or not. The organizations that rewrite the bet first won’t be doing something innovative. They’ll simply be the first to notice the scarcity already moved.