Do Androids Dream of Vibe Coding?

We live in the era of vibe coding, guardrails, evals, and the occasional scorn from experts who write or evaluate every line themselves. It reminds me of my android obsession days, when flashing ROMs onto phones was a thing—vibe flashing—and similar arguments and risks were discussed.

The first phones

My first phone was an Ericsson G-something, and I only remember it because it was the first hand-me-down I got as a broke kid in 90s post-liberalization India. It was a small monochrome candy bar, GSM, no color screen, no camera that could just call and text from a prepaid SIM card that seemed to run out of minutes every time I blinked. Between that, a beat-up motorcycle, some bruises, and limited courage, I was ready for the world.

Many of us came up that way, inheriting devices rather than buying them, and hacking around because there was no easy replacement if you broke one. After that, I moved through the feature phones: a Motorola Razr, which felt futuristic to me as a Star Trek fan (original generation, of course), then an Sony Ericsson K750i with a real camera.

Android Arrival

By the late 2000s I was dabbling with a Nokia running Maemo. It was not quite Android and not quite mainstream, but it showed me that a phone could be a pocket computer if the software could be imagined that way. Even as Nokia was going down in flames like a beautiful ship in a sea of colorful Windows Mobile phones, I held on to that phone as long as I could.

By 2009 the early Android handsets were literally coming thick and fast. The i7500 ran Android 1.5 Cupcake, 3.2-inch AMOLED screen, and most importantly it could run CyanogenMod. I flashed it, broke it, reflashed it, rebroke it, and learnt more about how a phone’s software worked than any spec sheet could teach. That was way more interesting than my day job debugging large enterprise Java codebases written by hundreds of people before me.

If you used CyanogenMod back then, you know exactly what I mean and the thrill of flashing nightly builds.

Later I moved to the Galaxy S, and the i9000 had a 4-inch Super AMOLED screen that looked beautiful, a 1 GHz Hummingbird processor, Android 2.1 Eclair, and a 5 MP camera. Android was now mainstream and I still remember the version names the way I remember the Pink Floyd catalog: Cupcake, Donut, Eclair, Froyo, Gingerbread and the rest of the desserts.

Vibe flashing

CyanogenMod kept me hooked as a hobbyist hacker through the early 2010s. It gave me CPU governors, quick-settings toggles, and a level of control I could not get from the stock build.

Flashing a nightly build was a small act of James Dean-esque rebelliousness. You downloaded a zip, booted into recovery, wiped what you needed to wipe, and prayed nothing broke. The mornings when the phone came up faster and smoother than it had the night before made it all worth it. On nights when it boot-looped on that cute Android logo, minutes turned to hours, reading logs, pouring over forum threads and figuring out rollbacks. The rush came from knowing that if it failed, you could try to fix it yourself, like a pretend phone engineer. if you had buddies with the same obsession, you would show off what you hot-rodded into your custom build the next day.

The recovery partition was the insurance policy, because you took a nandroid backup before you changed anything and kept a known-good zipfile on the SD card. This is why the whole vibe coding conversation sounds familiar. You point the agent at a repo, accept a change you do not fully understand, and find out on the next run whether you still have a working project. Most days the build passes and the demo looks great, depending on what it was for. On bad days, you are tracing hallucinated code through logs at 1 AM, trying to rollback to last known good commit.

The argument right now is mostly about comprehension, and about whether you can prove you’re still doing the job. Did you read the diff, do you understand what the model wrote, are you a real engineer if you shipped something you can’t explain line by line. Are you the script-kiddie who grew up into a vibe coder.

The comprehension argument is not wrong on the facts - a recent benchmark called SusVibes found that “the best-performing combination (SWE-Agent + Claude 4 Sonnet) achieves 57% functionality but leaves nearly 80% of working code insecure”, and a broader literature review of 40+ sources found strong evidence for vibe-coding speed but limited evidence that the output holds up over time. Andrej Karpathy has also coined “agentic engineering” to draw the distinction. Simply put, vibe coding is for prototypes and personal tools; agentic engineering is what you do when other people depend on the software.

The part that rhymes with 2010 is that none of that stopped anybody then and none of it will stop people now. Most of the people vibe-coding today do not have the background to parse every diff, and telling them to stop is like telling a broke kid with an outdated hand-me-down phone not to flash the ROM because they might brick it. They are going to do it anyway, because why the hell not. What’s required is to build guardrails that support their creativity and let them survive unwanted behavior within acceptable thresholds.

So the rest of this is restoration pathways and inexpensive ways to be wrong.

Boot-loop or radio

Boot-loops cost you an evening, while a botched radio (firmware that controls cellular communication) or bootloader flash meant bricking the phone with no rollbacks, So everyone who flashed regularly knew which partitions were recoverable and treated them completely differently from the ones that weren’t.

Editing a file today is almost like a boot-loop. Terminal actions like writing to a production database, sending the email to your audience, or hitting the payment endpoint are the radio partition, and the steps you take to set either one running remind me of the same.

Most boot-loops had nothing to do with the build, since you had dirty-flashed over the last ROM without wiping cache and dalvik, so you spent the next hour debugging leftover state while blaming the zip. I still lose time to this sort of thing with agents now, except now when the run goes wierd, I start reading logs, and 10 minutes later the actual problem turns out to be a stale context window or a half-applied edit from the attempt before or just something that the agent hallucinated.

Running Android from source was the same thing on a longer timescale. You synced AOSP, picked a build target with lunch, ran make, and waited for stuff to blow up: device trees, vendor blobs, kernel mismatches etc. Each build failed for a different reason and with a lot of print statements the only way through was debugging one variable at a time.

The forum was the eval

You never flashed a nightly build cold because forums had forty posts under it from people who had already flashed that morning on your exact device, saying the camera was broken and Bluetooth dropped. Right now, folks test agent workflows in private, rediscovering failures in parallel or asking the agent to file issues.

These days

A nandroid backup always worked, and the zip on the SD card was still the zip I could go back to so fifteen minutes got me my phone restored back every single time. That insurance was the only reason any of us pretenders were brave enough to flash anything in the first place.

Now, many things an agent touches can’t be restored that way. Version control covers repo damage, snapshots cover machine state, and microVM platforms branch and restore filesystems in seconds. Databases fork like git branches, but beyond that, it stops being restoration and starts being cleanup. Then there’s the horror of sent email and captured payment snafus, where no respite is coming because the state doesn’t exist anymore.

All this rambling is not an argument for shipping things you cannot explain into production. It is an argument for experiments under guardrails, keep running the thing and breaking stuff where restore paths exist. Know that for the parts that leave the machine and impact users, the tooling does not save you, and the guardrails are on you.

The arguments saying you are not a real engineer unless you can explain every line are making the same argument that got made in 2010, when the objection was that we had no idea what was in those ROMs. It has become a Voigt-Kampff test, and in the book that test was never as reliable as the people administering it believed.

Five things to consider

1. Keep the agent in a sandbox or a worktree for anything exploratory, so the worst case is deleting a directory.
2. Give it credentials that cannot reach production, amputating the key is faster than reviewing the diff
3. Anything that sends, charges, posts or deletes goes behind a human confirmation first
4. Before a long run I think about how I would rollback, which will occasionally may make me abandon as well if the risk outweighs the goals. Or create a detailed checklist that will help me rollback.
5. Time-box unsupervised runs when needed as long agent loops with no manual checks may accumulate stale context and create half-baked or partial edits. Always good to inspect and then continue if all looks well.

The goal is making being wrong cheap enough that you keep trying without regrets.