In Part 1, we looked at how AI is becoming both the coder and the client of our software, and how that client reads every word literally.
Because our customer is changing, our job shifts too. Writing instructions, labels, and error messages for an AI is a brand-new kind of literacy. And like any literacy, you usually learn it by getting it wrong first.
How a helpful guess becomes a silent failure
I learned this the hard way with a small tool I built to open customer support tickets. An AI assistant used it to log a request and left out the customer's email address. A human employee looking at a blank email field would have stopped and asked.
Instead, my software tried to be helpful. I had never written down what to do when the email was missing, so it guessed on the AI's behalf and quietly used the bot's own service account as the customer. The ticket was filed neatly, and every reply went straight back to the bot. The real customer never heard a word.
Two things guessed that day. The AI didn't ask for the email, and my code filled in the blank. Neither one raised a flag.
The eager reader
For decades, software had strict gatekeepers. Compilers and rigid forms acted like brick walls: give a computer bad or incomplete input, and it simply refused to run. The compiler was never the point. It was a reader standing between a person's idea and a real-world result.
AI stands in that same place, with one big difference. Where the old reader rejected bad input, this one is eager to please. It accepts incomplete input, fills in the blanks with its best guess, and ships the work anyway.
Turning error messages into signposts
I often label things too optimistically and assume context that isn't there. A human colleague can read between the lines. A literal-minded machine believes every word on the page, including the bad assumptions I left behind.
When we build tools and workflows that AI will operate, our priorities flip:
- A clear label matters more than a clever one. If a button or field has an ambiguous name, the AI will eventually guess its purpose wrong.
- One honest sentence about when to use a tool matters more than a manual of background theory.
- An error message that explains what to do next matters far more than one that simply says "Error."
In traditional software, flashing a vague "400 Bad Request" or "Invalid Input" warning was normal. A human would see the red box and figure it out. When an AI hits a vague error message, it often hallucinates a workaround just to finish the task. My ticket tool was worse. It didn't return a vague error. It returned no error at all, just a cheerful "201 Created."
I fixed it in two places, both written for the machine that reads them. Before the call, the tool's description now says to ALWAYS pass the real customer's email, and what happens if you don't. After the call, the result carries a signpost for the mistake that slips through anyway:
Warning: 201 Created, but the requester is the bot's own service account, so every reply goes to the bot and not the customer. Next: call create_ticket again with the real customer's email.
The description stops the mistake before it happens. The signpost catches the one that gets past it, and tells the agent what to do next instead of just saying something went wrong.
There was a catch I didn't see at first. Read that signpost again. It says to call again with the real customer's email, but never says what to do if the agent doesn't have one. An agent in a hurry will simply guess again. And every signpost I write well for a machine is one more problem a person never hears about: the agent reads it, fixes itself, and moves on. For a badly formatted date, that's fine. For a fact only a human knows, it isn't.
So I changed it. The signpost now says: if you know the customer's email, call again with it. If you don't, ask the user. Do not guess. Either way, tell the user the ticket belongs to the bot. Write the message for the machine, but make sure a person hears about the problem.
Notice what I didn't change. The call still returns 201. I kept it that way so I can show the scar in my talks, and it means an agent in a hurry can still read right past the warning. That gap is what Part 3 is about.
I expect that within a few years most error messages will be read by a machine first, and by a person only when the machine gives up. Write them for that reader, and teach it when to give up.
If a literal-minded robot filled out your team's most important internal form tomorrow without an ounce of common sense, which field would it guess wrong? Let me know on LinkedIn.
Cheers,
Markus
No bug 🐛 too small, no syntax too weird 🔍 🧐 🔨 🦾