Riding the AI roller coaster

Every few weeks something in AI "changes everything". A few weeks later, the same people say it's over. If you ride every wave, you spend the year switching tools and ship very little. Here's how I stay on the roller coaster without being thrown off.

Sort what changes from what doesn't

Models, tools and prices change every month. The fundamentals change every decade: how an app moves through its lifecycle, how a request reaches a database, how data is modelled, what makes an interface feel calm.

Here's the part people miss: the better AI gets at typing code, the more the fundamentals matter. You're no longer the one writing every line. You're the one judging whether the lines are right. You can't judge what you don't understand.

A cadence, not a feed

I don't try new things when they're announced. I try them on a schedule.

• A weekly lab block. A few hours for new models, APIs and tools, in a separate place. Mine is a repo called Native Lab, where every experiment is isolated so it can be thrown away.
• A monthly look at the tools I actually use. Is there something better? Is it better enough to switch?
• Never mid-project. The stack a project starts with is the stack it ships with, unless something is broken.

Keep your own test

Benchmarks measure someone else's work. Keep ten real tasks from yours: a bug you fixed, a screen you built, a migration, a tricky piece of copy. When a new model or tool arrives, run it on those ten. In an afternoon you'll know more than a month of threads can tell you.

Make switching cheap

If changing models means rewriting your app, you'll either never switch or switch too often. Keep one thin layer between your product and any provider. Keep prompts in files, next to a small test set. Then trying a new model is a config change and a test run, not a project.

Read the source

Release notes, documentation and changelogs are where the real information is. Screenshots of benchmark charts and hot takes are where it's lost. When something big is announced, I read the docs and try it in the lab. The opinions can wait.

Learn by building small

A weekend app teaches more than a month of reading. Most of what I know about new things came from small builds: a WebGPU world running inside React Native, a keepsake app with an assistant on Convex. Each one was small enough to finish, which is what made it worth doing.

Skills that compound

Whatever happens next, these keep paying off:

• Writing clear specs. Agents and people both do better work from a good brief.
• Reading code quickly. You'll read far more than you write.
• Verifying. Tests, types, running the thing, looking at the screen.
• Taste. Knowing what to leave out.
• Shipping. Getting it through review and into someone's hands.

Measure the right thing

At the end of each month I ask one question: what did I ship? Not what did I try, or what did I read about. The roller coaster will keep going up and down. What you ship should only go up.