So when I decided to deploy bwak.email to my family’s email domain, theeberts.us, I was naturally terrified of how my wife, Charlotte, would accept the change.

There was no hiding behind a screen of anonymity like bwak.news afforded me. This time, the user lives under the same roof.

She watched me toil over its development. I reported the progress to her as I tested it on my personal email domain, k3bert.net.

She understands the concept; it’s a tool for controlling who sends you emails. You get an email from our bank, approve it. You get an email from a Prince from Sub-Saharan Africa; you deny it. The difference is, these decisions are made before the email lands in your inbox.

Not a spam filter.

Not inbox rules.

Just a gate; you control who gets to enter your inbox.

The software flips the script; instead of anyone with your address emailing you, they have to pass through a gate that you hold the key to. You don’t let them in; their email never sees the light of day in your inbox.

Until last week, the concepts were just that, concepts to her. She lacked any hands-on experience. The things I told her about what the software would do had no meaning until now.

This was the first time I got to launch software where the primary user lived under the same roof as I did. Her ability to understand and operate the software is the litmus test I’ll use to decide whether to take the software public.

So, I was excited and nervous.

I hit the deploy button and in the immortal words of Vivian Ward (played by Julia Roberts) in the movie “Pretty Woman”

Big mistake. Big. Huge.

You see, I did something stupid. Not only did I deploy bwak.email to the theeberts.us domain, but I also decided to move our primary email provider from Proton Mail to Apple’s iCloud Plus (iCloud+) at the same time.

You never deploy two breaking changes at the same time. Never. Full stop.

So, it won’t come as a surprise to you when I tell you that she went to the USPS website and signed up to receive delivery notifications for a package she was receiving later in the week. Bwak.email sent her the approval request, “Let USPostalService@usps.com through” and she clicked the link to approve, and nothing happened.

I swear you could see the blood leave my face. Something I had tested hundreds of times before didn’t work.

Digging through the logs gave me the error.

Blocked due to content: The message was rejected because it contained content that the recipient’s server doesn’t allow

And as if the software gods were watching and laughing at me, another approval request came in, this time from our bank alerting us to a new statement.

She approved it.

And again, nothing delivered.

I sent my own test message in from my Gmail account, approved it, and it works!

After digging through the Resend API documentation and a few expletives later, I found the root cause.

The way Resend forwarded the email to the inbox after approval broke the email’s chain of custody and removed the original DKIM signature. Apple was interrogating the message, recognizing it originated from the USPS. But without the original DKIM signature, it flagged the message as spoofed and would not deliver the forwarded message from bwak.email.

This behavior was different. All my testing to date used Proton Mail as my mail provider, but as part of this changeover, I moved the domain to Apple’s iCloud+ service for our mail hosting, essentially negating the months of testing I did with k3bert.net.

I had a choice to make: roll back to the last known good state, which meant moving back to Proton Mail and undeploying bwak.email from theeberts.us domain. This didn’t excite me; by now it was 1:30 AM and any rollback would be a three- to four-hour process.

Emails weren’t being lost; I still had the failed messages in the logs, but my wife couldn’t see them.

So I did the next logical thing, I forged ahead.

Forging ahead meant finding another mailing service, Mailgun, that had an API that supported forwarding original MIME-type messages, which meant the DKIM would remain intact.

On paper, it should work.

It took 12+ hours to set up the Mailgun account. There was a verification process I had to go through to prove ownership of the domain I was using, and to describe the system I built, which required a human to review and approve.

In the end, I swapped out Resend for Mailgun, and I was ready to test again.

I might be making it up, but I swear I saw the clouds part and the sun come through the moment Charlotte hit approve on the same USPS message from the day before, and bwak.email delivered the message.

You could hear Katrina and the Waves’ song “Walking on Sunshine” start up in the background. That was me, walking on sunshine and partying like you’d expect a 54-year-old retired technologist would party.

A few days later, Charlotte is managing our email domain theeberts.us like a boss. I’ve purposefully stepped back to let her go at it. I spent 60 seconds explaining how to use the app, and here she was a few days later, owning it, approving and blocking senders like the pro she is.

Interesting Read

This week, I’m adding a new section to the newsletter that you’ll see from time to time. It’s part experiment and part advertisement for bwak.news, the first app I built to bring to market.

The whole point of this section is that it’s a quick take on something I read over the last week that got me thinking, and I want to share.

Hiding Out — Seth Godin

Originally published via Seth’s Blog Newsletter: https://app.bwak.news/share/aoci2PpJ10w

My Take
I have a long history of playing things safe, or at least holding things close to my chest.

Safe works until it doesn’t.

Being reminded that time is batting a thousand for outing safety motivates you to bet on yourself.

Truer words couldn’t be spoken for where I’m at in my life at this point. I’m calling myself retired, but I’m learning I have a lot more to give. So recoiling into the safety of my home is no longer a stance I’m taking because time will out me.

What’s something you built, wrote, or made that you didn’t really trust was good enough? Not until someone picked it up on their own and got it, without you there to explain it?

—Kevin

I had my assumptions, but decided it was worth looking into further.

