This is a submission for the Built with Google Gemini: Writing Challenge
What I Built with Google Gemini
Every developer has a ritual they're quietly ashamed of: Google the error, copy the fix, paste it in, move on. No reflection. No understanding. Same mistake next week.
I built DebugDiary to break that cycle.
DebugDiary is a full-stack web app where you paste your broken code, describe what went wrong in plain English, and Google Gemini doesn't just fix it — it writes you a personal diary entry. A reflection. A mirror.
Each entry contains:
- A poetic title ("The Async Blind Spot", "When JavaScript Doesn't Wait for You")
- The technical root cause, explained clearly
- A deeper psychological lesson — why this mistake happens, not just what it is
- A "Remember This" rule of thumb burned into an inky black card
- Tags that categorise your error type over time
The dashboard then builds up a personal map of your weaknesses — your most common bug categories, your streak of consecutive days logging bugs, and an animated breakdown of your error patterns. Over time, it stops being a debugger and starts being a journal of your growth as a developer.
Gemini plays the central role: every entry is generated by a carefully engineered prompt that instructs it to respond not like Stack Overflow, but like a thoughtful senior developer who's seen your mistake a hundred times and wants you to actually learn from it this time. The response comes back as structured JSON — title, fix, root cause, deeper lesson, pattern warning, tags, severity, mood — which the app maps directly into a beautiful, readable diary page.
Tech stack: React + Vite frontend, Node.js + Express backend, Google Gemini API (gemini-2.5-flash), local JSON persistence, Framer Motion animations, React Syntax Highlighter for code diffs.
Demo
Demo URL: https://debug-diary-ten.vercel.app/
What I Learned
I learned more building DebugDiary in one evening than I expected — and most of it wasn't what I planned to learn.
Technically, I deepened my understanding of prompt engineering in ways that surprised me. My first attempt at the Gemini prompt was a wall of instructions that returned inconsistent, unparseable JSON. The breakthrough came when I stopped telling Gemini what to do and started showing it the exact output shape I needed, with no room for interpretation. Shorter, more constrained prompts produced dramatically better structured output than longer, more descriptive ones. That's a counterintuitive lesson I'll carry into every AI integration I build.
I also ran headfirst into the moving target that is the Gemini model ecosystem. Within a single evening I hit 404s from deprecated model names (gemini-1.5-flash, gemini-2.0-flash, gemini-2.0-flash-001 — all returned "no longer available for new users"), SDK version mismatches routing to the wrong API endpoint, and 429 rate limits on the free tier. I ended up switching from the @google/generative-ai SDK to direct fetch calls against the REST API, then back to the SDK once I identified the correct model string (gemini-2.5-flash) and endpoint (v1beta). It was frustrating in the moment. In retrospect, it was the most valuable part of the build — I now understand the Gemini API surface deeply rather than just cargo-culting a quickstart.
On the soft skills side, I learned something about scope. My original plan was a full database, user authentication, sharing features, and a weekly email digest. What I shipped was a local JSON file and four clean pages. And it's better for it. The constraints forced clarity — every design decision became about the core loop: paste bug, get lesson, see pattern. Nothing else.
The most unexpected lesson was noticing the irony of what I'd built. DebugDiary is a tool for learning from your mistakes. And building it, I made more mistakes per hour than I have in months. Every 404, every malformed JSON response, every SDK quirk — DebugDiary would have written a diary entry about each one. The tool ate its own dog food before I'd even finished building it.
Google Gemini Feedback
What worked brilliantly: The quality of Gemini's reflective writing genuinely surprised me. I expected it to produce dry, technical explanations. Instead, when prompted correctly, it produced entries that felt warm and human — the kind of feedback you'd get from a patient mentor rather than a linter. The "deeper lesson" section in particular consistently hit a level of psychological insight I didn't anticipate. Lines like "under time pressure, you revert to synchronous thinking" aren't just accurate — they're the kind of observation that makes you pause and recognise yourself.
The speed of gemini-2.5-flash is also excellent for this use case. Diary entries generate in 3–5 seconds, which feels fast enough to not break the flow of a debugging session.
Where I ran into friction: The model availability situation is genuinely rough for new developers. I spent a significant portion of my build time fighting 404 errors caused by model names that appear in tutorials and documentation but are no longer available for new API accounts. There's no clear "here's what you should actually use if you created an account this month" guide. For a developer experience that's supposed to feel magical, the onboarding friction is real and it's the first thing a new user hits.
The structured JSON output reliability also has room to improve. Even with explicit instructions to return only raw JSON, Gemini occasionally wrapped the response in markdown code fences, which broke my parser until I added a cleanup step. A native structured output mode — where you pass a schema and get guaranteed valid JSON back — would eliminate this entirely and make Gemini dramatically more useful for production applications that depend on parseable responses.
Despite the friction, I'd use Gemini again without hesitation. The output quality when it works is genuinely ahead of what I've seen from other models for this kind of reflective, nuanced text generation. I just want the path from "I have an API key" to "I have working output" to be shorter.
Top comments (2)
Such a relatable project. Your takeaway about using shorter, constrained prompts for better JSON output instead of walls of text is incredibly insightful. I'm definitely adopting that approach.
Thanks! It genuinely surprised me too—I kept thinking more instructions = better output, but the opposite was true. Less room for interpretation meant more consistent structure