Overview

Two years ago, building a desktop notes app that could summarize videos would have been a month of evenings — a wall of open Stack Overflow tabs, a half-read Electron tutorial, and a lot of “why won’t this build.” When I made VNotes, I had a clickable prototype and a landing page inside a single weekend. The interesting part isn’t that it got faster. It’s which parts got faster — and which parts refused to.

How I used to build

A typical feature used to start with a research tax before I wrote a single useful line. The first hour went to figuring out the shape of the solution: which library, which pattern, whether the approach I half-remembered was still current. Setup and boilerplate ate a shocking amount of time — project scaffolding, config, wiring the same plumbing I’d wired ten times before.

Where I lost the most time was the gap between “I know roughly what to do” and “I know the exact API to call” — the docs-hunting valley. I lived in Stack Overflow, stitched three half-answers into something that worked, and often couldn’t have told you why it worked. Debugging was trial-and-error with print statements, and unfamiliar territory could stall me for a whole session before I produced anything runnable.

How I build now

  • Vibe-coding prototypes. I used Bolt to spin up the VNotes prototype and landing page fast, which saved time to validate the idea and simplify scope for the MVP. This is great when the goal is “is this even worth building?” — you get something real in front of yourself before committing to any architecture. Where it bites: the generated scaffold has opinions baked in, and carrying those into production without auditing them means inheriting decisions you never actually made. My rule now is prototype in Bolt, but re-derive the load-bearing parts by hand.
  • AI as a decision partner. The highest-leverage use wasn’t writing code — it was pressure-testing calls. For the video summaries I weighed transcript-only vs. GPT-4-vision on extracted frames vs. a hybrid, and separately whether to summarize in chunks or feed a combined transcript. Talking through the trade-offs (cost vs. fidelity vs. latency) surfaced the option space I wouldn’t have fully mapped alone, so I chose deliberately. The judgment stayed mine; the AI just laid the options out faster.
  • Faster orientation in unfamiliar tech. Electron, IPC between main and renderer, code signing, notarization for macOS distribution — all learned on the fly, mid-build, instead of front-loaded from a course. The learning curve didn’t disappear, but time-to-first-runnable on a new concept collapsed. When notarization failed with a cryptic error, I lost twenty minutes, not a day.

What got better

Speed to prototype is obvious, but the deeper win is willingness. I now reach for unfamiliar stacks without dread, because the cost of being wrong is lower — I can get far enough to learn whether an approach fits before sinking a weekend into it. Boilerplate fatigue is basically gone. And I run more experiments, because experiments got cheap.

What got worse (or riskier)

A real note I made to myself: “avoid over-reliance on prompting in Bolt.” That warning exists because the failure mode is seductive. When output arrives working, it’s easy to accept it without building the mental model underneath — and that debt comes due the moment something breaks in a way the model can’t one-shot. I’ve shipped subtle bugs from accepting plausible-looking code too quickly (a base64-vs-Uint8Array mismatch in the video pipeline that “worked” until it silently didn’t). Debugging code you didn’t fully write is genuinely harder, because you have to reverse-engineer intent first.

What stayed exactly the same

Everything that actually matters. Understanding the problem before touching the keyboard. Knowing why a fix works rather than that it works. System-design judgment — the JSON-vs-SQLite call for VNotes’ storage wasn’t something a model decided for me; it was a trade-off I had to own. Taste. Debugging discipline. The AI moved the boilerplate and the orientation cost. It didn’t move the thinking — if anything, the thinking is now a larger fraction of the job, because it’s the part that didn’t get automated away.

Tips for someone straddling both eras

  1. Prototype fast, but re-derive the load-bearing parts by hand. If a piece of generated code will matter in production, make sure you could have written it.
  2. Use the AI to explain, not just to produce. Before accepting a solution, ask “why does this work?” and “what would break it?” The answer is what you’re actually paying for.
  3. Break tasks smaller. “Build the whole system” gives you something you can’t debug. “Design the read/write for one note” gives you something you understand.
  4. Verify anything fast-moving. Models go confidently stale. Run it, read it, confirm the API still exists.
  5. Treat every “that got worse” as a guardrail, not a reason to stop. Over-reliance isn’t a reason to avoid the tools — it’s a reason to keep your hands on the wheel.