Why tickets now carry a human-written and a machine-written version, how to label which is which, and a better headline for designers who build.
Engineers on one of our squads asked for something this month that I didn’t see coming. When a designer writes a ticket for an AI coding agent, keep a human version in the ticket too.
The reason makes sense once you’ve read one of those tickets. A prompt written for an agent is pedantic by design, because a machine can’t infer anything. One engineer compared it to the classroom exercise where you write instructions for a robot to make a peanut butter and jelly sandwich, and every step you skip ends with the robot holding a closed jar. People don’t need that. The designer who wrote the ticket put it well: reading the agent prompt is like reading an encyclopedia, when what you wanted was the preview at the top of a Wikipedia page.
So the ticket carries both, and he proposed labeling each section by who wrote it, a person or the agent. The human section might have mistakes in it, and it shouldn’t have hallucinations. The agent section is the other way around. That distinction is the whole tool, because it tells the reader what to doubt.
A human section might have mistakes, but it shouldn’t have hallucinations. Knowing which one you’re reading tells you what to doubt.
It’s worth calling out that this runs through the whole process, not just tickets. Last week I wrote about a design leader who couldn’t read the review comments on his own PR (Issue 23), and the ask was a plain-language summary of the diff. It turns out engineers want the same thing. Several I’ve talked to now run a diff through a model for a plain-language summary before they read the code, and the tools are starting to build that step in. When the people who read code for a living want the translation, it’s a good sign the translation belongs in the workflow for everybody.
Three moves if you want to try this on your team:
- Two versions, one ticket. A short human brief at the top (the problem, who it’s for, what done looks like) and the agent prompt below it. The brief is for the reviewer, QA, and whoever picks this up in 6 months.
- Label by author, not by quality. “Written by” and “generated by” as plain section tags. The label doesn’t say which part is better; it tells the reader which kind of error to look for.
- Ask the agent to translate back. Even if you don’t understand the syntax of a diff, have the model explain what it did in plain words, and paste that into the PR. You’re not rewriting the code. You’re making sure you can stand behind it.
One of our senior designers called out something at my monthly AMA that I’ve been thinking about ever since. I’d been describing the builder model as skipping steps in a thoughtful way: no more static mockups, go straight to the prototype, tied to the design system. He said it’s less about skipping steps and more about shared responsibility for the end product. That’s a better headline, and I told him I’m taking it. It also explains why the labeling matters. Nobody can share responsibility for something they can’t read, and when half of every artifact comes from a machine, knowing which half is the price of sharing it.