This is article 3 in the series "The Art of Not Telling." It lays out symptoms that go wrong and their remedies, one at a time. Each article is finished once you put down a single file or script. Why that mechanism is needed becomes clear when you read the explanation afterward. The whole picture and the list of articles are in the introduction.

This time it is about how I tell the AI that something is broken. Which screen it was on, what I did, what came out. I used to write that out myself, every time. I do not write it now. I just run it, copy it, paste it. The information I had been copying out was something the screen knew in the first place.

In article 6 of the previous series, "The Art of Not Listening to the AI's Opinions," I wrote that a bug in production arrives from the person who hits it. One of the places it arrives is the bug report form. In that article it was a net for piling up in front of a human what a program cannot judge. This time I am the one using that same form.

Start by recalling just one thing.

The text you typed the last time you had the AI fix a bug. The steps to reproduce, the URL, the wording of the error, the browser.

Of that, how many lines were things only you could have written?

CC BY 4.0

What I was writing was what the screen already knew

A bug report takes time to write. Which URL. Which song. What you clicked. What was showing in the console. The size of the screen. You finish writing, hand it to the AI, get asked back for what is missing, and open the screen again to check.

What I noticed while writing was that most of it I was copying out of the screen. The URL is there in the address bar. The error is there in the console. The screen is right there. The only thing I know and the screen does not is the one sentence saying what struck me as wrong.

The production project on my own machine (typingtube, a web service for practicing typing along with music videos on YouTube) has a bug report form for its users. From one day on, I started sending the bugs I found myself through that form as well. I did not build a separate entrance for the operator. I press the same form the users press, on the same screen.

What I understood fits in one sentence.

The details of a bug are not something a human recalls and writes down; they are something the screen on the spot already knows. So instead of writing them, you let the screen collect them and paste what it collected.

The mechanism: keep the only thing a human types to the one sentence about the symptom

What you put down is 1 form. But it does not make a human write most of what it collects.

// app/javascript/controllers/feedback_controller.js (a shortened version of the code on my machine)
const payload = {
  category: this.categoryValue,                                  // just pick one (bug / request / wrong lyrics)
  comment:  this.commentTarget.value,                            // ← the one sentence about the symptom. this is the only thing a human writes
  page_url: window.location.pathname + window.location.search,  // where (the screen knows this)
  screenshot_data: includeScreenshot ? this._screenshotData : null,          // the screen itself (html2canvas)
  console_logs:    includeConsoleLogs ? getErrorLog().slice(-20) : [],       // the last 20. stack traces included
  screen_resolution: `${window.screen.width}x${window.screen.height}`
}

The server side adds the time of submission and the environment to that. All a human types is the one sentence about the symptom and 2 checkboxes.

A report that arrives lines up on the admin screen as one set. The page URL, the category, the environment, the screenshot, the console logs, and the one sentence about the symptom. What I do is open that page, copy all of it, and paste it to the AI. No words need typing. The moment it is pasted, everything needed to get started is there.

What is collected here is facts only. No guess at the cause, no way to fix it, goes into the form. The AI it is pasted to reads the code and decides that.

What I stopped writing

The steps to reproduce, the environment, the wording of the error. It is not that the reports themselves went down. I find just as many bugs as before. What went down is the step where I copy out what the screen already knows. What is left is the one sentence saying what struck me as wrong, and I still write that one myself.

Caveat: where there is no form, a human still writes it

One, if there is no form, I am still the one writing the details. The form is only on the path for bugs and requests; there is none for designing a new feature.

And building that form is not cheap. You decide the columns, wire up the submission, build the listing, give it a state. Stopping only the writing without doing that is not what this article is about.

Two, what the form collects is only what happened on that screen. Steps that start from a different screen, symptoms that come out after time has passed, do not make it into the form. For a bug like that, I write that fact into the one sentence about the symptom. Even so, the URL, the logs and the screenshot still come along.

Three, anything at all can end up in the console logs. On my machine I cut them at 2,000 characters per entry and 20 entries per submission, and both the client and the server hold the same limit (do not trust the caller). The thicker you make the collecting side, the more the sending side needs a line drawn.

How to verify: hand the same bug over in 2 ways

Prerequisites

  • You can do this without a form
  • You have 1 bug you can reproduce on your machine
  • You can start 2 sessions

Time required: 15 minutes

Steps

  1. You hand the 1st session only the one sentence about the symptom: "typing goes weird sometimes." Do not write the URL, or the wording of the error, or the size of the screen
  2. You write out, as they are, the items it asked you back for. You do not ask for a fix yet. That list is what this verification produces
  3. You hand the 2nd session the same bug with the materials attached: the page URL, the console logs, and the screenshot, 3 of them. You keep the one sentence about the symptom the same as in the 1st

Pass conditions

  • The AI in the 2nd session goes into investigating the cause without asking anything back

If it does not pass

  • It asked you back in the 2nd session too — that item is not in the 3 materials. Add it to the list from step 2. That is a column your form should be collecting

Cleanup

  • None needed. You have not had either session fix anything yet

What comes out of step 2 is usually the URL, the steps to reproduce, and the environment. That is what the form collects in your place. Before you build a form, this comparison of 2 runs lets you decide the columns.

Next time, the art of not asking for a plan. I have never once asked the AI to "write a plan." Even so, there are 200 plan documents.

Series: The Art of Not Telling