You’ve probably seen the viral posts: “I built a full-stack app in 20 minutes with AI — no coding required!” Feels like magic, right? But deep down, you know something’s off. The code is fragile. The logic is shallow. And when something breaks, you have no idea why.
I’ve been there. So when I decided to resurrect a real, 8-lane bowling alley in my own center, I had a choice: let AI do the heavy lifting and hope for the best, or treat AI like a research assistant and own every decision. I chose the latter. And what I learned might change how you think about AI-assisted development forever.
This isn’t a story about bowling automation. It’s a story about why “vibe coding” is a dangerous shortcut — and how real engineering still matters.
Let me take you inside OpenLaneLink, my open-source project to rebuild a bowling lane’s automation system from scratch. No expensive proprietary hardware. No black boxes. Just a mesh of ESP32 nodes, each doing exactly one job, communicating over ESPNOW, and a Raspberry Pi acting as a lane brain. The goal: bring Lane 2 back online after years of neglect.
When I started, I was tempted to let an AI architect the whole thing. But I’ve seen too many projects collapse under the weight of code that no one understands. So I set a hard rule: every sensor, every actuator, every node must be a dedicated ESP32. The Pi runs the state machine, the WebSocket server, and the REST API — nothing more. No cheating with a webcam wired to the Pi for object detection, even though that would be easier.
That decision led to my biggest challenge: pin detection on an ESP32-CAM. Can you run computer vision on a resource-constrained microcontroller? I don’t know yet. I’ve considered using mmWave radar — but at $50 per module times 8 lanes, that’s a non-starter for a hobby project. So I’m sticking with CV, and I’ll fight the ESP32’s limits until I either win or have to admit defeat.
Here’s the twist: I used AI extensively — but I never let it make a design decision.
I’d ask Claude, “What’s the C syntax for this?” or “How do I implement a score sheet class?” And when it insisted that frame scores should be attributes of the game, not the player, I argued back. Because I know bowling. I know that each player’s frame is independent. The AI was wrong, and I caught it because I owned the domain.
This is the difference between “vibe coding” and real engineering. Vibe coding lets the AI drive, and you just enjoy the ride. Real engineering uses AI as a copilot — you check the map, you question the route, and you take the wheel when the AI tries to drive you off a cliff.
I’ve also received incredible support from the community. When I shared my breadboard prototype, people sent me tips on ESPNOW mesh reliability, on state machine design for multiple bowling variants (10-pin, 9-pin, candlepin, duckpin), and on how to wire optocouplers to read pinsetter machine state. That’s the kind of collaboration no AI can replace.
The MVP is almost ready. The state machine works, the React UI drives a simulated game, and the UART bridge between ESP32 and Pi is stable. Once the vision and optocoupler nodes are done, I’ll finally bring Lane 2 back online. And then I’ll publish an alpha release so anyone can build their own.
But the real takeaway isn’t the bowling lane. It’s this: AI is a tool, not a creator. The best projects are still built by humans who understand the problem, own the architecture, and refuse to hand over their judgment.
So next time you see a post about “vibe coding” your next app, ask yourself: do you want to build something that works, or something that looks like it works? If it’s the former, pick up the soldering iron, open a terminal, and start making decisions. The AI can help with the syntax. But the vision? That’s all yours.
FAQ
Q: Can you really run computer vision on an ESP32 for pin detection?
A: It's borderline. The ESP32-CAM has limited RAM and processing power, so traditional object detection is tough. But using lightweight models like MobileNet or edge-optimized ML might work. If not, the fallback is a webcam on the Pi — but that breaks the 'one node, one job' rule.
Q: What's the practical takeaway for a maker who wants to build a similar IoT mesh?
A: Start with a clear architecture: each node does one thing well. Use a simple protocol like ESPNOW for low-latency communication. Keep the central controller (Pi) as a glue layer, not a processing powerhouse. And accept that you'll need to compromise between purity and practicality — that's engineering.
Q: Isn't using AI for coding just the future? Why fight it?
A: AI is a great assistant, but a terrible architect. The projects that survive are built by people who understand the domain, the constraints, and the trade-offs. If you let AI write everything without review, you'll end up with code that's hard to debug, impossible to extend, and full of subtle errors. Use AI to speed up syntax lookups and boilerplate, but never hand over design decisions.