You're paid to decide
Stop predicting AI. Start deciding what it should point at.
Nobody knows whether AI is about to eat half of software engineering, transform it, or merely make the existing work stranger. The confident people are mostly guessing. Sometimes with very convincing charts.
The far-horizon argument is seductive because it keeps you out of the immediate one. You can debate singularity timelines, labour displacement, whether models “really” reason, whether the work is still craft, whether the whole thing is a bubble. Some of that matters. Most of it does not help you on Monday.
The useful question is closer:
What is your value as an engineer when the machine can produce more of the artefact?
My answer is simple: you’re paid to decide.
Not just to type code. Not just to review diffs. Not just to be pro-AI or anti-AI. You’re paid to decide what good means here, what risk is worth taking, what boundaries need to hold, and what you are willing to own when the system reaches production.
AI changes engineering work. It does not remove judgment from it.
You set the target
LLMs are useful once they are pointed at something.
They can generate, search, summarise, refactor, compare, and surprise you. But the target still matters. In domains with clean check functions, like chess, tests, theorem proving, or benchmarked tasks, the system can search aggressively because success is legible.
In domains like product judgment, system design, research taste, engineering tradeoffs, and “what is worth doing here,” the target is not given by the domain. It comes from context, preference, responsibility, and taste.
That is the work.
This is why attempts to train AI taste are interesting but not decisive. A 2026 paper, AI Can Learn Scientific Taste, trains models against large-scale signals from scientific communities. That is useful. It may even be very useful. But the signal still comes from past human preference: citations, rankings, approvals, reviews, the residue of what a community already rewarded.
That can help predict what has been valued.
It does not fully replace the act of deciding what should be valued next.
This matters because AI tends to pull work toward the mean. When everyone asks similar models for similar help, the outputs start to rhyme. Sourati and colleagues make this argument directly in The homogenizing effect of large language models on human expression and thought: the more our expression and reasoning are mediated by the same systems, the more standardised they become.
Your variance gets more valuable in that world, not less.
The sharp requirement. The unpopular constraint. The strange analogy. The thing the organisation keeps avoiding because it is awkward to say out loud. The instinct that says “this is correct but wrong for us.”
That is not decoration around the work.
That is part of the work.
You manage risk both ways
A lot of engineers are trained to think of risk management as saying no.
That is only half the job.
Good risk management also means knowing which risks are worth taking. It means separating one-way doors from reversible bets. It means knowing when to fight, when to let the experiment run, and when to make the cost of a bad decision visible instead of silently absorbing it.
This matters more during the AI cycle because visible caution is easily misread as obstruction. The people pushing hardest often do not distinguish between caution about the tool and caution about misuse of the tool. Both get filed under “anti-AI” and routed around.
So the better posture is visible fluency plus visible judgment.
Use the tools. Show that you can move quickly with them. Then be precise about where the danger is.
Do not say no to everything. Say no to the decisions that calcify:
architectural commitments nobody understands
security boundaries nobody has verified
staffing decisions disguised as productivity gains
generated code nobody is willing to own
workflows that create verification debt faster than the organisation can pay it down
On the rest, run the experiment.
The engineer who refuses everything becomes easy to ignore. The engineer who can move quickly, explain the risk, and choose the right hill to die on is much harder to route around.
You own the boundary
The unit of engineering is changing.
Before AI, the unit was often the function, service, repo, or system. You wrote it, deployed it, and owned its behaviour.
With agents, the unit is increasingly the runtime cell: the model, the tools it can reach, the state it can mutate, the prompts and examples that shape it, the checks around it, and the human who remains accountable for the result.
That means engineering shifts toward boundary design.
What can the agent touch?
What must it never touch?
What evidence does it need before acting?
Where is the human checkpoint?
What would make you comfortable owning the incident report?
Vercel’s Agent responsibly post has the right litmus test: would you be comfortable owning a production incident tied to this pull request?
That question cuts through the fog.
If you understand and own the output, you are leveraging the agent. If you are hoping the review pipeline catches what you did not understand, you are relying on it. Those are different postures.
The best framing I have seen is Chad Fowler’s: probabilistic inside, deterministic at the edges. Let the model be flexible where flexibility is useful. Make the contracts, tests, permissions, audit trails, and rollback paths boring where boring matters.
That is not less engineering.
It is engineering moved to the boundary.
You need the squishy skills too
The uncomfortable part is that this is not only technical.
AI is compressing org charts, thinning management layers, and putting individual contributors closer to product, risk, cost, and power. The engineer who can only reason about the code is easier to misprice. The engineer who can reason about the system, the incentives, the business tradeoff, and the decision process is harder to replace.
This does not mean becoming political in the worst sense.
It means learning how to keep judgment in the room.
Speak the organisation’s language when you need to. If the room wants efficiency, show how your approach creates sustainable throughput. If the room wants speed, explain where speed is real and where it is borrowed from future verification. If the room wants AI adoption, demonstrate adoption while making the ownership model explicit.
The point is not to win the discourse.
The point is to stay close enough to the work that your judgment still affects the outcome.
This is where the “AI will flatten the org chart” story gets dangerous. Some flattening will happen. Some roles will disappear. Some work will be automated. But replacing judgment with generation is not a strategy. It is a bet. Sometimes a good one. Sometimes a very expensive one with a delayed invoice.
The cost usually shows up later, in the places nobody wanted to measure: verification, repair, security, coordination, trust, and the slow loss of system shape.
Someone has to notice that.
Someone has to make it legible.
Keep moving
None of this is permanent advice.
The line will move. The models will improve. The patterns will change. The work may not settle into “engineers supervise agents that write code.” That may be too small a frame. The team, the role boundaries, and the idea of a single canonical human-agent workflow may all get rewritten.
Fine.
The answer is not to defend the old shape of the job forever. The answer is to keep reading the work as it changes.
Use AI visibly.
Own the output.
Be specific about risk.
Design the boundaries.
Keep your taste sharp.
Share what you are learning with people you trust.
Move when the line moves.
Nobody has this figured out. The expert, for now, is the person running honest experiments and reporting back without pretending the map is finished.
The fight is not with the tool. The fight is not even with the hype cycle; that one you mostly navigate. The fight worth having is with your own assumptions.
Keep them loose.
You’re paid to decide.
Keep doing it visibly, keep doing it well, and keep watching what the work becomes next.