My first instinct told me this was a privacy nightmare, a case of false pretense, deceit, lies, or worse entrapment. I was having a visceral reaction of hell no, I’ll never set foot in a Waymo vehicle. I will not surrender any more of my privacy rights in the name of convenience in the surveillance economy.

I’m, of course, talking about the recent incident where Waymo stopped a vehicle and alerted local police because two teenage riders were acting suspiciously in the vehicle during their ride. The passengers were allegedly drinking and waving guns (that turned out to be toys). ^[1]

The story goes that suspicious activity was detected, alerted a Waymo employee who intervened telling the the passengers there was a “technical issue” with the car, advising that it was pulling over and that they should remain in the vehicle. Simultaneously, Waymo contacted the police, gave them the vehicle’s location, and kept it there until they arrived.

The police officers arrived on the scene and treated it like a high-risk traffic stop and proceeded to remove the passengers from the vehicle and ultimately took them home and didn’t arrest them.

After reading the article, I had questions and needed to research this further.

Did Waymo play judge, jury, and executioner?

Reading the article, that’s what every fiber in my body was screaming. But I’ve been known to overreact a time or two, and this was no exception.

As it turns out, no, not really.

Nearly a few dozen sensors are installed on each vehicle, both internally and externally. There are the obvious ones you’d expect any autonomous vehicle to have to drive safely, and there are the internal ones you might think about, but there are a few you may not consider. ^[2]

Internally, there are obviously the cabin cameras, seatbelt, door, and window sensors. Not so obvious are the weight sensors, smoke detectors, and microphones.

What is missing, though, is facial and voice recognition systems. ^[3]

And, according to the Waymo privacy statement and terms of service, the data collected is used to enhance the rider experience, improve vehicle operations, respond to emergency situations, and protect Waymo’s property. ^[4]

This data is not shared with law enforcement agencies unless requested through the normal judicial warrant process. They regularly receive and respond to these requests and assert that they follow the relevant laws of the jurisdictions in which they operate. No different of a stance than most technology companies take.

In the case of the two teenagers, the vehicle’s machine learning detected an issue from the data collected, involved a Waymo operator who decided there was enough concern to alert local police and suspend the ride so they could investigate.

So yes, Waymo alerted police, but they didn’t act as the judge, jury, and executioner. That was left to law enforcement and the district attorney.

What about privacy? Isn’t there a level of privacy you expect when riding in a taxi, ride-share, or autonomous vehicle?

At first glance, this screams of a privacy violation of sorts. People’s behaviors were monitored, someone was alerted, and action was taken.

But, as I thought through the situation, I found myself asking, what level of privacy do we expect when taking public transportation? Traditional taxi services? Or ride-share services?

In all of those cases, there is some level of human and autonomous observation, i.e., video recording, a driver, a conductor, an operator, and other safety sensors. So, you shouldn’t expect any specific level of privacy when using them.

Thus, I couldn’t see anything Waymo was doing that isn’t already being done through other modes of transportation. The primary difference is that the person isn’t in the same vehicle as you are; they are remote and interact with you in real time when required. But, they aren’t constantly monitoring the situation, AI is.

Take, for example, you jump into a cab and light up a cigarette; the cab driver is likely to turn around and tell you to put it out. Is that necessarily any different than an autonomous vehicle detecting the same behavior and asking you to refrain from smoking in the vehicle?

The more I thought about it, the more I couldn’t see any difference between the autonomous vehicle experience and other public transportation and taxi services when it comes to the level of privacy you should expect.

But, you have to admit the obvious, there is the layer of abstraction, filled by AI, that exists between the passenger and the Waymo employee that’s different.

When in a Waymo, are you aware that you are being monitored and recorded?

Yes-ish.

After watching a few different riders’ experiences on YouTube, you hear the car go through a series of instructions and disclosures when the passengers first enter the car and begin the ride.

The vehicles start with a confirmation of the destination, seat belt requirements, rider support button use, child seat safety, emergency protocol, no interference, and interior monitoring and microphones.

The announcement also covers the use of interior cameras to check on riders, analyze for product improvements, and more (see the next section). That’s the ‘ish’ in yes-ish, b/c what is more? The weight sensors? Door sensors? Window sensors? Other sensors?

The microphones remain off unless you activate them via a support request or when a situation requires them for two-way dialog with a Waymo operator.

The disclosure doesn’t get into how your data is collected and managed, or what your rights are regarding data privacy. For that, you have to use the app or go to their website.

So technically, you may hear that you are being recorded and monitored, but most people who sit down believe there is a level of privacy because a human is not present. Which is obviously different than when taking a taxi or other ride share service who have humans operators in the vehicle with you.

Is it an algorithm or human making the decision on what is suspicious activity?

Both.

Business Insider reports that “...Waymo hasn’t publicly disclosed the full range of behaviors its systems can recognize or exactly what prompts an employee to access a live feed.” ^[5] Nor will they disclose a full list of sensors they have.

But, Waymo does disclose that they leverage machine learning from the behavior detecting sensors, which trigger alerts to employees.

Only after anomalous events are detected will the vehicle engage with human operators from Waymo. These operators have access to all the sensors and internal camera feeds and can engage with passengers using the microphones and the car’s sound system.

