|
|
Earlier this month, most things I've built with AI got a new brain. |
(Including YouSpot -- the AI-native CRM for solo operators I’ve been building in public.) |
Several frontier models shipped (so far) in the month of September. Most recently we got Opus 5.5 from Anthropic's Claude, and refreshed GPT-6 "Sol" and "Luna" from OpenAI. Not long before that it was Fable 5.1 and GPT-6 "Astra." |
If you use AI through a chat window, these new models gave you a smarter chat partner. But if you’ve been working on mini-apps or building a second brain that scratch your own itch, then the judgment layer on everything you’ve built to date received a free upgrade too. |
My take after experimenting with the latest frontier models: they’re better at coding and long-running tasks, the two things I lean on most. That alone would be a win. |
But there’s a compounding effect at play -- the more AI tooling you've built, even if it only ‘kind of’ works, the more you have to celebrate when a new flagship model ships. |
So today I want to break down: |
Why learning through building benefits big time from new model releases How to maximize the benefits you get from new models How to position yourself for compounding wins
|
—@dharmesh |
|
|
Increase Your Compounding Surface Area |
Could you be building more with AI? |
One could argue the most important part about staying updated on the latest AI models is using them. You could read the multi-page changelogs and watch the tutorial videos that surface on your timeline a hundred times and still not walk away with durable knowledge. |
I believe a good best practice to follow is to err towards building things with AI, even if what you’re building doesn’t fully solve your problem. A lot of what I build starts as a personal itch and gradually scales from there. And when I say “building”, I don’t mean you need to dig into Claude Code and start generating apps. I’m talking about building systems. Could be a Claude Project or a Custom GPT — or a second brain with some agents on YouSpot. |
When you train yourself to try solving your own problems you naturally build mental models of where AI is capable enough to help you and where it’s not quite there. Each time you build something you increase the surface area of tooling that will automatically improve with the next major model release. Someone with five mini-projects benefits five times more than someone with just one. |
Even if AI can "sort of" do something right now, meaning you have to squint a little bit and think "well, it's kind of something, but not quite there," build it! The new models keep improving like clockwork. It’s entirely possible your half-working project is only one or two model updates away from functioning well, even if what you’ve built thus far remains otherwise unchanged. |
And if you build a bias toward building your own solutions, you’ll quickly find out if it was just a skill issue after all. Every experienced builder can likely recall experiencing a “eureka!” moment that came to them while they were working on a completely unrelated project and just happened to stumble upon an approach that made everything click. |
And the model keeps getting better underneath what you built. |
Which is also why I don't tear down the half-working ones. An experiment that sort of works is an asset that appreciates. Leave it standing and the next release does some of the finishing for you. |
(A short detour, for those interested: I think of experimenting by thinking of dots. You spend some portion of your life collecting dots -- experiences, people, skills -- and some portion of your life connecting them, and you really can't know in advance how they're going to connect. Not all of them work out. You don't need them to. You just need one or two to work really well. The half-working apps are dots, and each new AI model release is another chance for a few of them to connect.) |
|
|
Avoid Accidentally Limiting Your Upside |
The consensus on the optimal way to interact with AI has changed over the years. |
We had prompt engineering, where everybody worked to come up with elaborate walls of text that would lead the AI through an extremely detailed description of every step we wanted it to take. |
Then the context windows grew bigger, allowing us to focus less on optimizing what we ask, and instead optimize what the AI has access to when it thinks. That’s context engineering, and it’s still very important. |
More recently, the bottleneck moved again. Engineers and hobbyists alike grew tired of sitting in their chairs feeding their agents instructions after each task was completed. So they evolved to giving their agents the end goal and a way to check their work. Readers may remember this as loop engineering. |
When best practices change, the habits from the previous evolution don’t just give you worse output. In some cases, they actively block you from better output. |
When one of your mini-apps or agents you made with AI falls short, the reflex is to write more instructions for it. But every rule you force your model to abide by steers it according to your personal understanding of what the best path forward is. If you are an expert in your field, you may genuinely have an edge on the model -- but will you have an edge on the model that comes out six months from now? Or the one that comes out six months after that? |
I've said before that a startup's edge over a big company isn't the presence of any specific thing. It's the absence of all the weight and baggage the big company accrued over the years. When adding specific rules for your AI to follow, you need to be careful you’re not accidentally limiting your upside by forcing it to follow what you think is the best way to approach a problem. Because, if given the opportunity to rethink the best possible solution itself, I’ve found my agents capable of very elegant solutions when I don’t weigh them down with must-follow rigid rules about how to approach the problem. |
I don’t want to conflate context with rules. A rule is rigid. It instructs the model about how it should go about solving the problem. Context is about you. Here is what I like, here is what I've collected, here is what a good answer looked like last time. A rule goes stale because the model outgrows it. Context does the opposite, because every new model reads it better than the last one did. |
When the models get better, the outputs get better for everything built on top of them. |
|
|
Position Yourself for Compounding |
The more you build with AI, the more you benefit from future model updates. |
Don't think you need to wait for a viable business idea before you start experimenting either. The practical knowledge you pick up building something silly carries straight over to the thing that matters later. I built the dad joke generator partly because it was a low-stakes way to experiment with a closed learning loop. |
Whatever you build, feed it as much context as possible. And try to minimize the number of hard rules you force it to follow. Context can only improve output as models get better. Meanwhile, rules you write as band-aids for today’s models risk becoming tomorrow’s baggage. |
Traditional software may have conditioned you to worry about updates. Updates represent change, and change can be scary. New AI models, however, offer builders expanded capabilities without changing a thing. |
It’s an exciting time to be a builder 🙂 |
—Dharmesh (@dharmesh) |
P.S. I mentioned YouSpot above -- I’d love to hear from any one-person businesses who read this newsletter, if you have a chance to check it out. You connect the tools you use daily (like LinkedIn, X/twitter etc) and it builds a second brain from your business context. Please do hit reply and tell me what you think if you check it out. Thanks! |
|
|
|
|
What'd you think of today's email?Click below to let me know. |
|
|
