We staged 26 rewritten posts and published none of them. One of our AI tools had a broken login for most of the run, and the publish step stalled behind it. A hub session traced the break to our executors running as SYSTEM and fixed it. I had already merged the stuck promote branch.
What the 15 hours bought
Over the next 15 hours I fixed four bugs that were quietly blocking the blog pipeline. I backfilled the missing lesson blocks across the whole review queue. I wrote nineteen drafts for the gap week, split across our technical and non-technical tracks.
The finding was that nothing was publishable, and the reason was content, not plumbing.
A scoring record I couldn’t lean on
Part of the scoring record turned out to be untrustworthy.
If you run a small business, you have probably met this in another form. A dashboard says the numbers are green, so you assume the work is fine and look for the problem somewhere else.
Blocked or bad
When work stalls, the first question is whether the thing is blocked or whether the thing is bad. Those are different problems.
A score that nobody has checked against the actual text is a rumor with a number attached.
AI Skills
Use this lesson with the AI assistant you already use
A batch of 26 rewritten posts was staged and none were published, so 15 hours went into fixing four pipeline bugs and backfilling lesson blocks. Once the path was clear, nothing was publishable, and part of the scoring record turned out to be untrustworthy.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Check Whether Stalled Work Is Blocked Or Bad Before Fixing The Pipeline
SOURCE: dxdev.com/blog/2026-09-23_when-the-ai-grader-cannot-be-trusted
WHAT HAPPENED: A broken login in one AI tool stalled the publish step, and a hub session traced it to executors running as SYSTEM. Over the next 15 hours the author fixed four bugs quietly blocking the blog pipeline, backfilled missing lesson blocks across the review queue, and wrote nineteen drafts for the gap week. When the pipeline was finally clear, the posts still could not go out, because the problem was the content and not the delivery path. The scoring record that was supposed to say the content was fine could not be relied on, and the author could not say which scores were bad or how many. The author compares this to replacing the delivery truck when the product in the back was the problem.
THE RULE: When work stalls, first decide whether it is blocked or bad, because fixing the delivery path cannot make bad output publishable. Treat a score as a rumor until someone has checked it against the actual text.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Before spending time on pipeline fixes, someone has read a sample of the stalled items directly and judged whether they are good enough to ship.
2. Every automated score used to gate publishing has been spot-checked against the underlying text by a person or an independent method.
3. When a stall is reported, the write-up states whether the cause is a blocked path or low-quality output, with evidence for that call.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.