We Became 40% Faster. We Also Became Worse Engineers.

There is a study making the rounds. Participants who used ChatGPT to write showed a significant drop in brain activity compared to those who wrote without AI assistance. That finding came from EEG recordings — actual brainwave data from people at work, not a survey. And 83% of those AI-assisted participants could not recall the key points from what they had just produced.

We noticed the same pattern on our team before we saw the research.

The productivity numbers were real

After we rolled out AI coding assistants, the metrics improved immediately. Code review cycles got shorter. Feature delivery picked up. Engineers spent less time on boilerplate, and more time on the parts of the work they said they actually enjoyed.

We were happy with the numbers. Then we ran into a production incident.

The incident

We had an issue in production. The on-call engineer had written the rate-limiting logic that failed — or rather, they had approved it when the AI wrote it. When we asked them to diagnose the issue under pressure, they opened the file and started reading it as if it were new to them.

Because it effectively was.

They understood that it rate-limited requests. They had not thought through what it did when the Redis connection dropped. The AI handled the implementation; the engineer handled the approval. Those are not the same thing.

What cognitive delegation actually means

When you let a tool do the reasoning, you do not retain the reasoning. This is not unique to AI — it is how any cognitive delegation works. We stopped developing spatial reasoning when we started using GPS for every journey. We get to the destination, but we cannot navigate without the device. When the technology fails, the capacity is underdeveloped.

With coding tools, the risk is not that engineers forget syntax. Syntax is fine to delegate. The risk is that they delegate the architectural intuition — the sense of how a system behaves under stress, where the seams are, what breaks first. That intuition comes from having written things wrong, seen them fail, and fixed them. If the AI writes it and it ships without incident, the failure mode never gets learned.

Ours was a background-job-intensive system. The engineers who had built the job queue by hand knew, instinctively, what happened to state under an unexpected shutdown. The engineers who had only approved AI-generated queue logic did not.

What we did about it

We kept the tools. We would not go back — the productivity gains are real, and we are competing with teams that also have them.

But we changed one thing in how we review code. AI-assisted PRs now require the engineer to defend the output, not just describe it. “What happens when this database call times out?” is a question every reviewer asks. The answer has to come from the engineer who submitted the PR, not from re-reading the code mid-conversation.

It takes longer. It forces engineers to internalize what they approved. Over time, it has started to rebuild the intuition the tooling was quietly eroding.

The real cost of AI that works too well

The danger is not AI that fails visibly. Failure is noticed and fixed. The danger is AI that succeeds well enough that no one looks closely. That is how you end up with a team that ships faster and understands less about what they are shipping.

Forty percent faster is a good number. Make sure it does not come at the cost of the intuition that your senior engineers would otherwise pass down.