In other videos I’ve watched, though, it doesn’t appear that these operators can remotely operate the car per se, like with a remote control car. ^[6] From the video, you can see and hear the operator clearly explaining to the passenger that they are sending recommendations to the car on how to proceed when it became stuck in a parking area. And when finally faced with the fact the vehicle would not continue, the operator had to ask the passenger to exit the vehicle and look for alternative transportation.

This was a startling finding. So, not only is an algorithm making the initial decisions on anomalous behaviors its sensing inside the car. The remote operators have limited abilities to take control of the cars driving. But, they have every tool available to monitor, observe, and communicate with the passengers, up to suspending the service.

Where does this leave me with my thoughts on autonomous vehicles?

After looking through the Waymo website, it’s clear that safety is a top priority. And this makes sense: if the vehicles and service aren’t perceived as safe, there is no way people will set foot in the vehicle.

But, for me, this is just as much about trust as it is about safety. There is a level of trust that has to be developed. And feeling save requires trust.

A vehicle that is instructed to pull over under the pretense of a technical issue when, in fact, authorities are alerted and en route to investigate doesn’t build trust. Especially when Waymo doesn’t fully disclose what behaviors or actions will trigger such escalations.

While the algorithm engages a person, that person hasn’t been like a driver interacting with you. They step in and review the preponderance of evidence in near real time AND after the fact, making a quick decision without any obvious direct engagement with you about the circumstances.

I’ve read enough of Waymo’s policies and watched plenty of videos to feel they are working with positive intent to build a safe and reliable product. But they are falling short in building a brand you can trust.

It’s naive to expect there not to be incidents involving riders in their vehicles, no different from incidents we’ve heard about with taxi drivers and ride-share services. But the major difference is an algorithm and AI sitting between the passenger and the operators: no dialog or interaction, sensors and an AI model deciding how to proceed. Sure, a human is introduced in the middle. For now. Will that remain the case as the service scales to more markets and the number of daily trips increases? Only time will tell.

And that makes riding in a Waymo vehicle or other autonomous vehicle service a hard pass for me. What about you?

References

1. Original incident coverage — NPR, “Waymo called the cops on teen riders, raising privacy concerns” July 10, 2026: https://www.npr.org/2026/07/10/nx-s1-5886113/waymo-police-privacy-driverless-autonomous-vehicles

2. Sensor/camera count — Waymo, “Self-Driving Car Technology for a Reliable Ride” (”There are 29 cameras on our Jaguar I-PACEs”): https://waymo.com/waymo-driver/

3. No facial/voice recognition; interior camera/microphone policy — Waymo Help Center, “Cameras, microphones, and related data processing”: https://support.google.com/waymo/answer/9190819?hl=en

4. Data use / privacy statement — Waymo Privacy Policy: https://waymo.com/privacy/

5. ML flagging + Waymo’s declined comment on full trigger list — Business Insider, Lloyd Lee, “Kids, rowdy riders, don’t forget: Waymo could be watching,” July 2026: https://www.businessinsider.com/waymo-cabin-cameras-monitor-teens-police-san-mateo-incident-2026-7

6. Sawyer Merritt, “I rode a Waymo robotaxi in Nashville. It didn’t go as planned...” July, 2026 — YouTube:

And before you start screaming at me, of course you need to disclose it; how can we trust anything you are writing if you are using generative AI for your writing?

I was right there with you 96 hours ago when I started this piece. It was going to be simple; yes, I use AI to help aggregate data on my tinkering. Yes, I fact-check everything I post. Yes, all the ideas I write about are my own. And finally, no, I don’t mindlessly post AI-generated text.

But as I researched the topic, I came to understand that this is not a binary conversation, and that the data and reasons behind disclosing the use of AI-generated text are more nuanced than they appear.

I hope this article helps you think about the topic in a different way.

You may have seen recent headlines.

LinkedIn introduces an “AI Slop” reporting tool to wage war against content quality on its platform.

Hank Green, a YouTube creator and educator, inadvertently admitted to using AI in his process during a video he recorded, prompting swift condemnation from many and bringing the generative AI disclosure debate into focus.

Anthropic is rolling out the ability to watermark AI-generated text in new models, to comply with EU regulation.

Substack partners with Pangram to provide an AI text scanner.

For this piece, I’m going to keep my argument and research centered on LinkedIn, Substack, and YouTube. These are my platforms of choice. I think much of what I’ll assert is valid in other platforms, but I’m not going to take the time here to make that point.

At the time of this writing, none of the platforms have taken a firm stance on outright requiring you to disclose the use of AI-generated content on their respective platforms, except for YouTube, but, as it turns out, their stance is limited to specific use and not necessarily far-reaching.

YouTube requires disclosure of AI-generated content when it results in realistic content that a viewer could mistake as being real. This includes synthetic voices, altered events, or fabricated photorealistic scenes.

This makes perfect sense; it’s a visual platform, and the disclosure focuses on the content displayed.

But what is exempt from their policy is the use of AI to create scripts, ideas, captions, animated content, or thumbnails. In other words, no need to disclose when using AI to help with structure and research, but required when dealing with voice and visuals.

LinkedIn and Substack do not have specific terms of use regarding generative AI on their platforms, but both have given readers tools to flag or check for it. LinkedIn gives you an “AI Slop” reporting button, and Substack lets you scan a piece using Pangram.

