A few months ago we had a bad Tuesday. Our orders API started throwing remaining connection slots are reserved errors from Postgres around 2pm, right in the middle of a checkout spike, and the on-call engineer did the thing a lot of us do now without thinking twice: pasted the stack trace into ChatGPT, copied the reply, and dropped it straight into the incident channel as their diagnosis.
It sounded confident. It mentioned max_connections, pool sizing, idle_in_transaction_session_timeout, all the right nouns. Three of us spent the next twenty minutes tuning PgBouncer settings that had nothing to do with the actual problem, because the actual problem was a leaked client connection in our own code that the model had never seen. We didn't fix anything until someone finally opened the app and read the code instead of the chat log.
That night is the whole reason I now care about a tiny satirical site called dontpastetheai.com. It's one page, it's mostly a joke, and it's also exactly right about a failure mode that's specific to backend work: the model doesn't have your logs, your metrics, or your actual running system, and a fluent-sounding answer built on none of that can send an entire incident channel down the wrong hallway.
The bug versus the AI's diagnosis
Here's what was actually wrong, once someone bothered to look. Our order-lookup handler grabbed a client from the pool, ran a query, and only released the client back to the pool on the success path. Under normal load nobody noticed, because queries rarely failed. Under a checkout spike, a handful of queries started timing out, the catch block fired, and the client was never returned.
Multiply that by a few hundred requests a minute during a traffic spike and you exhaust the pool in under ten minutes. Here's the code that caused it:
async function getUserOrders(userId) {
const client = await pool.connect();
try {
const { rows } = await client.query(
'SELECT * FROM orders WHERE user_id = $1',
[userId]
);
return rows;
} catch (err) {
logger.error('order lookup failed', err);
throw err;
}
}
Nothing about this is exotic. It's the most common way to leak a Postgres connection in a Node service, and every backend engineer has written this bug at least once. The fix is a one-line finally block:
async function getUserOrders(userId) {
const client = await pool.connect();
try {
const { rows } = await client.query(
'SELECT * FROM orders WHERE user_id = $1',
[userId]
);
return rows;
} catch (err) {
logger.error('order lookup failed', err);
throw err;
} finally {
client.release();
}
}
The model's answer wasn't stupid, and it wasn't hallucinated garbage either. Raising max_connections is a legitimate thing to check when you see that Postgres error. It just wasn't our problem, and nothing in the pasted answer said "by the way, I'm guessing at your architecture because I can't see your code." A person who actually read our handler would have caught the missing release in about ninety seconds.
Why raw pastes fail specifically during incidents
The dontpastetheai.com page frames this as a communication problem, and mostly it is one. But on-call work makes the failure mode sharper than it is in, say, a casual Slack chat, because an incident channel runs on trust in whoever posts next. If someone posts a theory with the confident tone of a finished diagnosis, other engineers start acting on it instead of independently verifying it, and that's exactly what happened to us for twenty wasted minutes.
The core issue the site names directly: the person asking already has the same tools you do. If a teammate wanted the generic Postgres troubleshooting checklist, they could get it themselves in four seconds. What they actually needed from the on-call engineer was someone who had looked at this service's code, this service's recent deploys, and this service's metrics dashboard, and formed an opinion grounded in all three.
That confidence gap is the whole danger. A junior engineer guessing out loud will usually hedge — "not sure, but maybe check the pool config?" A pasted model answer reads like a senior engineer who already checked. It hasn't.
The four-step fix we adopted
After that incident we didn't ban AI tools, and I don't think that would have worked even if we'd wanted to. What we did instead was steal, almost verbatim, the "try this instead" list from dontpastetheai.com and put it in our incident response doc as the expected norm for anyone posting a theory in the channel.
- Use the AI to draft your theory. That part's fine, and honestly encouraged — a model is a good first pass at "what usually causes this error."
- Before you post anything, go check it against the actual code, logs, or metrics for the service in question. If the model mentioned a config value, go read that config value.
- Post your own three sentences: what you think is wrong, what you checked to confirm it, and what you're doing next. If a piece of the model's reasoning genuinely held up, say so and quote it — "checked with Claude and this part lines up" is a completely fine thing to write.
- If you don't have a theory yet, say that instead of posting a wall of speculation. "No leads yet, still digging" is more useful to the rest of the channel than a confident-sounding guess.
None of this slows anyone down in practice. The verification step for our connection leak would have taken maybe two minutes — open the handler, look for client.release(), notice it's only on one path. What costs time isn't checking; it's skipping the checking and hoping the model's answer was close enough.
What a lazy paste actually looks like, side by side
It helps to see the actual difference in text, because "read it and write your own take" sounds abstract until you compare two real messages. Here's roughly what got posted in our incident channel that Tuesday, close to word for word:
"Based on the error message you provided, this looks like a Postgres connection pool exhaustion issue. I'd recommend increasing max_connections in postgresql.conf, checking your PgBouncer pool_size settings, and reviewing idle_in_transaction_session_timeout to make sure idle sessions aren't holding connections open."
Compare that to what should have gone up instead, once someone actually looked: "Found it — getUserOrders only releases the pg client on the success path, so failed queries during the spike leaked connections. Deploying a fix with the release moved into a finally block, should recover the pool in a minute or two." Same underlying topic, a fraction of the words, and it's actually about our system instead of Postgres in general. That's the entire difference the dontpastetheai.com page is arguing for, just applied to an incident channel instead of a DM.
When pasting the raw output is actually fine
I don't think this rule is absolute, and I'd be annoyed by a teammate who turned it into a purity test. There are real cases in backend work where the raw output is the answer, not a draft of one.
If a teammate asks for the exact flag to reproduce a Node core dump, or the correct JSON shape for a Stripe webhook payload, or a regex that matches semver strings, pasting the model's answer verbatim is often the fastest correct response and adding your own commentary on top would just be padding. The line I've settled on is: if the answer depends on knowledge of our specific codebase, deployment, or incident history, it needs a human read on it first. If it's a lookup anyone could run themselves and would get the same result, paste away.
Making it stick without turning into the norms police
We didn't announce this as a policy in an all-hands, because nothing kills a good norm faster than making it sound like a mandate from leadership. We just added a line to our on-call runbook and started linking dontpastetheai.com in the incident channel whenever someone dropped an unedited wall of model output, the same low-key way people already link nohello.net when someone opens a DM with just "hey" and nothing else, or dontasktoask.com when someone asks "can I ask a question" instead of just asking it.
There's a small, funny detail buried in the site's footer that I like: the GitHub repo behind it is actually named dontquotetheai, a slightly different phrase than the domain itself. It's a small reminder that even the site about being precise with language didn't sweat a naming mismatch that doesn't actually matter. Consistency of the underlying idea beats consistency of the exact wording, which is sort of the whole point being made.
The thing that actually made it stick wasn't the link, though. It was that the first two or three times someone got called out gently for a raw paste, the corrected answer was visibly better and visibly faster to act on. Once people saw that the "read it, then write three sentences" version resolved incidents quicker than the "paste and hope" version, the norm enforced itself. Nobody wants to be the person whose diagnosis sent the channel down a dead end for twenty minutes.
The takeaway
Use the model. I still do, every single incident, usually before I've even finished reading the error message. The difference between that Tuesday and how we run incidents now isn't that we stopped asking a chatbot for theories — it's that nobody gets to post one without first checking it against the thing that's actually running in production. If your answer would be identical whether or not you'd looked at your own code, that's usually the sign you skipped the step that mattered.
Comments
No comments yet — be the first to share your thoughts.