Why I Build Everything With Claude Code

I need to tell you something that might undermine every word on this site.

I'm not a developer. I've never been a developer. I did Design Technology, Geography, and English for my IB — not computer science, not engineering, not anything that would suggest I should be building websites. The last time I wrote code from memory, it was HTML in a school IT lesson, and I'm fairly certain I couldn't close a div tag properly.

And yet.

This entire site — the frosted glass cards, the dark mode toggle, the OG images that generate themselves, the RSS feed, the reading progress bar tracking your scroll right now — I built all of it. Every page. Every component. Every weird little design decision that kept me up past midnight arguing with a terminal window.

I built it with Claude Code. And that experience broke something in the way I think about capability, about who gets to build things, and about what's coming next.

What Claude Code actually is

Let me be precise here, because the name is misleading. Claude Code isn't a chatbot you paste code snippets into. It isn't an autocomplete tool that finishes your lines. It's a command-line interface — a terminal agent that sits inside your project, reads your files, understands your architecture, and builds alongside you.

You type what you want in plain English. It reads your codebase, figures out what needs to change, edits the files directly, runs the commands, and handles the errors. You're not copying and pasting between a chat window and your editor. You're having a conversation with something that's already inside the machine.

If you've read my piece on agentic AI, this is what that looks like in practice. Not a theoretical framework. Not a conference slide. An agent that actually does things, in your actual project, with your actual files.

The difference between this and a regular AI chat is the difference between texting someone directions and having them sit in the passenger seat. One is helpful. The other changes everything.

The real story of building this site

I want to be honest about what this process actually looks like, because the discourse around AI coding tools is either breathless optimism or performative scepticism, and neither is useful.

Here's what actually happened.

I started with a blank Next.js project and an idea: a site called Promptology, where I could write about AI with the nuance I wasn't finding elsewhere. I wanted it to feel like Apple designed a blog — minimal, considered, with just enough personality to not feel sterile. Violet accents. Beautiful typography. The kind of site where the design earns the reader's trust before the first sentence does.

I described this to Claude Code. Not in technical terms — I don't have technical terms. I said things like "I want frosted glass cards that feel like they're floating" and "the fonts should feel premium but not pretentious" and "make the dark mode actually good, not just an inverted colour scheme that burns your eyes differently."

And it built it.

Not perfectly. Not on the first try. But it built a working version, and then we iterated. Over and over. For weeks. That's the part nobody talks about — the iteration. The forty-seven times you say "no, slightly more rounded" or "the spacing feels wrong on mobile" or "that animation is too slow, it feels sluggish, speed it up but make it still feel intentional."

This is where my background actually helped. Design Technology taught me to think about user experience, about form following function, about the gap between what something does and how it feels. Geography taught me systems thinking — how parts connect to wholes. English taught me to be precise with language, which turns out to be the only programming skill that matters when your programming language is English.

The midnight debugging sessions

I'd be lying if I said it was smooth. There were nights — more than I'd like to admit — where something would break and I'd have no idea why. The OG image generation alone nearly ended me. I wanted each article to have a custom social preview image that generated automatically. The kind of feature a developer might knock out in an afternoon.

It took me three days.

Not because Claude Code couldn't do it. It could, and did, multiple times. But each version had some subtle issue — a font that wouldn't load in production, a layout that broke on certain screen sizes, a colour that looked right in the preview but wrong on Twitter. And I couldn't just look at the code and spot the problem, because the code might as well have been Mandarin. I had to describe the symptom, wait for the diagnosis, apply the fix, and test again.

Here's what I learned from those sessions: debugging with an AI agent when you don't understand the underlying code is an exercise in radical specificity. You can't say "it's broken." You have to say "the font renders correctly in the local preview but appears as Times New Roman when I share the link on LinkedIn, and only on the first load." The more precise your description of the problem, the faster the fix.

It turns out that being a good communicator is a legitimate technical skill. Maybe the most important one left.

What it teaches about building things

There's a larger argument here that I think most people are missing because they're too busy debating whether AI will replace developers.

It won't. That's the wrong question. The right question is: what happens when building becomes accessible to everyone who can think clearly and communicate well?

