mister automate

If you’re not going to nail it, is it worth doing?

That doesn’t mean doing every little thing perfectly. A rough draft can be rough. A prototype can be ugly. Some work is temporary, some attempts fail, and some steps along the way simply need to get you to the next one.

Those aren’t the home run. They’re part of the at-bat.

The question is whether the larger thing you’re pursuing is worth hitting out of the park.

If it is, then the imperfect steps, mistakes, experiments, and failures all belong. They’re in service of something worth doing exceptionally well.

And if the ultimate goal isn’t worth nailing, maybe the better question is:

Why are you doing it at all?

I have a memory of a time, which was corrupted.

I'm not sure if the time was corrupted, but the memory was for sure.

Thankfully, most of it was still in the recycle bin, so we were able to restore it to 4K.

It went something like this.

I was completely broke.

I had $43.17 in my checking account.

Rent had an AI-generated due date of tomorrow.

Tomorrow was still in beta, which made the deadline difficult to plan around.

I sat at my Play-Doh kitchen table trying to Photoshop $43.17 into several hundred dollars.

That's when the fear set in.

It was 3D-printed fear, but it felt real enough.

My buddy buffered into the kitchen.

He scanned the bills spread across the table and said, “Man, you're going to be alright.”

I needed to hear that, but his voice was simply extracted from 10—no, 11 Labs.

We debugged my finances together.

The electric bill could wait until Friday.

Friday was still rendering, so that bought me some time.

We checked the refrigerator for liquid assets.

There wasn't much liquidity.

Half a gallon of milk.

A few eggs. No, they were solid leftovers.

“We can work with this,” he said.

His optimism was open source, so I downloaded a copy.

No matter what we tried, I still had $43.17.

At least I thought I did.

The $43.17 was cake. Wanna ETABITA Cake?

I felt like a complete failure.

The failure was a hologram, but I didn't know that at the time.

Unfortunately, life couldn't be real.

Real was trademarked.

Inspired by a video from @jackcarden.art

Earlier in my IT career, I wished there were a way to accelerate experience—to encounter years' worth of real problems, see the mistakes people made, understand why they failed, and learn how they eventually solved them. Experience comes quickly when you repeatedly encounter problems and have to overcome them.

AI changes what is possible here, particularly in software development.

An AI coding agent can now accumulate experience through the work itself. It attempts a solution, encounters a problem, diagnoses it, tries different approaches, and eventually finds what works. That process produces something potentially more valuable than the finished code: a lesson.

And we aren't starting from zero. There is already a massive world of GitHub repositories containing working solutions to real problems. When starting a new project, finding the right repository can provide an enormous head start. AI makes this even more useful because it can reference another project's code and approach while working through your own problem, extracting relevant patterns without requiring you to understand the entire project first.

The next step is to extend that idea beyond the code itself.

The lessons generated during an AI-assisted build don't necessarily require exposing the underlying codebase. They could be abstracted and anonymized into the problem encountered, approaches that failed, why they failed, the eventual solution, and what should be avoided in the future.

Now imagine those lessons becoming universally referenceable.

Instead of every AI encountering the same problems independently, one AI's experience could become available to others. The accumulated mistakes and solutions from millions of builds could form a growing body of practical experience that future AI systems can reference while working.

That creates a fundamentally different learning cycle:

Encounter a problem → attempt solutions → discover what works → abstract the lesson → share it → reference it during future builds.

The important shift isn't simply that AI can write code. It's that AI can do the work, experience the failures, extract the lessons, and potentially make those lessons reusable without exposing the proprietary work that produced them.

If that becomes possible at scale, experience itself becomes something we can accumulate and share much faster—allowing each new build to benefit from mistakes already made somewhere else rather than repeatedly rediscovering them.

Super old videos being reposted online are more likely to be interesting.

Bad videos stop getting reposted.

Time is a great filter.

Sometimes, it simply isn't economically feasible to have a live human answer every call immediately.

That doesn't mean a bad hold experience is inevitable.

If customers occasionally have to wait, the goal should be to design that wait so it demands as little of their time, attention, and patience as possible. Unfortunately, many common hold-system practices do the opposite.

Typical Hold Experience Design Flaws

Telling customers to visit your website

"If you don't want to wait, you can visit us online at..."

Often, the customer's inability to accomplish what they needed online is the entire reason they're calling you.

Stopping the hold music to make an announcement

The music stops. The customer thinks someone answered, grabs the phone, and hears:

"Your call is very important to us..."

Nobody answered. The system just interrupted the customer to tell them they're still waiting.

Telling customers how much you value their time

"We know your time is valuable."

"We value your time."

"Your call is very important to us."

These messages are being delivered by a robot while the customer is experiencing the opposite.

Design the experience to demonstrate that you value their time instead.

Repeating messages instead of providing information

"Thank you for continuing to hold. Your call is important to us."

Repeating this every few minutes doesn't help the customer. If you're going to interrupt them, provide useful information.

Calling normal call volume "unusually high"

"We are currently experiencing unusually high call volume."

If customers hear this message every time they call, the volume isn't unusual. It's your normal call volume.

Advertising to a captive audience

Someone waiting for help probably doesn't need to hear about your latest promotion, loyalty program, or premium service.

Don't turn an unavoidable wait into an advertising opportunity.

Designing a Better Hold Experience

Set expectations

If you can reasonably estimate the wait, tell the customer:

"Your estimated wait is approximately 12 minutes."

For longer waits, provide an update when that estimate meaningfully changes.

Keep the music playing during automated updates

Lower the music during automated updates instead of stopping it. Use a consistent tone for those announcements and a completely different sound when an actual representative connects.

Offer a callback

For longer waits:

"Your estimated wait is approximately 20 minutes. Press 1 and we'll call you when a representative is available. You will not lose your place in line."

Let customers stop paying attention

Tell customers what will happen when someone actually answers:

"Feel free to put your phone down or continue with what you're doing. You'll hear a distinct chime when a representative is ready."

Interrupt only when you have useful information

A meaningful wait-time update, queue position, callback option, or specific self-service option can justify an interruption.

If nothing has changed, let the music play.