A rejection email, a resigned engineer, and a founder's warning about "AI psychosis" landed within weeks of each other. They describe the same shift, and it has nothing to do with whether AI writes good code.

Over the past few months, a cluster of posts on Dev.to and Hacker News circled the same observation from different angles. One engineer wrote about cognitive atrophy: the Prompt > Accept > Repeat loop with no review step, and how small skipped reviews accumulate until you can't code without AI. Another wrote about losing flow state with agentic coding: more output, less connection to the work. A third got rejected from a job for admitting he used AI, then watched the interviewer do the same thing. A fourth described the quiet weight of a field where the floor keeps rising and nobody announces the new number. A fifth rebuilt a college project for production and learned that "it works" and "I understand it" are different sentences.

Key Numbers

• 30 days: one engineer let AI write 100% of his code and shipped a real product. The part that made it shippable was the moments he said no to a plausible diff.
• 80%: the HMR time cut on a rebuilt MERN app, which still shipped a production bug. The bug lived in an assumption about document.hidden, not in the code.
• 500+ to top 10: that rebuild's placement in a GitHub finishing challenge, with the author still insisting the real lesson was the bug.
• 40, 96, 98: comments on three of the posts. This is not a fringe take. It's a conversation people are having alone, in public.

A pattern across recent developer posts

The threads connecting these posts matter more than any single argument. Each writer starts from a different point, and each arrives at a version of the same claim: AI shifted the engineering work from writing code to judging code, and the industry hasn't adjusted what it values, measures, or tests.

Hashimoto's post frames it at the organizational level. He lived through the MTBF vs MTTR argument during the cloud transition, and he sees the same shape now. Systems can appear healthy by local metrics while globally becoming incomprehensible. Bug reports can go down while latent risk explodes. Test coverage can rise while semantic understanding falls. The machinery looks fine until it doesn't.

The individual posts describe the same decay from the inside.

The cognitive atrophy loop

The first post frames it as a workflow problem. Most engineers now instinctively ask AI what to do before forming their own answer. The loop is prompt, accept, repeat, with no review step. Each cycle feels small. "It's just a small change." Stretched over months, the small changes accumulate into a skill you no longer have.

I recognize the loop from my own terminal history. Prompt, accept, move on. The review step was the first thing I cut when I got busy, and it was exactly the wrong thing to cut.

The dangerous part is that the wrongness hides in assumptions nobody examined. Commenters on that post described the same failure. One useful habit came up repeatedly: predict the failure modes before you prompt, then compare the model's output against your predictions. That keeps your mental model of the system in the loop even when you're not typing the code.

The other lesson from that thread: read the real diff. One commenter routed git through a CLI proxy that reported two files as identical when they weren't. Only re-running /usr/bin/diff exposed the change. The review step was the thing he'd stopped skipping, and it caught a tool lying about its own work.

Flow state and the attention tax

Brad Traversy's post looks at what changes when an agent takes over the work. Manual coding runs a tight loop: think, write, run, observe, adjust. Each result gives you something to respond to. The next decision stays close to the last one. With an agent, you write a prompt and wait. Then you check email. Then project B finishes. Then you rebuild enough context to judge what project A did.

The table below captures the difference I experience with each workflow.

Dimension	Traditional loop	Agentic loop
Feedback timing	Immediate, result-driven	Delayed, notification-driven
What you review	Your own decisions, made minutes ago	The agent's decisions, made without you
Context retention	Built incrementally, stays in your head	Reconstructed after every handoff
Failure mode	Slow and visible, you own it	Clean-looking, hidden assumptions you didn't choose
Satisfaction source	Solving the problem	Watching output accumulate

The comment on that post that stuck with me: the re-entry cost tracks the number of decisions made without you, not the size of the diff. Three small diffs you didn't reason about still cost three context reloads. The real unit of a handoff is a decision. Task size matters less than how many decisions got made while you weren't part of them.

I've felt the fragmented attention thing directly. Running three agents on three projects meant I was never fully settled into any of them. The work moved, but I spent my hours remembering where I left off, not thinking. Traversy's fix is simple: keep each task small enough to review, stay with the project while the agent works, and review the result while the original reasoning is still fresh.