Because that's what's actually happening. Not the replacement of developers — the expansion of who gets to build. The same thing happened with publishing (blogs killed the gatekeepers), with video (YouTube democratised broadcasting), with design (Canva meant you didn't need a graphic designer for every social post). Each time, the professionals didn't disappear. The pie just got bigger.

I wrote about this dynamic in The Art of the Prompt — the idea that prompt engineering isn't a hack or a shortcut, it's a genuine skill of translation between human intention and machine capability. Building with Claude Code is prompt engineering at its most ambitious. You're not asking for a poem or a summary. You're asking for a functioning system.

And the people who'll be best at this aren't necessarily the ones who understand JavaScript. They're the ones who understand what they're trying to build and why. The ones who can hold a vision in their head and systematically close the gap between that vision and reality through clear, iterative communication.

I've done a deep comparison of the different AI tools available, and they all have strengths. But for this particular use case — sustained, complex, project-level building — Claude Code operates differently. It's not a conversation that resets. It's a collaborator that remembers.

The honest limitations

I promised honesty, so here it is.

There are things Claude Code can't do, or can't do well, or can do but probably shouldn't. And pretending otherwise would make me exactly the kind of uncritical AI enthusiast I find exhausting.

You still need taste. The tool builds what you ask for. If you ask for something ugly, you get something ugly, fast. The design sensibility, the editorial judgment, the "this doesn't feel right" instinct — that's entirely on you. Claude Code is a brilliant builder. It's not an art director.

Complex architecture decisions require understanding. I've made choices about how this site is structured that I don't fully understand the implications of. When something goes wrong at the architectural level, the debugging is harder because I can't reason about the system the way a developer can. I can describe symptoms. I can't diagnose root causes. That gap is real and it matters.

It occasionally gets confident about wrong things. I've had sessions where Claude Code will implement something, tell me it's working, and it isn't. Not maliciously — it's genuinely trying. But the confidence-to-accuracy ratio isn't always calibrated, and when you don't have the expertise to sanity-check the output, you have to test everything empirically. Click every button. Check every page. Resize every screen.

The learning is shallow. I've built a Next.js site and I still couldn't explain what a server component is versus a client component. I know the words. I've seen them in the code. But I don't understand them the way a developer who learned from first principles does. Whether that matters is a philosophical question I haven't fully resolved.

Why it matters beyond coding

Here's where I think the real story is, and it's bigger than websites.

We're entering an era where the bottleneck on building things is shifting from technical knowledge to clarity of thought. The constraint used to be: can you code this? Now it's: can you articulate what this should be, how it should work, and why it matters?

That's a profound shift. It means a geography teacher with a clear vision can build a learning platform. A small business owner can build custom internal tools instead of buying overpriced SaaS. A writer can build exactly the publishing experience they want instead of choosing between WordPress themes.

It doesn't mean everyone will. Most people won't, because building things is hard even when the technical barriers are gone. The thinking is hard. The persistence is hard. The willingness to sit with something broken at midnight and not give up — that's hard regardless of whether you're writing the code yourself or describing what you want to an agent.

But for the people who have ideas and the stubbornness to see them through, the moat around "building" just got a lot smaller.

The meta moment

I need to point out something that you may have already noticed. This article — the one you're reading right now — exists because of the process it describes. It was written on a site built with Claude Code, published through a system Claude Code helped create, generating an OG image through a pipeline Claude Code implemented, delivered via an RSS feed Claude Code configured.

The medium is the message, as someone once said. And in this case, the medium is a non-developer's entire publishing infrastructure, built through conversation.

I've written before about why Opus specifically matters to me — the particular quality of thought that makes working with Claude feel less like using a tool and more like thinking alongside something that genuinely engages with what you're trying to do. Claude Code is where that quality of thought meets the actual filesystem. Where the ideas stop being theoretical and start being deployable.

If you'd told me two years ago that I'd be running a Next.js site with TypeScript and Tailwind CSS, hand-tuning OG images and debating server-side rendering strategies, I'd have assumed you were confusing me with someone competent. But here we are.

What I'd tell you if you're considering it

Start with something real. Not a tutorial project, not a to-do app, not a practice exercise. Start with something you actually want to exist in the world. The motivation matters more than the skill, because there will be moments when it's frustrating and confusing and you won't know whether the problem is your description or the tool's interpretation or some invisible dependency you don't know exists. The only thing that gets you through those moments is caring about the outcome.

Be specific about what you want but flexible about how you get there. I had a vision for Promptology that was clear in my head — the feel of it, the tone, the experience. But I had zero opinions about the implementation details, and that flexibility let the tool work in whatever way was technically optimal.

Test everything yourself. Don't trust that it works because the agent says it works. Click every link. Check every page on mobile. Share a test post on every social platform. The bugs are always in the places you didn't think to look.

And most importantly — don't let anyone tell you that building with AI tools isn't "real" building. The gatekeeping around technical creation has always been more about identity than utility. Nobody asks whether a filmmaker who uses digital cameras is a "real" filmmaker. Nobody questions whether a musician who uses a DAW is a "real" musician. The tool changes. The creativity, the vision, the relentless iteration toward something that didn't exist before — that's the real work. And it always was.