Here is the line that changed my project:
Next · Generate draft
That's a label on a button in a terminal UI. It appeared right after you approved an editorial brief in Meldr, the writing workflow tool I'm building. I deleted it, and I want to explain why, because it ended up changing more than the interface.
Where Meldr came from
Meldr was born out of selfishness: I wanted to streamline article writing for my own workflow. Writing a technical article involves a lot of work around the writing. Before I start, I'm checking whether someone has covered the idea and what evidence I actually have. Afterward, I'm verifying claims. In practice that meant 15 browser tabs, a few AI conversations, my editor, and scattered notes. The fragmentation was the slow part, not the writing.
So I'm building it to meld those steps into one terminal workflow:
research → angle → editorial brief → approved outline → write → review → publish
Everything between steps lives in plain Markdown files, and two points are human decisions: approving the brief, and accepting or rejecting review proposals.
What the button was saying
Meldr generating a publishable draft
Approving a brief means "I agree with this direction." The button turned that into "now generate all the prose." One keystroke took you from an outline to something that looked like a finished article.
Something about that didn't sit right with me. If other writers were going to use Meldr, I had to ask myself: would this encourage fully AI-written articles, even slop?
Technical posts are useful when they carry something only the author has: the real bug, the tradeoff that was harder than expected, the thing that surprised them. A model working from an outline has none of that. It fills the gaps with plausible, confident, interchangeable text, which is the thing people mean by AI slop.
To be clear, I'm not saying nobody should draft with AI. That's each writer's call. My decision was narrower: I didn't want to build the tool whose recommended path leads there. Defaults tell people what a tool expects from them, so I removed draft generation entirely instead of tucking it behind a setting.
After you approve a brief now, the next action is to open working.md and write.
What Meldr does instead
Meldr helps with the work around the writing, and each piece is built so the model proposes and the author decides.
Your article is yours. Without a generated draft, ownership is simple:
article/
├── brief.md direction, audience, thesis, scope, outline
├── working.md your article
├── editorial-notes.md author placeholders, open verification work
└── revisions/ review proposals, section suggestions, claim reports
Review needs real prose. If working.md is just a title, "review my draft" could quietly become "write one for me." Meldr refuses to review a title-only file. Once there's text, it looks at structure, voice, and claims that sound more certain than the evidence supports, and everything comes back as a proposal you can accept, edit, or ignore.
Section help is on request. For a section I'm stuck on, Meldr asks what I want:
What would you like to do?
› I'll write this section
Suggest talking points
Help me start it
Skip for now
The model is called only when I ask, and the result is a proposal that never touches working.md unless I accept it.
Proposals can go stale. If Meldr reviews your article and you then rewrite three paragraphs, accepting the old proposal would apply it to a version that no longer exists. Meldr records the source article's SHA-256 digest when it creates a revision and checks it again on accept:
proposal source ≠ current article → stale, refuse to apply
Gaps stay visibly yours. When a model has no real example, it will invent one. So Meldr leaves author-owned gaps unresolved instead of papering over them:
[AUTHOR: Add the real debugging problem that caused you to build this.]
Claims get the same treatment. Meldr flags statements that deserve verification and says what evidence would help, but it doesn't declare them true. Claim reports stay separate from revisions, so uncertainty can't be accepted into verified prose. It becomes a research list.
The tradeoff
Meldr is slower than a tool that hands you a draft in a minute, and that's deliberate. It's also still in progress, so I may find that some of these choices need adjusting. But the parts of writing I wanted help with were the research, the structure, and the checking, and none of those needed the tool to write the article for me.
One note on privacy: Meldr is local-first, so projects live on your machine and stay inspectable, but when you ask for model help, the relevant context goes to whichever provider you configure. There's no autonomous publishing step either.
What I took from it
I expected the lesson to be about AI. It turned out to be about defaults. One recommended button shaped the file layout, the review logic, and how I thought about who owns what in the tool.
If you build tools with AI in the loop, has a default ever surprised you like this? And if you use AI while writing technical posts, where do you want the help: research, structure, proofreading, claim checking, or getting through one hard section?
Top comments (16)
Forcing the author to write working.md directly keeps the voice grounded. The place where an assistant model genuinely speeds up that phase is checking notes against the brief before drafting starts. When drafting technical walk-throughs, noticing mid-paragraph that an outline claim contradicts a CLI reproduction note burns a lot of momentum. Running verification against the research notes before touching the editor catches those factual gaps while keeping the prose entirely human.
That mid-paragraph moment is the worst, because by then you're attached to the sentence. Right now Meldr only checks claims once there's prose in working.md, so it would catch that contradiction after I'd already written it. Checking the outline against the research notes before drafting would catch it earlier, and it still fits the rule that the model proposes and I decide, since nothing gets written for me. I'm adding it to my list. but do you run that check by hand, or do you have something doing it for you?
Refusing to review a title-only file is a nice guard, but I wonder where the line sits once there's more than a title. Someone could put one sentence under each heading of the approved outline, ask for review, and get back proposals that add up to the draft the button used to generate, just delivered in pieces. Is the check about length, or about whether review proposals may add new content versus only reshape what's already there? The second sounds harder to enforce but closer to what you're after.
woah you found the real loophole. The guard today is basically "is there prose here, or just a title," so one sentence under each heading would get past it, and nothing in review stops a proposal from adding new material. You could rebuild the old button in pieces.
I'm okay with part of that. I can't stop someone who's determined to have a model write their article, and I don't think that's the tool's job. What I care about is the default path. But your second framing is closer to what I'm after: review should reshape what's already there, and new content should only show up when I explicitly ask for help on a section. The cheap way to enforce that is probably a cap on how much a review proposal can grow a section. Going to think about that one. Thanks for pushing on it!
A growth cap is cheap and I think it gets you most of the way. The case it misses is a proposal that keeps the length flat but swaps your sentences for new ones, so a word-count cap could pair with a check on how many of the original sentences survive the review. That said, I agree with where you drew the line: the tool can't stop someone determined, it can only make the honest route the easy one. A cap that makes "rewrite my section from scratch" feel like an explicit request rather than a side effect seems like exactly that.
Keeping claim reports separate from revisions is a useful boundary. One edge case for the digest check: two proposals reviewed against the same working.md are both initially valid, but accepting the first should make the second stale. Do you test that path? I'd also include a write failure after acceptance begins and check that neither a partial article nor a falsely "accepted" proposal is left behind. That would exercise the acceptance contract rather than only edits made between review and accept.
Thanks, this is a useful edge case. The two-proposal path should be covered by the digest check, since accepting the first changes working.md and makes the second stale, BUT I don't have a test for it yet and I'll add one. I'm going to write to a temp file and rename it over working.md, mark the proposal accepted only afterward, and add tests that fail at each step to confirm nothing partial is left behind
Separating verification from drafting makes a lot of sense, especially keeping claim reports outside the document itself. Once a model inserts unverified claims into prose, editing usually turns into fact checking every clause after the fact. Treating claims as an open checklist keeps the actual working text much cleaner.
Checking every sentence after the fact is exactly what I wanted to avoid. Once a shaky claim is sitting inside polished prose, it looks as trustworthy as everything around it. As a checklist it stays visibly unfinished until I've actually checked it
Review-only is where I got value too: on a bench of 24 runs, the review pass produced exactly one note worth keeping, a pre-existing reuse-after-close bug the change had not caused. Everything else was restatement. Do you keep the rejected proposals anywhere, or is that signal gone once you decline?
One keeper out of 24 is a useful number to have. In Meldr, proposals are written to revisions/ as plain Markdown, and declining one doesn't delete it, so the record is there. What I'm not doing yet is anything with it. An accept rate by proposal type would tell me which parts of review are mostly restatement, and those are the parts worth turning down or cutting
Usually when I use AI to write an article, I could tell it to write a full blown article on the topic, and then I start changing things to make it sound more like something I will write, or better still, I don't even use AI all together, and I still come out with a pretty decent article.
I guess the reason I do the second option is to keep harnessing my ability to write articles, and not outsource it entirely to AI
Yes exactly! I do the former as well with shorter articles / opinion pieces that don't require much research, it's easy and tempting. I love writing. I went to school for it. I want AI to enhance my writing without replacing it
It's to find the balance, and know when to bring AI into the process. AI should be part of the system, not the entire system
Does an edit to an unrelated section invalidate every pending proposal, or does Meldr scope the SHA check to the section it touches?
Right now any edit invalidates every pending proposal. The digest covers the whole working.md, so Meldr can't tell an unrelated edit from a conflicting one. That's the simple and safe version, and the cost is exactly what you're pointing at: fixing a typo in section 1 throws out a still-valid proposal for section 4. Scoping the digest to the section a proposal touches is the obvious next step if that gets annoying in practice.