A single prompt builds an application. A single prompt writes a report that reads like two weeks of work. And a single prompt drafts a proposal that would have taken a team a month. Execution is the trivial part now. What that broke was our best evidence for who was good at the work.
The portfolio was always a proxy
For a long time we evaluated people by their output. The resume listing accomplishments. The portfolio of work you could hand an employer or a client. The artifact itself. This worked because producing things was hard. If you could ship a clean, working result, it meant you had the skill, the intuition, and the judgment to get there, and the result was the proof. The worst forgery we had to worry about was plagiarism, or lifting someone else’s intellectual property.
Then execution became trivial, and the proxy stopped carrying signal.
The output stopped being evidence
AI makes the surface of a thing good by default: well-written, convincing, sharp. That is what the models are good at. So the quality of a finished artifact no longer tells you anything about what the human put into it.
This is the part that confuses people, because the artifacts look better than they ever have. They are better. The signal is gone anyway. A polished application and a polished report are no longer evidence of the person who produced them, because the part that used to require skill is now the part a model does in seconds.
What the human injects
The question flips. It is no longer “what did you produce.” It is “what did you inject.” What you inject is judgment.
Judgment is knowing when to say no, and recognizing that an approach is suboptimal before it hardens into a codebase or a proposal, and being the person who looks at a working result and says, no, implement it this other way. It means holding the mental model that owns the trust and the accountability for the thing that ships.
I keep reusing a line because it keeps being true: agents are good at doing the wrong thing correctly. Left to its own devices, working off its training data and its weights, a model lands on the right answer most of the time. But the right answer is not always the best answer. The answer a model defaults to is the most widely-referenced one in its training, which is rarely the one your specific case needs.
The part you cannot see
Here is what makes this skill hard to judge. Most of it never gets recorded.
The judgment shows up in the chat window. How many times did you reject a proposal the model made. How many times did it start implementing something and you stopped it to ask a question instead. How many times did you read a result that passed every test and still say, this is not how this should be built. That is the work. It is the difference between an agentic engineer and someone who is, to use the term that stuck, vibe coding.
I can make this concrete. In my own work I had six AI-built features that each passed their full test suite with zero failures. Green across the board. An independent review caught that not one of them actually worked once the data was saved and reloaded. The tests passed because they exercised in-memory copies and direct function calls, never the real path that persists state. The model had done the wrong thing correctly, six times in a row, and every green checkmark was confirming it. Trusting the checkmarks would have shipped six features that did nothing. The catch, not the first pass, was the work.
The pattern repeats every time. An independent review caught a model proposing a time-of-concentration value that was not anywhere in the source data. It looked plausible, and it passed a first read. A different feature passed its tests and a first review, and a deliberate live stress test still surfaced a path that data could have escaped through, one that both the tests and the review had missed. In every case the win was not a clean first try. It was that the wrong answer got caught before it cost anything. Catching it is the skill. Producing the first draft is not.
You do not have to be an expert in everything
I am not arguing that you need to be a domain expert in every area your work touches. The whole premise of AI uplift is that the model brings expertise you do not have. The asymmetry only holds if you bring the things the model cannot.
You have to know what right looks like, and the path to get there. And you have to know the limits of the model you handed the work to.
Model literacy is the strange part
That last one is the part most people skip, and it is the strangest. The model that is supposedly the smartest, the biggest, the one with the most parameters, routinely does worse on a real task than a weaker model, or an older version of the same model. Even inside a single model it flips. I have seen Opus 4.8 at its highest reasoning effort do worse on a task than the same model at a lower setting. This is not a one-off. It shows up across benchmarks, because at the end of the day this is language processing, whether the language is code or plain English, and “more” does not map cleanly to “better on your task.”
Knowing which model, at which setting, for which job is the same judgment as knowing when to say no to a working implementation. It is one muscle, and choosing between models is most of the practical work.
The use case decides the deployment
Which model is only the first question. The deployment follows from the use case, and the use case has to be asked about directly. Is this a sealed environment where the data cannot leave your servers? Is the workload high-volume inference, where the token bill becomes the deciding factor? Is it a regulated context where accuracy and adherence to a standard are what gets audited? Each one pushes you toward a different answer.
Hosted frontier models are more capable, and local models are not, whatever the marketing says. But local buys you things the hosted providers cannot sell you: security, control, traceability, and a cost curve that does not move with how much you run it. Making a local model do real work is genuine engineering. You build the tools, you right-size the model to the task, and you trade raw capability for sovereignty over the process. The use case is what tells you which side of that trade to land on.
Continuity is its own problem
There is a separate problem that has nothing to do with picking the right model and everything to do with the fact that the model will not hold still. Frontier models from OpenAI and Anthropic ship major updates on a monthly cadence. The new version is generally more capable, and it can still be worse at the exact task you built your workflow around. Even when it is not worse, it tends to break something: the prompts, the tools, the way the pieces were wired together.
When the model “improves,” your use of it changes. Output that used to be near-perfect can degrade, because a stronger model is now fighting tools that were built for the older one. Vercel wrote about pulling 80% of the tools out of their internal agent and watching it get 3.5x faster and more accurate. Their stated lesson was that good context and clean structure beat a wall of tools. My read is blunter: a lot of those tools were right for the model they were written against, and that model moved on. Continuity is maintenance, and most teams do not budget for it.
The harness is not neutral
The medium you reach the model through changes what it can do. Claude or ChatGPT in a browser has different constraints than the same model on the command line or in a desktop app. Open-source harnesses like OpenCode or Pi make their own trade-offs again. Two engineers pointing the same model at the same task through different harnesses are not doing the same job, and the harness is usually the invisible part of why one got a better result than the other.
Understanding that is part of the literacy: the model, the deployment, and the harness are three separate variables, and most people only look at the first one.
The skill the market cannot see yet
Agentic workflow engineering is a real skill. Right now it is an unclear one. The market is still trying to evaluate people the old way, by the artifact, and the artifact has stopped being evidence. The skill lives in the rejections and the course corrections, and most of those never leave the chat session.
This is why I build the way I do. A sealed workshop where the agent can do real work without being pointed at anything that matters. Checks that run in the real workflow, not the model’s own tests. A rule that every reported number traces to a source document, a published table, or a federal data feed, and never to a model’s guess. None of that is about generating output. It is about making the judgment visible, and catching the confident wrong answer before it reaches a drawing.
If you are hiring or buying and trying to tell who actually has this skill, stop looking at the portfolio. Ask what they rejected.