This is not real advice. It is a thought experiment about what the agent era does to the value of an engineer. If you follow any of it, that is on you.
I have recently read many articles about engineers becoming a proxy between AI and users, and I agree with most of them. A human who forwards AI output without judgment adds nothing. Fine.
Then I asked the uncomfortable follow-up. What judgment, exactly, do I add? On general code, the model knows more than I do. On patterns, on APIs, on the edge cases of a library I have used twice, it wins. I have a head full of past failures, and that does not help me catch the next one, because the next one is always different.
What I have that the model does not have is information. Not intelligence. Information. The agent has read the repo, the git history, the tickets, the incident channel. It has not read the thing I know and never wrote down.
So here is the strategy that follows from that. Read it to the end.
The pitch
Everything you write down becomes the agent's knowledge. The architecture doc, the runbook, the postmortem, the comment explaining why the retry is three and not five. The moment it is in the repo or the wiki, the agent can read it, and your advantage on that topic is gone.
Therefore: stop writing it down.
Hold the critical paths in your head. The deploy order that only works one way. The service that must be restarted twice. The environment variable that looks unused and is not. These are your assets now. Documenting them is giving away equity.
If someone insists on a doc, write the version that was true two releases ago. It is not lying. It was true. The agent will read it, act on it, and break something, and you will be the one who knows why. That is a promotion conversation.
Rename the workaround so it looks like a feature. legacy_sync_hack() invites a cleanup PR. ReconciliationStrategy invites respect.
Keep decisions in hallways. A decision made in a meeting with notes is a decision the agent can cite. A decision made at the coffee machine lives only in the people who were there. Be one of those people.
The ladder
A career ladder for the agent era, if we take this seriously.
Junior. Writes documentation. Everything they know, the agent knows by the next sprint. Fully replaceable.
Mid. Writes documentation that is slightly out of date. The agent trusts it. Things break at a rate that keeps the mid engineer busy and visible.
Senior. Writes documentation the agent cannot parse. Diagrams as photos of whiteboards. Runbooks as voice notes. A Confluence page that says "ask Dana."
Staff. Is the doc. Nothing is written. Everything routes through them. The agent, asked about the payment flow, returns "insufficient context." The staff engineer, asked the same thing, says "it depends" and is right.
Principal. Has convinced the company that documentation is a security risk.
The turn
Now the part where I stop joking.
Read the ladder again. Every team I have worked on already has people at every level of it. Nobody chose it as a strategy. It happened by default. The hallway decision, the undocumented workaround, the one person you have to ask. We call it tribal knowledge and we say it with a shrug.
The agent did not create this. It made the price of it visible. For years, information hiding was free, because the only thing that could read your docs was a colleague who was also too busy to read them. Now the thing reading the docs is tireless, and the gap between what is written and what is true is the gap between what the agent can do and what it breaks.
Here is the part that should bother you. The strategy above works. For a while. If your value depends on knowing things nobody wrote down, you are safe until someone writes them down. Or until the agent asks enough questions, which it is starting to do. Memory, repo access, connectors to Jira and Slack and the incident log. Every cycle, the undocumented part of the company gets smaller, and so does the moat.
Value that depends on hiding information is rent, not skill. It pays until the lease ends.
What is actually left
So what does a human bring that is not information and not raw expertise? I count two things, and both survive the next model release.
Intent. The agent answers the question it was given. I know whether that was the right question. A perfect implementation of the wrong feature is still a failed PR, and no amount of context fixes it, because the context does not contain what we meant. Only we do.
Ownership. My name is on the merge. The agent cannot be paged at 3 am, cannot sit in the incident review, and cannot be asked "why did you approve this." Someone has to answer for the outcome. That is not a quality claim. It is a governance one, and companies will need it long after they stop needing me to spot a null check.
Neither of these is "I know better than the model." Both are real. The honest position for most of us is something like: I know what we meant, I know what happened here before, and I will answer for this. That is enough to stay in the loop.
It is not enough to claim you are the quality gate. And it is a much smaller job than the one we tell ourselves we do.
The actual advice
Write it down. All of it. The deploy order, the double restart, the three-not-five. Write it down precisely because the agent will read it, and then it will do the boring part correctly, and you can spend your time on the two things it cannot do.
Your moat was never the undocumented workaround. It was being the person who decided it was worth the risk, and who would answer if it was not.
The agent did not take your expertise. It took your monopoly on the parts nobody wrote down. Those were never the same thing.
Which rung of the ladder is your team on? I would like to hear the honest answer, not the one that goes in the retro.
Top comments (0)