The AI Productivity Paradox — Part 1 of 3
AI made the first draft free. The thinking it used to force is now the part you have to choose on purpose.
A pull request comes in clean: readable code, an articulate description, a commit history that looks like a sequence of careful decisions. In review, someone asks one question. Why this approach and not the obvious alternative? And no one can answer it.
The work isn’t bad. It’s that no one actually made that decision. The model made it, and the engineer forwarded it.
What Actually Changed
I don’t think this is a story about people becoming lazy. That reading is easy, and it’s wrong. What changed is more specific, and more interesting.
Producing a first version of anything, whether a document, a plan, a function, or an analysis, used to cost something. And that cost quietly did work for us. You could not get words on the page without engaging with the problem at least enough to begin. The effort was never the point. The thinking it forced was.
AI unbundled that. The first version now arrives in seconds, fully formed, before any of that thinking has happened.
This produces a strange new condition. The artifact looks identical whether or not anyone reasoned about it. A well-considered draft and an unconsidered one are visually indistinguishable now. Same structure, same confident tone, same polish.
For most of working history, “it’s written down” carried an implicit signal: someone understood this well enough to produce it. That signal is gone. The output stopped being evidence of the reasoning, because the output stopped requiring the reasoning.
So teams generate more, and they feel faster, because by every visible measure they are. More pull requests, more documents, more tickets moved. The dashboards climb.
What the dashboards do not show is that a growing share of that output entered the workstream before anyone validated it, before anyone asked whether it was correct, complete, or even the right thing to build. That is false productivity. It is motion that looks like progress and is, underneath, just volume.
How It Settles Into a Team
I have watched this settle into teams that are, by any normal account, good teams. Someone accepts a model’s first answer. It might be a schema, an architecture, a requirements breakdown. They move it one step downstream, and the next person treats it as settled, because it arrived looking settled.
Then the gap shows up: a wrong assumption, a missed case, a misread requirement. By then the work is three or four steps into execution, and expensive to unwind. The cost did not come from the model being wrong. It came from no one being positioned to notice that it was.
The reviewer becomes the last line of defense, and reviewers were never built for this load. A reviewer can catch what they were asked to look for. They cannot reconstruct, from a clean diff, a line of reasoning that never happened.
When the only real thinking step left in a process is review, that process has quietly narrowed to a single point of failure: one person reading the most polished version of work they had no part in shaping.
There is a quieter version of the same pattern that never reaches review at all. A requirements document gets generated, read once, and approved because it reads as thorough. A design gets accepted because it is articulate. In each case the fluency of the artifact stands in for a judgment no one actually made. The team is not cutting corners; it is trusting a signal that used to be reliable and quietly stopped being one.
Meanwhile the volume keeps climbing, and volume is reassuring. It feels like the team is pulling ahead. But output produced this way does not remove work. It defers it.
The rework is still coming. It simply arrives later, detached from the burst of productivity that caused it, which makes it nearly impossible to trace back. Sprint after sprint, the team gets busier, busier untangling things that were started before they were understood.
It Is Not a Discipline Problem
Here is the part most of this conversation misses. The problem is not that people stopped thinking. It is that AI separated two things that used to be a single act.
Producing work and thinking about work used to happen together; you reasoned your way through the production because there was no other way through it. Now they are two separate steps, and the second one is optional. It happens only if something in the process deliberately asks for it.
None of this is the model’s fault. The model did exactly the thing it is good at. What broke is an assumption buried in how we work: that producing something and understanding it are the same event. They were, for a long time, close enough to treat as one. They are not anymore.
Which means this is not a discipline problem, and you will not solve it by telling people to be more careful. Careful people are skipping the step too, because nothing in the workflow asks them not to.
It is a structural problem. The place where validation used to live, inside the effort of producing the first version, no longer exists. If you want that thinking back, you have to rebuild it on purpose: as its own step, with its own moment and its own owner. It will not return on its own, because the thing that used to enforce it is exactly what AI removed.
What to Treat as a Signal Now
If you lead a team, the practical move is to change what you treat as a signal. Stop reading “it’s done” as “it’s been thought through.” Those are now two different claims, and only one of them is visible in the artifact.
The question worth asking is not whether your team is producing more. It almost certainly is. It is where, in your process, someone still has to demonstrate they understood the work rather than just generated it. If the honest answer is “in code review,” that is too late, and too thin. By the time work reaches review it has already accumulated decisions, and a reviewer can question a line of code far more easily than they can question the premise underneath it.
None of this is an argument against AI. The first draft being nearly free is a genuine gain, and a large one. But a gain you do not manage turns into a cost somewhere else.
The teams that will do well with AI are not the ones generating the most. They are the ones who decided, deliberately, where judgment has to happen, and made that step as fast and as unavoidable as generation has become. The time AI saves is real. The question is whether you reinvest it into the thinking AI stopped requiring, or just spend it producing more.
AI made the first draft free, and the thinking it used to force is now the part you have to choose on purpose.
The New Productivity Problem with AI: People Are Generating More and Thinking Less
The AI Productivity Paradox — Part 1 of 3
AI made the first draft free. The thinking it used to force is now the part you have to choose on purpose.
A pull request comes in clean: readable code, an articulate description, a commit history that looks like a sequence of careful decisions. In review, someone asks one question. Why this approach and not the obvious alternative? And no one can answer it.
The work isn’t bad. It’s that no one actually made that decision. The model made it, and the engineer forwarded it.
What Actually Changed
I don’t think this is a story about people becoming lazy. That reading is easy, and it’s wrong. What changed is more specific, and more interesting.
Producing a first version of anything, whether a document, a plan, a function, or an analysis, used to cost something. And that cost quietly did work for us. You could not get words on the page without engaging with the problem at least enough to begin. The effort was never the point. The thinking it forced was.
AI unbundled that. The first version now arrives in seconds, fully formed, before any of that thinking has happened.
This produces a strange new condition. The artifact looks identical whether or not anyone reasoned about it. A well-considered draft and an unconsidered one are visually indistinguishable now. Same structure, same confident tone, same polish.
For most of working history, “it’s written down” carried an implicit signal: someone understood this well enough to produce it. That signal is gone. The output stopped being evidence of the reasoning, because the output stopped requiring the reasoning.
So teams generate more, and they feel faster, because by every visible measure they are. More pull requests, more documents, more tickets moved. The dashboards climb.
What the dashboards do not show is that a growing share of that output entered the workstream before anyone validated it, before anyone asked whether it was correct, complete, or even the right thing to build. That is false productivity. It is motion that looks like progress and is, underneath, just volume.
How It Settles Into a Team
I have watched this settle into teams that are, by any normal account, good teams. Someone accepts a model’s first answer. It might be a schema, an architecture, a requirements breakdown. They move it one step downstream, and the next person treats it as settled, because it arrived looking settled.
Then the gap shows up: a wrong assumption, a missed case, a misread requirement. By then the work is three or four steps into execution, and expensive to unwind. The cost did not come from the model being wrong. It came from no one being positioned to notice that it was.
The reviewer becomes the last line of defense, and reviewers were never built for this load. A reviewer can catch what they were asked to look for. They cannot reconstruct, from a clean diff, a line of reasoning that never happened.
When the only real thinking step left in a process is review, that process has quietly narrowed to a single point of failure: one person reading the most polished version of work they had no part in shaping.
There is a quieter version of the same pattern that never reaches review at all. A requirements document gets generated, read once, and approved because it reads as thorough. A design gets accepted because it is articulate. In each case the fluency of the artifact stands in for a judgment no one actually made. The team is not cutting corners; it is trusting a signal that used to be reliable and quietly stopped being one.
Meanwhile the volume keeps climbing, and volume is reassuring. It feels like the team is pulling ahead. But output produced this way does not remove work. It defers it.
The rework is still coming. It simply arrives later, detached from the burst of productivity that caused it, which makes it nearly impossible to trace back. Sprint after sprint, the team gets busier, busier untangling things that were started before they were understood.
It Is Not a Discipline Problem
Here is the part most of this conversation misses. The problem is not that people stopped thinking. It is that AI separated two things that used to be a single act.
Producing work and thinking about work used to happen together; you reasoned your way through the production because there was no other way through it. Now they are two separate steps, and the second one is optional. It happens only if something in the process deliberately asks for it.
None of this is the model’s fault. The model did exactly the thing it is good at. What broke is an assumption buried in how we work: that producing something and understanding it are the same event. They were, for a long time, close enough to treat as one. They are not anymore.
Which means this is not a discipline problem, and you will not solve it by telling people to be more careful. Careful people are skipping the step too, because nothing in the workflow asks them not to.
It is a structural problem. The place where validation used to live, inside the effort of producing the first version, no longer exists. If you want that thinking back, you have to rebuild it on purpose: as its own step, with its own moment and its own owner. It will not return on its own, because the thing that used to enforce it is exactly what AI removed.
What to Treat as a Signal Now
If you lead a team, the practical move is to change what you treat as a signal. Stop reading “it’s done” as “it’s been thought through.” Those are now two different claims, and only one of them is visible in the artifact.
The question worth asking is not whether your team is producing more. It almost certainly is. It is where, in your process, someone still has to demonstrate they understood the work rather than just generated it. If the honest answer is “in code review,” that is too late, and too thin. By the time work reaches review it has already accumulated decisions, and a reviewer can question a line of code far more easily than they can question the premise underneath it.
None of this is an argument against AI. The first draft being nearly free is a genuine gain, and a large one. But a gain you do not manage turns into a cost somewhere else.
The teams that will do well with AI are not the ones generating the most. They are the ones who decided, deliberately, where judgment has to happen, and made that step as fast and as unavoidable as generation has become. The time AI saves is real. The question is whether you reinvest it into the thinking AI stopped requiring, or just spend it producing more.
AI made the first draft free, and the thinking it used to force is now the part you have to choose on purpose.
Get new insights when we publish them
Receba novos insights quando publicarmos