Field Note 26current

LLM-assisted content needs no disclaimer, only a human who can back it

Drafting engineering content with an LLM needs no disclaimer — inside a team or codebase that already shares the co-sign norm. The obligation is human co-signing. Writing for strangers inverts it: there, stating your policy builds trust rather than diluting a default.

By
Theo Zourzouvillys
Published
Tags
principlesprocessllm

TL;DR

Using an LLM to draft or polish engineering content — team-chat messages, commit messages, PR descriptions and review comments, design docs, READMEs, code comments, anything with words — is fine and requires no disclaimer. The working assumption should be that any content published under a person’s name has been read and is stood behind by that person: they drove it, checked it, and own every word, regardless of what tool produced the draft.

The one obligation this places on you: meaningfully co-sign everything that goes out under your name. You drove the substance, you read every word or line, you agree with it, and you can defend it as if you’d typed it yourself. If that’s true, ship it with no annotation. Three carve-outs to the “no disclaimer” default: disclose when the ideas are the model’s and you can’t personally back them (you’re forwarding what your tool found, which is valuable but isn’t yours), never let an agent publish under your name unsupervised, and say how you work when you’re writing for strangers — in public, the co-sign is not a shared assumption, so stating it is the only way it reaches the reader. Don’t add 🤖 / ~ AI signatures to content you’ve actually reviewed — it implies the absence of the human co-sign that should always be present.

The scope of the no-disclaimer default is a shared context. It holds inside a boundary where the co-sign norm is already understood and agreed: a team, a repo, a review culture — and in code, where a personal LLM policy governs and everyone reading has the same expectations. Outside that boundary the default does not travel, and the reverse applies.

Context

LLMs are now in the daily loop for most engineers. A common and genuinely useful pattern: drop a few bullet points with the argument you want to make, and the model returns a tight paragraph that lands the point better and faster than you’d have written by hand. The ideas are yours; the words are the machine’s.

This makes people uncomfortable, and the discomfort splits into two different worries that get conflated:

  • “Am I passing off a robot’s writing as my own?” This leads people to add a signature — a 🤖 emoji, a ~ AI tooltip — to LLM-assisted comments, especially when posting many from their own account. The fear is that readers will think the author isn’t taking the work seriously.
  • “Is content going out that no human actually stands behind?” This is the real problem. Such a signature does nothing to address it, and the absence of one does nothing to cause it. The failure mode is content — signed or not — that the named human didn’t drive, didn’t read, or can’t defend.

Most tools have no native “this came from an agent” flag, so the workarounds are ad-hoc in-band signatures. The result is an inconsistent, per-person convention where the same LLM-assisted-but- human-reviewed paragraph is annotated by one engineer and not another — which trains readers to read the annotation as signal when it carries none. Inconsistent norms about something this frequent are a tax on everyone; better to settle one default so engineers stop walking the line case by case.

Recommendation

Assume all content published under a person’s name is human-reviewed and human-co-signed. Using an LLM to generate, draft, summarize, or polish that content is a normal engineering tool, like a calculator or an IDE refactor. It requires no disclaimer.

What “meaningfully co-signed” means — the bar every piece of published content must clear, LLM-assisted or not:

  • You drove the substance. The point being made, the decision being recorded, the argument in the review — that’s yours.
  • You read every word or line that goes out under your name.
  • You agree with and understand all of it. Not “it looks plausible” — you can be questioned on any sentence and defend it.
  • You can stand behind it as if you’d typed it yourself, because for all purposes that matter, you did.

If content clears that bar, publish it with no annotation. Do not add 🤖, ~ AI, or similar signatures to human-reviewed content. Such a marker implies that unmarked content carries a stronger human guarantee — and it doesn’t, because the human co-sign is always present. The signature inverts the default and quietly erodes it for everyone.