So, the case for disclosure is more of an ethical/moral/voluntary choice, not compulsory.

And to throw some fuel on the fire, a research article by Toff and Simon in The International Journal of Press/Politics^[1] asserts that when it is disclosed that AI was used in the writing of articles, trust in the content drops significantly, even though the articles are factually correct. The research also showed that this drop in trust is reversed when specific sources outside AI are used.

So, where does this put creators?

If you disclose your usage of AI, you may be labeled as untrustworthy, even if still factually correct. The damage is mitigated somewhat if you cite sources outside the AI sphere. Creators are also benefiting from using AI in their content creation processes.

But, as the late-great Paul Harvey liked to say, now for the rest of the story (or something like that).

Here is an uncomfortable truth that I suspect will have you throwing your shoes at me. Humans are barely more able to reliably identify AI-generated text than using a simple coin toss.

Yup, your ability to detect AI-generated text is only slightly better than tossing a coin.^[2]

I know, you don’t believe me. There’s the em dashes, the sameness in sentence structure. Lack of rhythm in the work. It’s not X, it’s Y. Not an original thought, etc.

Just head to LinkedIn and ask anyone; they’ll gladly proclaim they can, without a doubt, identify AI-generated text.

The data shows otherwise. People are confident about the wrong signals.

But there is actually one tell that is obvious and tips the scales in your favor: hallucinated facts and fabricated sources.

All at the same time now, “well no sh*t Sherlock.”

And that’s the point: for most people, human detection is more performative art than fact unless the text in question is factually incorrect and the sources are invalid.

It’s such a big point that the EU recently enacted the EU AI Act’s Transparency Code (Article 50(2)).^[3] It says several things, but most notably as related to this article:

AI models need to produce a synthetic content marking when it’s generative AI. This includes having the software machine-mark text, image, audio, and video output so it’s detectable as AI-generated.

There’s one important limitation to this legislation worth noting.^[4] The watermark ONLY proves the AI touched the content it’s producing, but doesn’t indicate who wrote it or how much of the text is generated; i.e., stuff heavily edited by a human after the fact will no longer necessarily bear the watermark. As such, the watermark isn’t enough to purely indicate that content is AI-generated, and thus any claims to be able to identify AI text are more performative than quantifiable.

So, this article is getting lengthy; let’s summarize quickly before moving on.

• We are more likely to distrust AI-generated content, even when factually correct.

• AI is proving to be a very effective tool for generating content and researching topics.

• People’s ability to identify AI-generated text is slightly better than a coin toss; the signals we rely on are unreliable. The ability to detect AI-generated text changes when it hallucinates or cites non-existent sources.

• Disclosing AI usage is more a matter of principle than a compulsory rule.

Where does this leave someone like me, someone without a well-known brand, but liked by my colleagues (for the most part), who is starting on a new journey to publish works in the public space? Should I or should I not disclose the use of AI as part of my workflow?

Interestingly, it was difficult to find straightforward examples of more well-known creators disclosing their use of AI. The few I found include Katie Harbath, Carlo V. Santiago, Hank Green’s personal policy, and Complexly’s institutional policy.^[5] And that was it. It’s not to say others don’t disclose their use, nor does it imply people aren’t being honest about it, but what it does signal is that the topic, while hot, isn’t necessarily being addressed by widespread acceptance of disclosing AI use.

For me, I’m all for disclosure. I’m beginning my creator journey, and it’s not just about publishing my thoughts, but about building trust in what I’m doing so I can share what I’m creating with you, and you can see my process.

In 2025, I started posting on LinkedIn to build a personal brand. It was more of an experiment than driven by a specific cause, and it yielded modest results.

When I began the process, I was all in, leveraging Claude to help generate content. This included taking my ideal customer profile (which AI helped me create) and asking about the pain points people were experiencing in my areas of expertise. I’d find a pain point and write my own thoughts around it, more of a brain dump than a structured article.

I fed my brain dump into an AI process I created, which helped me write two versions of the same article. The first was a story-based arc and the second was a contrarian take on the original idea. A third process compared the dueling articles, scoring them against an opaque rubric (again created by AI) and recommending which version to publish.

Maybe not ironically, the scores were often 39 out of 50 vs. 37 out of 50. Read into this what you will, but I find it funny that the two different arcs converged into near sameness when quantified by AI. The humor lands hard when looking back on that time.

Not only was there the sameness, but the articles that were being produced were flat, uninteresting, and void of soul.

The output I was reading looked eerily similar to so much of what I was seeing on LinkedIn. As it turns out, a peer-reviewed study confirmed that people who frequently use AI for writing are better detectors of AI-generated content.^[6]

I was producing AI slop. The same slop I rolled my eyes at so often when scrolling.

What was produced was a sanitized, watered-down version of a brief I fed to the AI that looked like so many other posts.

I tried to rewrite them to follow the arc of the winning article. If the measure of success for the posting was engagement and views, I had a few land well, but most of the articles posted didn’t move the needle.

The frustration was mounting with the lack of results, especially as I started writing more about the business I was starting.

