Yesterday I wrote about teaching a local model to write in my voice, and the honest ending was that the fine-tune worked and still lost to a bigger model holding a distilled skill prompt. This is part two. The writer holds its seat; the question became how it gets better. Every draft it produces goes through an editor pass, and every pass generates corrections. Those corrections were the most information-dense artifact in the whole pipeline, and until this week nothing was harvesting them.
So I built an autoresearch-style loop: the writing skill has to improve after every blog post, and the editor's corrections are the teacher.
What I built
The loop runs in four stages, and no model in it ever grades its own work. First it diffs the writer's raw draft against the editor's final and stores each correction as a before-and-after pair. Second, an analyst model, a different one from the writer, reads the cycle's corrections and proposes exactly one new rule for the writing skill: imperative, two sentences at most, general enough to apply to any future post. Third, validation: the writer generates the same bench briefs twice, once under the current skill and once under the skill plus the candidate rule, and the outputs go through a deterministic style scorer plus a blind pairwise judge. The rule is adopted only if it measures better. Fourth, adopted rules land in a managed block of the system prompt, capped at ten before a human has to consolidate.
The correction pairs do double duty. Beyond feeding the analyst, they accumulate into a training corpus, so when there is enough of it, the next fine-tuning run learns from months of real editorial judgment instead of a one-time snapshot.
What broke first
The first live cycle ran on part one's own draft. The system mined five editor corrections, and the analyst named the failure class correctly: unsubstantiated technical assertions, numbers asserted without the context that earns them. It proposed a rule to fix that, and the rule sounded wise. Require the methodology before the metric.
Validation killed it. Under the candidate rule the style score dropped from 98.0 to 94.0, and the blind judge preferred the current skill six briefs to zero. A rule that demands methodology in front of every number turns prose into hedge-soup; the fix for a real disease made the patient worse. The loop logged the rejection, emailed me the verdict, and changed nothing.
I expected the first cycle to produce a win. It produced a lesson instead, and the lesson is the whole design: most self-improvement systems rubber-stamp their own suggestions because every stage optimizes for sounding smart. The only defense I trust is a validation step with the power to say no and the data to back it up. Rejection here is a first-class outcome, recorded with the same care as adoption.
The verdict
One cycle in, the loop's record is zero adoptions, one rejection, and my trust in it went up, not down. A system that can decline its own idea on evidence is worth compounding; a system that accepts everything is prompt drift with a progress bar.
There is a recursion here I want to name plainly. This post was drafted by the writer inside the loop, about the loop. My corrections to this draft become cycle two's input. If a rule from those corrections survives validation, part three of anything I write arrives slightly better because this post needed editing. That is the compounding I was after when I started, and it costs nothing per cycle beyond electricity the machine was already burning.
If you build one of these, instrument the reject path first. Watch for the times the loop says no; that is where the trust lives. Expect rejection to be common early, and treat a high adoption rate as a warning sign, not a success metric. The value of the loop is not only in the fixes it finds. It is in the fixes it blocks.