Quick Take: The real skill in an AI-assisted workflow is the review pass, and most people are skipping it.

The interview double standard

The interview post is the sharpest one in the cluster. The author was rejected for "reliance on AI tools" during a live coding round, after announcing out loud that he'd let the assistant scaffold boilerplate so he could focus on edge cases. Forty minutes earlier, he claims, the interviewer's eyes did the flick: the half-second reading pause, the answer that came back too clean to be off the top of someone's head.

He admits in the comments that he can't prove what was on the interviewer's screen. A "too clean" answer is a signal, but it isn't proof. The point that survives the uncertainty is the asymmetry. He was marked down on an inference, "reliance on AI," read off eye-flicks and a pause, and dressed up as a conclusion about his character. If a canned answer sheet and a live model produce the same too-clean response, then the format was never measuring what it thought it was.

The rule being enforced, he argues, is a theatrical one. You're allowed to use AI as long as nobody sees you. So candidates perform the 2019 version of themselves for a job where everyone, including the interviewer, ships with AI every day.

His distinction between recall and judgment is the part that matters:

• Recall is syntax, API names, flag order. AI made it cheap, and testing for it in 2026 is testing for penmanship.
• Judgment is knowing what to build, what to distrust, what breaks when a real user does something strange. You can only earn it by doing the work, and you can only demonstrate it by catching the AI when it's wrong.

The strongest comment in that thread reframes the entire format. The interview question that matters asks the candidate to explain the design, identify the failure modes, challenge the generated solution, and say what they'd change before shipping. That's the actual job. The teams still pretending the crutch is the character flaw never noticed they'd been handing out answer sheets for years.

The quiet weight

Not everything in this cluster is about skill decay. James Anderson's post on the quiet weight of working in tech names the psychological cost. This exhaustion has a different shape from the burnout we know. Burnout is a volume problem: long hours, crunch, a shape you recognize, an end you can see. This weight is a pace and ground problem. The tools change every week. The thing you were an expert in last year has a new best practice this quarter, and a new "you're doing it wrong" the quarter after.

The post identifies five pressures that compound. The floor keeps rising, so you ship more and feel more behind. The fear of going stale never lets you settle into your own competence. The identity wobble: "am I actually good, or is the AI doing it?" The vigilance tax of reviewing, verifying, and catching what the model got confidently wrong. And the comparison trap, where everyone online posts the 10x wins and nobody posts the anxiety.

The comments on that post were the most honest of the whole cluster. One commenter described resigning, with Claude as the trigger. The assumption embedded in the work culture, that the tool could replace them, is what hurt more than the tool itself. Another described feeling worn down, like a knife sharpened until only a sliver of blade is left.

The practical answer from that thread, and it's a good one: you cannot keep up with everything, and neither can anyone. The half-life of a specific framework is short. The half-life of judgment, taste, and knowing why things work is long. Invest in the stuff that ages well.

The ShelfTalk bug: when correct code is still wrong

The ShelfTalk post makes the same point from a different angle. The author rebuilt a MERN book-club app for production, placed top 10 out of 500+ entries in a GitHub finishing challenge, and then hit a production bug that taught him more than the whole rebuild.

He'd added an optimization: suppress desktop notifications when the tab is visible. Clean UX. Then users started missing direct messages, and his own testing couldn't reproduce it. The code was working exactly as designed. The bug lived in an assumption underneath a correct line of code. His implementation had conflated "the OS can render this pixel" with "a person is paying attention." A tab in full view on a second monitor is technically visible while nobody has looked at it in twenty minutes.

Nothing about that bug shows up in a demo. You don't discover it by prompting your way through a project. You discover it because a user complains and you sit with "it's working exactly as designed" long enough to realize the design was wrong. The fix was deleting the optimization he was proud of. A redundant ping is mildly annoying. A silently dropped message is a broken product.

