TL;DR — I’m a long-time dev trying vibe coding: ship small, learn loud, repeat. Here’s what that means to me and what I plan to write about here.
Why a reboot (after years of shipping)
I’ve shipped for long enough to see tools and trends loop back with new names. What didn’t change: shipping is still hard when perfection creeps in. I used to over-plan, under-ship, and miss the moment.
So I’m trying something deliberately simple: vibe coding.
What vibe coding means to me
Not chaos, not cowboy coding. It’s a posture:
- Smaller surfaces → reduce scope until a demo fits in a tweet-length sentence.
- Shorter loops → merge before it’s pretty; write the postmortem while it’s fresh.
- Evidence over ego → telemetry, user notes, quick A/Bs.
- Narrate the work → build-in-public notes beat polished silence.
My tiny rules (so I don’t backslide)
- 48h rule: if it’s not shipped in two days, I cut scope until it is.
- One metric per week: pick exactly one “did we move it?” number.
- Write the README first; if it reads confusing, the scope is confusing.
- When stuck, publish a question instead of hiding the branch.
What I’ll share here on DEV
Short, honest notes as I practice:
- How I pick “tweet-sized” scopes and still keep a roadmap
- Checklists for shipping faster without breaking trust
- Postmortems (good and bad) with the actual tradeoffs
- Tooling that keeps me honest: tests, feature flags, and telemetry
If any of this sounds useful, follow along and tell me what you want to see first. I’ll happily write it.
PS: what I’m building (soft mention)
I’m also building DocBeacon — a document sharing tool with heatmap insights to see what readers actually read (think: beyond per-page stats). If that problem interests you, my profile has more info. Happy to swap notes.
Top comments (0)