Your Decades Are the Asset

Last week a post made the rounds. Someone wrote that they got dramatically better code out of an AI coding tool by lying to it. They told it they’d lose their job if the work wasn’t good enough. The output improved. The post framed it as a trick: manipulate the machine, unlock the quality it was holding back.

That’s not what happened.

The threat didn’t motivate anything. There’s nothing in there to motivate. What it did was narrow the task. “My job depends on this” is a crude specification. It changed what counted as done: not the first thing that runs, but something hardened enough to survive scrutiny. The output improved because the instruction finally carried a constraint it hadn’t carried before.

The trick didn’t manipulate the model. It accidentally set a guardrail.

And that is the whole game: the guardrail, not the threat. It also tells you who’s about to be very good at this, and it probably isn’t who you’d guess.

The skill was never the typing

Hand one of these tools a blind instruction like build me X, and you get something that runs and falls over the first time it meets a real edge case, a permission boundary, an input nobody planned for. You don’t fix that by asking more politely, or by asking harder. You fix it by setting guardrails: stating the non-negotiables up front, walking the intended outcome before a line gets written, and walking it again when it comes back wrong.

I’ve spent the last few months building real systems with these tools, and that discipline is the difference between something that demos well and something that holds up when it meets real conditions. The work has a name, and it isn’t coding. It’s the judgment to know what to ask for, where to push, when to push back, and the part most people skip: how to push back so the problem you caught doesn’t resurface three steps downstream. It’s recognizing the shape of a failure before it arrives, because you’ve watched it arrive before.

Here’s the part that should reorganize how you see your own position: that judgment is the most transferable thing you have, and most of the people who have it don’t write code.

Twenty-five years of the same job

I don’t write the code. I’ve spent thirty years in technology, and twenty-five of them doing one thing across every kind of software team: hold the outcome, set the constraints, and refuse the version that’s almost right. The tool is new. The job is not.

If you’ve spent a career as the generalist in the room, you’ve done this thousands of times. You’ve been the program manager, the analyst, the one translating between the engineers and the people who sign the checks. You sat between groups who each saw one face of the problem, and you held the whole shape. That is guardrail-setting. It is the exact skill these tools reward, and you spent decades building it.

The reflex says the opposite. It says these tools belong to engineers, and that if you haven’t written code in years, or ever, you’re watching from the outside. That reflex is wrong, and it’s wrong in an expensive direction. The scarce input here isn’t the ability to produce code; there’s a machine for that now. The scarce input is the judgment to constrain it.

So if the tooling intimidates you, get over it. Your background isn’t a liability you’re working around. In an organization standing up these tools, you’re the most valuable person in the building.

The window

We’ve been solving the same problems for decades: correctness, security, the systems that don’t quietly rot. The toolset is new; the problems are old. I’ve spent the last few months watching decades-old judgment do more for output quality than any prompt trick, and the work is shifting in a way that rewards exactly that: from building things to hardening the things that get built, which favors the people carrying the most scars.

The younger crowd will catch up. They’ll have to. A few years of shipping security holes and mismatched libraries and code that’s confidently wrong teaches the lessons the rest of us learned the slow way. They’ll learn them faster, because the feedback is faster. Call it five years before that edge closes.

Which makes the next two or three the opening. Not to learn to code. To set the guardrails, the way you already do, against a tool that finally executes as fast as you can decide.

The machine will write anything you ask it to. Knowing what to ask for, and what to refuse, is the job.