Confessions of a Vibe Coder: Keep your Humans in the Loop!
I'm not sure how this is going to bite me, but here's the truth: most of the server work and application design I've done in the last 6 months is 100% thanks to Claude. It can search, optimize, and teach me things I'd never figure out on my own.
But here's what bugs me—I'm not sure if I'm actually learning faster, or just building faster.
Take setting up my YuNoHost server, for example. The whole thing took about 10 hours. If I'd been doing it the old way—Stack Exchange threads, half-finished documentation, forum posts from 2017—it could have easily taken me weeks. I probably would have given up. Instead, I had Claude coaching me through network errors, explaining server architecture in a way that actually made sense. It was like Google Search on steroids plus having a professional IT friend I could spam with the same problem 20 times without feeling guilty.
It was incredible.
Since then, I've made a habit of asking Claude to teach me what we were doing by having it write tech blog posts that walk through our work. It's been super helpful, and I've started posting them on my new /Tech page for anyone else who needs them.
At this point, I'm aware of two things: 1) I am learning with Claude's help, and 2) my understanding is not complete.
It's true that I'm learning a lot. Just like in university when I needed friends to explain MatLab or Python to me, Claude is always there to explain and re-explain things until they click. But once Claude starts troubleshooting things out of my depth, I get uncomfortable. I no longer have oversight of its decisions.
Recently, Claude helped me fix a Celery/Redis problem in Paperless-NGX. What is Celery? What is Redis? What is their relationship and where do they sit in the network? I still don't really know. I know a little bit more now, but Claude guided me through most of the troubleshooting. It's in instances like this where Human-In-The-Loop stops working—because the human in question doesn't have enough information to make an informed choice.
One of my mentors taught me something incredibly important early in my career: the Johari Window. I think the "not known to others" and "not known to self" quadrant is where many of us sit when we're vibe coding with AI. We don't know what we don't know, and neither does anyone watching us work.
Mitigating this risk means training the human in the loop to stop and actually understand what they're doing, to be comfortable with the responsibility of their actions, and to know when to pump the brakes.
In my opinion, the Johari Window should be taught to everybody as basic training, right alongside the Dunning-Kruger effect—to really drive home just how little we know and how much we think we know about what we know. After all, self-awareness is what drives intuitive and effective safety systems - you cannot
protect what you do not know. Just being aware would mitigate risks, because people would be more likely to think twice before asking a sensitive security question to a third-party LLM.
