I just built a full-stack web application. And I have absolutely no idea how to code.
Well, that’s not entirely true. I can write SQL. I can hack together some Python code. But React? TypeScript? Node.js? I couldn’t tell you what any of those things actually do, let alone write a functional application with them.
And yet, I did.
The Absurdity That Started It All #
When I switched from Windows to Mac about a year ago, I faced a peculiar problem. For nearly a decade, I’d tracked my speaking engagements in Microsoft Access. Access is one of the most underestimated prototyping tools out there - it stored my events, sessions, call-for-content URLs, and everything else I needed. It integrated beautifully with Power BI for reporting. It was a quick hack that did exactly what I wanted.
But Access doesn’t exist on Mac.
I needed a solution. After briefly considering Excel, I arrived at what seemed like the only viable option: run a dedicated virtual machine in Azure with Office and Access on it.
Let that sink in for a moment: a dedicated virtual machine for running Access. ONLY Access.
There had to be a better option.
Everyone Else Is Doing It, Maybe I Can Too? #
A few months ago I read through Kurt Buhler’s blog posts on LLM-assisted coding and had several conversations with Eugene Meidinger on the topic of LLM-assisted coding, a.k.a “vibe coding”. Eugene showed me things I never thought possible.
“Don’t let that stop you,” Eugene said when I pointed out the massive gap in our coding abilities.
So I decided to try vibe coding with something as far removed from production work as I could imagine: rebuilding my speaking tracker. How hard could it be?
Getting Ready #
Eugene was clear on one thing: the better you describe what you want, the more likely you’ll get it. I wrote down everything I could think of - tables for events and sessions, how they connected, what properties each needed, and how filtering should work.
The more I wrote, the more ideas came to mind. After a while, I had solid specifications.
I like being forced to be clear on outcomes. If nothing else comes from the pervasive use of LLMs, this alone can have a huge impact on projects.
I exported my Access tables to CSVs and opened Claude Code.
The Magic Moment #
My first question: what should I build this in?
“Use React, TypeScript, and Node.js,” Claude responded.
I didn’t know what that really meant. I’d heard of React and Node, but I don’t actually know what they are. But who cares, right? Onwards!
I explained my request, used my specifications, and offered the CSVs as instructions (and partly as sacrifice). Claude thought for a while, asked for permissions to set up Node.js and run commands in my local environment, then told me to open a web browser and navigate to localhost port 5172.
And there it was: a complete, fully functioning (almost) version of my Access speaking event tracker.
I was blown away. Claude accomplished something that would have taken me weeks or months.
And then I ran out of tokens.
The Hidden Cost Of Ignorance #
I’m on the Claude Pro plan at $20 per month, which gives me a set amount of tokens per session and per week. Estimating costs with Claude (or any LLM where you pay per token) is about as simple as estimating costs in a cloud SaaS solution.
You can’t.
What’s more sinister: things that would be dead easy for a human might require massive amounts of tokens for the LLM. A supposedly simple request can burn through tokens at an exceptional rate.
But tokens reset at intervals during the day and week, so I parked the project and did other things. As someone who easily gets consumed by problems (to the tune of forgetting to eat), having forced breaks wasn’t entirely bad.
The Winding Path #
Having exhausted my specifications document, I launched into a long conversation with Claude. I’d ask for a small change, Claude would think, and deliver what I wanted. For the most part, I got exactly what I asked for, which made it even clearer that I needed to be explicit in my requests.
For prototyping, this made Access look like a toy. I had the wild idea to import data from a Sessionize call-for-content URL. I described what I wanted, and a few minutes later, I had an (almost) working import button.
But this exposed a huge issue: since I’m not a developer, I don’t know the implications of my requests. Asking for an import button seemed simple to me. Claude had to do substantial work to make it happen.
The same thing occurred when I asked for filters in session and event lists. They turned out far more computationally expensive than I’d thought.
And the statistics page - an off-the-cuff idea that took on a life of its own.
When Your Co-Pilot Enables Your Worst Habits #
Being able to rapidly prototype is exceptionally powerful. It also enables scope creep at a whole new level.
Scope creep is bad enough when you’re responsible for implementing your ideas. When you have an eager assistant that will do anything for you, scope creep becomes an outright sprint race. I started adding things I didn’t really need.
I decided I wanted statistics showing the performance of specific sessions, where I’d been in the world, how many times I’d spoken each year. It turns out I’m much better at requesting outcomes than considering the difficulties involved in making them happen.
I was also getting things I never asked for. Somewhere along the line, Claude decided that an API was the best way to implement the connections between the front end and the back end. Claude isn’t wrong, but it did up the complexity.
My little toy project was becoming rather complex - and I still hadn’t even looked at the code. (Not that it would have helped; I still wasn’t sure what language this was.)
The Devil In The Details #
The more complex the project became, the more difficult it was to describe accurately what I wanted. Ambiguity crept in, leading to some interesting experiences.
Take the date field saga:
I asked for a date picker and got a field with a date picker.
I asked for keyboard input capability. I got it, but the date picker disappeared.
I asked for the date picker back. I got it back, but the field now accepted six digits for the year.
It took several rounds to get the field to behave correctly. This taught me about being explicit - and how easy it is to not be explicit enough.
Small details matter enormously. What seems like a simple request (“make the date field useable from the keyboard”) contains assumptions about behavior, validation, and user experience that need to be spelled out.
The Tools Provide Structure #
Claude thrives on good structure and specifications. It can also provide good specifications itself. Throughout my project, Claude continuously updated both the specification file and a human-readable readme. The combination of rapid prototyping AND producing clear, succinct specifications is incredibly powerful.
For years in business intelligence, we’ve said that business analysts must set direction for technical projects. Sadly, this rarely happens. Most technical projects - data warehouse implementations, for example - are tool-centric and almost entirely run by IT. This produces technically capable tools that might not fulfill actual business needs.
There’s a huge chasm between technical people and business people. In language, in presumptions, in expectations.
LLM-assisted prototypes might bridge this chasm. They can help IT understand what the business really needs, and help business people grasp the complexities involved. They might be the Rosetta stone we’ve been missing.
Just as long as the prototypes stay exactly that - prototypes that should not go straight into production.
But that’s a discussion for another blog post.
Skills Transfer (Or: Why Flight Simulators Are Like Vibe Coding) #
A few weeks ago I watched a YouTube video titled Can a Flight Simmer Hover a Real Helicopter?. The answer: yes, he did an excellent job transferring simulator skills to a real helicopter.
I’m both a private pilot (gliders, motor gliders, and single-engine piston aircraft) and an experienced flight simmer. I’m reasonably convinced that an experienced flight simmer could probably fly and land a commercial airliner, provided the automatic systems work (autopilot, autothrottle, instrument landing systems), the weather is good, and their deity of choice is smiling on them.
But the moment the automatic systems fail, so do any chances of getting on the ground safely. That’s where flight training and experience matter - and that’s exceedingly difficult to get sitting behind a monitor at home. The Dunning-Kruger effect tends to kick in as well, making flight simmers overestimate their abilities.
Vibe coding has similar dynamics. I can prototype something functional because the “automatic systems” (the LLM) will handle the complex parts. I understand enough about software architecture and requirements to describe what I want. But ask me to optimize performance or handle edge cases? I’d crash spectacularly. I’m looking forward to showing this code base to a developer that actually has a clue how to code.
The parallel matters because it helps set realistic expectations. LLM-assisted development lets non-developers create functional prototypes. It doesn’t make us developers any more than a flight simulator makes someone an airline pilot.
But just like a proper level D full-motion simulator is invaluable for teaching already qualified pilots the skills needed for type ratings or emergencies, an LLM can be equally invaluable in the hands of a skilled developer.
The Event Tracker Project #
I’ve decided to open-source the event tracker I built (Did I build it? Should I say “prompted”?). It might come in handy for someone else, be a great example of how not to write React apps, or be useful for learning.
Have at it.
Speaking Event Tracker GitHub repository
What Have You Built? #
Have you taken matters into your own hands and created a tool to help you? I’d love to hear what you’ve built and how you use it. Reach out on LinkedIn or BlueSky.