You Own What You Send

AI has made it very easy to produce text, including a blog post 😅. A few prompts and you have a design document, a PR description, a product requirements doc with six numbered sections and a tidy summary at the bottom. The words are coherent. The structure is sensible. The formatting is clean.

Nobody can really complain about any of that.

But your colleagues still have to read it. Reading takes time. Figuring out what someone meant takes more time. And time is the thing everyone on a busy team is quietly short of.

Generating text is not communicating

Communication is not about producing output. It is about transferring understanding from one person to another. When you send something, you are making an implicit claim: “I thought this through, and here is what I want you to know.”

That claim does not change because an AI helped with the words. You are still the sender. You still own the message. The name in the from field is yours.

The question is not whether AI helped. The question is whether the thinking happened before the sending, or whether you quietly handed that cost to the reader.

There is a version of this that works fine. AI helps you structure something you already understand. You review what it produced, cut what is redundant, write the summary yourself, and send it. That is using a tool.

There is another version. You generate, skim, and send. Your colleague does the work of figuring out what you meant, what you need, and whether the thing is even ready for review. That is not using a tool. That is outsourcing the thinking. And the invoice arrives in someone else’s inbox.

Performance pressure makes this worse

Most teams reward visible output in some form. Tickets closed. PRs opened. Documents written. Emails sent. These are easy to count, so they start to feel like progress.

AI makes that pressure easier to satisfy. You can create more tickets, longer descriptions, and fuller documents in less time. But the judgment required to validate that output does not get faster just because the writing did.

The cost does not disappear. It moves. AI-generated tickets created across separate sessions can contradict each other or carry different versions of the same requirement. A person writing them across a sprint would probably notice the inconsistency. An AI prompted in isolation often will not, and the team pays the cost in confusion, rework, or arguments in planning.

None of this is bad intention. It is what happens when generation is free but communication discipline is not automatic.

What it looks like in practice

A PR description that walks through every changed file in full prose, but does not say why the change was made or where a reviewer should focus. The diff already shows what changed. What the reviewer needed was the why and where to look.

A PRD with a context section, a goals section, a non-goals section, a constraints section, an assumptions section, and then a solution section that is vague about the actual decision. The document is six pages long. The decision has not been made. The author spent their time generating; the readers will spend their time parsing.

A design document with three pages of background written to think out loud. Useful process for the author. But it got sent because writing it felt like progress. Now six people are in a review meeting trying to figure out what they are being asked to decide, and the meeting ends with a follow-up scheduled for next week.

In each case, text was produced. In each case, communication was incomplete. The generation was fast. The thinking arrived later, if at all, and often in someone else’s head.

A few things that actually help

Write a short human summary at the top. Not generated, not polished: just one or two sentences in your own words. What is this, and what do you need from the reader? If you cannot write that summary without help, the document is probably not ready to send.

This forces the thinking to happen before the sending. It also signals to your reader, immediately, that you did the work. That matters more than people say out loud.

Match the length to what was asked. Nobody asked for a book. A PR description longer than the diff it describes has a problem. A PRD that takes forty minutes to read has a scope problem, a writing problem, or both, and it is worth figuring out which before asking several people to block off an hour.

If AI helped you write something and it came out long, ask it to cut by half. Then read what remains. What survives is usually closer to what needed to be said. Brevity is not laziness. It is respect for the person reading.

Understand what you are sharing before you share it. This applies to code as much as to prose. If you open a PR with AI-generated code you have not fully read, you have handed a comprehension problem to your reviewer. They will spend time understanding something you have not understood yet. That is not a code review. It is a debugging session on someone else’s time.

There is also the reviewer side to consider. Before AI-generated code was common, at least one person had read or written every line that went to review. Now there is a real chance nobody has. A reviewer hitting the fourth thousand-line diff of the day, under delivery pressure, may approve without fully understanding what they are looking at. That is not a personal failure. It is a structural gap the team needs to account for.

The same test works for documents. If you cannot explain in one sentence what the document recommends, it is not done yet.

Push back when something you receive is too long. This goes both ways. If a colleague sends ten pages and asks for feedback by Thursday, it is reasonable to ask: “What is the core question here? Can we start there?” That is not an unhelpful response. It is often a more useful one than dutifully working through every section and leaving comments on paragraphs that probably should not have existed.

Most long documents have a shorter document inside them. Helping someone find it is a real form of collaboration.

Your colleagues will notice

There is an upside to taking communication seriously that does not get mentioned enough: people remember who is easy to work with.

The teammate who writes a PR description that makes reviewing fast. The person who sends a one-paragraph summary instead of a document-sized pre-read. The engineer who pushes back on their own generated output before it lands in the review queue. These people make the whole team faster. Everyone knows it, even if nobody says so in a performance review.

Communication quality is a kind of gift. It is invisible when it goes well and obvious when it goes badly. Most of your colleagues are carrying some amount of cognitive load at any given moment. Sending something thoughtful, right-sized, and clear is a small act of respect for their time.

AI can help you get there faster than before. It can help you draft, structure, and clarify. Use it freely.

But the thinking still has to happen on your side of the send button.