Four Vibe-Coded Projects in Six Months: From a 3,721-Line Monolith to an AI That Writes for Itself
theme: lilsnake
Last year, starting from my wife's pregnancy, I built 4 projects using vibe coding. A full-stack parenting app with 58 commits, a pixel diary game written in a single commit, a mental-friction detection mini-program, and an AI writing toolchain. The total lines of code exceed ten thousand, but I never wrote a complete PRD, nor did I draw a single design draft.
This article chronologically breaks down these six months into four projects. For each project, it covers three things: why I built it at the time, what pitfalls I hit during development, and what crystallized in the end. The conclusion distills the shared experiences from all four projects into a few actionable methods.
One: baby-tracker, a collection of trivial inspirations
Last year, my wife got pregnant. I wanted to use this milestone to build something with vibe coding—bought a domain, fumbled through Vercel, Cloudflare, Supabase, set up the whole environment, and the project was launched. No product planning, just building whatever popped into my head.
Motivation: My wife was pregnant, I wanted to do something
After learning about the pregnancy, I kept thinking "I have to build something now," and the project started. Feeding records, sleep records, diaper change records were the first features to land, but honestly, they were more of a primer—I just needed something that could run to connect the entire tech stack.
Messy: 58 commits, the project became a hodgepodge
I made a classic mistake with this project: no main thread, just adding a feature whenever an idea popped into my head. Today I'd think "record the baby's feeding," tomorrow "how about a chart to see patterns," the day after I'd think of the Raiden game—a childhood nostalgia, wondering if AI could replicate it. And then I actually built it.
So baby-tracker simultaneously housed: feeding/sleep/diaper records, Recharts routine curves, a mood diary (with photos), family sharing (invite code), a message board, and four mini-games (Match-3, Block Party, Raiden Shoot-em-up, After-Work Release Day). Raiden Shoot-em-up was purely for my own enjoyment, to see if AI could write a bullet-hell game, and it actually did—and along the way, it casually added bosses, power-ups, and background music. The games weren't for the baby; they were nostalgia for me.
By the end, you couldn't tell if this project was a parenting tool or a game collection. It's not terrible, but it's messy. Each feature stands alone reasonably well, but together they lack direction.
It's not terrible, but it's messy.
Crash: A 3721-line single file
Tech stack: Next.js 16 + TypeScript + Supabase + Tailwind CSS + Shadcn UI, PWA using Serwist. But the most glaring thing wasn't the tech; it was that src/app/game/raiden/page.tsx: 3721 lines, the largest file in the project, and the biggest pitfall. Game loop, collision detection, bullet pool, enemy spawning, UI, sound effects, save data—all in a single file.
The first 800 lines went smoothly; the AI had enough context for changes. By 2000 lines, every change required re-reading the entire file. At 3721 lines, the AI started duplicating implementations: two copies of bullet collision logic appeared in the file because it forgot it had already written one. The problem stemmed from additive development: each time I only said "add an X," never mentioning "this file is already too large."
I only understood the cost when splitting the file: dependencies were a web, the render function was called from 20 places, game state and UI state were mixed in the same component. It took two nights to split it into 8 files to straighten things out. The lesson isn't "vibe coding doesn't need structure," but that structural problems get postponed, then erupt all at once.
Structural problems get postponed, but they never disappear.
Highlight: Live Photo export, the most useless and most fun
Mood diary entries can include a Live Photo (the moving photos on iPhone), and the export feature packages them into a downloadable file. The flow: the frontend uploads a still frame and short video via FormData, the Next.js API Route uses fluent-ffmpeg to transcode WebM to MOV, exiftool-vendored writes the ContentIdentifier tag, then archiver zips it up and returns the download. One POST request, server-side pipeline processing, the user gets an iPhone-recognizable Live Photo ZIP package.
DOM → canvas → ffmpeg → exiftool → ZIP, all in one POST request.
This feature solves no parenting problem, has no KPI, just "since I've recorded so many moods, might as well export them as moving photos." After building it, I barely used it—this feature also has environment requirements, the server-side ffmpeg dependency isn't always installable on ordinary PaaS, so in production it basically just runs happily on localhost. Every time I open it and see that one frame of my baby from three months ago, it feels worth it.
Two: caveOfSoul, a diary game written in one commit
The previous project had 58 commits; this one had 1. Commit message: "initial commit: caveOfSoul - 2D pixel diary exploration".
What's inside that one commit
Vite 8 + React 19 + TypeScript + Canvas 2D, no game engine used. Core logic all in App.tsx, 569 lines. Canvas 3600px wide, 70 stars randomly twinkling above, two layers of mountain scenery with parallax scrolling, pixel texture on the ground, a timeline stretching from 2018 to 2026.
Diaries I usually write are exported as JSON, scattered across the canvas—each node is a 📓, coordinates anchored to the timeline by year. The player controls a 🚶 walking, colliding with nodes opens a popup to read, 120 characters per page, spacebar to flip pages. No save, no menu, no settings. Open the browser, and it's a game.
Not for release, just for myself
This project will probably never be released. The night I finished it, I walked the timeline twice, read the scattered pieces of myself on the ground, then shut the computer. Not for others to see, nor for "productization"—just that one day, I felt these diaries shouldn't lie forever in a JSON file.
Not all code needs to go live. Sometimes you just want to render a segment of your life on a 3600px-wide Canvas, walk through it once, and then close it.
Three: check-neihao, building a mental-friction detector for myself
Conversation norms, present from the start
To be honest, I'm quite particular about "how to talk to AI." I installed skill frameworks like superpowers early on and got used to clearly stating the background, rules, and constraints before each conversation. So CLAUDE.md wasn't a new invention for me; it was a natural extension of this habit.
check-neihao's CLAUDE.md is 58 lines, clearly stating the tech stack (uni-app + Vue 3 + TypeScript + Vite, H5 + WeChat Mini Program dual-platform), component directory structure, naming conventions, known issues, and TODOs. Every new conversation, the AI reads this file first. Context isn't carried by my words; it's carried by the file.
Later, I kept this habit for several projects and even got creative—mandating that the AI call me "Daddy" every time it speaks. Not out of mischief, but to prevent it from losing context: by making it say that first, it has to keep the thread of "who am I talking to" taut. It works reasonably well, though the AI gets a bit too natural at acting coy.
Tools: From line-by-line checking to writing checking tools for AI
The previous pattern: AI generates code, I paste it into the project, manually check for missing braces or accidentally truncated template strings. Human attention lasts only 20 minutes—after 20 minutes, I wouldn't notice a missing parenthesis.
Later, I wrote a verify.mjs that automatically scans all .vue / .ts / .js files during build, counts { } [ ] ( ) and template string ` quantities, and throws an error and exits the build if they don't match. 33 lines, no AST parsing, just character-by-character counting.
I no longer check the AI's code; I write tools for the AI to check the AI. My job shifted from "fixing bugs" to "writing machines that fix bugs."
This script's value isn't technical—regex can do it. The value lies in a pivot: rather than staring at the AI line by line, let a script stare at it.
Not just functional—starting to look good
Tech stack: uni-app + Vue 3 + TypeScript + Vite. Feature line: 5 scenario questionnaires (Work / Study / Family / Daily Life / Romance) → answer scoring → long-press release interaction → cat healing poster generation. The standard for previous projects was "just get the features running"; this time I didn't stop there.
Visually, I set a GQ cyber-print style—black and white dominant, hard 4px solid borders, layers of thick drop shadows, all hand-written CSS, no UI framework dependency. The 23 cat SVGs in the poster are purely hand-written path data, each paired with random themed copy ("Finish this question and clock out" "You don't need to make everyone happy"). The questionnaire bank is centrally managed in src/data/questions.ts, with deliberately different question directions for the five scenarios: workplace tests trade-offs, family tests relationships, romance tests self-awareness.
By this point, I started enjoying the leap from "it runs" to "it runs beautifully." Building this project was also pure exploration—wanting to make something I wanted to make, to see if vibe coding could land it.
The result: it landed, but the WeChat Mini Program's 30 RMB certification fee still hasn't been recouped. A wry smile.
Four: wechat-ai-editor, AI writes code for AI to use
The first three projects share one commonality: I write code, humans use it. The fourth is different—it's a toolchain, where AI-written code is for the AI itself to use.
From building houses to building production lines
wechat-ai-editor's pipeline isn't complex: Markdown article → marked converts to HTML → juice inlines CSS → WeChat API saves draft. Another branch: Markdown → HTML → Playwright opens Xiaohongshu → auto-fills form to publish. Node.js + Playwright + marked + highlight.js + juice + front-matter. 3 commits, written over two weeks.
But its key isn't the permutation of package managers. It's a system called skill.
Installing methodology into AI
Skill is teaching the AI "how to write." If I tell the AI "write a WeChat official account article," it writes generic copy. But if I install three skills—article-writing manages article structure, style constraints, and a banned words list, writing-beats manages interactive beat-by-beat writing, grounding each concept before advancing, writing-shape manages paragraph-level iterative polishing, rolling back on disputes—what it writes gains a skeleton and rhythm.
What's installed isn't "what to do," but "how to write."
An analogy: in Project Three, CLAUDE.md sets rules for one project, those few dozen lines tell the AI "in this project, pay attention to these things." Skill is different—it's reusable across projects. I use it today for a WeChat article, tomorrow for Xiaohongshu.
The entire project has 127 agent skill files installed, including 100+ hallmark design system reference files, dbs-wechat-html, SVG animation toolchain, etc. But this number isn't important. What's important is: I no longer re-explain writing rules in every new conversation. Skill shoulders that for me.
15 articles, and the final step of automation
This toolchain runs on a personal WeChat official account from the perspective of a husband/dad, covering parenting, marriage, and daily life themes. Over 15 articles published so far, including ones with SVG interactions. Integrated Xiaohongshu Playwright auto-publishing—after writing an article, it automatically fills the title, pastes the body, and submits.
The official account brings in roughly 1 RMB a day, takes two days to save up for an extra steamed bun. Not much, but I find joy in it.
The final link in the entire chain: AI writes code → AI writes articles → AI helps you publish articles. I'm left with only one thing: deciding what to write today.
The article you're reading now, nine times out of ten, also went through this workflow.
Four things to take away
1. Set rules for AI: Put a file in the project root, even make it call you Daddy
I've been doing this from the start. Installed superpowers early on, got used to writing down "what the AI should pay attention to in this project" into a file—CLAUDE.md, AGENTS.md, whatever you call it, containing the tech stack, directory structure, naming conventions, known issues, updated before every code change. check-neihao's is 58 lines, and subsequent projects followed suit. Action: create CLAUDE.md or AGENTS.md in the root directory, clearly state the tech stack, directory structure, naming conventions, known issues. Update it before every change.
Not documentation for humans—it's a memory external drive for the AI.
However, the superpowers approach isn't for everyone—some people using ChatGPT's new model with this workflow actually felt it made the AI dumber. Tools are rigid; suitability depends on the individual.
2. Split files early, don't wait for them to explode
baby-tracker's raiden/page.tsx grew to 3721 lines, game loop, collision detection, UI, sound effects all crammed together. Splitting at eight hundred lines takes minutes; at three thousand lines, it took two nights. The AI even wrote two copies of bullet collision logic in the file—it forgot it had already written it. Action: prompt the AI to split when a single file exceeds 800 lines. Before splitting, have it draw a dependency graph first, then propose a plan, otherwise the split will still be messy.
3. From checking AI to writing checking tools for AI
Early in check-neihao, AI-generated code was pasted into the project, and I checked braces and template strings line by line—fatigue set in after 20 minutes. Later, I wrote a verify.mjs, 33 lines, scans all files during build for brace and template string matching, throws an error and exits build on mismatch. Action: identify what you repeatedly manually check, and script it. Your job shifts from fixing bugs to writing machines that fix bugs. Rather than staring at the AI line by line, let a script stare at it.
4. Install methodology into AI, not just issue commands
wechat-ai-editor has three skills: article-writing manages style constraints, writing-beats manages writing rhythm, writing-shape manages iterative paragraph polishing. Before, I re-explained writing rules for every WeChat article. After, three skills are reusable across projects, for both WeChat and Xiaohongshu. Action: crystallize repeatedly used specifications into skills or prompt templates—writing rules, code style, deployment processes. What's installed isn't "what to do," but "how to do it."
What's still owed
Looking back after these six months, a lot is still owed. baby-tracker's "messiness" wasn't cured—four games mixed with feeding records, ultimately because I added a feature whenever an idea popped into my head, never pausing to ask "what exactly is this project?" raiden/page.tsx was split from 3721 lines into 8 files, but I know very well it will grow back sooner or later; the inertia of additive development hasn't been broken. Testing is an even bigger debt: across all four projects, there's only one live-photo-metadata.test.mjs; the rest is all "if it runs, it's fine."
The code written in these six months, not a single line was seriously treated as a product. baby-tracker for my own family, caveOfSoul for myself to walk through, check-neihao for myself to test, wechat-ai-editor for myself to publish on my official account. The article started by saying "no PRD, no design drafts," and now it can be completed:
The code was written by AI, the rules were honed along the way, but every idea was genuine. This is probably the most honest face of vibe coding.