I Stopped Building With What I Know

5 min read
AIWeb DevelopmentLearningCareer

For years I picked the same stack because it was safe. AI changed that — not by writing code for me, but by making it safe to choose tools I'd never used.

Part 0 of a series on building with the modern web platform — and letting AI handle the learning curve.

The comfort zone

Every developer has a stack they reach for. Mine was React, Next.js, TypeScript, and whatever database felt right for the job. I'd used this combination for years across companies and side projects. It worked. I shipped things. I never questioned it.

When I wanted to build a reading list app a while back, I picked Next.js and Firebase. Static rendering, server components, Tailwind — the usual. It was a personal project with no deadline, no stakeholders, no constraints. I could have tried anything. I picked what I already knew.

That's the thing about comfort zones. They don't feel like a limitation. They feel like efficiency. You tell yourself you're making a smart choice — why risk a new tool when you know this one works? But what you're really doing is optimizing for the short term and closing doors you don't even see.

The alibi

The idea had been brewing for a while. I'd been experimenting with how AI can support content creation — research, writing, SEO — and I needed a subject I genuinely know and care about to properly evaluate what the AI produces. A few weeks ago, I decided to turn that experiment into something real: a Bitcoin education blog. I'd been following Bitcoin since 2017 and had even co-founded a crypto platform in Brazil years back. The topic was the easy part. The interesting question was the tooling.

I'd had Astro (opens in a new tab) saved in my bookmarks for ages. Static-first, zero JavaScript by default, content collections built in. On paper, it was a better fit for a content site than Next.js (opens in a new tab). But I'd never written a single line of Astro.

In the old world, that would have been enough to stop me. Learning a new framework means hours of docs, tutorials, trial and error — all before you ship anything. The return on that investment is uncertain. So you go back to what you know.

But something had changed. Since mid-2023, I'd been experimenting with AI-assisted development — first casually, then more seriously. By the time this project came around, I had a different mental model. The risk of picking an unfamiliar tool was no longer "I'll waste two weeks learning it." It was "I'll have a conversation about it."

So I picked Astro. Not because I was confident. Because I finally had an alibi to try.

The teacher you never had

When I started the project, I didn't read the Astro docs from top to bottom. I didn't watch a tutorial series. I opened my editor, described what I wanted, and started a conversation.

The AI wasn't writing the code and handing it to me. It was more like having a senior Astro developer sitting next to me, explaining concepts as I needed them. Content collections (opens in a new tab)? Here's how they work, here's the config file, here's how glob() loaders differ from what you're used to. i18n routing? Here's the pattern, here are the tradeoffs, here's what the config should look like.

In the first few iterations, I still had to go in and understand how the framework actually worked. I'd read what the AI suggested, check it against the docs, and build a mental model. But the feedback loop was incredibly fast. Instead of spending an afternoon figuring out why my content schema wasn't working, I'd describe the problem, get an explanation, and move on.

Within a few sessions, I wasn't just copying suggestions. I was making architecture decisions — choosing patterns, rejecting anti-patterns, designing a structure I actually understood. The AI was the facilitator. The decisions were mine.

Learning while delivering

Here's the part that surprised me most: I wasn't learning Astro before building the blog. I was learning while building it. Every feature was both a deliverable and a lesson.

This is a fundamentally different model from how most of us learned our current stack. We usually learn first, build later. Tutorials, courses, toy projects — then the real thing. With AI in the loop, the real thing is the learning environment. You ask questions in context, get answers that apply to your actual code, and build understanding alongside the product.

The blog ended up with a clean architecture: page-views pattern, JSON-based i18n, content collections with flexible tags, a utility layer for URLs and formatting. All in a framework I'd never touched before. Not because the AI handed me a blueprint, but because I could explore options and make informed decisions without the upfront cost of mastering everything first.

The door that opens

The point of this story isn't "use AI to learn Astro." It's that the cost of trying something new has dropped dramatically.

For years, the practical barrier to exploring unfamiliar tools was time. You had to invest it upfront, with no guarantee of return. AI changes that equation. It doesn't eliminate the learning — you still need to understand what you're building — but it compresses the feedback loop so much that exploring becomes a reasonable choice instead of a risky one.

I'm now building with a framework I didn't know, using native web APIs (opens in a new tab) I'd never tried, and making design decisions I couldn't have made from inside my comfort zone. Not because I'm a better developer than I was a year ago. Because I stopped letting unfamiliarity be a reason to say no.

Next in this series: the modern web platform (opens in a new tab) can do more than you think — and most of us are still shipping JavaScript the browser doesn't need.