People call it vibecoding - letting AI write your software while you sit back and watch. I didn’t write a single line of code for this project. But calling what happened “vibecoding” misses the point entirely.
The brief
A client messaged me on a Sunday. He had a demo with a large facility management company the following Tuesday. He needed a web dashboard that pulled live data from real IoT sensors on AWS, showed diesel generator status in real-time, and demonstrated device-to-device routing. He had some starter HTML, an AWS account with devices already publishing data, and a budget that assumed I’d be coding for weeks.
I delivered it in a few hours of actual effort, spread across the week. The demo landed. The client’s prospect started talking about monthly per-sensor licensing and permanent deployment.
Not a single line of code was mine. So is this vibecoding?
No. And the distinction matters.
What vibecoding actually looks like
Vibecoding, as most people use the term, means prompting an AI to generate code and shipping whatever comes back. The developer becomes a spectator. If the output works, great. If it doesn’t, prompt again. Architecture is whatever the AI defaults to. Security is whatever the AI remembers. The “vibe” is the absence of deliberate engineering decisions.
That’s not what happened here.
What actually happened
The client builds IoT sensor devices - diesel generator monitors, solar controllers, temperature sensors - deployed into residential communities managed by facility management companies. He had devices live on AWS IoT Core. He had a dashboard prototype. What he didn’t have was the architecture to tie it together, or the time to build it before Tuesday.
I pointed Claude at the codebase and the AWS account. The AI investigated the IoT Core setup, discovered live devices, mapped MQTT topic structures, and rebuilt the dashboard from the ground up - real device types, real data fields, live integration.
The AI did the building. I did something different.
The decisions the AI didn’t make
Cloud orchestrator over device-to-device pub/sub. The client initially discussed having solar sensors subscribe directly to DG sensor topics. That’s a debugging nightmare at scale - if something fails between two devices in a mesh of 300, you’ll never trace it. I redirected to a pattern where every device only reports telemetry up and reacts to commands down. All routing intelligence lives in a cloud orchestrator that logs every message received, every instruction sent, and every confirmation. The AI built the orchestrator. It didn’t choose the pattern.
Security boundaries. The client raised a concern about a recent smart home breach where shared OAuth credentials exposed thousands of strangers’ floor plans. Per-device certificates were already in the codebase, but multi-tenant isolation between facility managers wasn’t. The AI could implement the isolation. It couldn’t assess where the liability sits when an FM company maps the wrong sensor to the wrong diesel generator. That conversation happened between humans, and it shaped what got built.
Scope control. The client wanted “reliable and scalable” on a budget that said “working demo.” The temptation with AI is to build everything, because building is suddenly cheap. I focused the work on exactly what Tuesday needed: one DG sensor publishing, one device subscribing, a dashboard showing it live. Data retention, dynamic remapping, notification pipelines - all deferred. Knowing what to cut is not a vibe. It’s judgment.
The demo
Tuesday came. The DG sensor demo worked. The prospect got excited enough to immediately test the solar sensor integration - which wasn’t in scope and hit some hardware glitches. But the software held. The conversation shifted from “show us what you can do” to “how much per sensor per month” and “can we keep data for a year.”
A week earlier, none of this existed as a working product.
Why “vibecoding” is the wrong word
The term implies passivity. What happened here was the opposite - active architectural direction, continuous judgment calls, deliberate scope management. The AI was the executor. I was the architect. That’s a collaboration with a clear hierarchy, not a vibe.
A plainer way to put it: the AI writes the code, I decide what gets built and what ships. The senior engineer spends their time on architecture, security, scope, and review. The AI handles implementation at machine speed. Neither could have delivered this alone. The AI couldn’t choose the cloud orchestrator pattern. I couldn’t have rebuilt the dashboard, investigated the AWS account, and wired up the IoT integration in a few hours of hands-on time.
The ratio has inverted. Where a senior developer used to spend 80% of their time implementing and 20% deciding, AI flips that. Implementation becomes the fast part. Decisions become the valuable part.
What this means for engineering teams
If you’re leading a team and evaluating AI-assisted development, here’s what I’d take from this:
Pair AI execution with senior judgment. The AI does the volume work. The senior engineer makes the calls that keep the project on track, secure, and architecturally sound. Without that pairing, you get vibecoding - fast output with no structural integrity.
Use AI for investigation, not just generation. Half the value here was the AI exploring an existing AWS account, figuring out what was deployed, and mapping live device data. Reconnaissance that usually takes days of clicking through consoles took minutes. Most teams underuse this capability.
Scope ruthlessly. AI makes everything buildable. The discipline is still knowing what to build first. A working demo with one device type beats a half-finished platform with five. This hasn’t changed - it’s just easier to ignore when building feels free.
Measure in outcomes, not hours. The client got a live dashboard, a successful demo, and a prospect ready to buy. Whether that took three hours or three weeks of my time is irrelevant to the value delivered. If you’re still pricing engineering by the hour, you’re pricing the wrong thing.
The real question
The question isn’t whether AI can write your code. It can. The question is whether anyone is making the decisions that determine if the code is worth writing.
Vibecoding says no one is deciding. This says someone is - and that someone’s experience is more valuable than ever, precisely because they’re no longer spending it on implementation.
I didn’t write a line of code. But every architectural decision, every security call, every scope cut - that was mine. Call it whatever you want. Just don’t call it passive.