DEV Community

Cover image for I Didn't Always Understand What I Was Building. That Was the Point.
L. Cordero
L. Cordero

Posted on

I Didn't Always Understand What I Was Building. That Was the Point.

This is a submission for the Built with Google Gemini: Writing Challenge

I Didn't Always Understand What I Was Building. That Was the Point.

A reflection on Memoria Clew, Google Gemini, and nine months of learning to build.


Nine months ago I wrote my first API call. This past December I built a full-stack application with Docker, rate limiting, a real MCP server, and multi-model fallback — in 20 hours, over a holiday weekend, inside an IDE that felt like magic.

I didn't always understand what I was building. That turned out to be the most important thing I learned.


What I Built with Google Gemini

I built Memoria Clew inside Google's Antigravity IDE, powered by Gemini. That means Gemini was doing two things simultaneously: it was the engine building the project from my architecture documents and staged prompts, and it was the intelligence inside the product itself — handling content summarization and tag extraction for every URL and snippet a user captures. Builder and built-in at the same time. That turned out to matter more than I expected.

Here is the problem the project solves, in its simplest form: I read AI and dev articles constantly. I forget constantly. The gap between those two things is where useful knowledge goes to die.

I would read something genuinely useful — a deep dive on async patterns, a thread about Docker networking, a README from a project doing something clever — and weeks later, while struggling through exactly the problem that article solved, I couldn't find it. Not because it wasn't saved. Because I couldn't remember why I saved it. The context was gone. Bookmarks don't remember why.

Memoria Clew was built to close that gap. It's a local-first research memory for developers that captures what you read, stores it with Gemini-generated summaries and tags, and surfaces relevant items back when your current work context matches something you already know. Not based on a search query you have to think up. Based on what you're actually building right now.

When something surfaces, you see exactly why. "Matches tags: REACT, TYPESCRIPT. Saved 4 days ago." No mystery. The system shows its work.


Demo

Video walkthrough: YouTube Demo

GitHub: earlgreyhot1701D/memoria-clew

Hackathon results: AI Vibe Coding Hackathon — Full Rankings

Memoria Clew placed 4th out of 250 projects and won two category prizes: Top 6 Best Projects Built with ElevenLabs and First Place Build with Featherless.ai. The happy path is strong — capture a URL, watch it summarize and tag, trigger recall, see the reasoning. The logs are there. The pattern analysis runs. It doesn't pretend to do more than it does.


What I Learned

The question that changed how I build

The question I learned to ask wasn't will this work? It was will this work the way my idea intended? Those are different questions. The first is about function. The second is about meaning.

When something broke or didn't behave the way I pictured, the answer was almost never to abandon it. It was to pivot. The pivot usually taught me something the original plan couldn't have. That's not a consolation prize — it's actually how vibe coding works when it's going well. It's discovery with guardrails, not chaos.

The PRD made that possible. Before a single line of code was written, there was an architecture document, a philosophy statement, and a staged build plan. When Antigravity's context window couldn't hold the whole system at once — and it couldn't, that was a real constraint — the stages gave each prompt clear scope. The agent knew what it was building in Phase 3 because Phase 3 was defined before Phase 1 started.

The moment that became the whole philosophy

There was a specific problem with tag extraction mid-build. Gemini was producing plausible tags for captured content — tags that sounded right but weren't actually in the text. It was inferring rather than extracting. The fix was a single prompt change: extract only what is explicitly mentioned in this content, do not infer.

That one constraint — extraction versus inference — turned out to be the recall engine in miniature. The whole project in one prompt fix. If you ask a model to be helpful without boundaries, it will be helpful in ways you didn't ask for. If you ask it to extract, it extracts.

I built a logging layer to catch exactly this kind of problem. When tags didn't match content, the mismatch was visible. The system showed its work even when the work was wrong. That logging layer, which started as a debugging tool, became the thing a judge — a principal engineer at Microsoft — specifically called out: "The explainable recall engine with transparent scoring is exactly what most AI projects lack."

Friction became feature. I want to remember that pattern.

The thing vibe coders usually skip

Rate limiting isn't glamorous. It doesn't show up in demo videos. Nobody puts it in a project thumbnail.

