The Case for Vibe Coding
September 2025 Monologue
During my sophomore summer, I was a bit crazy and did two internships. One of them was at a company called Glowforge which creates hobbyist 3D laser cutters that you can use to create everything from clothing and cutting boards to board games and furniture.
Five years later, I still remember the vision that one of the founders Dan Shapiro communicated: I hope to create a world where when we want something—a new tablet, a kitchen table, a gift for a friend—our first question to ourselves is not “where can I buy it?” but instead, “how can I create it at home?”
I love that vision. If you sit back and think about it, we are all living a life that others have created for us.
We go to the places where the trains will take us.
We fuel our bodies with the food the grocery store offers us.
We fill our minds with headlines and videos that algorithms have chosen for us.
And after decades of outsourcing our problems to different companies, I increasingly feel like we are waiting for companies to tell us what we should be focusing on in our lives.
But what if instead we ignore the product shelves and ask ourselves “what can I create to solve my own problems?” This framing forces us to think precisely about what we want and only when we want it and I hypothesize that following it would help us fill our lives with things we need rather than approximate solutions to advertised problems.
While it might not be possible to print every physical object you could ever want at home right now, I do think this year’s developments in code generation does make it possible for us to create any digital tool we would want.
The next time you think about ways to up skill in your career, maintain a healthy workout routine, or stay connected to your siblings, your first action doesn’t need to be hiring a person, buying a subscription, scrolling through an infinite feed of encouraging influencers or just ignoring the problem. Instead, you can open some kind of IDE, describe your requirements and start using your new tool instantly, with no additional noisy features or retrofitting to a general solution.
This is what I believe is the case for vibe coding.
The case for vibe coding personal software
The hours you spend looking at your phone during your commute, in front of a computer at work, or scrolling on your bed at night, are no longer in the hands of computer science majors, the MBA grad who called you to understand problems they never lived, or simply the people who have the most money to pay for their problems.
It is in your hands. And I believe every piece of software that is targeted toward solving a problem or workflow that you understand well and have opinions about, should be created by you.
For example, I love writing, and I want to get better at it.
The canonical way to improve your writing is to read books and articles from esteemed and amateur authors, analyze and critique what you read, write more, and have others critique your writing.
But I work a full time job. And getting the moment to sit down with a book or my laptop leaves getting better at my hobby to a weekend at the end of each month.
What can I build that helps me achieve what I want while fitting the parameters of my life?
I used this app called Vibecode to create a simple app that pulls writing snippets from different authors every day, allows me to see the background of the author, and save quotes and notes from each passage as inspiration for my own.
And this took me less than 5 prompts under 20 minutes!
And the fun thing about this is as I’m reading and realizing I want certain features, a system for tagging content, analysis on the types of writing that resonates with me—it is all just a prompt way.
Now, I am a full-time software engineer, and I work on building intelligent document processing for thousands of enterprises handling data at unimaginable scales. I know that software is hard to architect and hard to maintain. I do not think engineers will be replaced (more on that in another essay), and I’ve used Claude Code, Cursor, Windsurf for over a year, enough to know its limitations and the places a non technical user would get stuck.
This begs the question:
When should I create my own software? When should someone else do it for me?
Let me present you this nice chart:
I plot here a non exhaustive list of software that people both in a personal and business context will interface with from day to day. On the y-axis we have “customer’s understanding of the problem” and on the x-axis we have “software complexity”.
The y-axis is simple. People should only vibe code software for problems they understand and have opinions about. For example, I’m a restaurant owner, and I want software that helps me manage my employees’ work shifts. I want a simple interface that let’s employees sign up for shifts, trade shifts, ask for time off, and receive reminders to make sure the restaurant is always staffed. Right now, I can buy a general purpose shift tracking app or pay a dev shop to set something up. In the former, I may be lucky and find something that exactly fits my requirements, but commonly with general solutions there is a “last mile delivery” problem where some set of requirements are missing or there are additional bundled features that make the platform more noisy and costly than what I need. In the latter, sitting with a dev shop to communicate my needs and paying retainer for maintenance and additional features over time leaves me in a costly and suffocating place.
The restaurant manager could instead vibe code a simple scheduling app and iterate on the requirements they have over time. This saves them shopping, negotiation, and translation time that they could spend focusing on my actual craft.
On the other hand, let’s take a workflow like filing taxes. Even as a W2 employee where taxes are as simple as filling out a form, I do not have the expertise to understand all the tax filing logic and the cost of inaccurately filing my taxes is high. I choose not to vibe code this and thank the team of software engineers who can take on this responsibility for me
The x-axis is more controversial. At what point is a piece of software so complex that it cannot be created well by a human with a coding agent? When do we need a team of experienced engineers?
In my opinion, the hardest part of building most software is designing data models and infrastructure that serve the features you want today and are extensible to all the features you would want tomorrow. The best engineers I’ve worked with have great intuition on what abstractions to create, when to refactor something, which features to support now, and which features to avoid.
Our current coding agents, don’t have this intuition. From my experience, when you try to vibe code a full stack app with something like Cursor, the agent will make “mistakes” like hard coding text in your React components, creating table schemas with extra fields you didn’t ask for or too few fields like missing a creation time that would allow for backwards compatibility, or even creating duplicate APIs that branch in logic over time. For a single user, small data app, these mistakes might be okay—the surface is small enough that the builder can manually test and debug all user flows. But as soon as you start to build apps that support multiple users, concurrent interactions, and large data, the agent’s poor abstractions cause bugs that make the software hard to recover and unusable.
I believe a good vibe coding platform can help solve these issues.
I talked briefly about this “last mile delivery” problem with small scale enterprise apps, and I imagine a catalog of templates covering the most basic CRUD apps like fitness trackers, appointment booking, meeting recording, forums etc would give a great foundation to help enforce good programming practices like model view controller design but still allow the user to mold the solution to their exact requirements.
The other trap I see vibe coders falling into is over complex, conflicting asks.
“I want an app where all my employees can schedule shifts and they cannot edit each other’s shifts. I want the buttons to be blue and to show confetti after an employee finishes a shift. Employees should be able to swap shifts with another employee. Oh and automatically pay the employee after their shift if they completed it.”
These asks are not unreasonable, but a good vibe coding platform should help the user work toward a cohesive interface. We can help the user maintain a set of global guidelines that confirm and prioritize the their features so both the user and the AI can maintain existing features while debugging and adding new features.
Parting thoughts
Having lived amongst the entrepreneurs and engineers of Silicon Valley, I’ve seen many talented computer science grads chasing increasingly niche personas, in hopes of striking profit. But as the coding picks and shovels become cheaper and easier to use, the real gem isn’t the software, it’s the context and first hand understanding of problems that the we all have.
I would love to wake up to a world where the person walking down the street observing what’s in front of them and dreaming about what it could be has the power to contribute to software. A new gallery of open source projects, with people forking projects for their own lives and contributing back insights from their lived experiences.
Then, you can leave the fun large data, high traffic, high security software challenges for us engineers to build.
If you made it this far, thank you for reading my September monologue. If you have questions, opinions, experiences about any of these topics, I would love more than to discuss! That’s why I write after all :) You can find me @jjanezhang on X.
A special shoutout to my friends Luke and Judy for being a big part of my support system :)
Other topics I thought about but didn’t write about:
Writing fictional characters that I want myself to become but am too afraid to be.
Why engineers will not be obsolete in the next decade.
We do not know all the things that people in our lives are going through.
Read the original motivation for my this writing project here:
I loved this part in particular. Alpha comes from knowing a problem more deeply than anyone else in the world, not from being able to do good UXR on a problem you haven't lived yourself.
"But as the coding picks and shovels become cheaper and easier to use, the real gem isn’t the software, it’s the context and first hand understanding of problems that the we all have."
Your writing is always so great.
I think the problems for engineers will get increasingly more complicated, so I'm not too worried about our jobs :)