It Was Never About Coding — A Vibe Coding Philosophy for People Who Have Something to Build
It’s a Vibe!”
I'm teaching a class on vibe coding right now, and I'll be honest — I've been finding my own footing with it at the same time. That's not a disclaimer. It's kind of the point.
What I want people to walk away with isn't a workflow. It's a way of thinking. A problem-solving posture. Because the tools are going to change — constantly — and if your whole approach is built around mastering any specific workflow, you're going to feel lost every time something shifts. And things are shifting fast.
It was never about coding. It was about designing experiences for people — because seeing information in a new way can ignite your imagination, make learning easier, and make being productive and helpful for others more rewarding.
Software has always been built around this idea. Companies have competed fiercely over who has the better interface, the cleaner workflow, the right balance of features — all designed to keep you on the platform. And with that comes a deal you may not have consciously agreed to: your data lives on their server, and your loyalty is the price of admission.
Vibe coding changes that equation. When you build something yourself, your data can live on a database structured around an interface you asked for, built around a workflow you're trying to create for yourself. You can import it. You can export it. That portability is a significant advantage — you're building your own material instead of renting access to someone else's platform.
What people are discovering in this process is what it actually feels like to be a product designer. They're learning what "done" means for a first version. They're figuring out which features matter most — not in the abstract, but in the context of something they're genuinely trying to build.
The tools are expanding fast
Platforms like Lovable are built specifically for creating websites and web-based apps through natural language. Tools like Claude and ChatGPT can render code, process data, and simulate interactive worlds based on what you ask for. If you want a 3D environment that looks like you're walking through a forest with a Minecraft or Pixar aesthetic, you can ask for that — and depending on how well you can articulate it, you might get surprisingly close.
What I appreciate about a platform like Lovable is that most of the foundational infrastructure — authentication, payment gateway, database, GitHub, production server, security checks, package updates — is handled for you out of the gate. You can customize later, after you have a working prototype. For database, I've found Convex handles data relationships better and renders them faster when called upon. Sorry if that offends you, Supabase.
A word on Cursor
Using Cursor has been genuinely impressive for one specific reason: the level of control it gives you. But that control is most valuable when you already know what the necessary components are for running a program. Most people entering this space aren't technically inclined, and many don't want to make this their new job — unless they see software development as a field to get into.
I'll be transparent about where I stand: I'm more interested in what I can create for people than in becoming a software developer in the age of AI. I'm an idea person and a solutions architect — someone who brings design thinking to enhance a business process or a service offering. That's a different role, and it's a legitimate one.
Cursor has its place — particularly when working with a technical team on proprietary software, or when a specific environment requires more hands-on configuration for compliance or a unique feature. But for someone who wants to create a tool or test an application with people they already know, jumping into Cursor first introduces a learning curve that may not be necessary. Interestingly, Cursor is starting to evolve — looking more and more like Lovable and Bolt, where the conversation thread, not the code editor, is becoming the primary canvas, with an integrated view across all the platforms keeping your application running.
The real danger: drift
You can go into any of these platforms and start experimenting, and before you know it, you're deeply invested in whatever direction the tool took you. This is what's now being called drift — where the AI is steering you instead of the other way around.
This is especially true when you have any emotional attachment to what you're building. That first prompt is exciting. You're either hoping to see something specific or about to be pleasantly surprised by how it gets interpreted. But adding complexity on top of what you've already built, without any prior planning, will eventually work against you. It makes the program harder to develop and harder to use for anyone, including yourself.
Start on paper
The best solution I've found — regardless of which platform you use — is to start with a blank piece of paper. A large one if you have it. Write it out. Draw it. Don't worry about getting it right. Draw what you're initially imagining: how you want the information or data to be displayed — whether that's a dashboard, an interactive game, or some kind of mashup that's both informative and entertaining.
When you do this, something becomes clear: what the different components actually are. Because any project has at least two layers — the content being brought to the user, and the design, the way that content is presented and engaged with. Separating those on paper before you ever type a prompt changes everything.
When you iterate with yourself on paper, two things happen: you retain your agency — preventing an AI tool from causing you to drift — and you start recognizing the questions you need to ask to take the application further.
It's very similar to sculpture. You begin to notice that both the idea and the process of rendering the idea are teaching you something. Something about yourself. Something about the way you see the world. And something about the way the world interacts with the thing you've made.
Your thinking should live somewhere you own
Writing shouldn't be limited to how well you use Microsoft Word or Google Docs. Those tools were built on the idea of writing on paper — that's literally why they look like a page on a screen. Here we are using AI through a chat interface, because that's where we've started. But why should our thinking be limited to the interface these platforms provide?
If all of your thinking lives inside the chat, the process isn't necessarily yours — unless you can remember it, and unless you're able to observe the way it's shaping you.
I can see critical thinking being genuinely enhanced through AI — solving problems with data, crafting a user flow that has the sense of a story arc. These are places where AI extends human capability rather than replacing it. But most people are beginning to recognize that there are pre-existing frameworks embedded in these large language models that can give the illusion of intelligence. The real starting point is being willing to recognize how much we don't yet know — and needing to level up in order to craft the solutions we actually want.
When you own the process of crafting solutions, you become more discerning. You add more value to the conversations you have with the people you collaborate with.
This post — the thinking behind it — required that I step away from the technology, reflect, and then bring it here. None of it was driven by the tools. The thinking came first.
Start on paper. Then build.