How to Get Ahead in the AI Era

One post tells you software engineers are dead. The next is a guy on X claiming his AI app is making him rich.

Then Andrej Karpathy writes:

“this gap in shared understanding of LLM capability is widening.”

His October 11 post ranges from casual chatbot use to researchers with access to internal systems most of us cannot test.

And you're trying to figure out what to learn, what to build, and whether any of this is actually going to change your life.

Karpathy connects that gap to access, the work people attempt, and the areas where models perform well. That got me thinking. We can spend hours arguing about AI while barely testing what it could do for our own work.

I'm figuring this out too. I pay $200 a month for Claude, use Claude Code, and still hit usage limits. Some of my recent AI experiments are still side projects. But those experiments are changing what I think I can build.

For a builder, that's where I see an opportunity: develop the ability to turn these tools into useful results, then give people evidence of what you can do.

Here's the plan: test AI on your own work, expand what you can build, finish something useful, and make that work visible. By the end of this article, you'll have a way to work on each of those over the next 30 days.

1. Find out what AI can do for your work

I've talked with nontechnical people trying to build websites with AI. I've seen some pretty rough results. I understand why someone would look at that first attempt and decide the whole thing is overhyped.

But I've also seen enough to know that better results are possible. The model, the instructions, the context, and the time spent improving the result all affect the experience.

Access matters too. A person who can keep working through a difficult problem has a different experience from someone who hits a limit halfway through.

Claude Pro currently costs $20 a month when billed monthly and includes Claude Code. Max starts at $100, with options offering five or twenty times Pro's usage per session. That gives you more room to work; it doesn't promise proportionally better results. You can check Claude's current plans before choosing one.

If a usage limit keeps interrupting useful work and you can afford more access, an upgrade may be worth testing. If $20 is your budget, choose a smaller task you can investigate properly. Spending more won't automatically clarify an idea or tell you whether the result works.

Start with a task you understand well enough to evaluate. For a mobile developer, that might be adding saved searches to an existing app. Give the agent the relevant code, describe the expected behavior, and test the result on a device. Change a requirement and see how it handles the revision.

Record how long it takes to reach a result you trust, including your review and fixes. Note where the tool needed help. You'll start learning which work you can delegate and which decisions still need your attention.

Your job may keep you inside one stack. Your team may not be ready to try these tools. Family responsibilities might leave you an hour in the evening. Work within those constraints and make the experiment small enough to finish.

Your first advantage is firsthand evidence. Choose one task, define what a good result looks like, and find out how much of it you can accomplish with the tools available to you.

2. Expand what you're capable of building

I worked as a software engineer at Walmart, where I used React Native. Later, at Expo, I worked closely with developers and the tools they used to build apps. React Native and Expo became the way I understood mobile development because they were what I used every day.

That experience gave me a lot. It also shaped what I considered trying.

There are other ways to build: SwiftUI, Jetpack Compose, Flutter, Kotlin Multiplatform. As I've experimented with AI and explored different frameworks, I've started seeing possibilities I used to put off because of how much learning they seemed to require.

I still use React Native and Expo. I'm also enjoying having more options.

My understanding of navigation, data, device capabilities, and user experience carries into another framework. AI can help me investigate unfamiliar code while I learn the parts I'm missing. I can attempt something and check my assumptions sooner.

I've felt this outside app development too. While working on a little display for my desk, I downloaded Blender and asked AI to design a case for it. It produced a case design. A small experiment gave me a reason to explore another part of making a product.

Established teams are reconsidering their choices too. In September 2026, Shopify announced plans to move its mobile apps from React Native to Swift and Kotlin because coding agents had changed the cost of maintaining separate implementations. Its Shop app had reached the stores after a 12-week migration assisted by AI, with a core group of six engineers and feature teams joining later.

Later that month, DHH showed six native HEY applications in development and said the work had started about a week earlier. These were early versions of an existing product.

The useful signal is that experienced teams are retesting assumptions about what it costs to build. Shopify also emphasized that native expertise remained essential. Technical decisions still matter, and we have more help exploring them.