Three things this default does not cover:

  1. Disclose when the ideas aren’t yours — and do it freely, because it’s useful. When the model suggests something you find valuable but cannot personally back — an approach you didn’t think of and can’t fully evaluate, a fact you haven’t verified, a conclusion outside your competence — say so. Framing it explicitly (“here’s what my robot thinks about this — I can’t fully back it”) is not a confession; it’s a contribution. You may lack the context to evaluate it, but someone else might, and a model’s conclusion they can validate is genuinely valuable. The disclosure is about authorship of the idea, not authorship of the words — and here the right default is to share generously rather than stay silent.

  2. Never let an agent publish under your name unsupervised. Content reaching any shared surface under a human’s identity without that human having reviewed it is irresponsible and breaks the co-sign. Autonomy in doing work (drafting, searching, refactoring locally) is encouraged; autonomy in publishing under your name is not. The human is the gate before content goes out, every time.

  3. Writing for strangers is the one place a disclosure earns its keep. Everything above assumes a shared context — a team, a repo, a review culture, or a codebase where a personal LLM policy is the understood default. Inside that boundary the co-sign is a standing guarantee, so a marker adds nothing and quietly implies the unmarked work carries less of one. Outside it, none of that context travels with the text. A reader who does not know you has no way to know what you hold yourself to, and silence is not read as a strong default — it is read as nothing at all. So in public writing, state the policy: how you work, and what you still owe the reader regardless. Done that way it is not a hedge, and it is not the robot emoji — it is an accountability claim, and it builds trust rather than diluting a default. The failure mode this whole note is about is content nobody stands behind; saying plainly that you stand behind this one is the same argument, addressed to someone who cannot take it on faith.

Scope: this covers engineering content — anything with words an engineer publishes in the course of the work — and the no-disclaimer default within it assumes readers who share the co-sign norm. It is not a policy on LLM-generated code (code is governed by review like any other code), nor on product features built on LLMs, nor on customer-facing copy with its own brand and legal review. For public, personal writing, carve-out 3 governs rather than the default.

Consequences

Easier:

  • Engineers stop walking the line on every LLM-assisted comment. The default is settled: review it, own it, ship it, no annotation.
  • One consistent norm instead of per-person signature conventions that mean different things from different people.
  • The useful pattern — bullet points in, tight prose out — is unambiguously endorsed, so people use the tool that makes their communication clearer instead of feeling vaguely guilty about it.
  • A reader knows a human stands behind a comment because that’s the shared guarantee, not something inferred from the presence or absence of a robot emoji.

Harder:

  • The co-sign bar is real work. “Looks plausible” is not “I understand and agree with every line,” and the gap is exactly where un-reviewed LLM content slips out. The ease of generating volume makes the temptation to skim larger.
  • Judging when an idea has crossed from “mine, phrased by a machine” to “the machine’s, forwarded by me” takes honesty with yourself. When unsure, disclose.

New obligations:

  • Before publishing anything LLM-assisted under your name, clear the co-sign bar above. If you can’t, do the work until you can, or disclose that you’re forwarding the model’s idea.
  • Remove existing 🤖 / ~ AI style signatures from human-reviewed content; they cut against the default rather than supporting it.
  • Don’t wire agents to post under your identity without a human review step.
  • The flip side of “no disclaimer needed” is that you can no longer hide behind the tool. “The model wrote it” is not a defense for anything published under your name. You co-signed it; it’s yours.
  • You now have to notice which side of the boundary you are on. The same paragraph, posted in a team channel and posted on a public blog, wants opposite treatment — silence in the first case, a stated policy in the second — and the deciding question is only ever whether the reader already knows what you hold yourself to.

References

  • ZFN-1Field Note · currentZFN-1 — Keep engineering decision recordsRecord significant engineering decisions as short, versioned markdown files — context, decision, consequences. Write one for cross-team contracts, directional principles, hard-to-reverse choices, and conventions others must follow. Cite them instead of re-arguing.Open ZFN-1 → — the directional-record shape this follows.

Changelog

  • 2026-08-19: Scoped the no-disclaimer default to a shared context — a team, a repo, a codebase with a personal LLM policy — and added carve-out 3: in public writing, for readers who do not know the author, stating the policy builds trust rather than diluting a default. The position within its original scope is unchanged; what was implicit about that scope is now written down.
  • 2026-06-12: First published as a Field Note.