I Write About Technology. So I Finally Built Something.
A few months ago, I found myself watching people around me build things with AI. Some were shipping production tools. Others, like me, were exploring. But they were all actually building. And I was writing about technology strategy.
So I asked the obvious question: why not me?
The goal was modest. A blog, my own site, hitomim.com, a place to publish content I was already writing elsewhere. No complicated requirements. No database. No infrastructure I would need to maintain, monitor, or pay someone to manage. Something that worked automatically, deployed on a push, and stayed out of my way.
I turned to Claude Code. A few hours later, I had a working, deployed blog, built the way I wanted it, running on infrastructure that costs almost nothing to maintain. And the experience taught me something I had not expected about where the real work in building still lives.
The Architecture Decision Came Before the Code
Before I touched any tool, I spent time with Claude, not to generate code, but to clarify exactly what I wanted to build and why. That conversation forced real decisions.
Content would live in MDX files. Each post would have its own folder with its own images. There would be no database to configure, back up, or migrate. Deployment would be automatic: push to the main branch on GitHub, and Vercel would detect the change and publish.
That is the full stack. A GitHub repository, MDX files, and Vercel. The operational overhead is near zero. If I ever want to move the site, the content comes with me; plain text, version-controlled, fully portable.
For someone who has spent years advising companies on total cost of ownership, this was satisfying in a specific way. The decision to avoid a database was not a compromise. It was the right architecture for the problem.
How I Actually Built It
I used two tools to execute.
The first was Samuel — an AI agent framework built by my co-founder at Cuemby. Samuel is compatible with a wide range of coding environments: Claude Code, Cursor, OpenAI Codex, GitHub Copilot, and Google Jules. More important than the tooling compatibility is what Samuel brings structurally: guardrails, a four-step methodology it calls 4D (deconstruct, diagnose, develop, deliver), and on-demand workflows for complex tasks. This is not just a layer on top of a coding tool. It is an agent that guides you through decisions you would otherwise skip, including design considerations. For a project as simple as mine, that structure made the difference between a coherent build and a collection of half-connected pieces.
The second was Claude, used differently, not to generate code, but to pressure-test my thinking before handing anything to Samuel. This step is the one most people skip. AI coding tools are effective at execution. They are not effective at deciding what to execute. That part is still yours.
The process was easier than I expected, partly because I already had my environment set up. Terminal with basic tools installed, a code editor, a GitHub account, a purchased domain, and Vercel configured ahead of time. That prior setup removed the most common friction points before I started.
Where I did run into difficulty was error loops: a fix that introduced a new problem, which introduced another. This is a recognized pattern in AI-assisted development, not an edge case. The standard practice and the one that worked for me, is to commit working states frequently. Small, specific commits mean you always have a known-good point to return to. If a loop continues, the right move is to stop, commit the last stable state, and restart the session with a clean description of the problem. Continuing to iterate on a broken path rarely resolves it.
Once the local build was stable, I ran npm run dev, confirmed it looked right, and pushed to GitHub. Vercel detected the push and deployed automatically. The first time that happened — a push to main, a live website appearing; it landed with a quiet satisfaction I had not entirely anticipated.
What This Actually Means
The narrative around vibe coding, using AI to build without traditional engineering, tends toward two extremes. Either it is positioned as magic that removes all barriers, or it is dismissed as a toy for people who do not understand real software development.
Neither is accurate.
The tools have genuinely compressed the distance between intent and execution. What once required a developer, coordination with a product manager or subject-matter expert, and weeks of back-and-forth can now be done in a weekend by someone without an engineering background, provided they arrive with a specific, clear picture of what needs to be built.
But the compression only works if the intent is precise.
"Build me a blog" produces a different outcome than "build me a blog with MDX files, no database, automatic Vercel deployment, and content organized by slug." The specificity is not a detail. It is the entire execution.
The bottleneck in building has not been eliminated. It has moved. And it has moved to exactly where it always belonged: in the clarity of the person who wants the thing built.
A Note on Starting
I had some starting advantages: a terminal I had used before, an existing GitHub account, a domain already registered, and Vercel configured before I wrote a single line. Those things reduced friction, and I am not going to pretend otherwise.
But the honest prerequisite for a project like this is not technical knowledge. It is setup, and setup itself can now be done with an AI chat assistant. Ask Claude or other tools you are using for step-by-step instructions and follow them, like how to set up your terminal. When you encounter an error, and you will, describe exactly what you did and what you are seeing. That level of specificity is enough for the AI to diagnose and resolve most setup issues.
The remaining prerequisite is clarity about what you want to build before you ask anything to build it for you.
If you have been curious about building something yourself, the access is genuinely better than it has ever been. The question worth sitting with first is not whether you can use the tools.
It is whether you are clear enough about what you want that they will be useful.
That clarity is still the work. It has always been the work.