Thinking the problem was that the output was lacking my voice, I launched into a 100-question interview of me to generate a voice profile to give to AI to make it sound more like me, an idea I took from Ruben Hassid’s newsletter article titled “I can be you.”

I reworked my dueling agent process to leverage my newly minted voice profile, and while the quality of the drafts improved and sounded more like me, the output was still flat and lacked soul, so I was rewriting it before publishing.

So, I pivoted my process to where I’m at today. I trashed the dueling agents and replaced them with a muse process I created that takes the output of my weekly tinkering, considers a backlog of article ideas I’ve generated based on things I’m reading, and asks me one question.

“What’s on your mind — tell me the idea or the moment, like you’re talking it through.”

It takes my long-form brain dump of an idea, often transcribed, and helps identify the threads to pull on, the ones to leave alone, and the ones to cut out altogether. It asks clarifying questions, restates what it understands, and iterates to help fully develop the article’s scaffolding. Not prose, just a scaffolding that looks like:

I use scaffolding to craft the article, and when satisfied with the content, I feed it into Grammarly to help with grammar, punctuation, and sentence structure.

The result of the process is the article you are reading now.

With the backstory out of the way, it’s time to formalize my disclosure statement:

What I have learned is that creating content is hard. The urge to find shortcuts in the process is real, and AI genuinely eases friction in it. This creator economy is always in flux, and the idea of AI disclosure, while not new, has taken on renewed vigor due to the proliferation of creators, pressures to produce, recent legal changes, and the high-profile case of Hank Green.

As I look at what happened with Hank Green, the court of public opinion hasn’t been kind to him for doing something he never fully explained. Clearly, I don’t know his intent or how widely AI was used in his process, but for me, I’m willing to give him the benefit of doubt. I’ve enjoyed the videos he’s produced over the years. What I’m taking away from his situation, disclosing how I use AI early in my creator journey is important to me. And how that disclosure looks includes what tools I use, how I use AI, and when I use AI.

Sources

1. Toff, B., & Simon, F. M. (2025). “Or They Could Just Not Use It?”: The Dilemma of AI Disclosure for Audience Trust in News. The International Journal of Press/Politics, 30(4), 881–903. https://doi.org/10.1177/19401612241308697

2. Human detection of AI-generated text hovers near chance — or worse — across multiple independent studies:

   
   Penn State News, “Q&A: The Increasing Difficulty of Detecting AI vs. Human Text” (May 14, 2024): https://www.psu.edu/news/information-sciences-and-technology/story/qa-increasing-difficulty-detecting-ai-versus-human

   
   Yale Daily News, “Readers Can’t Accurately Distinguish Between AI and Human Essays, Researchers Find” (Nov. 18, 2024): https://yaledailynews.com/blog/2024/11/18/readers-cant-accurately-distinguish-between-ai-and-human-essays-researchers-find/

   
   Berber Sardinha, T. (2024). AI-Generated vs Human-Authored Texts: A Multidimensional Comparison. Applied Corpus Linguistics, 4(1). https://www.sciencedirect.com/science/article/abs/pii/S2666799123000436

   
   “Bot or Not: Can People Tell the Difference Between Stories Written by a Human or by an AI System?” Judgment and Decision Making (Cambridge Core): two studies, N=424 and N=481 adults — 39.39% and 51.97% correct respectively, both at or significantly below chance. https://www.cambridge.org/core/journals/judgment-and-decision-making/article/bot-or-not-can-people-tell-the-difference-between-stories-written-by-a-human-or-by-an-ai-system/45E6DC0BB90AA648654D5AE243F6C667

   
   Milička et al. (2025). Learning to Detect AI Texts and Learning the Limits. PLoS One. Baseline (untrained) accuracy 55.4% (N=254), rising to 65.1% with corrective feedback training — still short of reliable. https://pmc.ncbi.nlm.nih.gov/articles/PMC12527182/

3. The EU AI Act’s Transparency Code (Article 50) itself, effective Aug. 2, 2026:

   
   European Commission, “Safer and More Transparent AI” (Aug. 2, 2026): https://commission.europa.eu/news-and-media/news/safer-and-more-transparent-ai-2026-08-02_en

   
   EU Artificial Intelligence Act, Article 50 transparency obligations, explainer: https://artificialintelligenceact.eu/transparency-rules-article-50/

4. Anthropic’s own published limitations on its text watermark:

   
   Anthropic Support, “How Claude Marks AI-Generated Content”: https://support.claude.com/en/articles/16266773-how-claude-marks-ai-generated-content

   
   TechCrunch, “Anthropic Says It Will Watermark Text Generated by Its AI Models” (Aug. 11, 2026): https://techcrunch.com/2026/08/11/anthropic-says-it-will-watermark-text-generated-by-its-ai-models/

5. Named creators with published AI-disclosure policies:

   
   Katie Harbath, “How I Use AI” (Anchor Change newsletter): https://anchorchange.substack.com/p/how-i-use-ai-newsletter-workflow

   
   Carlo V. Santiago, “Coming Out (AI Edition)”: https://carlovsantiago.substack.com/p/coming-out-ai-edition

   
   Hank Green / Complexly AI policy (YouTube Community post, ~2026-08-09): https://www.youtube.com/post/UgkxbXRPEpONUqoIf0Zu2OPNaKBtd95IIgxU

