Last updated: September 10, 2026 · By Vishal Swami, Founder & Lead AI Reviewer, AISagely
"Prolific AI psychosis" is a term coined by psychiatrist Jeff Clark, MD. It names a specific pattern: someone uses an AI coding tool to generate a large volume of output, then loses the ability to judge whether any of it is actually good. It isn't a clinical diagnosis. It also isn't the same thing as the "AI psychosis" that shows up in psychiatric case reports.
Short answer: "Prolific AI psychosis," coined by psychiatrist Jeff Clark, MD in a September 8, 2026 post, describes generating a large quantity of AI output — usually code — without a real increase in its value, paired with an inability to judge that gap. It's distinct from clinical AI-induced psychosis. Warning signs: hyperfocus without sleep, dismissing feedback, and not understanding your own project.
I read Clark's post the day it hit Hacker News, where it pulled in 60 points and 43 comments as of this writing, and then spent an afternoon running his self-check questions against three of my own AI-assisted projects. In my testing, the checklist caught something real: a script I'd had Claude expand into nine helper files over a weekend, only two of which I could still explain without opening them. That's the exact gap Clark is naming — output that looks productive and isn't, produced by someone who's lost the ability to tell the difference.
What "prolific AI psychosis" actually means
Clark's Part 1 post argued that "AI psychosis" gets applied to three different things. Lumping them together does nobody any favors. There's true AI psychosis — a genuine psychotic episode, usually a variant of a pre-existing condition, where chatbot use is a contributing factor. There's parasocial AI psychosis — a maladaptive relationship with a chatbot that substitutes for human connection. And there's prolific AI psychosis, the subject of Part 2. Clark defines it as generating a large quantity of AI output "without significantly increasing the real value of their work," combined with a mild disconnection from your own ability to assess that work.
The example Clark uses is a software engineer shipping thousands of lines of AI-generated code a day with little real-world utility. His comparison: a novelist who suddenly writes 100,000 words a day. The volume isn't the problem by itself — it's that the judgment required to write 1,000 careful words doesn't scale linearly to 100 times the output. Something has to give, and what gives is usually the person's ability to notice.
This term is not a substitute for a real diagnosis, and it shouldn't be used as one. If you or someone you know is showing signs of an actual psychotic episode, that's a medical situation, not a productivity problem — see a clinician, not a blog post. The BJPsych Open review of AI psychosis mechanisms covers the clinical phenomenon in detail, and it's a different topic from what Clark is describing here. I ran into the same need for precision when I covered Cloudflare’s AI Psychosis, a separate viral post that borrows the same phrase as a metaphor for corporate behavior. Three different uses of one loaded phrase, and conflating any of them does a disservice to the one that's a real medical condition.
What you'll need to check your own work
You don't need Clark's clinical background to run his self-check. You need access to whatever you shipped in the last week or two — commits, generated files, a project folder — and about twenty honest minutes. It helps to have someone else look too, since the whole point of the pattern is that your own judgment about your own output is the thing that's compromised. A second pair of eyes catches what self-assessment misses.
Step-by-step: checking for prolific AI psychosis in your own output
1. Count the ratio, not the total
Pull up your commit history for the last two weeks and count lines added versus lines you can point to a real, working use for. Clark's marker isn't "did you write a lot" — it's whether the value line tracks the volume line. In my three test repos, one had a roughly 1:1 ratio (a lot of code, most of it load-bearing) and one was closer to 6:1 (a lot of code, most of it dead weight the AI had generated to "help").
2. Try to explain your own project out loud, without opening it
Pick a file the AI wrote for you in the last week and describe what it does and why it exists, from memory, to another person. Clark flags "I couldn't understand my own project" as a specific red flag. If you can't explain it without opening the file, that's worth sitting with.
3. Check for the sleep and isolation pattern
Clark lists hyperfocus without sleep and pulling away from peers as symptom clusters, not personality quirks. If a project has had you skipping sleep or ignoring people who'd normally review your work, the volume of output you're producing during those sessions deserves extra scrutiny, not extra trust.
4. Ask the four craft questions before you ship
Clark's proposed antidote is human judgment applied deliberately: is it useful, is it good, is it desirable, is it delightful? None of those are things an AI model can answer for you about your own work. Answering them yourself, in writing, is slower than shipping — that's the point.
5. Get a human reviewer who didn't write the prompt
If nobody but you and the model has looked at the output, you don't have a second opinion — you have the same blind spot twice. A teammate, even a non-technical one asking "what does this actually do for a user," breaks the loop that self-review can't.
Example prompts you can copy
These aren't prompts to generate more output — they're prompts to audit output you already have. When I tested the first one against a file Claude had written for me, it produced a more honest description than I had going in, including a function I genuinely couldn't justify keeping.
- "Explain this file back to me like you're teaching a junior engineer who has never seen it. Don't skip anything you'd normally gloss over."
- "List every function in this file that isn't called anywhere else in the project."
- "If I deleted this file entirely, what would break? Be specific, not reassuring."
- "Summarize what changed in my last 10 commits in plain English, as if reporting to someone who didn't write any of it."
Common mistakes to avoid
The biggest mistake I made in my own test run was trusting the AI's own summary of what it had built instead of reading the actual diff — the model will describe its own sprawl in confident, tidy language even when the underlying code is a mess. The second was treating "it runs" as the finish line; several of my nine helper files ran fine and did nothing anyone needed. The third, and the one Clark spends the most time on, is ignoring feedback from a person specifically because it's slower or less flattering than the AI's response. If a teammate's pushback and the model's encouragement disagree, that disagreement is the signal, not the noise.
Tools that make this easier
None of this requires new software — it requires slowing down with the tools you already have. If your current workflow is closer to "vibe coding" than deliberate review, AI Coding Without the Vibes walks through adding specs, small diffs, and real tests to an AI-assisted workflow. If you're deciding which AI coding assistant to build that discipline around, our AI tool reviews and best AI tool for code compare the options we've actually tested, and how to use Cursor for beginners is a reasonable starting point if you're new to AI-assisted coding specifically. If you want the harder argument for why this matters beyond one person's output, Coding Expertise Is Going to Collapse from AI Reliance and AI Can Make You Suck Faster Too both cover adjacent failure modes worth reading.
The three kinds of "AI psychosis," compared
| True AI psychosis | Prolific AI psychosis | Parasocial AI psychosis | |
|---|---|---|---|
| What it is | A genuine psychotic episode, usually a variant of pre-existing psychosis, linked to chatbot use | High-volume AI output with no matching increase in real value, plus reduced ability to judge that gap | A one-sided relationship with a chatbot that substitutes for human connection |
| Who names it | Psychiatric case reports; covered in BJPsych Open | Jeff Clark, MD (Sept. 2026 blog post) | Jeff Clark, MD (referenced in the same series) |
| Typical setting | Vulnerable individuals with heavy, sustained chatbot use | Developers and other knowledge workers using agentic AI tools | Anyone using a chatbot as a primary companion |
| What helps | Clinical evaluation and treatment | Human review, output-vs-value tracking, deliberate craft questions | Rebuilding human social contact; professional support if it's compulsive |
| Is it a medical diagnosis? | Yes, in the clinical literature | No — a descriptive term, not a DSM category | No — a descriptive term, not a DSM category |
Frequently Asked Questions
Is "prolific AI psychosis" a real medical diagnosis?
No. It's a descriptive term coined by psychiatrist Jeff Clark, MD, in a September 2026 blog post, not a diagnosis in the DSM or any clinical guideline. Clark himself distinguishes it from true, clinical AI-induced psychosis, which is a genuine psychiatric concern covered in peer-reviewed research.
Who is most at risk of prolific AI psychosis, according to Clark?
Clark speculates that people with ADHD or impulse-control tendencies may be more susceptible. He also flags high openness and low conscientiousness as risk traits. His reasoning: AI tools give an unpredictable reward — a great result sometimes, junk other times — and that pattern resembles the intermittent reinforcement behind other compulsive behaviors.
How long does checking for it take?
Clark's self-check questions — counting output versus value, explaining your own project out loud, and asking whether the work is useful, good, desirable, and delightful — take about 20 minutes per project if you're honest with yourself. Doing it with a second reviewer takes longer but catches more.
What's the easiest first step if I think this applies to me?
Pull up your last two weeks of commits and try to explain, from memory, what one AI-generated file does and why it exists. If you can't, that's the fastest, cheapest signal Clark's framework offers, and it doesn't require any tool beyond your own memory.
Does this mean I should stop using AI coding tools?
No — Clark's argument is for boundaries, not abstinence. The fix he proposes is keeping human judgment, sleep, and outside review in the loop, not giving up AI-assisted coding. See AI Coding Without the Vibes for a workflow built around exactly that balance.