This is not another hot take.

Over the last three months, across hundreds of comments and half a dozen long threads on DEV and Hacker News, working engineers have quietly arrived at a consensus that has nothing to do with the hype cycles or doomer takes you see on Twitter. No one is arguing that AI doesn't work. No one is arguing that it will replace all developers next quarter.

Everyone is arguing about the thing that actually matters: how do we live with this thing, right now, today, while still being good engineers.

The quiet consensus no one is blogging about

There are no radical positions here. No one is a pure luddite. No one is a pure accelerationist. Almost every working engineer using AI today holds exactly the same set of contradictory beliefs:

• AI makes me 30-40% faster at my job
• I would never let an AI output go to production without reading every line
• Most of the time AI saves me from work I hated doing anyway
• I am terrified that junior engineers will never learn the things I had to learn
• I have already caught silent failures that would have killed production
• I will never go back to working without it

This is the default position. This is where almost everyone lives. All the public debate is at the extremes. All the actual work is happening in this uncomfortable middle.

The principle of least AI

The single most useful framing that emerged from these threads is the Principle of Least AI, first laid out by Ingo Steinke. It is an extension of the old Principle of Least Power: use the least powerful tool that will reliably solve the problem.

AI is the most powerful, most expensive, least reliable tool you have available. It should be your last resort, not your first.

This pyramid is not a moral statement. It is a practical one. Every step lower on this pyramid is faster, cheaper, more reliable, and will teach you more. You only move up one level when the one below it has failed.

Almost every bad AI experience people report comes from skipping the bottom four layers and going straight to the top.

The silent failure mode no test catches

There is one failure mode of AI generated code that is discussed more than every other combined: functional but incorrect code.

This is not broken code. Broken code crashes. It throws errors. It fails tests. You find it.

Functional but incorrect code runs perfectly. It passes every unit test. It hits 97.2% test coverage. It will sit in production for six months quietly doing exactly the wrong thing, and every automated check you have will stay green the entire time.

Failure mode	Visibility	AI amplifies?	Standard guardrails work?
Syntax error	Immediate	No	Yes
Runtime crash	Fast	No	Yes
Performance regression	Slow	Sometimes	Partial
Functional but incorrect	Silent	Extremely	No

This is the trap. All of the guardrails we built over the last 50 years of software engineering are designed to catch the first three failure modes. None of them are designed to catch the last one.

AI does not make broken code more common. It makes silently wrong code dramatically more common.

What actually changed in 2026

Almost all of these conversations shifted permanently in the first half of 2026. That is when agents arrived.

If you are still pasting code from ChatGPT into your editor, you are not using AI the way heavy users are today. Modern coding agents do not answer questions. They accept tasks. They read your entire codebase. They run linters. They run tests. They iterate on errors. They come back hours later with a PR.

We got confirmation of this shift from the most unlikely source possible: OpenAI themselves.

By June 2026, 99.8% of all AI output tokens used inside OpenAI came from Codex agents. ChatGPT, the product that started the entire revolution, is now effectively deprecated for internal work at the company that built it.

No one announced this. No one put out a press release. It just happened. Everyone voted with their tokens.

Comprehension debt is the new technical debt

Everyone knows what technical debt is. We now have a new kind of debt that no one has a name for yet: comprehension debt.

You incur comprehension debt every time you merge code that you did not fully understand. It does not matter if that code was written by a junior engineer or an AI. The debt is the same.

The difference is that AI lets you incur comprehension debt at a rate that was never before possible. You can build an entire system in a week that you could not possibly explain to another human being.

This is the core insight behind the Thinking Engineer Toolkit. The problem is not that AI produces bad code. The problem is that AI removes exactly the friction that used to build understanding. All of that annoying, slow, tedious work of translating a requirement into code? That was not overhead. That was where you learned how the system worked.

The great unlearning

The single most repeated warning across every one of these threads is not about production outages. It is about junior engineers.

Right now we have an entire cohort of new developers who have never known work without AI. They have never spent three days debugging a memory leak. They have never had to read 200 pages of man pages to answer one question. They have never hit the point where every tool failed them and they had to think.

No one knows what happens when that cohort becomes senior engineers.

AWS CEO Adam Selipsky put it bluntly: replacing junior staff with AI is the dumbest thing I have ever heard. Junior engineers are not there to write code. They are there to learn how to make good judgements. There is no shortcut for that.

We are all hypocrites

Almost every person writing these warnings uses AI every single day.

Almost every person complaining about hallucinations has merged AI generated code this week.

Almost every person warning about comprehension debt is 30% more productive because of AI.

This is not a contradiction. This is the default state. No one has a clean position here. We are all building the plane while we are flying it. We are all making this up as we go. We all know this is dangerous. We all know we can not stop.

This is not a debate about productivity

All of the public debate talks about productivity. All of the private conversation talks about judgment.

AI will never replace the engineer who knows when the code is wrong. AI will never replace the engineer who knows that the requirement written in Jira is not actually what the business needs. AI will never replace the engineer who looks at a perfectly green test suite and says "this still feels wrong".

That is the work that is left. That is the work that will always be left.

You can use AI to do almost everything else. But if you outsource that judgment, you are not an engineer any more. You are a prompt operator.

What comes next

No one has the answers. No one has this figured out.

But there is one rule that almost every engineer agrees on right now:

Think first. Prompt later.

If you can not describe the solution before you open the AI, you should not open the AI.

If you can not explain the code after the AI gives it to you, you should not merge it.

That is the entire rulebook. Everything else is details.