6. Complication — frequent AI-tool users are a real exception:
   
   Russell, J., Karpinska, M., & Iyyer, M. (2025). “People Who Frequently Use ChatGPT for Writing Tasks Are Accurate and Robust Detectors of AI-Generated Text.” Accepted, ACL 2025. Five annotators who write with ChatGPT frequently reviewed 300 non-fiction articles against multiple frontier LLMs (GPT-4o, Claude, o1); majority vote misclassified only 1 of 300 — outperforming commercial detection tools, even against paraphrasing/evasion tactics. https://arxiv.org/abs/2501.15654

“...I’m in a long lifetime battle with email terrorism... it’s something that I battle every day, about three or four times a day.”

I snort laugh when I hear the term email terrorism, but continue listening.

“I purchased something for my new apartment... I know when I checked out it was like, ‘Sign up for our savings email blast.’ And I was like, uncheck. Want no part of this.”

“I’m talking I’m like eight emails deep after I purchased like some towel hooks. Something incredibly pedestrian... something you would never write a review about unless you’re a complete whack job bored to tears.”

“So I unsubscribed. And then it pops up, ‘Thank you. We’re sorry to see you go. Thank you for unsubscribing. This will take 48 hours to update.’ Which is total — and a pathological lie.”

“In those 48 hours after I declined the survey... I unsubscribe. And in the ensuing 48 hours, six emails per day, 12 additional nukes to my inbox.”

“Here’s what I hate — you put the unsubscribe when you’re checking out, but they have your email for billing. So then they keep emailing you. So you unsubscribe twice.”

“A lot of these retailers are abusive husbands. And the consumers are the battered wives... everything’s a hustle. Everything’s a shakedown. Everything’s a harassment.”

”Will you ever buy anything from that company again?”

”If I need it, I probably will... that’s the problem. I’m just being honest... the instant gratification person in me... I’ll be like, tap the vein, hit it... let’s go with the emails. I’m ready. I’m locked and loaded.”

It’s too much. I stopped the lawnmower, turned it off, and then pulled my headphones off. I was belly laughing at what I just heard. I’d been mowing the yard listening to the podcast “I’ve Had It” for the first time, where the hosts Jennifer Welch and Angie Sullivan discuss all things political pop culture.

Buried in the podcast, the hosts described one of the problems that led me to build bwak email. There is real frustration when you opt out of receiving emails from a company. Most of the time, you opt out of receiving promotional or product updates, but you still receive emails asking you to “rate the product you bought” or to “tell them about your shopping experience.” And the colonization of your inbox happens as you receive these unwanted emails.

When it happens, you feel powerless and don’t know what else to do, nor do you have many good options today other than to write a rule in your inbox or mark the emails as spam.

And the scary part- not scary like The Amityville Horror kind of scary, but scary like What a coincidence, I was experiencing something similar with emails I was receiving from LinkedIn the other day.

Bwak email is one of the Tinkers I’m working on today. It is an email alias gateway that sits in front of my real email address and acts as a gate for emails I receive. The inbound emails require explicit human opt in approval before reaching my inbox. I can give anyone an alias that passes through the gate and gets delivered to my email if I’ve approved the sender.

Since I began tinkering with this idea, I’ve approved over 130 senders to different email aliases I’ve created for my k3bert.net domain. And after several weeks, I started to feel like I was experiencing déjà vu as I approved six different senders from LinkedIn.

It took the 6th approval to finally catch on to an issue I’m having with the user experience. Each time I received an email from LinkedIn, I approved it, and each time I thought to myself, I had already approved the sender on LinkedIn, not realizing each approval was for a different sender from LinkedIn. I was only keying on the domain LinkedIn, and that was the missing piece for the application.

The original design for the app included a per-sender (From) AND per-receiver (To) address approval process, which would mean if I received emails from different senders, albeit the same domain, I’d have to approve them all explicitly.

The answer: build a DOMAIN-level approval/denial mechanism.

In other words, give the user the option to Opt In to all emails from a specific domain (a.k.a. website) and forgo the explicit approval process for each sender.

And this is what I built in version v0.6.0 of bwak email. A unified 5-state approve/block model (sender/domain/alias scopes) replacing the previous asymmetric terminology I developed.

The five states?

1. Let newsletters-noreply@linkedin.com through

2. Trust everyone from linkedin.com

3. Block just newsletters-noreply@linkedin.com

4. Block everyone from linkedin.com

5. Block anyone emailing linkedin@k3bert.net (To)

With this approach, a block action (domain or sender) ALWAYS overrides an approve. Domain-level actions override sender-level approvals.

This approach creates a streamlined user experience, giving them the control they need over their emails.

Looking back at the discussion between Jennifer and Angie, if they had bwak email, they wouldn’t have to worry about unsubscribing; they would potentially have the option to block the “review the product emails”, but approve “order update emails” because they come from different senders. And if they ever got annoyed to the point of no return, they could go nuclear and block ALL the emails from the sender.

I just rolled this out last week, and I’m testing it. I’ve tested with sample data, but I couldn’t test all the usage/approval/denial paths due to limitations in my ability to send emails from different senders, so I’m fishing with bait, waiting to see how the system performs in the real world.