But vibe coders ship fast and leave the door open. It's one of the most consistent blind spots in AI-assisted development — you build the thing that works, you demo it, you submit it, and somewhere in the backend there's an endpoint with no protection on it. Anyone who finds it can hammer it until your API credits are gone or your service falls over.

I knew this going in and built rate limiting deliberately — per-IP limits, security middleware, tests to verify it held. Not because I had to. Because leaving it out felt dishonest to the project's whole premise. If Memoria Clew was going to be a system you could trust, it needed to behave like one even in the parts nobody sees.

That same judge who called out the recall engine also mentioned the production-grade infrastructure. I think rate limiting was part of what he meant. It's the kind of thing that's invisible when it works and catastrophic when it doesn't.

On nine months and what magic actually means

Working in VS Code with chat windows as a guide and working inside Antigravity with Gemini embedded in the build process are not the same experience. The difference is night and day. The IDE feels like a collaborator. That collaborator is fast, capable, occasionally wrong, and completely unaware of what it built in the previous session.

The speed is the thing that's hardest to describe to someone who hasn't felt it. The Christmas Day skeleton — a full-stack application scaffold with routing, services, and component structure — appeared faster than seemed possible. For someone nine months into coding, that speed doesn't just save time. It changes what feels buildable. Projects that would have taken weeks to attempt became weekend sprints.

The word that came to mind watching it happen was magic. Not metaphorically. It genuinely felt like that.

When the project placed 4th out of 250 and won two category prizes, one judge left a comment that felt like — there's no better way to put this — a connection to the ether. Like work done in relative isolation had been seen by someone who understood exactly what it was trying to do. That feeling was real and I'm not going to undersell it.

Another judge scored it 2.9/5 and noted that similar tools already exist. That was also fair. Both things are true at the same time. The idea isn't novel. The execution had something worth looking at.


Google Gemini Feedback

This is where the paradox lives.

Memoria Clew was built to be transparent — to show its reasoning, log its decisions, make its intelligence inspectable. It was built inside a tool that felt like magic, whose reasoning wasn't always visible, whose context window had edges I didn't know about until I hit them.

Building a tool that shows its work, inside a tool that doesn't always show its own — that tension ran through the whole project.

What worked:

The speed is real and it's genuinely extraordinary. Not just convenient — for a developer still learning what questions to ask, it changes what feels possible. That's not a small thing.

Antigravity understood architecture documents. Feeding it a staged PRD and watching it wire components to real APIs felt like having a senior developer read the brief and start building. When the prompts were clear and scoped, the output was strong.

Gemini's summarization quality, when the prompt was right, was solid. Technical content came back with accurate summaries. The model understood the domain.

Where the friction was:

The context window was the main constraint. The agent didn't remember what it had built in a previous session. Stage 3 didn't know what Stage 1 had decided. Fixing something in one part of the system could quietly break something elsewhere because the agent was working with a partial picture of the whole.

The solution was external — better staged prompts, tighter scope per session, architecture documentation that could be re-fed as context. That worked, but it meant I had to carry the full system in my head even when the agent couldn't.

The tag inference problem was Gemini defaulting to helpfulness in a way that wasn't useful. When asked to identify topics in content, it would go beyond what was actually there. It was trying to be smart. The fix was constraining the prompt — but the constraint had to be discovered by watching the output carefully and noticing when something was slightly off. Which is the whole argument for transparency in the first place.

The last thing is more of an observation than a criticism. Antigravity moves fast enough that it's possible to outrun your own understanding. Something gets built, it works, and you're not entirely sure why. For a developer still learning, that speed is a double-edged thing — you ship faster, but the gaps in understanding compound quietly if you're not reading what gets built, not just running it.

The right relationship with these tools turned out to be the same relationship Memoria Clew tries to model: use the intelligence, stay in control, keep the reasoning visible. AI that shows its work.

I didn't set out to build a project that embodied the lesson I was learning while building it. But that's what happened.


Built for the Built with Google Gemini: Writing Challenge presented by MLH.

GitHub: earlgreyhot1701D/memoria-clew
Hackathon results: vibe.yaps.gg

This article was written with structural assistance from Claude Code, which helped organize and refine the draft. The experiences, observations, and bad decisions are entirely my own.


#geminireflections #devchallenge #gemini #ai

Top comments (0)