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 (4)
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.
Does an edit to an unrelated section invalidate every pending proposal, or does Meldr scope the SHA check to the section it touches?