Humanizer can still over-explain conversational replies
I ran into a case where Humanizer removed most of the obvious AI tells, but the result still felt very AI-written because it preserved too much of the original explanation and structure.
The input was a response to a PR review comment. Humanizer produced something along these lines (Anonimized private information):
Yeah, you're right. This is working around the issue rather than fixing it.
I think the actual fix is in
MergeService#process!: when we move a child under a new parent, we should updatepipeline_idalong withparent_id. The model already expects those to match (parent_pipeline_matches), we're just not keeping that true during a merge.We should be able to backfill this pretty easily from Trails too.
MergeServicewrites these changes withsource: "port_merge"and we trailpnt_id, so we can find the projects that have gone through this path with:
Model.where(related_to_type: "Project", field: "pnt_id", source: "port_merge")I checked QA and found 123 historical merge events, with only 6 projects currently having the wrong pipeline, so it looks like a pretty small cleanup.
Since the fix is in the shared
MergeServicemodel and isn't Client A-specific, I'd rather put that in a separate ticket instead of expanding the scope of this PR. The fallback here is still fine to keep; it'll just stop being necessary once we fix the merge behavior and backfill the existing bad data.If that split sounds good, I'll create a ticket for the
MergeServicechange + backfill.
It was better than the original, but still sounded like a generated technical memo. It explains the diagnosis, proves the diagnosis, explains the backfill, and then gets to the actual point.
What I ended up writing was:
Yeah makes sense, but still here changing MergeService would blow up the scope of this ticket. To fix it properly means testing every account’s merge flow, not just Client A’s Pipeline A, and doing the backfill migration for the existing bad data. That’s another, bigger piece of work.
I would prefer to keep this PR Client A specific and open a separate ticket for the MergeService fix and the backfill. LMK if that works for you.
The difference seems broader than any of the individual AI patterns.
In conversational writing, especially PR comments, Slack, email threads, etc., humans rely heavily on shared context. If the other person already understands the bug, I don't need to re-establish the root cause or prove that I've investigated it. I only need enough context to explain the decision I'm making.
So I think Humanizer could use an additional check along the lines of:
- Is this text a reply in an ongoing conversation?
- What does the reader already know?
- Is the rewrite repeating reasoning that only exists to make the answer feel complete?
- Can established context be left implicit?
- Is the actual purpose of the reply buried under diagnosis/explanation?
- For short conversational replies, prefer the decision + the minimum reasoning needed to support it.
The current guidance that every sentence should add something the reader didn't already have gets close to this, but "the reader didn't already have" probably needs to include information from the surrounding conversation, not just information introduced earlier in the text being rewritten.
I think this would catch a category of AI writing that survives the existing pattern cleanup: prose that is individually natural at the sentence level, but still too complete, self-contained, and explanatory for the context it's being written in.
Source: blader/humanizer