Pick one constraint you've accepted and test it. Rebuild a familiar screen in a different framework, try a device API you've avoided, or automate a task you usually do manually. Write down what transferred from your existing experience and what you still need to learn. That gives you another option the next time you build.

3. Turn an experiment into something someone can use

Starting a project doesn't mean signing away the next six months of your life.

Build the weird app. Try the idea that sounds ridiculous. Start five tiny experiments in a day if you want.

Two hours later, you can decide it's going nowhere and delete it.

You still learned something: what AI can do, where it breaks, or what you actually enjoy building. That experience might become useful on a completely different project a year from now.

Give your ridiculous ideas a couple of hours before you talk yourself out of them.

“When you adopt the perspective of a researcher, you see everything as an experiment.”

Give that experiment a question to answer. Find out whether a particular interaction is possible, whether an automation saves you effort, or whether you enjoy working in a different stack.

Some of my recent projects are still at that stage. They're helping me learn, and I'm deciding which ones deserve more time.

When you find something promising, take it through one complete workflow that another person can use.

Imagine a small app that helps a friend track equipment they've lent out. The first version might let them add an item, record who borrowed it, and mark it returned. Put that workflow in their hands. Watch whether they understand it, whether the data survives closing the app, and whether they come back to use it again.

Their behavior will show you work the first demo didn't reveal. They might need reminders. They might find adding an item too slow. They might already have a solution they prefer.

You can use that information to improve the app, change the idea, or stop. If they keep using it and the problem matters, you have a reason to explore whether others would pay for it.

This is the part of the Builder's Loop I keep coming back to: idea, understand, build, ship, earn, iterate. AI can help with the work throughout that loop. You still need to choose a problem, inspect the result, and learn from the person using it.

Finish one useful workflow and let someone test it. An internal tool, a small app, or a reliable automation counts. Make one improvement based on what you observe. That's how a promising experiment starts becoming something valuable.

4. Give people evidence of what you can do

Some of the clearest AI success stories I see are creators teaching people how to use the tools. Part of that is visibility. Creators show up in my feed. Someone quietly improving their work with AI is much easier to miss.

Still, there's a real lesson there. When people are confused, a clear explanation is useful.

A tutorial that feels basic to you might be exactly what someone else needs. You already know which tool to open, what information to give it, and how to recognize a bad result. A beginner may be missing all three.

Naval has a line that connects building with communicating:

“Learn to sell, learn to build, if you can do both, you will be unstoppable.”

Explaining your work helps someone understand the problem, see the result, and decide whether it matters to them.

I've experienced this with Code with Beto. I started sharing what I was learning about React Native while preparing for interviews. That work helped open doors at Walmart and later Expo. Teaching became a much bigger part of my life than I expected.

You already have material from the work in the previous sections. Show the screen you rebuilt. Explain where the agent got stuck. Demonstrate the workflow someone is now using and what you changed after their feedback.

Include enough detail to be useful: the task, the tool, the context you supplied, the result, and the part that still needed your judgment. If you tested something for an afternoon, say that. Your honesty helps people decide how much confidence to place in the result.

Write a short post, record a demonstration, or share it with a relevant community. You can start by helping one colleague. Pay attention to the questions people ask, because they can reveal another problem worth solving.

Over time, this gives people reasons to trust your judgment, hire you, collaborate with you, or try something you build. You become easier to recommend because they have seen your work.

Make one useful result easy to find and understand. Show what you did, explain what you learned, and invite someone with the same problem to try it.

Your next 30 days

Keep the scope small enough that you can complete this alongside your existing responsibilities. Use one problem throughout the month so each week builds on the previous one.

At the end of the month, review the evidence: what you can now build, what you can delegate reliably, what someone found useful, and what you can show for it.

That's an advantage you can keep developing. Each finished cycle gives you more experience to bring into the next one, and more work that other people can discover.

Start with one problem you understand. Give yourself 30 days to build, test, and share something useful.

Let's keep building.

Beto