Category: learning

  • What I Learned From Vibe Coding

    I started vibe coding last month because I wanted to understand the parts of building that I usually only see from the product side. I’m not trying to become an engineer. I’m not trying to reinvent myself. I just wanted to be more realistic sense of what my own team deals with.

    Most of the things I built were small. A few got complicated by accident. And somewhere in the middle, I learned the difference between “can I make this work at all?” and “can this survive real users without collapsing?”

    👋 This is coming from a PM/founder who codes out of practicality, not identity

    So here’s what happened…


    Pantun Generator: The easy win

    What it does: You pick a mood, write the first phrases, or just wing it, then we generate a Pantun for you

    Simple Next.js app + Groq API.
    It worked. It was fun. A few friends used it, too lol. And even this tiny thing needed proper error states and basic guardrails.

    Takeaway: Small projects feel good because feedback is instant. This is the ideal vibe coding zone.

    Try yourself: https://pantun-generator.vercel.app/


    Kanji Practice: Scope is everything

    What it does: It’s just a list of kanji, really, with the Onyomi, Kunyomi, and meaning, within each JLPT group (N5-N1). Oh, but the list is a bit limited.

    Just static assets and minimal logic.
    I’m just trying to play around with UI patterns and learning how fonts work in different language, and uh… it works, I guess?

    Takeaway: sometimes “boring” tech is the right choice. Not everything needs to be hyper-engineered.

    Try yourself: https://kanji-practice-innit.vercel.app/


    Tes Buta Nada: Audio APIs are not funny

    What it does: You record yourself 10x trying to copy the tone we play, then we tell you how good your pitch is.

    Web Audio API + Tone.js + Pitchy.
    This broke more often than it worked, especially on mobile. A lot of bugs weren’t even visible… Also my co-founder got a bit mad as the result says she’s tone-deaf (sorry).

    Takeaway: Audio introduces a whole new level of inconsistency that vibes cannot fix. Testing on actual devices is non-negotiable.

    Try yourself: https://tes-buta-nada.vercel.app/


    Compatiblah: Generative results with defined scope

    What it does: We tell you how compatible you are with your buddies by inputting your name MBTI, and other optional params like DISC/SNS/zodiac (whatever lol)

    Just for fun.
    This started as a fun compatibility thing after we did MBTI workshop in the company and I got inspired to just wing it. Then people use it and want it to be more comprehensive. OK so I did improve it.

    Takeaway: Once people use it for real, results matter lots, so I had to tweak it several times. Don’t wanna break hearts…

    Try yourself: https://compatiblah.vercel.app/


    Fix My Form: Vibe turns to depression

    What it does: You take video of your deadlift/squat, then we tell you how to improve your form

    Video uploads + FastAPI + R2 storage + Vision API
    Suddenly I’m dealing with file formats, timeouts, retries, naming conventions, and things I can’t just casually ignore…

    Takeaway: Gosh, video pipelines are not friendly (lol). This was the first project where I felt irresponsible if I didn’t do things properly… I had to verify the results by asking around my friends for some vids…

    Try yourself: https://fix-my-form.vercel.app/


    Vocal Ambitus: I’m so tired

    What it does: Lets you talk, sing, and record a few vocal ranges, then calculates your ambitus and shows where your voice sits.

    Next.js App Router + Postgres + Drizzle + custom recording flow
    This was the first project where I couldn’t just wing it. Once I added real data storage and multi-step recordings, real bugs start arise: weird browser behaviour, bad recording result, people recording twice, people not recording at all… all of it forced me to slow down and rethink about “vibe”.

    Takeaway: Every shortcut from earlier projects came back to haunt me here. And making UI components consistent across steps is way harder than I expected.

    Try yourself: https://vocal-ambitus.vercel.app/


    My Setup: Semi-technical, semi-blackbox

    I’m semi-technical: technical enough to choose stacks, debug basic issues, and understand how things fit together, but also very willing to treat things as a black box when the problem doesn’t deserve deeper energy.

    Here’s what my workflow really looks like:

    • I use Cursor to generate the first pass of components or API routes. Then I adjust, rewrite, or simplify the parts that matter. Some things I understand deeply; some things I fully accept as “Cursor’s problem.”
    • Vercel is my default for anything frontend. It’s fast, clean, and predictable.
    • For backends, I switch depending on the project:
      • Render when I need a FastAPI service running without thinking too much about infra.
      • Supabase when I want instant Postgres or quick API routes without managing servers.
    • For anything involving video or bigger files, I plug into Cloudflare R2 because it’s cheap and straightforward.
    • Databases: usually Postgres (mostly from Supabase) when the project needs structure; SQLite only for tiny prototypes.
    • I don’t try to build “the perfect architecture.” Sometimes I care about doing it properly but many times I’ll just push whatever works and clean it up later if it grows legs.

    This mix of knowing enough, ignoring enough lets me ship ideas quickly without drowning in engineering complexity, while still learning how the real pieces work when I choose to pay attention.


    All in all: What did I actually learn?

    1. Vibe coding is great for getting ideas out of your head.

    If the goal is to validate or explore, it’s perfect, but IMO vibe coding won’t scale (at least given the state it is today). Maybe in a few months/years along the way, it’d get way better. For now, my take is anything that touches audio, video, AI chains, or persistent data needs structure, not vibes.

    2. The back-and-forth of fixing things is real work.

    One improvement creates two regressions. This is where engineering discipline actually matters.

    4. Production-grade work requires a different mindset entirely.

    Predictability, consistency, testing — the stuff people rarely notice unless it’s missing. Most non-technical peeps will underestimate it, but having worked with engineers for years, I just knew that what I’ve built won’t scale.

    5. Vibe coding didn’t make me feel “more legit.”

    It just made me more realistic. I now know exactly where vibes help, and where I should step aside and let people who actually know what they’re doing handle the rest.


    OK, That’s it for now! Anyways, keep up with my learning progress from my Github: https://github.com/anindilla