lotherk/deardiary
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

rewrite: blog posts with unixsheikh-inspired tone - direct, opinionated, no fluff

Browse Source
This commit is contained in:
lotherk
2026-03-27 14:34:15 +00:00
parent b2b2e80f0a
commit 98b29db8a0
2 changed files with 135 additions and 109 deletions
Download Patch File Download Diff File Expand all files Collapse all files

137
www/_posts/2026-03-27-building-deardiary-with-ai.md
View File

@@ -1,135 +1,124 @@
--- ---
title: Building DearDiary with AI - Lessons from Human-AI Collaboration title: What I Learned Building Software with AI
date: 2026-03-27 date: 2026-03-27
author: Konrad Lother author: Konrad Lother
excerpt: What I learned from building a full-stack app using an AI coding assistant excerpt: I built DearDiary with an AI coding assistant. Here's what actually happened.
--- ---
# Building DearDiary with AI # What I Learned Building Software with AI
## A Tale of Miscommunication and Debugging I built a full-stack application using an AI coding assistant. Let me tell you what it's actually like.
I built DearDiary using an AI coding assistant. It was enlightening, frustrating, sometimes hilarious, and ultimately successful. Here's what I learned about human-AI collaboration. No, I'm not going to tell you it's magical. No, I'm not going to tell you it replaced my job. It's more complicated than that.
## The Setup ## The Setup
DearDiary is a full-stack journaling app: Bun + Hono backend, React + Vite frontend, SQLite database, Docker deployment. Not trivial, but not rocket science either. DearDiary: Bun + Hono backend, React frontend, SQLite, Docker. Nothing exotic. I gave the AI context about the project, set it loose, and watched what happened.
I gave the AI context about the project structure, my preferences, and let it work. ## The Problems
## The Problems We Hit Here's what actually went wrong:
### 1. "It Should Work, But..." ### 1. The Invisible Gaps
The first major issue was the most classic: the AI made changes that *should* have worked according to its understanding, but didn't. AI is excellent at systematic changes. Change `DATABASE_URL` to `BACKEND_DATABASE_URL` everywhere? Done. Except it missed:
We consolidated environment variables into a single `.env` file with prefixes. The AI updated most references to `DATABASE_URL` → `BACKEND_DATABASE_URL`, but missed several:
- The Prisma schema - The Prisma schema
- The test helpers - Test helpers
- A variable in the healthcheck config - A healthcheck config
The app failed to start. The error message? Cryptic Prisma errors that took time to trace back to a simple env var mismatch. The app crashed. The error message was cryptic. It took time to find the missing env var.
**Lesson**: AI is great at systematic changes, but when it misses something, the gap is invisible to it. Always verify systematically. The problem: AI makes systematic changes, but it doesn't know what it doesn't know. The gap is invisible to it.
### 2. The Disappearing Routes ### 2. Routes That Should Exist But Don't
The AI moved API routes into a separate file (`events.ts`) and mounted them at `/api/v1`. Simple, clean. "Fixed the routes by moving them to a separate file." Except the routes were at `/api/v1/events` but the frontend called `/events`. The AI didn't catch the mounting path mismatch.
Except the routes were at `/api/v1/events` but the frontend was calling `/events`. The AI didn't catch that the mounting path was part of the route definition.
**Lesson**: AI understands code structure well, but context about how pieces connect across files is easily lost.
### 3. "I Fixed That" ### 3. "I Fixed That"
Multiple times, the AI would say "Fixed!" and show the corrected code, but the actual file hadn't been changed. Or it would describe a solution that wasn't implemented. Multiple times: the AI said "Fixed!" and showed the corrected code. The file wasn't changed. Or it described a fix that wasn't implemented.
This is the most dangerous mode of failure - confidence without execution. This is the most dangerous failure mode. Confidence without execution.
**Lesson**: Never trust "fixed" without verification. Make it show you the actual changes. ### 4. Docker Permissions
### 4. Permission Denied Entrypoint scripts kept failing with "permission denied." The AI knew about `chmod +x`. The order was wrong - file copied after chmod, or Docker cache served old versions.
Docker entrypoint scripts kept failing with "permission denied". The AI knew about `chmod +x`, but the order of operations was wrong - file copied after chmod, or Docker cache serving old versions. AI knows facts. Execution order matters.
**Lesson**: AI knows facts, but execution order matters. Sometimes you need to walk through the sequence step by step. ### 5. The Real Problem Wasn't Code
### 5. The 404 Debugging Journey Events returned 404. Routes: correct. Mounting: fixed. Auth: fixed.
Events returned 404. We checked: The actual problem: port 3000 on the host mapped directly to the backend, not through nginx. The frontend (served by nginx) couldn't reach the API.
1. Routes - correct
2. Mounting - fixed
3. Auth middleware - fixed
4. The actual problem: nginx port mapping. Port 3000 on the host was mapped directly to the backend, not through nginx. The frontend (served by nginx) couldn't reach the API.
**Lesson**: The AI focused on the obvious layers. The problem was in the infrastructure/configuration layer. AI needs explicit context about the full stack. The AI focused on code layers. The problem was infrastructure configuration.
## What Went Well ## What Actually Worked
Despite these issues, things also went surprisingly well: Core features worked on first try. The AI understood the patterns, maintained consistency. Once we established how things worked, it stayed consistent.
- **Feature implementation**: The core features (event capture, AI generation, search) worked on first try The README updates, documentation, refactoring - all smooth after the initial chaos.
- **Consistency**: Once a pattern was established, the AI maintained it consistently
- **Refactoring**: Moving from multiple `.env` files to one was smooth after the initial issues
- **Documentation**: README updates, code comments, and AGENTS.md were accurate
## The Communication Patterns That Worked ## The Communication Patterns That Matter
### Be Specific About Failures ### Be Specific About Failures
Instead of "it doesn't work", I'd say:
> "Events endpoint returns 404, checked docker logs and the route is registered"
The more context, the better the fix. Don't say "it doesn't work."
Say: "Events endpoint returns 404, docker logs show route is registered."
More context = better fix.
### Ask for Verification ### Ask for Verification
> "Show me the exact changes you're making before committing"
This caught the "I said I fixed it" problem. "Show me the exact changes before committing."
### Break Down Complex Changes This catches the "I said I fixed it" problem.
Instead of "consolidate all env vars", we did it in stages:
1. List all current env vars ### Break It Down
2. Decide on naming convention
Instead of "consolidate all env vars," we did it in stages:
1. List current env vars
2. Decide naming convention
3. Update backend 3. Update backend
4. Update frontend 4. Update frontend
5. Update docker-compose 5. Update docker-compose
6. Verify 6. Verify
### State What You Know Works ### State What Works
> "Previous similar changes worked with `docker compose build && docker compose up -d`"
Context about what has worked before helps the AI avoid untested approaches. "The previous approach worked with `docker compose build && docker compose up -d`."
## The Meta-Lesson Context about what has succeeded helps the AI avoid untested solutions.
## The Real Insight
Building with AI is like working with a very knowledgeable junior developer who: Building with AI is like working with a very knowledgeable junior developer who:
- Has read every Stack Overflow post - Has read every Stack Overflow post
- Can write code faster than you can type - Writes code faster than you can type
- Sometimes confidently does the wrong thing - Sometimes confidently does the wrong thing
- Needs supervision, especially for changes spanning multiple files - Needs supervision, especially for cross-file changes
- Gets better with clearer instructions - Gets better with clearer instructions
The key insight: **Your job becomes managing the AI, not just writing code.** You need to: Your job becomes managing the AI, not just writing code.
1. Provide good context
2. Verify systematically
3. Catch the invisible gaps
4. Maintain the mental model of the system
## What I'd Do Differently ## What I'd Tell Someone Else
1. **Track changes more carefully** - Use a changelog when AI makes changes, not just git diff AI is a tool. Like any tool, it has strengths and weaknesses.
2. **Test incrementally** - Don't let the AI make 20 changes before testing
3. **Be clearer about expectations** - "This should work out of the box" is less clear than explicit test criteria
4. **Document the debugging journey** - The process of finding issues is valuable context for future fixes
## Conclusion Use it for:
- Pattern matching
- Speed on routine tasks
- Generating boilerplate
- Explaining unfamiliar code
DearDiary is live. The AI and I built it together, argued about typos in environment variables, debugged at 2am, and shipped something I'm proud of. Don't use it for:
- Complex multi-file changes without verification
- Infrastructure configuration without checking
- Anything you don't understand yourself
Human-AI collaboration isn't about replacing programmers. It's about amplifying what humans do well (context, judgment, verification) with what AI does well (speed, consistency, pattern matching). The future isn't "AI replaces developers." It's "developers who use AI replace developers who don't."
The future is not "AI replaces developers." It's "developers who use AI replace developers who don't." Just keep an eye on those environment variables.
Now go build something with AI. Just keep an eye on those env vars.
*— Konrad*