Charlotte’s grandchildren hadn’t ever shot arrows before, but they instantly fell in love. After a few hours, they were drawing the arrow back and hitting the target like a pro. This is life on the farm. When you visit, we create an experience you take home with you. Charlotte’s grandchildren now have their own archery range back in Texas, set up by their parents.

Visits to our farm are not casual; they are experiences carefully planned, created, curated, and executed by us.

I’ve been on LinkedIn for two decades now, and I’ve been posting regularly for the past several years. More recently, I started posting with a purpose. After experiencing a career disruption, instead of jumping back into the familiar corporate life, I decided to bet on myself and post on LinkedIn with the purpose of promoting a business I started.

The performance of those posts has been lackluster, and it would be easy to blame the algorithm for killing my reach. I refuse to assert that my posts are flopping. No, I failed to realize the strength of the LinkedIn platform and how to succeed on it. I’ve been a stubborn donkey not reading the room.

With new resolve and a shift in focus, I’m going to refine the work I’m doing on LinkedIn AND extend my outreach to include Substack.

LinkedIn is the snack bag you get on a short airline flight. You open the bag and pick through the contents while reading the nutritional information on the back. It’s the platform you open up at work when you have a few minutes and scroll to kill time. You enjoy the saltiness of the posts; they are quick, tasty hits of time management, leadership development, and other career-growth flavors that reflect your interests.

Substack, on the other hand, is the dinner you sit down to once you arrive on the farm. It follows a day of activities like archery. It’s a time where you receive a multi-course meal with an appetizer, main course, dessert, and a relevant drink pairing. It’s a time to reflect on the day’s activities and wonder what tomorrow will bring.

We have a seat waiting for you. Subscribe to The Weekly Tinkerer.

It’s time to turn the opt-out model of email on its head to fix it.

I wanted another Apple HomePod speaker for our home. Found it online for in-store pickup at my local Electronic Express. I added it to the cart, checked out as a guest, and forgot about it.

A couple of years later, I received a spam message addressed to: electronicexpress-0921@k3bert.net. I was confused; I didn’t create an account with them. Why am I receiving spam?

I looked up the address on Have I Been Pwned and found out that in Feb of 2023, Eye4Fraud, an online fraud protection system used during payment transactions, was breached and the data made available to hackers.

The forgotten email came back to life until I created an inbox rule to delete any messages sent to electronicexpress-0921@k3bert.net permanently. Opt-out.

And then there was the time I decided to sign up for updates to my Alma Mater, CU. I opted to receive alum emails at cualumni@k3bert.net related to the engineering school, from which I graduated.

I received my first few updates, but then there was a shift. It wasn’t just updates on the School of Engineering; the emails were now boosters for the Alumni Association and covered other clubs and associations within the university. And then, to make matters worse, someone from the Alumni Association started calling. Their whole job is traveling around meeting alumni to “catch up,” which I’m fairly sure means asking for money.

I tried to opt-out through my mail preferences, but the emails and calls kept coming in.

I created an inbox rule to delete any messages sent to cualumni@k3bert.net permanently. Opt-out and blocked the phone number.

And then there was Verizon and Heritage Bank and Trust. For a few years, we did business with these companies until we stopped and permanently closed our accounts. Or at least we thought.

But, for months after closing the accounts, we still received monthly statements of our accounts. Confused, I called several times, explaining the accounts were closed and that there was no need to send us statements anymore. They agreed. The emails kept coming.

I created an inbox rule to delete any message sent to their aliases permanently. Opt-out.

Today, AI agents are augmenting and supercharging inbox rules and, if you decide, will take over your entire inbox for you. But what’s the difference between an AI agent managing your inbox for you versus you manually managing the rules? Other than out of sight, out of mind, it’s still opt-out.

In the immortal words of Buzz Lightyear: “This isn’t flying, it’s falling with style.”

And personally, I’m not all that comfortable with an AI agent crawling through my inbox and noticing who I shop or bank with, what credit cards I have, when I received my tax return, or when I pay my utility bills. This is all personal information that I would like to keep personal.

For years, I’ve been trying to manage the 1,390 unread messages like most everyone else. Giving out my email, receiving unwanted messages, trying to opt-out, giving up, and waving the white flag.

And now, I’m tinkering. I’ve started an experiment with my personal k3bert.net domain that, if successful, I’ll transition the domain my wife and I share for all our household accounts.

The experiment started with a declaration of email bankruptcy, archiving off all my messages into cold storage. And a gate slotted in front of the domain that inspects all senders and aliases, comparing them to an allowed list. When a new email arrives and the sender is not in the allowed list, I have a choice to allow the email to land in my inbox; in other words, I opt-in.

And then something caught my attention. The green highlight text I chose for the site was difficult to read.

I have good color perception. In fact, Charlotte has crowned me the official paint color picker when it comes to decorating our house. So, I figured if the text was difficult for me to read, the roughly 8% of men with red-green color vision deficiency would struggle to read it also.

That wasn’t ok with me.