The comment thread produced the cleanest rule of thumb I've seen. If the change is greenfield, let the AI draft a POC and refine from there. If the change touches a live assumption, do the reasoning yourself, regardless of who typed it. When I tried to be lazy and just prompt a fix in brownfield code, the agent blew the change out of scope or made core modifications that broke the feature. Reviewing manually was faster than untangling the damage.

The "I'm tired of talking to AI" essay is the same failure mode in human form. A developer asks about malware-infested repositories, gets a useless AI answer, opens a GitHub discussion, and receives the exact same AI text back from a person. He asks his business owner a question. The owner forwards a ChatGPT screenshot that answers a different question, doesn't read the reply, forwards another screenshot. The exhaustion isn't about productivity. The loop of human judgment is being bypassed on both sides of the conversation.

The systemic version: MTTR is not a strategy

Hashimoto's thread ties the individual experiences to an organizational failure mode. The lesson from infrastructure was that you can automate yourself into a very resilient catastrophe machine. The psychosis mentality he describes: "it's fine to ship bugs because the agents will fix them so quickly and at a scale humans can't." But MTTR was never a replacement for building resilient things. As he put it, you can't yeet resilient systems entirely.

He also names why this is hard to raise with anyone. Bring it up and you get dismissals: "no no, it has full test coverage" or "bug reports are going down." Those metrics can all be green while the architecture quietly becomes something nobody understands.

The chart is a proxy, but it signals something real. The posts that drew the most engagement weren't tool reviews. They were the posts naming the discomfort: the quiet weight, the engineering work debate, the atrophy argument. People are having this conversation, largely because they've been having it alone.

What trips people up

Across these posts and their comments, four recurring mistakes stand out.

1. Skipping the review step because the diff looks clean. AI-generated code is convincing, that's the trap. The fix is a habit: before reading any generated diff, write down what would break in production that the diff doesn't show, then read against that list. One commenter's version: generate the first draft, then write the load tests and failure-mode tests before reading the code. The AI passes "does it compile." It fails "what happens when the database autosuspends mid-transaction." That gap is where engineering lives.

2. Handing off tasks bigger than your decision surface. "Build authentication" is a handoff where dozens of decisions get made without you. "Create the registration endpoint using this user model" is a handoff you can actually review. Size the task to the checkpoint you can meaningfully judge, not to what the agent can produce.

3. Measuring progress with metrics that hide the decay. Test coverage rising, bug reports falling, all while the architecture becomes incomprehensible. If your only signal is green checks, you'll miss the red. Watch for the opposite signals: you can't explain why a change was made, you're afraid to touch a module, the "why" lives in nobody's head.

4. Letting AI be step one instead of step zero. Form your own model of the problem first. Predict the failure modes. Write the tests that encode your understanding. Then prompt. AI is the fastest way to elaborate an idea you already have. It's a poor substitute for having one.

One thing to remember

The engineers writing about this aren't Luddites. They use AI every day. Traversy built an open-source framework for AI-assisted workflows. The interview author says AI still writes all of his code. The distinction that matters is between delegating the typing and delegating the judgment. Keep the judgment. That's the part the job actually is.

The Bottom Line

Three takeaways, depending on where you sit:

• If you're an individual contributor, adopt a predict-then-verify workflow. Write down expected behavior and failure modes before you prompt, read the full diff after, and keep handoffs small enough that you can defend every decision in the change. Your skill curve depends on the review step, not the generation step.

• If you're an engineering manager, stop rewarding raw output and start rewarding defensible ownership. Ask the question the interview author wished he'd been asked: explain the design, identify the failure modes, and say what you'd change before shipping. If your team can't answer it, you have an understanding problem, not a tooling problem.

• If you're hiring, drop the pretense that the 2019 interview measures anything useful. Hand the candidate AI, tell them it's allowed, and grade them on whether they can catch it being wrong. That's the only skill that survived the last two years, and it's the one both sides of the table actually use.

Also watch: as agentic tools get faster, the temptation to widen the handoff grows. Expect the review problem to move from "did the code work" to "did anybody understand the decisions." The teams that build explicit review checkpoints into their AI workflows will keep their judgment edge. The ones that optimize for output alone will discover the decay the hard way, likely in production.