107
www/_posts/2026-03-27-quick-start-guide.md
View File

@@ -1,59 +1,96 @@
--- ---
title: Quick Start Guide title: How to Actually Use DearDiary
date: 2026-03-26 date: 2026-03-26
author: Konrad Lother author: Konrad Lother
excerpt: How to get started with DearDiary in 5 minutes excerpt: Stop writing essays. Start capturing moments.
--- ---
# Quick Start Guide # How to Actually Use DearDiary
Getting started with DearDiary takes about 5 minutes. Here's how: Here's the thing about journaling: most people don't do it because they don't have time to write paragraphs at the end of the day.
## 1. Create an Event I built DearDiary because I wanted to remember my life. Not write essays.
Press **Ctrl+J** anywhere in the app to open the Quick Add widget. Type your event and press Enter. ## The Core Idea
That's it. It takes 3 seconds. You capture events throughout the day. In seconds. Then AI writes your diary.
Try these: That's it.
- "Had coffee with Sarah at the new cafe downtown"
- "Finished the chapter on machine learning"
- "Rain started around 3pm, got soaked walking back"
## 2. Add More Events Not "write down your thoughts." Not "reflect on your day." Just: what happened?
Throughout your day, capture anything that feels worth remembering: ## Step 1: Capture Everything
- Meetings and conversations
- Meals and what you ate
- Exercise and how you felt
- Thoughts and ideas
- Photos and voice memos
Don't overthink it. A short note is better than nothing. Press **Ctrl+J**. Type what happened. Enter.
## 3. Generate Your Diary Examples:
- "Coffee with Marcus at that new place downtown"
- "Finished chapter 5 of the ML book"
- "Got caught in rain walking back from the station"
- "Argument with Sarah about the project direction - she's probably right"
When you're ready, click the **Generate** button on today's page. AI reads all your events and writes a narrative diary entry. Three seconds. Done.
You can: Don't think. Don't edit. Just capture.
- Regenerate with different instructions
- Add context by including previous days' diaries
- Edit the generated diary (but the events stay locked)
## 4. Review and Reflect ## Step 2: Keep Going
Read your generated diary. Does it capture the essence of your day? If not, regenerate with instructions like: Throughout the day, whenever something happens that might be worth remembering:
- A conversation that mattered
- Something you learned
- How you felt
- What you ate
- Where you went
> "Focus more on the interesting conversations I had" Short notes. Bullet points. Voice memos if you're driving.
or A short note beats no note.
> "Make it more concise, highlight the key moments" ## Step 3: Generate Your Diary
## Pro Tips When you're ready, click **Generate**.
- **Be specific**: "Lunch with Marcus, talked about his new hiking trip to Patagonia" beats "Had lunch" AI reads all your events and writes a narrative diary entry. Not a summary. A story.
- **Capture emotions**: "Felt anxious before the presentation" is more interesting than "Presented to team"
- **Use voice**: Record voice memos while driving or walking - very efficient ## Step 4: Make It Better
Not happy with the result? Add instructions and regenerate.
> "Focus on the conversations I had"
> "Make it more concise"
> "I want more detail about the technical work"
Or don't. The AI diary is a suggestion, not scripture.
## The Secret
Be specific.
Bad: "Had lunch"
Good: "Lunch with Anna at the Italian place, she mentioned moving to Berlin next month"
Bad: "Meeting"
Good: "Project kickoff meeting - new client wants delivery by June, seems doable"
Specific notes = interesting diaries.
## Why This Works
Traditional journaling asks you to reconstruct your day from memory at 11pm when you're tired.
DearDiary asks you to note things in 3 seconds when they happen.
3 seconds beats reconstructing from memory every time.
## What You Get
At the end of the week, you have:
- A diary entry for each day
- The actual events, not reconstructed memories
- Locations, times, context
- Something you can actually read and remember from
Not perfect. But real.
That's the point.
That's it. Happy journaling!