I was aware of the accessibility guidelines published by the Web Content Accessibility Guidelines (WCAG), but never had to worry about building with them. So I was surprised when I handed the problem off to my AI agent, and it threw up a sample page showing that indeed, the emerald-600 (hex #059669) green color I selected for the website failed the standard.

Standard? What standard? Up until now, my choice of colors was always based on taste and if it reads fine, ship it. I had no idea that the standard specified a way to calculate the contrast and grade it as a means to quantify accessibility usage of your application.

Every color has a computable relative luminance, which is a fancier and more accurate way of saying “how bright it actually reads to the eye.” Take two colors, compare their luminance, and you get a contrast ratio. Identical colors give you 1:1, invisible against themselves. Pure black on pure white gives you 21:1, the ceiling. Everything else falls somewhere in between, and the formula gives the same answer every time, for every viewer, regardless of taste.

My green, emerald-600, measured 3.77:1 against white. WCAG’s baseline standard for normal text is AA, and AA requires 4.5:1. My “fine, it’s just a light green” accent color was failing the accessibility standard I didn’t know existed.

There are two levels worth knowing; AA is the baseline most sites are expected to hit: 4.5:1 for normal text, 3:1 for large text (think 18-point-plus, or bold at 14-point-plus). AAA is the stricter tier, not usually a legal requirement but the one that gives you real margin instead of a bare pass: 7:1 for normal text, 4.5:1 for large. My original green wasn’t even clearing the low bar.

I went with the recommended emerald-800 (hex #065f46), a 7.68:1 ratio. Not a bare pass over the AA line, but clear of AAA too, with real margin to spare.

Because the color lived in one config token instead of being copy-pasted into forty places, changing it fixed the accent color across the entire app in one shot: CSS, every transactional email, account and billing pages, badges. All of it, except three admin-only internal tools I left alone on purpose, because nobody outside my team ever sees those.

The part I want to hand you isn’t the story. It’s that this is checkable, right now, on whatever you’re running, without asking anyone’s opinion:

1. Chrome DevTools — inspect any text, click the color swatch next to color in the styles panel, and it shows you the live ratio plus AA/AAA pass or fail, along with a suggested color that would pass. Fastest option, already installed.

2. WebAIM Contrast Checker (webaim.org/resources/contrastchecker) — paste in two hex codes, get the ratio and pass/fail for both normal and large text. It’s the tool most accessibility writeups point to first.

3. Lighthouse (also built into Chrome DevTools) — audits a whole page at once instead of one pair of colors at a time, so it’ll surface every low-contrast spot you didn’t think to check.

4. An AI coding assistant — ask it to build you a side-by-side comparison tool for your candidate colors, with real computed ratios. It’s not a shortcut around the standard; it’s a fast way to see the standard applied to your actual palette, which is exactly what got me here.

You already have a website, an app, a newsletter template, something with text on a background. Open DevTools, click your accent color, and read the number. If it says fail, you now know something concrete instead of something you assumed.

That’s what happened to me today.

“Hey Kevin, I signed up for your service, but I can’t login. Here’s my email address I’m trying to log in with and the device/browser I’m using. Can you help?”

I had 10 minutes before Charlotte and I were to head out for an appointment, so the pressure was on.

Check the logs, yep, there were the three login attempts made. But no indication of an error in the process nor that they received the message saying the magic link the app sent them to failed.

This was going to require intuition and an educated guess.

The difference in the time that the token was created and the time it was used was only a dozen seconds. That seems quick, too quick.

An AI prompt later, the working theory was developed. Somehow, the token for the magic link was already used before my friend could click the link in the email. But, why?

AI had an idea. I didn’t, this was outside of any experience level. I’ve been around a lot of systems in my career, but authentication and authorization mechanisms was an area I didn’t spend a lot of time in.

The most likely cause was that an email security scanner/pre-fetch was loading the link in the email and because the way the /auth end point was written, it was validating the token with the pre-fetch which in turn told the system that the token was valid, and no longer needed and discarded.

That all happened between the email being delivered and the time my friend clicked the link. When they clicked the link, they received the unfriendly message that they couldn’t login.

And to add insult to injury, there was no way in the app for them to reach out and ask for assistance. Luckily, they had my number.

This was the theory, it was easily tested and confirmed.

The fix is simple, don’t validate the token when the /auth end point is called. Instead, put an intermediary step requiring the user to click the link in the email, load a new page with another button to select to finish the login process.

Yes, the solution adds a bit of friction to the process, there’s an extra click now. But, it eliminates any pre-fetch or inadvertent previewing of the page assuring that the token will work when the user intends it to work.

So, the embarrassment is real, I have no way of knowing how many other people have had the issue, more than I’m willing to admit to b/c I can see the similar usage patterns.

The embarrassment was replaced with gratitude quickly b/c someone took the time to say, something wasn’t right and brought it to my attention.

This isn’t about not trusting what AI builds. That’s too easy, and it sidesteps the real responsibility. I understood the design. What I didn’t have was the experience to know there was a gap in it. And building alone means there’s no one else around to catch what you don’t know to look for.

The counter to that is building a system that expects surprises and handles them gracefully. For me, that means an easy way for someone to reach me when something breaks, and auditing every critical process that could stop a user dead and hardening those first.

What tips or techniques do you build with to handle the unexpected surprises that will inevitably hit your system?