A friend with no software experience comes to me and says, OMG, you should see what I vibe coded this weekend. I look at it and I see so many things that make me cringe that I don't even know where to start.
Being able to build things these days is real. You can build some incredible things. I'm really happy with my giveready.org project, something I vibe coded over a few weeks. But I also have experience building software, at least knowing what exactly goes into it, running teams as big as 75 people building.
First of all, it's one thing to have something running on your local machine. That's probably where it should stay. But you turning this into an app, bringing it to hosting, and bringing users? Run away.
The first app that I vibe coded ended up being like that. It was about a year ago. I started building a KPI dashboard that would monitor things from our software's API. Everything was great and looked beautiful on my home machine. So I got bolder, and I started moving more APIs into the dash to make it a real powerful reporting machine. Then things started to break.
The numbers seemed off. AI-generated SQL was joining tables on what looked like the right key but wasn't. Dates were converting to my local timezone in some places and UTC in others, so the same row would appear on two different days depending on the chart. Aggregations were silently dropping nulls instead of treating them as zeros, which made averages look better than they actually were. None of it threw an error. It just produced wrong numbers that looked right.
I wanted to introduce call transcription and AI chatting to the database. It was exhilarating to be building things in front of my eyes. Like, with one command, and 10 minutes later screens would change and show up instantly. Whenever I wanted to bring those changes to the hosting platform, other things would break. What works locally and what works in production are two different machines. Different environment variables, different versions of the same library, secrets stored in different places, network rules that block the call you tested at home. Anyone who has shipped real software lives this every day.
It became a frustrating nightmare. I was scared to go in and touch things for fear of breaking other parts of the app. What it ended up being was a three-month-long time suck. The project had some useful applications and some of the data was good. The problem with some of the data being good and some not? If there is any bad data in a KPI dashboard, it makes the whole app suspect. The team stopped trusting any number on the screen, even the right ones. Trust is binary. You either have it on every line or you have it on none.
Out of frustration, I ended up bringing in a 'real' software developer to help me manage the deployments since that is where I was having most of my frustration. The problem for them was that I had built the app and knew how everything worked. He didn't know anything about it. He had to learn the platform, ask me all kinds of questions, and then rebuilt a lot of it the right way. Tests on the SQL queries so the wrong-key join screams instead of silently lying. Migrations that move the database schema forward in version control instead of by hand. Secrets in a vault, not in a config file checked into the repo. Logging and error tracking so the next break shows up on a monitor, not in a Slack message from a confused user. A deploy pipeline that promotes from dev to staging to prod, instead of clicking the same button on the laptop and hoping. Each of those is its own discipline that takes years to learn.
We ended up killing the project, and it soured my views on vibe coding. At the very least, if I started another project, I would know that it should be very light, useful for just me at a minimum, and not be something I grow too attached to. Write something, play around with it, learn, but if you need to totally blow it away to redo it, that's the right way to think about how to learn vibe coding as a non-technical person.
Vibe coding has gotten better since that time. There is also research now that backs up what the dashboard taught me the slow way. A study from METR last summer measured experienced developers using AI tools on real open-source tasks and found they took 19 percent longer to complete the work. The kicker was that the developers thought they had gone 24 percent faster. The thrill of generation outpaces the cost of cleanup, and you don't notice the gap from the inside. GitClear ran a separate analysis on millions of commits and found that AI-assisted code gets rewritten or rolled back inside two weeks at roughly twice the rate of human-written code. The lessons I learned still hold.
When it comes to seeing project briefs that sound like real software, touching upon enterprise APIs, I will always bring in the experts. I know there are limits to what I should be doing and what I should not be doing. After all, I'm a 5 out of 10 generalist in 15 different areas. Enterprise software projects, like the ones I am asked to do nearly all the time, should have 9 out of 10 experts checking out their domain areas of expertise. SOC 2 auth, database schema design, security, making sure the foundation is built properly. SOC 2 alone is a 30 to 100 thousand dollar audit and a 6 to 12 month observation window before the report is even valid. It is not a checklist you knock out the weekend before a client demo. Database schema design is the difference between a system that scales for five years and a system you have to migrate at 2am next quarter. Security at production scale means treating every authenticated request as a potential attacker, not a curious user. The foundation is what nobody asks about while it works and everybody asks about the day it doesn't.
What I am the 9 out of 10 at is the layer above the code. Reading a process and turning it into the shape of an AI workflow. Picking the right platform out of a noisy market. Writing the skills that put domain expertise on paper. Connecting the wires between Slack, Trello, Claude, the database, and the partner who needs the answer at 06:30 in the morning. Also being able to tell a good CTO from a bad one, and have the right person to call and ask in my 20-year Rolodex. When the brief turns out to be real software, I scope it, find the right 9-out-of-10 expert, and run the harness around them. That is the job of a Chief AI officer or fractional AI ops person.
Vibe coding with today's models can make you feel like a Silicon Valley senior developer, but I can assure you that you are not. I've felt the thrill of cutting non-thinking engineers out of the loop and having the ultimate freedom to build things. I've also felt the extreme frustrations, mostly at myself, for taking on more than I could handle. There are times to know when you can build a light, fun tool for yourself, and other times when you need to call in the experts. That's probably another one of my 5 out of 10 skills, knowing I'm not the right person to try and take it on myself.
Monthly Revenues $11,800 | Clients 2 | Prospects 1 (will book once closed) | Employees: me
Day 38 of 365.