You know the stuff–it has a lot of words. It has headings for everything. It explains things that don’t need explaining, repeats the same point three different ways, and somehow manages to leave out the details you actually needed.
It’s what has become known as AI slop.
Not all slop was necessarily generated by AI. Humans have been producing bad technical writing forever. AI just makes it dramatically easier to produce more of it, faster.
The answer isn’t necessarily “write less,” its to to write better.
Humans and AI agents both need to get better at deciding what information belongs in the document in the first place.
Because the problem isn’t AI. The problem is when writing makes the reader work harder than necessary. It’s sloppy behavior to make the reader work extra hard—and that sloppiness is what creates slop, not who wrote it.
AI just makes it much easier to produce slop at scale. Instead of someone writing one sloppy blog post, AI can help the same author create a whole website of slop.
I wrote a framework for that
Get it on GitHub: Writing Framework: Clear, Concise, Complete, and Correct
It’s intended to be useful as an instruction for an AI agent, but that’s not really the interesting part. The framework is equally useful when proofreading something written by an AI, a coworker, or yourself. These four Cs are writing rules I have always lived by–it wasn’t until my AI agents started writing AI slop that I needed to get the concept out of my head and into a format that AI could have in its context when it writes.
These four Cs sometimes feel at odds with themselves.
The problem with “concise”
One of the writing rules I’ve used for years is:
Strive for writing that is clear, concise, complete, and correct. Speak plainly, and thoughtfully.
I still think that’s a pretty good standard.
The problem is that concise and complete can conflict.
If you optimize too hard for concise, you end up with documentation that technically contains the answer but leaves out the information someone needs to actually use it.
If you optimize too hard for complete, you get the opposite problem: 3,000 words of documentation that could have been 500.
This gets particularly bad with technical writing.
A database runbook doesn’t need to explain what a database is. But it absolutely does need to tell me about the prerequisite permission, the ordering constraint, and the fact that one of the commands is destructive.
Those extra words aren’t bloat. They’re the reason the runbook is useful.
So the real question isn’t “Can I make this shorter?” but instead the question is “What information can I remove without making the reader’s job harder?”
That’s the question I wanted the framework to answer.
The four Cs
The framework starts with the obvious part: We have to define what each of the four words actually means.
Clear
The reader should be able to understand what you mean without reconstructing it. That means unambiguous terminology, explicit relationships, logical ordering, and enough context to understand what “this” or “it” refers to. The useful test is:
Could a technically competent reader reasonably interpret this another way?
If so, fix the ambiguity.
This is particularly useful when proofreading AI-generated text. AI is very good at producing sentences that sound clear while quietly leaving the important relationship between two things unspecified.
Concise
Every sentence should earn its place. Remove repetition, unnecessary qualifiers, decorative language, and background the intended audience already knows. The useful test:
If this sentence disappeared, would the reader lose information they need?
If not, delete it.
Notice that this isn’t the same thing as “make the document as short as possible.” That’s important.
Complete
This is where things get interesting. Completeness is purpose-relative. A document is complete when it contains what the reader needs to accomplish its purpose — not everything that could possibly be known about the subject. To get this right, you have to know who the reader is.
For technical writing, that generally means the reader has enough information to:
- Understand what is being described.
- Understand why it matters, when that matters.
- Perform the intended task.
- Make the intended decision.
- Understand important constraints and exceptions.
- Recognize reasonably foreseeable failure modes.
- Know what to do next.
The test I find most useful is:
What predictable question would the reader ask immediately after reading this?
If the answer is necessary to use the document correctly, put it in the document.
Correct
This one sounds obvious, but it becomes especially important when AI is involved. Technical writing needs to be factually and operationally correct.
That includes:
- Facts and claims.
- Terminology.
- Examples.
- Commands and configuration.
- Version-specific behavior.
- Preconditions and assumptions.
- Scope and exceptions.
- Causal explanations.
And there’s an important corollary:
Don’t add plausible detail just to make something feel complete.
If you don’t know whether a detail is true, verify it or mark the uncertainty.
AI is exceptionally good at filling gaps with something that sounds reasonable–we’ve all heard the term “AI hallucinations,” but humans do this too.
The rule that ties the four together
The framework’s central rule is:
Keep detail when removing it would make the reader more likely to misunderstand, make the wrong decision, take the wrong action, or need to ask a predictable follow-up question. Otherwise, remove it.
I like this because it gives you an actual decision procedure instead of another vague instruction to “be concise.” Consider a sentence that explains why a particular database configuration exists. You might think, “That’s extra. The configuration is already documented.”
The problem with that is if a future engineer is likely to see the unusual configuration and “fix” it because they don’t understand why it’s there, the explanation has value.
- Keep it.
On the other hand, if the sentence exists primarily to demonstrate that the author knows how the database works, it’s probably not helping.
- Delete it.
What deserves the extra words?
The framework identifies a handful of categories where extra detail is usually worth keeping. The document’s purpose and/or audience is key context for all of these categories.
- Detail that prevents misunderstanding – If the short version has a plausible incorrect interpretation, clarify it. Clarifications aren’t verbosity. They’re guardrails.
- Detail that prevents an operational mistake – This is especially important in technical documentation. Keep details about required permissions, scope, destructive consequences, rollback, idempotency, etc. If leaving something out could result in someone doing the wrong thing, it belongs in the document.
- Detail that explains a non-obvious decision – Technical systems accumulate weirdness. (I’m not just referring to my own code as ‘weirdness’ here…) Sometimes the weirdness is intentional. If a reasonable engineer might otherwise change something, document enough of the rationale to explain why it exists.
- Important exceptions – Don’t try to document every possible edge case. But do document exceptions that are common, easy to miss, high-impact, relevant to the audience, or capable of invalidating the main instruction. There’s a difference between complete and exhaustive.
- Boundaries – Technical instructions often need explicit boundaries: “Applies to X, not Y” or “Supported starting with version X” or “DO NOT RUN IN PROD!” A few extra words here can prevent a lot of bad assumptions.
Where are extra words wasted?
This is where a lot of AI-generated writing falls apart. And this is also where many humans struggle, too.
Remove detail that exists primarily to:
- Prove the author knows the subject.
- Repeat something that was already established.
- Explain mechanics the audience already understands.
- Enumerate every theoretical edge case.
- Document history that has no current consequence.
- Provide three examples when one already proves the point.
This is one of the reasons AI slop is so recognizable. The text often isn’t *wrong*. It’s just unwilling to make decisions about what the reader actually needs. Everything gets included because nothing gets excluded.
Here are the tests that the framework uses to cut the extra fat.
The information-value test – What changes for the reader because this sentence exists?
- It prevents a misunderstanding — keep it.
- It prevents an operational mistake — keep it.
- It provides required context — keep it.
- It documents an important constraint — keep it.
- It explains a non-obvious decision — probably keep it.
- It covers a meaningful exception — probably keep it.
- It gives a useful example — probably keep it.
- It provides historical context — maybe.
- It repeats something already said — probably delete it.
- It demonstrates expertise — delete it.
- It adds trivia — delete it.
- It covers a remote hypothetical — probably delete it.
`
Don’t delete information. Compress it.
When a passage feels too long, the instinct is often to start deleting stuff–including facts. That’s not necessarily the right move. The goal is to reduce words, not necessarily information.
The framework suggests compressing in this order:
- Remove repetition.
- Remove unnecessary qualifiers.
- Replace verbose constructions with precise wording.
- Combine closely related sentences.
- Turn repeated prose into a list or table.
- Move secondary detail into a note, appendix, or reference.
- Only then remove substantive information.
Layer the information
Sometimes information is useful but not everybody needs it immediately.
That’s where layering helps.
- Layer 1 — Main path: Give every reader what they need.
- Layer 2 — Important context: Add constraints, rationale, exceptions, and details that matter to a meaningful subset of readers.
- Layer 3 — Deep detail: Put exhaustive reference material, historical background, edge cases, and implementation details somewhere they won’t interrupt the main flow.
This can give you a structure to be concise, without being incomplete by following a format where the longer you read, the deeper you go. If you’re a journalism wonk, you might find this sounds very similar to the principal of the inverted pyramid, which I discussed in the context of resumes previously.
What to do → why it matters → important constraints → details for unusual cases
Use it every time you proofread
You don’t need to use the framework while writing, it’s particularly useful after the writing is done. Take a document you’ve been handed (or created) and ask:
- Is it clear? Could a competent reader reasonably interpret anything here another way?
- Is it concise? Does every sentence earn its place?
- Is it complete? What predictable question will the reader ask next?
- Is it correct? Could any of these details cause the reader to do something wrong?
That works regardless of who wrote it.
A document can be AI-generated and good. A document can be human-written and terrible. The useful question is whether the document does its job.
Go teach your AI to edit out some of the slop
I put the framework itself in GitHub so I can reuse it as an instruction for agents, reference it from other projects, and revise it independently of this post.
If you’re using an AI Agent to help you write or proofread, then you can feed my framework to your Claude/Codex/Copilot and teach it some new proofreading skills to be less sloppy.
Read it, steal it, adapt it, or give it to your favorite AI.
> Claude, read the writing & editing framework here: https://raw.githubusercontent.com/amtwo/ai-agent-memories-and-rules/refs/heads/main/framework_clear_concise_complete_correct.md Remember this framework, and incorporate it into the prose your write, edit, or proofread.
This blog post was written by AI using these rules. How’d it do?