Journal · The AI Architect · 2026-08-01
Send it to yourself first. See exactly what an automation produces before you point it at anyone real.
Send it to yourself first. See exactly what an automation produces before you point it at anyone real.
The gap between “I built this” and “this works” is where most automation problems live. You test the logic. You check the trigger. You confirm the API call went through. And then, weeks later, someone tells you the automated email addressed them as “Hi {{first_name}},” and you realize you never actually looked at what a real recipient saw.
This isn’t carelessness, exactly. It’s a trust problem. Once a system runs correctly a few times, we start trusting the mechanism instead of checking the output. The automation becomes a black box we glance at rather than a product we inspect. And the more steps you chain together, the more that gap between “ran without error” and “produced something good” quietly widens.
The output is not the same as the logic
When you build an automation, your attention naturally goes to the parts that feel like engineering: the conditionals, the data mapping, the sequencing. That’s where the puzzle is, so that’s where the satisfaction is. But the person on the other end never sees your logic. They see a message, a document, a notification. They see the output, full stop.
This means the thing you’re least likely to scrutinize closely is the thing your reader will judge entirely. A perfectly correct workflow can still produce something tone-deaf, confusing, or oddly formatted, because “correct” and “good” are different tests. Your automation can pass the first and fail the second without you ever knowing, because you were watching the wiring, not the result.
Try this: before launching any automation that touches another person, route its very first output to yourself. Not a test environment. Not a log file. Your actual inbox, your actual phone, your actual calendar. Read it the way a stranger would, cold, with no context about how it was built.
Distance reveals what proximity hides
There’s a particular kind of blindness that comes from building something. You know why the message says what it says, so it reads as reasonable to you even when it would confuse anyone else. You know the trigger conditions, so an edge case that produces something strange doesn’t register as strange, because you understand its cause.
Receiving your own automation strips that context away, at least partially. You get a small taste of what it’s like to encounter the thing with no explanation attached. Is the subject line clear? Does the message assume information the recipient doesn’t have? Does the tone match how you’d actually talk to someone, or does it carry that faint robotic stiffness that creeps into automated text? You often can’t answer these questions by reading your own code. You can answer them by reading your own inbox.
This matters more as automations get more consequential. A malformed welcome email is embarrassing. A malformed automated response to a customer complaint, an automated scheduling conflict, an automated billing notice, these carry real weight. The more the output matters to the person receiving it, the more that self-test becomes not a nicety but a basic form of care.
Build in the pause before you build in the scale
The appeal of automation is that it removes friction. But removing friction between you and the output is not the same as removing friction between the output and the world. Sometimes what looks like inefficiency, that pause where you send it to yourself and actually read it, is the only checkpoint standing between a flawed system and a hundred people receiving that flaw simultaneously.
This is especially true for anything with a feedback loop that’s slow or invisible. If an automated message annoys someone, they usually don’t tell you. They just quietly think less of whatever sent it. You won’t get an error message for “this was slightly off-putting.” The only way to catch that category of failure is to encounter the output yourself, before it’s scaled.
Try this: for any automation that sends more than one message, run it against a small, fake batch first, three or four dummy variations, to catch edge cases your primary test won’t reveal. Then let it run once more, live, to you specifically. Two checkpoints, not because you don’t trust your own testing, but because logic-testing and reader-testing catch different things.
None of this requires elaborate infrastructure. It requires the discipline to add one extra step before flipping a system loose: stand in the recipient’s place, even briefly, before anyone else has to.
I go into more depth in the book about how this habit scales as automations get more complex, chained together, or dependent on external data you don’t fully control. But the instinct underneath all of it is the same one described here: look before you point.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.