Transcription
I listened to Dario and Daniela, the co-founders of Anthropic, speak at a Claude conference in San Francisco, and I learned something that I wasn't expecting. Most people are building the wrong things with Claude.
So, I dug deeper, and after studying everything the Anthropic founders have recently said, I uncovered four rules for how they actually decide what to build. And it turns out that these rules apply to you whether you're building a side project or your dream business.
The first rule is you have to recalibrate what's possible. If you look at Anthropic's product release schedule, they are shipping faster than almost any company ever. You can see each release highlighted here, and this isn't normal. Most companies will do one of these releases every quarter if they're lucky, and they're doing this almost every single day.
So, how do they actually do this and decide what's worth building? Well, they've successfully recalibrated three key factors that help them decide what they can and can't build.
The first is cost. Can you afford to build it? Before AI, a lot of builds died because you had this great idea, but you had to hire someone, or it just cost too much to build for the opportunity. But, the math has now changed. Listen how Dario framed this new reality in a recent interview.
"Software is going to become cheap, maybe essentially free. The premise that you need to amortize a piece of software you build across millions of users, that may start to be false."
The calculus has entirely changed for what you should build because you don't need millions of users for it to be successful. That means the bar for what should be built is a lot lower, meaning you should build a lot more.
The second factor that they recalibrated is domain expertise. Essentially, do you know how to build what you want to build? Here's a clip from Daniela at Stanford, who is one of the co-founders of Anthropic, and it's also Dario's sister, if you're wondering that, because I was also.
"I didn't think I could build a website, right? And now using Claude, I'm like, 'Oh man, that's so easy.' Like, I just click a couple buttons and Claude like build a website for me."
AI has made it so that anyone can get to level one understanding in almost any domain, which opens up a whole realm of possibilities for what individuals can actually build.
And the third factor is a time constraint. [music] Do you actually have enough time to build it? A lot like cost, the total time required to deliver features is entirely collapsing. And as a result, the Anthropic team can now elect to ship more features and products that they may have never built before. For example, Claude Co-work, one of their biggest products, here's Dario talking about how long it took to build it.
"This was a a version of our tool, Claude Code, for non-coding. This was built in a week and a half, almost entirely with Claude Opus."
So, they're building quicker and more things, but does the data back it up? According to their internal data, 27% of Claude-assisted work that would have never been completed without Claude.
So, how can you do this with whatever you're working on? Well, run a shelf audit. Every person watching this video has a mental shelf of ideas that you've parked because of one of these three factors, right? The time, the skill, or the cost. Now, a lot of these items on the proverbial shelf are very doable, and you just haven't thought to look, or you haven't recalibrated what is actually possible.
Now, before you start building everything on the shelf, rule number two could actually kill a lot of the ideas that you have.
Rule two, kill anything you can't verify. Simply put, for certain projects, if you can't verify it, you can't release it. At Anthropic, the most extreme example of this happened earlier this year. They had to hold back one of their most capable models, Claude Mythos, because they weren't certain that it was reliable and secure enough. Daniela spoke about this recently at Stanford.
"But, we're just not confident enough yet. It's irresponsible of us to release it until we are confident that all of the patching that needs to be done has been done."
So, the filter isn't does this work in testing? It's can I prove this works consistently? Now, are you going to ship an AI model that could change the trajectory of humanity? Probably not. Maybe, maybe, but probably not. But, this concept a thousand percent holds true to you. For example, if you're building an email response automation or a financial analysis tool, can you prove it works consistently?
I had to learn this the hard way. I built an email drafting automation tool for one of my clients, and none of the emails were done properly. I couldn't verify that it was doing things correctly, so I probably should have never built it.
Now, you don't have to run everything through this lens, but you need to when the cost of error is high. What this means is, if there is an error, what is the cost of this error? In Anthropic's case for Mythos, the cost of error was extremely high. And I'll dive into this cost of error concept later in this video as well.
So, if the cost of error is high, before you actually do anything, here are the two things you have to consider.
First, define how you'll verify before you build. Figure out what the final output needs to be to confirm that it actually works. If you can't figure out what is needed to verify before you start building it, how will you know it works at the end of building?
Step two is set a way for Claude to verify its own work as it builds. This is a tip from Boris Cherny, the creator of Claude Code, where he tweeted, "The most important thing to get great results out of Claude Code is to give Claude a way to verify its work. If Claude has a feedback loop, it will two to three x quality of the final result."
If you do these two things, and you'll build outputs that actually provide value, not stuff that looks cool and breaks the second it's running because the cost of error is just too high.
So, to help with this, here's a prompt you can add to the end of anything you do to force Claude to think about how to verify the output. You can also add this to your Claude.md file, so it's a general rule across your entire project.
Before we get to rules three and four for how Anthropic actually decides what to build, we're going through a lot of concepts quickly here. So, if you want something that you can go at your own pace, I have a free five-day email course that walks through a lot of these concepts, as well as the AI system that I used as a COO of a $25 million startup. To get that, click the first link in the description. It's entirely free, and based on over 5,000 people who have gone through it, I'm confident you'll love it.
Rule number three is know who you're building for and who you're not building for. Most people try and do everything for everyone. And the result is they build a bunch of stuff that is just sort of valuable when they should have focused and provide value on a specific group of people.
There's two high-level concepts you need to understand for this rule. The first is your ICP, and the second is your audience anti-goal. An ICP stands for your ideal customer profile. Who are you building this for? And for people watching this video, the answer can be just you. That's totally fine. And second is And an audience anti-goal is the customer you are explicitly not building for. And what has helped Anthropic be so successful is they have clearly defined both of these.
First, listen to what Daniela said at Code with Claude about their ICP.
"I think in many ways developers are the most important users of Claude."
And here's Dario talking about what they're not building or their audience anti-goal.
"We don't make, you know, models that generate images and videos and and for many reasons."
Who they're building for, which is developers, and they know what they're not building, image and video generation for creatives and consumers. If you look on the other hand, right, Open AI, they've gone for general consumers, image generation, video generation, enterprise, social media, essentially trying to do everything at once. And this is likely why Anthropic has been able to grow much faster than Open AI.
Listen to Steve Ballmer, the then CEO of Microsoft, talk about who they were building for.
"Developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers."
Developers, developers, developers, developers. The tenacity is amazing. Not to mention the sweat stains. I may have to hop on my bike before the next YouTube video I make so that I can just freaking bleed that intensity. But anyway, the filter is clear. They know who they're building for and who they're not building for. And by drawing that line in the sand, every decision in terms of what you're building becomes faster and more effective.
And the added benefit of this is something that most people miss. When you pick one customer, your builds start to compound and complement each other over time. Each new build sharpens the relationship with that one audience. The next build is easier and more valuable than the last. For Anthropic, they built for developers, which gets more developers to use it, which helps train their Claude model, which then makes it better for developers. They then use that same Claude model to build Claude Code, which helps developers. And this clearly worked, right? Anthropic grew 80x in Q1 2026 against a 10x plan. 80, that's a lot of x's.
Now, here's where it gets interesting for me and you. This concept scales down to whatever you're working on. You just have to understand who you're building for and how it helps them. Let's say you're building for yourself and you stay laser focused on what you need. You shouldn't chase shiny objects that solve problems that you don't actually have. If you're building for a specific audience, focus on that audience. For me, this is my audience that I look at every single day. That ends up being 30 to 50-year-old males who live in the United States. Honestly, shout out everyone watching this. You guys are legends.
And if you're unsure who you're building for, a good starting point could be identify who you aren't building for and say your anti-audience goal. At the end of the day, the most successful people I know only work on things that complement each other thing that they're working on. And that's because there's no waste of time and effort. And that's what Anthropic did and that's what you should do as well.
So, that's the first three rules that Anthropic follows when deciding what and who to build for. And before we get to rule number four, which dives into how to build what we're working on. If this is your first video, welcome to the channel. But if it's your second or more, here is our anti-slop agreement. The visuals, the testing, the time I put into this, this is all for humans, not for AI clanker robots. So, all I ask is that you subscribe as part of this agreement to help this content reach more people. Also, every couple of weeks I give away a Claude Max subscription. So, comment below with what you're building to enter.
Rule number four is build middle and middle, not end to end. Most people when they think about AI, they're thinking about end to end. They prompt it, they walk away, and they hope something good comes out on the other side. Anthropic is looking at it a different way, middle to middle.
Every task you start has three parts. A start where you frame the problem, a middle where the work gets done, and then an end where you deliver the actual final product. End to end is when AI takes all three parts, the start, the middle, and the end. The human in general is just gone. Middle to middle is where AI only takes the middle. A person starts, AI does the middle, and a person reviews at the end.
In a morbid example, here's Dario explaining a use case they refused to support, a classic end-to-end example.
"If you have a large army of drones or robots that can operate without any human oversight, where there aren't human soldiers to make the decisions about who to target, who to shoot at, that that presents concerns. And we need to have a conversation about about how that's overseen, and we haven't had that conversation yet. And so, we feel strongly that, you know, for for, you know, those two use cases should uh should not be allowed."
Autonomous weapons are end-to-end. AI decides who to target, AI fires, AI delivers the outcome. I know that's an extreme example, but it's where the cost of error, losing a human life, is too high. They drew the line and they refused to build for use cases like this.
Now, the same logic shows up in smaller stakes. Listen to how Dario explained the math that makes middle-to-middle actually work.
"Comparative advantage is surprisingly powerful, right? Even if you're only doing like, you know, 5% of the task, like, you know, that 5% gets super amplified and leveraged because it's like you're only doing 5% of the task, the AI does the other 95%, and so you become, you know, 20 20 times more productive."
The 95% is the middle. Claude takes that, and the 5% is the stuff that matters, the start and the end. The decision at the front, the judgment on the back. That's what stays human, and it gets 20x more leverage because the middle just got cheap and more effective.
And if you look at two of Claude's most successful products, Claude Code and Claude Co-work, these are tools that are optimized for middle-to-middle workflows. Interface assumes that you're at both ends of the work for most of the use cases, and that's exactly how I use it. I'm at the start of every interaction, and then I'm reviewing the final output.
So, how can you use this concept when evaluating which Claude projects to build? Well, before you start building anything, think about the three parts of the process. The start, what decision or framing do you need to bring before Claude actually does any work? The middle, what routine work do you want to hand off? And the end, where do you review, judge, and sign off on the final output? If Claude is doing all three parts, you've built end-to-end, and this will likely produce low-quality work. My recommendation would be to redesign it so you're at the start and end. And just this mental tweak of thinking about things middle-to-middle makes everything easier because the output doesn't actually have to be perfect. You can take it and make it perfect at the end.
So, if you follow the four rules I covered here, you will get amazing results with whatever you're building. And look no further than the success that Anthropic has had.
Now, if you like this video, you'll love this video where I break down how Anthropic's own engineers actually prompt Claude code. That's a tactical layer underneath all of this, which will streamline whatever you're building. I'll see you over there. Peace.