The honest view from inside technical leadership
Analysis

Culture

Field notes on how engineering teams work, communicate, and decide together as AI changes the job.

Culture · Response

AI Writing Policy for Engineering Teams: Which Opinions a Human Must Write

An AI writing policy should sort messages by what the reader relies on. Honeycomb’s four categories show which opinions a person must write themselves.

Line-art illustration of a handwritten letter with a signature beside a stack of machine-generated pages, representing an AI writing policy for human-written opinions

An AI writing policy for engineering teams should name the messages a person must write personally, and a recent article by Sarah Wells argues that personal and professional opinions belong on that list. This piece takes that one claim and tests how a team could apply it.

Wells says opinions need a human author

Wells is introducing the themes she plans to follow as an editor. One of them is keeping human connection as teams get smaller and more work passes to agents. She worries that teams may lose the context-sharing, learning, and challenge that come from working together. To make the worry practical she points to the AI norms series Charity Majors published at Honeycomb, and in particular to its sorting of communication into personal opinions, professional opinions, prose artifacts, and code.

Her conclusion is short: "The first two of these need to be human, not agent-written." She also expects more agreement over time on how to state the level of AI used and where to avoid it completely in writing.

An AI writing policy should sort messages by what the reader relies on

Honeycomb’s third AI norms post, published by Charity Majors on 9 September 2026, gives each category its own expectation. Personal opinions should stay personal, because using AI there tends to destroy trust instead of building it. Professional opinions can be organized, structured, or polished with AI, but they should remain recognizably the author’s. Prose artifacts are reviewed by reading, so the group improves the ideas through comments whoever owns the document. For software artifacts, the post says to defer to the machines for testing wherever possible, while merging code still requires that a human has read it.

Read together, the four rules follow one logic. In an opinion, the reader is relying on the judgment of the person who sent it. In an artifact, the reader is relying on content that can be inspected and corrected. A team that wants a policy it can actually apply can sort every message type by that question. If the reader relies on the sender’s judgment, the sender must supply it. If the reader can inspect the content on its own merits, the tool matters less and the review step matters more.

Honeycomb’s first post in the series, published on 20 August 2026, states the underlying duty for customer-facing prose in one sentence: "If your name is on it, you own it." That sentence turns a writing rule into an accountability rule, and accountability is the part a leader can enforce.

Review duties are easier to enforce than authorship rules

A rule that says "write this yourself" invites an argument about detection, and nobody can reliably prove how a paragraph was drafted. A duty to own the message does not depend on detection. Camille Fournier’s guidelines for respectful use of AI, published on 31 May 2026, give two tests that a manager can ask about. The first is "Don’t ask someone to read/review what you haven’t read or reviewed yourself." The second is whether the sender can describe the document and discuss its concepts with others. For a document the sender does not fully understand, she suggests a caveat such as saying it is AI-generated and asking for help. Her post does not set a formal disclosure rule, and she presents her own statement that her post is human-generated as personal practice.

These tests apply the Honeycomb logic at the moment of use. A sender who can defend a recommendation in a live conversation, without the tool open, has supplied the judgment. A sender who cannot has passed the tool’s judgment along under their own name. The policy I would draft for a team has three lines: opinions the sender must be able to defend unaided, artifacts the sender must have read in full before asking anyone else to, and any use of AI beyond polish disclosed to the reader who is relying on the message.

The boundary between opinion and artifact is blurry

This sorting has limits, and a team should say so in the policy. A design document is a prose artifact, and it is also a vehicle for a recommendation, which is a professional opinion. A postmortem records facts and also assigns weight to causes. For mixed documents, the safer reading is that the recommendation and the causal judgment fall under the stricter rule, and the surrounding description falls under the artifact rule.

There is also a counter-case for AI assistance. Honeycomb allows polish on professional opinions as long as they stay recognizably the author’s, and that allowance matters for engineers writing in a second language or struggling to organize a long argument. A blanket ban on AI in opinion writing would remove a real benefit from them. The test is whether the author can defend the content, which leaves room for assistance that improves clarity without replacing the author’s judgment. Finally, I am not aware of a primary study that shows how readers weigh disclosed AI involvement in workplace opinions, so I treat the trust claim as Honeycomb’s experience, and I would treat any firm statistic on it with caution.

Why This Matters for Engineering Leadership

Engineering leaders already rely on written opinions to make decisions about architecture, hiring, risk, and priorities. When agents write more of the text, the volume of opinion-shaped writing can rise while the number of people willing to stand behind it stays the same. From an AI governance view, accountability needs an identifiable person whose judgment is on the record. A short writing policy that names which messages carry personal judgment, and who owns them, protects that record before a dispute tests it. Wells expects consensus to form over time. A team that writes down its own version now will not have to wait for it.

FAQ

What should an AI writing policy cover?

It should say which messages a person must write personally, which can be AI-assisted, and who is accountable for each. Honeycomb sorts communication into personal opinions, professional opinions, prose artifacts, and software artifacts.

Does Sarah Wells say opinions should be written by humans?

Yes. In her article she says the first two Honeycomb categories, personal opinions and professional opinions, need to be human and not agent-written.

Can AI help with professional opinions at Honeycomb?

Yes. Honeycomb’s norms say AI can help organize, structure, or polish a professional opinion, as long as the message remains recognizably the author’s.

Who is accountable for AI-assisted prose?

The person whose name is on it. Honeycomb’s first AI norms post says, “If your name is on it, you own it.”

Should you ask colleagues to review AI-generated text you have not read?

No. Camille Fournier’s guidelines say not to ask someone to read or review what you have not read or reviewed yourself.

Where does an opinion end and an artifact begin?

The line blurs in documents such as design docs and postmortems. This piece suggests applying the stricter opinion rule to the recommendation and causal judgment inside them.

Source: 5 shifts I’m watching as LeadDev’s new Editor at Large by Sarah Wells, LeadDev, 15 October 2026.

Read more news & analysis