The Two Bets Every AI Team Has to Make

Two weeks ago, I received two emails on the same day. Both have driven my daily focus ever since.

The first was from an investor-type, one or two steps removed from our company. He'd taken the MCode assessment, loved it, and wanted to share his observations. His core suggestion: shorten the experience. Maybe think about voice.

The second was from our parent company. An international lead wanted to talk about taking MCode into other countries. A meeting was scheduled for a week out.

Two emails. Two different challenges. Neither one new. But both critically important.

Here's what I didn't tell you: I had tried to solve both of these problems four or five times each over the last two years. I had built prototype after prototype for shortening the assessment. I had experimented with voice capture in multiple forms. I had thought about internationalization for longer than I want to admit. None of it worked. Not well enough. Not at a level I was willing to ship.

And yet, two weeks later, both are working.

I want to tell you how, because the answer isn't what you'd expect. It's not that I finally figured out the right prompt, or found the right library, or got the right idea. The answer is that I had already tried. Many times. And I had the discipline to leave time in between.

That discipline, it turns out, is one half of a pair of bets that explains almost everything about how fast the best AI teams are moving right now. And most companies are only making one of them.

Bet #1: Build products that are on the edge of working

Cat Wu runs product for Claude Code at Anthropic. In a recent interview, she laid out something that stopped me cold:

"Build products that are on the edge of working."

She gave an example. Claude Code's code review feature failed multiple times. Earlier models weren't accurate enough. But because the prototype was already built, when Opus 4.5 and 4.6 shipped, they could drop the new model in and immediately test whether the gap had closed. Teams that wait for the model to be ready, she said, will always be a cycle behind.

When I read that, I said "exactly" out loud.

That's what the translation work was. I had thought about taking MCode international for years. I'd played with machine translation pipelines that were close but not good enough. I'd looked at editing workflows that required too much human touch. Each time, I left it alone.

Then the email arrived, and the international meeting was on the calendar, and I tried again. Within seven days, I had a working version of the assessment, the report, and the portal in five languages. Machine translated, with a full editing workflow for inviting native speakers to review and refine.

A week before that, the answer to "can we go international?" would have been no. A year before, it would have been "not anytime soon." Two or three years before, it would have been a shake of the head and a change of subject.

What changed wasn't me. What changed was the context around the problem. The models got better. The tooling got better. The cost curve shifted. And because I had already tried, I knew exactly where the previous version had broken. When I tried this time, I could aim directly at those breakage points.

That's Bet #1. Prototype the thing that almost works. Leave it alone. Come back when the world has changed around it.

Bet #2: Lean into chaos and face every challenge with a smile

Cat's tenth point in that same interview was this:

"Hire people who lean into chaos and face every challenge with a smile."

She described weeks at Anthropic when a P0 on Sunday becomes a P00 by Monday and a P000 by Monday afternoon. If you get too stressed about any one thing, you burn out. The team looks for people who can see a hard challenge and say, "Wow, that's going to be hard. But I'm excited to tackle it."

Here's what most people miss about this point: it isn't a hiring tip.

It's the prerequisite for Bet #1.

Because if you build things on the edge of working, you are, by definition, building things that fail. Multiple times. Over months. Over years. The code review feature at Anthropic failed more than once before it worked. My translation pipeline failed more than once. My voice experiments failed more than once.

If your team can't metabolize that failure, you never make it to the version that ships.

This is where most organizations break down. They celebrate the technical bet, "let's prototype aggressively, let's try new things, let's ship fast," without making the human bet. And then they're surprised when the prototyping culture produces anxiety, churn, and learned helplessness instead of velocity.

You can't tell people to build on the edge if failure is treated as a verdict. You can't ask them to try, fail, wait, and try again if the waiting gets called "lack of progress." You can't expect them to greet a P000 with a smile if you greet it with panic.

Bet #1 is technical. Bet #2 is cultural. And Bet #1 is impossible without Bet #2.

The two mantras

I run both bets on two mantras I come back to constantly.

The first is "let time do the work."

Most of the problems I've solved in the last decade weren't solved by trying harder in the moment. They were solved by trying, noticing it wasn't working, setting it down, and coming back later. Not because I got smarter. Because the context around the problem changed. New tools. New models. New understanding. New examples to learn from.

Letting time do the work is hard because it feels like quitting. It's not. It's staging. You're building the context for your future self to succeed where your current self can't.

The second is "keep the small things small."

It's easy to get frustrated when something doesn't work and turn a little issue into a big deal. But if you do that, you have nothing left when the big deals arrive. You burn your emotional reserves on things that don't deserve them. And you train the people around you that everything is a five-alarm fire.

Those voice integrations that didn't work over two years? They never bothered me. They were simply a few different approaches that didn't work. I logged what I'd learned, set them down, and moved on. When the context changed, with better APIs, better latency, better conversational models, I picked them back up without the baggage of previous disappointment.

Let time do the work. Keep the small things small. One mantra for each bet.

What happened with voice

A few days ago, I got conversation-mode voice working for the MCode assessment. Not voice-to-text with three clicks. One to start the mic, one to stop, one to submit. Actual conversation. It detects when I finish speaking, responds, listens for me to speak again. The last time I tried it, it didn't work. This time it did.

And because I had the translation work done first, I knew what to ask next: can we do conversation-mode voice in five languages?

I'm almost there.

Two weeks ago, neither of these felt solvable. Both had resisted me for two years. Today, one is done and the other is a couple days away.

Nothing about me changed. The world changed around the problems I had already prototyped against.

Be those people

When Cat said "hire people who lean into chaos and face every challenge with a smile," my first thought wasn't about hiring.

It was: don't just hire those people. Be those people.

Because here's what I've come to believe: the companies that will win in AI aren't the ones with the best models. They won't be the ones with the best engineers. They'll be the ones where the technical bet and the human bet reinforce each other. Where building on the edge of working is matched by a culture that can absorb what "not working yet" feels like for months at a time. Where leadership signals, by their own behavior, that failure is operating mode, not verdict.

You can't delegate that. You can't hire your way out of it. The mantras have to be yours first.

So try the thing. Let it fail. Let time do the work. Keep the small things small. Try it again when the context changes.

And when the P000 arrives on Monday afternoon, smile.

That's the bet.