Writing · April 2026

I Shipped Four AI Products in One Month. Here's What Actually Works.

I am not a developer. For years, I worked on national climate plans and corporate climate actions. At WRI, I analyzed national climate plans for countries around the world. At BCG, I helped a Middle East government write their national climate plans, and helped corporations build net zero strategies they could actually execute.

One month ago, I started with a small task — just out of curiosity — to figure out how I could get better at prompting when I talk to ChatGPT. It ended with me shipping four products: Smoke Story, a wildfire intelligence tool; NoThanks, a workplace AI chatbot; Echo, a music visualizer; and Climate Triple Takes, a climate storytelling experiment.

Here's what I actually figured out.


Download it and learn by doing

The fastest way in is to start. Not to read. Not to plan. To build something real.

Friends often ask me: how do I even start with Claude Code? They see a command-line interface and assume they need to know how to code. You don't.

My advice: just download it and do something small. Once you feel how powerful it is — especially when you're using it as an agent — you'll naturally want to keep going. The most common trap is thinking you need to read a textbook before you start. You don't. Downloading it is the most powerful step.

That said, before you figure out what to build, figure out how you learn. There are a hundred ways to get into AI: YouTube tutorials, structured courses, boot camps, documentation deep-dives. None of that matters if you don't know how you absorb things.

After years of studying, the format that works best for me is a flipped classroom. My experience is that learning by doing is way more effective than opening a textbook first — reading a cloud computing textbook before you've touched the thing teaches you almost nothing. Start building, get stuck, figure out why, then go back and read. The confusion isn't the obstacle. It's the prerequisite. An explanation lands when you already have a question to attach it to.

One more thing: I haven't spent a penny on learning resources. The best ones are free. I've been curating what's actually useful in my AI Learning Journey on GitHub. Start there.


Start with what you already know

Your first project should come from your deepest expertise, not from what sounds impressive.

The most common question I get is: where do I start? What should I build first?

My answer: start with your expertise. I spent years working on NDCs — national climate plans — at WRI and BCG. When I decided to build my first tool, I went straight to that subject matter. What that background gave me wasn't just context. It gave me a quality signal. I could tell when the AI's output was confidently wrong about what a country had actually committed to — a mistake a generalist would have no way to catch.

You already know what good looks like in your domain. That's the underrated advantage.

One pro tip: keep the scope small. Don't start with an ambitious project. You'll lose interest before you finish, and that's discouraging in the wrong direction. Small projects teach you more, move faster, and are far easier to ship.


Let AI design your curriculum

The most effective learning plan isn't one you map in advance — it builds itself around the problems you're actually trying to solve.

I didn't start with a learning roadmap. I had no idea what my curriculum should look like.

What actually happened: as I built small projects and ran into problems, I'd ask Claude what I needed to learn next. Claude would recommend a course or concept. I'd take it, run into the next problem, ask again. The roadmap built itself — shaped entirely by what I was actually trying to do.

Every concept arrived exactly when I needed it. I already had context. I already had a problem I was trying to solve. That's when things stick.

AI is very good at teaching you how to use AI.

Having an AI tutor that meets you where you are — not where a course designer assumes you are — is genuinely different from anything we've had before. Most people haven't fully reckoned with what that means for how we learn.


Building is a lifestyle, not just a skill

Good building requires developing your intuition — and intuition grows outside the desk.

Most of my previous work was analytical — identifying problems, running analysis, making recommendations. Building is different. And the more I do it, the more I believe the foundation isn't technical skill. It's intuition.

Intuition is what gives you sense and judgment. It's what lets you spot a problem that's actually worth solving. It comes from your own life — the experiences, decisions, and observations that are entirely yours. You can't shortcut it, and AI can't replicate it.

What I've learned is that intuition doesn't grow at a desk. My best ideas come on walks, in rest, on days I've stepped away entirely. I've started treating this the way artists do: actively seeking out things that have nothing to do with AI — art, nature, experiences that are entirely their own. Not as a break from the work, but as the source of it.

AI can execute. It cannot tell you whether something feels right. That judgment is entirely yours.


Ship the embarrassing version

Sharing before you're ready almost always produces better results than waiting.

“If you're not embarrassed by the first version of your product, you launched too late.” — Reid Hoffman

In the beginning, I held back. I didn't think my tools were ready. I kept waiting for the version I wouldn't be embarrassed by.

The opposite happened. When I finally shared, people reached out — former colleagues, friends, people I hadn't spoken to in years. They told me the work was inspiring. Those conversations turned into something real: genuine exchanges about what we were each building, what was working, what wasn't.

You don't know what you'll get when you put something out. But the upside of sharing early is almost always larger than you expect.


Find your people

When you're building alone, the people around you become your team.

Before vibe coding, building meant a team. A product manager to define scope. An AI engineer to build the model. A data scientist to validate the output. A designer to make it usable.

Now it's just me.

I could use AI sub-agents to fill some of those roles — an AI PM to review product decisions, an AI designer to critique the UI. And I do. But I still keep a small group of real people around me: an artist, a PM, an AI engineer, a data scientist, a visual designer. Not just for feedback — as sparring partners. Sources of inspiration. People I have regular conversations with.

The range of perspective is hard to replicate any other way.

If you stay in your own silo, your feedback loop is just you. That's not enough, and it's not the point. Find your people, even a small one.


The barrier to entry is genuinely lower than it looks. The harder question is knowing what you want to build, and for whom.

← All writing