How it started: I thought I was building a product
This morning I opened Cursor planning to add a blog to dahui.ai. I didn't have "a small static blog" in mind. I had a real product in mind: signup, login, rich-text editor, one-click publish, whitelisted authors, content moderation.
I told the AI:
For the blog feature, I want to expand it: signup with email + name, login, see all past posts, publish new posts directly in the browser, format text and images, one-click publish to the public web.
The AI didn't push back. It actually designed me a full stack: Auth.js + Vercel Postgres + Drizzle ORM + a TipTap rich-text editor + Cloudflare Turnstile + the OpenAI Moderation API + Upstash Redis rate limiting — the whole catalog.
Then I asked:
Compare globally: what are the best practices for personal websites and blogs, and where does my current architecture have gaps or risk?
It came back with 24 best-practice items and asked me to write them into an architecture.md. By the end the doc was 655 lines, with decisions D1 through D11 and three milestones M0/M1/M2.
Looking at that document, I felt the rush of "I am about to start something big."
The pivot: office hours snapped me out of it
Around lunch I ran the /office-hours skill — basically asking the AI to play YC partner and pressure-test me.
I expected to be praised for "thinking it through." The first question was:
Why are you building this site? Who reads it? How often do you publish?
I answered honestly: a logbook for myself and for hiring managers, every 2–3 days, exactly one author — me.
The AI paused (it didn't, but it felt like a pause), and then:
Then why do you need auth? Why a database? Why moderation? Why a rich-text editor?
If there's only one author — you — and you already spend the day in Cursor writing code, docs, and prompts with AI, then Cursor + the filesystem + git is already your most fluent editor. Building a browser-based TipTap on top is replacing a tool you're good at with a slower tool you'd have to relearn.
You're not building a blogging platform. You're building an AI learning logbook.
That made me uncomfortable, because I had just spent a full morning writing something that looked like a serious software project and was being told it didn't fit the actual problem.
Then the AI said the line that made me stop arguing:
"You're already doing this workflow — you just hadn't named it. Your first post is literally a Cursor 中文 session, summarized and translated. You already did the right thing; you just didn't know you'd done it."
The real product: a codified workflow
Over the next two hours we wrote a second architecture doc together: architecture_v2.md. The core is a single flow:
- Open Cursor / Claude with intent ("today I want to learn / build X")
- Chat in 中文 — natural language for thinking
- Build / debug / explore in the chat session
- At end of session, ask AI to summarize the chat into a draft post
- AI translates 中文 draft → EN
- Human edit pass: voice, taste, drop the boring scaffolding, keep the surprising bits, add the honest moments AI smoothed over
- Commit MDX file, push, deploy via Vercel
The shift looks tiny. The meaning is total:
- v1 (architecture): treat dahui.ai as a piece of software, so build every part software is supposed to have.
- v2 (product): treat dahui.ai as the visible artifact of an AI session, so the core feature is the shortest path from session to post.
What v2 cuts vs. v1:
- TipTap rich-text editor - Auth.js + Magic Link + GitHub OAuth - Vercel Postgres + Drizzle ORM - Vercel Blob image upload - OpenAI Moderation API - Cloudflare Turnstile - Upstash Redis rate limiting - /admin/feed, /admin/users, /admin/queue - Phase 2 multi-author whitelist + post-hoc moderation - audit_logs table + src/content/posts/*.mdx (git is the database) + scripts/new-post.ts (chat → MDX scaffold) + scripts/translate-post.ts (zh → en) + <WorkflowNote> / <ChatSnippet> / <PromptBox> / <DiffBlock> / <AISummaryNote> + RSS + sitemap + JSON-LD
The total scope went from "a multi-milestone project with phase 1 and phase 2" to "one weekend, 6–8 hours."
What I learned (AI summarized, I added the gloss)
- Mature ≠ more code. I had been equating "more complete architecture" with "more mature." Mature = fits the use case. For a one-author logbook, adding auth makes it less mature, because it adds complexity you don't use.
- AI won't push back unless you make it. When I confidently said "I want signup, login, moderation," the AI confidently designed all of it. The pivot only came because I explicitly ran
/office-hoursand asked it to challenge me. The role I cast it in determined what I got. - A workflow is "codified" because it's written down, not because it's complex. I was already doing this; I just hadn't named it. Naming it is what makes the Nth post not more expensive than the first.
My own addition: when you confidently tell an AI what you want, it earnestly helps you build it. When you honestly tell an AI you don't know why you want it, it asks you whether you actually need it. Honesty is the better prompt.
What I shipped this afternoon
After v2, I executed M1-B1 (install MDX deps, migrate the first post to .mdx) and then M1-B3 (build the five custom components): <WorkflowNote>, <ChatSnippet>, <PromptBox>, <DiffBlock>, <AISummaryNote>.
The post you're reading is the first post that uses all five of them — so this post is simultaneously a logbook entry and an acceptance test.
Next
- Write 5 posts using this workflow (M1 acceptance criterion).
- Then a typography / OG-image / reading-time pass (M2, ~12 hours).
- Auth / DB / multi-user — maybe one day, as a separate learning project (M3, e.g.
guestbook.dahui.ai). But definitely not as a blog feature.