The reply nobody read: how we work with AI at Twipe

A few weeks ago a pull request landed in my review queue. For readers outside engineering: a pull request is when a colleague asks you to check their code before it goes live. This one was a modest change, one extra validation step in our content processing flow. The code looked fine.

I left one comment: “Have you checked what happens when a customer sends us an article without an author? I want to be sure we do not drop the whole edition over one missing byline.”

The reply arrived within two minutes and ran to four hundred words. It opened by thanking me for the thoughtful question. It summarised my comment back to me. It listed three considerations, each under its own heading. It explained how validation works in general. It closed by noting that both approaches have merit and offering to elaborate further. It did not say whether anyone had tried an article without an author.

I have received this reply, or one very like it, more times this year than I can count, and I suspect most people reading this have too. An LLM wrote it, that much was obvious, and I have no objection to that. My problem was that I could not tell whether a person had read it before it reached me. My question took thirty seconds to type. Answering it properly would have taken the author five minutes. Instead I spent those minutes reading four hundred words to learn that my question was still open.

Two problems hiding in one reply

The first problem is trust. Did the author think about my question, and did anyone check the answer? When I cannot tell, I stop taking replies at face value and start re-checking things I used to accept. That is slow, and between colleagues it is corrosive.

The second is readability. The reply was long and it committed to nothing. Reading it cost me more than writing it cost the sender. A perfectly reasoned answer still fails when it arrives like this.

These are two separate issues which require distinct fixes. Disclosure sounds like the obvious answer, but it does not solve either problem.

There is no fair line to draw. “Pasted unread” and “iterated ten times, restructured, kept only what I agree with” both count as using AI. Calling both cases “AI-assisted” does not tell the reader much. A label changes no decision either: I should be checking the claim whether it is marked or not. And it cannot be enforced, because people are bad at spotting machine-written text. A 2023 study in PNAS put human accuracy at roughly the level of a coin toss.

There is one exception. When nobody read a message before it went out, there is no author, and the reader deserves to know that. We handle it with identity rather than etiquette: bots post as bots, from their own accounts. Everything posted under a person’s name is that person’s.

The principles we keep coming back to

Agentic tools are part of normal work at Twipe now. That made it urgent to agree on what we expect of each other while using them. These are some of the principles we keep coming back to.

Whoever signs the code, the comment or the decision owns it, whatever tools were involved. A named engineer owns every ticket, however much of the work an agent did. A person with a name stands behind everything we ship and every answer we give.

Owning the work does not mean doing every step of it. As agents take on more, what the human owns is the goal, the limits, the evidence that has to exist before something ships, and the moments where a person steps in. Where it sits at any moment is a decision, and someone owns that decision too.

The oldest rule there is, and AI makes it easy to break by accident. The everyday case is a reply nobody would sit through, including the person who sent it. So answer the point first and add context only where it helps. Read what you are about to send as the person who will receive it. If you cannot put it in your own words, it is not ready.

AI can be wrong, but it is always confidently wrong. Check it as you would check work from a colleague you do not know yet. How closely we check depends on the work. A change that is tested, visible in production and easy to roll back can go out with a light look, whoever wrote it. Where the judgement is hard or a mistake is expensive, a person stays close. And when a reply feels hollow, do not try to guess from the writing style. Ask something specific about the content. If they engaged with it, a specific follow-up should be easy to answer.

Judging and deciding stay with people. Most of the rest, typing first and increasingly the steps in between, does not. The time this saves is what makes room for the first three principles.

Where that leaves us

Back to that pull request. The reply I wanted was two lines.

Yes. A missing author becomes an empty byline and a warning in the log. Test added in the same commit.

Ten seconds to read, and my question is closed. The author had probably done exactly that work. The verbose reply hid it.

Look at what the short reply contains: a test, in the commit, that I can go and read. My question was one of the moments where a person had to step in. In this case, the missing step was simply checking the edge case.

That is what AI-first means for us. People used to do every step. The job now is to decide what can safely be handed over, what evidence is enough to accept it, and where a person still has to be in the room. Do that well and the speed follows. Do it badly and you get four hundred words that answer nothing.

The principles above are not ours to keep. Take them, use them, and if you think one of them is wrong, tell us.