DEV Community: L. Cordero

STEEP: Your repo's fortune, steeped in truth.

L. Cordero — Sat, 04 Apr 2026 19:42:43 +0000

This is a submission for the DEV April Fools Challenge

What I Built

Think teapot. Think tea. Think Ig Nobel. Think esoteric. Think absolutely useless. Think...Harry Potter?...Professor Trelawney?...divination!

Tea leaf reading. For GitHub repos.

That's Steep.

Paste a public GitHub repo URL. Steep fetches your commit history, file tree, languages, README, and contributors. It finds patterns in the data and maps them to real tasseography symbols, the same symbols tea leaf readers have used for centuries. Mountain. Skull. Heart. Snake. Teacup.

Then Madame Steep reads them.

Madame Steep is an AI fortune teller powered by the Gemini API. She trained at a prestigious academy (she won't say which) and pivoted to software divination when she realized codebases contain more suffering than any teacup. She delivers a structured reading of your repo's past, present, and future with a brew rating, a lucky commit message, and a one-sentence verdict.

She will not help you write better code. She cannot brew coffee. She can only read leaves.

I pointed Steep at my own repo.
The Sun appeared (test files found). The Spade appeared (CI/CD configured). The Apple appeared (README over 12,000 characters). And Madame Steep had this to say:

"A robust brew, full of promise, awaiting its next steep."

She's not wrong.

Three teapots. I'll take it.

When your reading is done, hit "Share My Fortune." Steep generates a downloadable card with your verdict, symbols, brew rating, and lucky commit message. Post it. Tag a developer who needs their leaves read.

Demo

Video:

Live app: steep418.vercel.app

Paste your repo. Or a coworker's. Or that side project you abandoned in 2023. The carousel has readings for some well-known repos if you want to see what Madame Steep does before you hand her your own cup.

When you land on the page, you'll see what looks like a crash screen. It's not a bug. It's the opening act. Press any key to skip, or wait for the glitch dissolve.

What a reading looks like:

Paste a repo URL. Click DIVINE. Madame Steep peers into your cup. She tells you about your repo's past, its present state (the roast), and its ominous future. She rates your brew (1-5 teapots). She gives you a lucky commit message. She delivers a one-sentence verdict.

Then you can download your fortune as a shareable image or save it to your Grimoire (localStorage).

This has been a reading from a teapot. You came here for code review. The leaves had other plans.

Code

earlgreyhot1701D / steep

A deliberately useless tea leaf reading app for GitHub repos. Paste a URL, get a dramatic, wildly specific, and entirely unhelpful divination of your codebase. Powered by Gemini, tasseography, and poor judgment. Built for the DEV April Fools Challenge 2026. This is a teapot. It cannot brew coffee. 🫖

STEEP

Your repo's fortune, steeped in truth. 🫖

Demo

In 1998, Larry Masinter wrote RFC 2324 as an April Fools' joke. It defined a protocol for controlling coffee pots over HTTP and introduced status code 418: "I'm a teapot." The spec notes that the response body "MAY be short and stout."

It was satire about over-extending HTTP. Then a 15-year-old developer started the Save 418 movement. Major frameworks kept it. Python 3.9 added IM_A_TEAPOT. A joke became permanent internet infrastructure.

Steep is that teapot.

It reads tea leaves. The tea leaves are your GitHub repository. Paste a repo URL and Steep fetches your commit history, file tree, languages, and README. It finds patterns in the data and maps them to real tasseography symbols from centuries-old tea leaf reading traditions. Then an AI fortune teller named Madame Steep delivers a dramatic, weirdly specific, and entirely useless divination of your codebase's…

View on GitHub

Architecture

User pastes repo URL
        |
        v
github.js fetches repo data (unauthenticated, 60 req/hr)
        |
        v
symbols.js selects symbols deterministically
  - 17 triggers evaluated against real repo data
  - sorted by drama (Grim before Apple)
  - Teacup always included
        |
        v
/api/divine.js sends data + symbols to Gemini 2.5 Flash
  - 80+ line Madame Steep system prompt
  - returns structured JSON
        |
        v
reading.js renders the full reading
  - DOM construction via textContent (no innerHTML)
  - shareable card via html2canvas
  - save to localStorage grimoire

One page. Vanilla HTML/CSS/JS. No framework. One Vercel serverless function. Total cost: $0.

The pixel art crash screen, the dusty blue aesthetic, the scanline overlay, the three-font system (Press Start 2P for the machine, VT323 for the terminal, Cormorant Garamond for the mystic) are all CSS. No images except the SVG pixel teacup, which is drawn inline.

21 unit tests. Yes, the joke app has tests.

How I Built It

The idea

The concept started in a conversation with Gemini. I was exploring Ig Nobel Prize winners for "delightfully useless" inspiration. We went through dead code reanimation tools, commit quality scanners based on astrology, and repo phrenology before landing on tasseography. Tea leaf reading. Because the challenge prizes are teapots. And the Larry Masinter category is literally about a tea/coffee protocol. The concept locked when I realized the ENTIRE APP could be a 418 response: a teapot that someone asked to do useful work, refusing politely.

The design

I explored eight UI directions across Claude, Google Gemini, and Google Stitch. Carnival fortune teller. Victorian broadsheet. Dark séance dashboard. Warm tea shop. Steampunk newspaper. The dark directions kept looking too serious. The light directions didn't match the pixel art energy.

Google Stitch generated complete Material Design 3 systems with color tokens, font stacks, and Tailwind configs. Beautiful, but they all looked like SaaS products. The final direction, dusty blue pixel art with a crash screen opening, came from stripping everything back and asking: what would a haunted computer's fortune teller look like?

I also used Google Veo to generate the banner image for this post.

The symbols

The 17-symbol system is the part I'm most proud of. Each symbol comes from real tasseography tradition. Each one maps to a deterministic trigger in the GitHub data. The Mountain appears when your repo has 100+ commits. The Skull appears when you have no LICENSE file. The Grim appears when your repo hasn't been touched in 6 months.

The selection happens client-side in symbols.js. No AI involved. The symbols are sorted by drama (Grim outranks Apple). If fewer than three triggers match, the Bird (good news) appears as a default. The Teacup is always present. The reading happens inside a teapot.

This split is deliberate: the DATA is deterministic, the STORYTELLING is AI. Same repo, same symbols every time. But each reading is a unique narrative.

The AI

Madame Steep is an 80+ line Gemini system prompt. She's Professor Trelawney meets a disappointed senior engineer. The prompt engineering focused on:

Making her reference specific repo data (file names, commit messages, percentages) instead of generic observations
Weaving tea metaphors naturally into every section
Keeping verdicts under 15 words (the shareable moment)
A banned word list to kill LLM filler ("formidable," "testament," "leviathan," "sprawl")
Never giving useful advice. She's a mystic, not a linter.
Never being cruel to the developer. She roasts the code, not the coder.

The stack

Layer	What
Frontend	Vanilla HTML/CSS/JS
Hosting	Vercel (free tier)
Backend	One Vercel serverless function
AI	Google Gemini 2.5 Flash
Data	GitHub REST API (unauthenticated)
Storage	localStorage
Share	html2canvas

The 60 request/hour GitHub API rate limit is a feature. The neon bar at the top of the app tracks it in real time: "LEAVES REMAINING: 47 / 60 • THE LEAVES GROW WEARY." When you run out: "THE LEAVES HAVE GONE SILENT. RETURN WHEN THE HOUR TURNS."

Prize Category

Best Ode to Larry Masinter

In 1998, Larry Masinter wrote RFC 2324 as an April Fools' joke. He defined a Hyper Text Coffee Pot Control Protocol, complete with a BREW method, Accept-Additions headers (cream, sugar), and status code 418: "I'm a teapot." The spec notes the response body "MAY be short and stout," a nod to the nursery rhyme.

It was satire about over-extending HTTP for absurdly specific purposes. Then in 2017, a 15-year-old developer named Shane Brunswick started the Save 418 movement when the IETF tried to remove it. The movement went viral. Node.js, Go, Python, and ASP.NET all kept 418. Python 3.9 officially added IM_A_TEAPOT. A joke from 1998 became permanent internet infrastructure.

Steep is structurally a 418 response. The entire app is a teapot that someone asked to do useful developer work (code review), and it responded with a tea leaf reading instead. The 418 page is not an Easter egg. It's the thesis.

Click "Actually, give me a real code review" and Steep tells you: "You asked me to brew coffee. I can only read leaves. This is not a code review tool. This is a vessel of divination. RFC 2324, Section 2.3.2."

The rate limit bar says "THE LEAVES GROW WEARY." The loading screen says "Madame Steep peers into your cup." The crash screen error code is ERR_TEAPOT_418 :: STEEP_DIVINATION_FAULT. Every interaction is steeped (sorry) in the teapot metaphor. The app IS a teapot. It has always been a teapot.

Best Google AI Usage

Google AI is embedded throughout Steep, from concept to design to product:

Gemini Chat helped shape the concept. The path from "Ig Nobel prizes" to "tasseography for GitHub repos" happened in a Gemini conversation.

Google Stitch generated the UI explorations. Multiple rounds of complete page mockups with color token systems and component patterns. Eight distinct directions before locking in.

Google Veo generated the banner image for this submission.

Gemini 2.5 Flash API powers the live product. Every reading is a real-time Gemini call with an 80+ line character prompt, structured JSON output, and creative interpretation channeled through a deterministic symbol framework.

The symbol system is where the architecture gets interesting. 17 symbols from real tasseography, each mapped to a deterministic trigger:

Symbol	Meaning	Your repo earns it when...
⛰ Mountain	A great journey	100+ commits
💀 Grim	Death approaches	No commits in 6+ months
♥ Heart	Devotion	Solo contributor, 50+ commits
🐍 Snake	Deception	50%+ lazy commit messages
☀ Sun	Great happiness	Test files found
☠ Skull	Danger	No LICENSE file
♠ Spade	Hard work	CI/CD configured
🍎 Apple	Knowledge	README over 500 characters
⚔ Sword	Conflict	30%+ merge commits
⚓ Anchor	Stability	Consistent commits over 6+ months
🐦 Bird	Good news	Pushed within 7 days
✝ Cross	Trials	20+ open issues
🌳 Tree	Growth	5+ active branches
🪁 Kite	Wishes	Roadmap file detected
🌙 Moon	Mystery	.env and .env.example both present
🐈 Cat	Treachery	Outdated dependencies
🌰 Acorn	Windfall	High stars-to-age ratio
🫖 Teacup	The vessel speaks	Always present

Symbol selection is deterministic. No AI involved. Gemini's job is to interpret the symbols it's given, not to choose them. This means every reading is grounded in real data, and Gemini's creativity is channeled through a structured framework rather than generating everything from scratch. The data is consistent. The storytelling is not.

Built by L. Cordero (@earlgreyhot1701D)

AI assisted. Human approved. Powered by NLP.

Do you work here? I flew to Albuquerque to speak at a national conference. Someone asked if I worked the door.

L. Cordero — Tue, 31 Mar 2026 17:59:36 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

I get asked if I work here. A lot.

Target. Hallmark. Grocery stores. I'll be in jeans and a t-shirt, baseball cap on, holding my own cart, my own bags, clearly in the middle of my own shopping, and someone will walk up and ask where something is. Or skip the question entirely:

"Do you work here?"

I never do.

After a while, you stop being surprised. You start keeping track without trying. What you were wearing. How you were standing. Who asked. What they saw when they looked at you, and what they decided it meant. The catalog builds on its own.

It gets heavy.

In March 2026, I flew to Albuquerque for the NACM Midyear Conference, the National Association for Court Management.

I was there to present. My session was about whether courts should invest in building internal AI capacity through their frontline staff, and I used my own work as the case study. Jury eligibility chatbots. Document processing with AWS Textract. A data pipeline for eleven years of jury utilization records. An automation attempt that dead-ended when I found out vendor data quality was the real problem, not the AI.

Civic tech, built from the operations side, for people trying to figure out what AI actually means in their courts. I'd been writing about it and building for months. But this was the first time I was standing in front of court administrators at a national conference, in person, walking them through what I built and what it taught us.

I got to the hotel early, before registration opened. A woman walked up to the entrance at the same time I did, her hands full. I reached for the door.

"Would you like me to open it?"

She looked at me.

"Do you work here?"

I had on a baseball cap. Sunglasses. A Mexican woven shirt. I was just a person holding a door.

"No. Your hands are full."

She said she appreciated it.

I walked in ahead of her, stood in line ahead of her, and checked in.

Another entry.

Here's what I keep coming back to.

The places where people mistake me for staff are places where I've never once felt out of place. I think about the grocery store near my house where one of the women who works there calls me mija every time I come in. She doesn't know what I do. She doesn't care. She just sees me, and that's the whole interaction. No performance required. I think about the aisles where someone won't just point you toward what you're looking for but will walk you there. Those places take care of people.

No one asks you to earn it first.

The rooms I've actually earned my way into are different.

Not because anyone inside is doing something wrong. But because by the time I reach the door, someone has usually already told me what they think I am. So I walk in carrying it. Adjusting anyway. Even when I shouldn't have to.

That's what I carried into the conference room when I set up my slides and tested my mic in Albuquerque.

I gave the talk. It went well. People stayed for questions. Courts have followed up since, asking how to start their own AI work, how to think about risk, how to structure bounded experiments in an environment where you can't afford to get it wrong.

That was the whole point of being there.

That question doesn't stay at the door.

There's a conversation in AI/tech/dev communities right now about what counts as "real" building. If you learned with AI tools, if you came from outside the industry, if you figured it out as you went, there are people who will question whether it counts. Whether you understand what you shipped. Whether you earned it.

Sometimes it sounds like "Do you understand what you've built?"

Sometimes it sounds like "Do you work here?"

The mechanics are the same. Someone looks at you, decides what you are, and asks a question they already think they know the answer to.

I built things that work. I learned in the margins of a full-time job, using the tools available to get started and keep going. I also know what I don't know yet, and I'm working on closing those gaps.

Both of those are true at the same time.

I was careful about how I built for my work prototypes. Nothing went into production. That was by design. Every prototype existed to generate operational intelligence, to help court leadership understand what these tools could actually do before committing real resources. I documented everything. I set boundaries. I stopped when something wasn't mine to solve. I made it easier for my manager to say yes the next time.

The work did what it was supposed to do.

I don't have a clean ending for this.

The pattern started long before I learned to code, and it will keep going whether I build ten more prototypes or a hundred. I'm not interested in performing my way past it, and I don't think the answer is accumulating enough credentials that people stop asking the question. They won't.

I walked into that hotel. Then I walked into that conference room. I gave the talk I came to give.

If you're building from a path that doesn't look the way people expect, from a role without a clean title, from someone people size up before they listen to, you already know what the catalog feels like. It's not any single entry that weighs you down. It's that there's always a next one.

The catalog gets heavy.

The work is still yours.

AI assisted. Human approved. Powered by NLP.

I Planned an Exit Strategy. I Stayed the Whole Time.

L. Cordero — Mon, 09 Mar 2026 03:37:29 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

I told my wife to keep her phone close. "I might call you to come get me early," I said, already mapping the exit in my head before she'd even pulled away from the curb. Large groups of strangers in new environments are not my thing. Never have been. I had a whole contingency plan: polite excuses, a headache maybe, the classic slip-out-the-back-door if it came to that.

That was this morning, March 8th. International Women's Day. I was walking into a SheBuilds on Lovable event to celebrate by doing something I would not have imagined doing a few years ago: building an app in a room full of people I had never met. Lovable opened its AI app builder for free for 24 hours, powered by Anthropic, and handed every participant $100 in Claude API credits and $250 in Stripe credits. No application. No eligibility requirements. Just show up with a laptop and an idea.

I showed up with both, and a detailed exit strategy I never used.

What I was building

Live music memories fade. You remember the feeling but not the setlist. You remember the venue but not the year. You have ticket stubs in a shoebox or maybe just a mental list that gets shorter every time you try to recall it. I wanted a way to preserve that history and actually see the story it tells about you.

Aftershow Atlas. A personal concert history tracker with an Old Hollywood marquee aesthetic. You log a show you attended (artist, venue, date), and the app pulls the real setlist from setlist.fm, drops a pin on your map, and you enter memory line for each show.

The feature I was most excited about is Musical DNA. It reads your concert history and tells you who you are as a music fan. Not stats. Interpretation. "A devoted alternative rock archaeologist who excavates the grittiest gems of the '90s underground, returning again and again to worship at the altar of Shirley Manson's defiant anthems. They chase the raw, unpolished edge of rock's rebellious daughters across continents, from Dublin's punk halls to Mexico's intimate venues." That kind of thing.

I had spent the night before building out the full brief with Claude: design system, database schema, edge functions, accessibility requirements, a 14-section build document. I came prepared. What I did not come prepared for was how the day would actually feel.

What happened in the room

Christina, our host, gave us about an hour and twenty minutes to build. I remember her announcing that time was up and genuinely not believing it. How? We had just gotten here.

But that is the thing. We did not just build. We got to know each other first. And then, even while building, I talked to Billie, Alison, and Kushboo about what they were working on, what they were experiencing, what problems they were trying to solve. Sharing ideas with strangers. Getting excited about someone else's project. Offering a suggestion. Asking a question you were not sure was smart enough to ask.

I do not think I spoke with a single builder who had an engineering background. Not one. And they were all building something that mattered to them.

The builder identity

One of the conversations Christina led, and I keep coming back to, was about embracing the builder identity. Not the engineer identity. Not the developer identity. The builder identity.

We may not be building unicorns. Our apps might stay at v1 forever. The code might not be elegant by anyone's standard. But we are building. We are taking up space and filling it with our ideas, our products, our passions. And we are doing it together, which means we get to shine in our strengths and support each other through the parts that are hard.

That reframe mattered to me. Because when you come from courtroom operations, not computer science, when you learned to build by directing AI tools instead of writing code from scratch, calling yourself a builder can feel like you are borrowing someone else's jacket. Christina made it clear that the jacket fits.

Where I come from

I spent years managing courtroom operations before I ever touched a codebase. My path into tech was not a boot camp or a CS degree. It was curiosity, AI tools, and a stubbornness about building things that actually help people.

I do not write code from scratch. I provide creative direction and validation. I work with a handful of AI tools, compare their outputs, choose the best pieces, and stitch them together into something that works. The AI generates. I direct, validate, and refine. That is a deliberate workflow, not a limitation.

The point is not that engineering degrees do not matter. They do. We need people who can read code, write code, and help the rest of us fix our mistakes. The point is that there is more than one path to building something worth using, and mine started in a courtroom.

What I keep waiting for

I keep waiting for the part where I have to be cynical about this. The part where I hedge, or qualify, or add the "but of course, it is not all sunshine" paragraph so it does not sound naive.

It has not come yet.

Nobody in that room felt like they had to perform. Nobody was networking in that calculating way where you can feel someone scanning for your job title. People showed up. People built. People helped each other. Product.io hosted us, Christina put the whole thing together, and the energy was just... great.

When you spend enough time building alone in an echo chamber (solo builder anyone?), or showing up to spaces that feel curated or transactional, you notice when one feels different. This one did.

Who this is for

If you are reading this and you do not have a tech background but you have been thinking about building something, this is for you. If you are in an underserved community wondering whether the tools and the spaces and the support actually exist, they do.

If you want to be a founder, help others, invest in your community, or just finally build that idea that has been sitting in your notes app for six months, it feels like the barrier is lower than it has ever been. I built Aftershow Atlas as a solo builder with no engineering background and a very detailed brief. If I can do that, I think a lot of other people can too.

The app

Aftershow Atlas is live. It is not perfect. The auth flow gave me trouble (Google OAuth was a disaster, we pivoted to magic link mid-event). Lovable ran out of Claude credits partway through, and we kept going anyway. The marquee bulb animation is maybe a little extra. The Musical DNA feature still needs more show data before it really sings.

But it exists. Because I showed up to a room full of strangers on International Women's Day, did not call my wife for an early ride home, and built something.

Built at SheBuilds on Lovable on March 8, 2026, celebrating International Women's Day. Powered by Lovable, Anthropic Claude, Supabase, and the setlist.fm API. Thank you to Christina, Product.io, and every builder in that room.

Check out Aftershow Atlas or find me on GitHub: @earlgreyhot1701D

I'm a semifinalist in AWS 10,000 AIdeas Competition 🎯 Community voting is open through March 20th — would love your support! 👉 https://tinyurl.com/clewdirective Better yet, try it: clewdirective.com — 4 questions, personalized AI learning path PDF.

L. Cordero — Sun, 08 Mar 2026 00:48:29 +0000

L. Cordero

Feb 22

Me? A Semi-Finalist in the AWS 10,000 AIdeas Competition? Here's What I Built

#ai #beginners #aws #learning

Comments

4 min read

AWS Builder Center

Connect with builders who understand your journey. Share solutions, influence AWS product development, and access useful content that accelerates your growth. Your community starts here.

builder.aws.com

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

L. Cordero — Sun, 01 Mar 2026 22:19:58 +0000

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

Me? A Semi-Finalist in the AWS 10,000 AIdeas Competition? Here's What I Built

L. Cordero — Sun, 22 Feb 2026 00:27:03 +0000

So this happened: my little project, Clew Directive, got selected as a semi-finalist in the AWS 10,000 AIdeas Competition. I'm now among the top 1,000 innovators moving to the building phase.

Quick version: Clew Directive is a free tool that generates personalized AI learning paths in 60 seconds using Amazon Nova's reasoning. No paywalls, no tracking, no accounts. Just a PDF you can download and keep.

I'm genuinely shocked. But in a good way - like, I believed in the idea, and it turns out other people saw the vision too.

Why This Matters (To Me)

AI literacy is becoming a baseline life skill. But access shouldn't depend on:

How much money you have
Where you live
Whether an algorithm decided to feed you the "right" courses
Your ability to figure out which resources are legit

When people are overwhelmed, they freeze. They don't move forward. And that's exactly who I'm building Clew Directive for - the people who want to learn but don't know where to start, who are tired of hype, who just need someone to point them in the right direction.

I'm inspired by work like Yuda.io, which is built on the same belief: AI literacy shouldn't be gatekept. Yuda is creating free, high-quality AI education specifically designed for people who are being left behind by the current tech landscape - people without expensive bootcamp access, people in regions where resources are limited, people who just need clarity without the hype. That idea keeps me going. If you haven't checked them out, they're doing important work.

The Moment That Started It All

Here's where it came from: I was doomscrolling Instagram and my algorithm had decided I needed to learn AI. Every. Other. Post. "Learn AI in 10 Days!" "Master ChatGPT!" "AI Bootcamp Starting Now!"

I couldn't tell which courses were actually free. Which ones were worth my time. What came next after the first course. I spent like an hour just... researching which resources to use. Tab after tab. Spreadsheet comparisons. Analysis paralysis.

And I thought: I'm not the only person overwhelmed by this.

What Is Clew Directive?

It's straightforward:

You answer 4 quick questions about your experience level, goals, learning style, and background
Amazon Nova's reasoning agents synthesize that into a personalized profile
The system reasons through 28 curated, verified free resources and builds your learning path
You download a PDF and start learning

What makes it different: The PDF is yours to keep. It's not just a list - it's a thoughtful roadmap with reasoning about why each resource was picked for you, clickable links, estimated time commitment, and next steps. The links are live (not just URLs), so you can click directly from the PDF into each course. Since Clew Directive is completely stateless (no accounts, no tracking, no database), that PDF becomes the artifact you can reference later, share with a friend, or revisit months into your learning journey. It's something tangible you walk away with.

No paywalls. No tracking. No accounts.

The core idea: AI-powered reasoning should democratize access, not gate it behind subscriptions.

I should mention: I built this without formal computer science training or education. I work in public service and stumbled into coding through hackathons (3 wins, lucky me) and built my own learning path. So when it came time to actually build Clew Directive, I leaned on AI tools - Claude, ChatGPT, Gemini, Kiro - for scaffolding, code generation, testing, and architectural review. Every line got reviewed and tested. All decisions and mistakes are mine.

What's Next

The competition moves into a voting phase. The top 300 projects (by likes) move forward to final judging. If you're curious about what I built, I'd genuinely love for you to check it out:

Try it: clewdirective.com
Read the deep dive: AWS Builder post (detailed breakdown of the architecture and reasoning)
Watch the explainer: My avatar explains it (yes, I made an AI avatar explain my AI project)
Check the code: GitHub repo
See it in action: YouTube demo

If you dig it, great. If you have feedback or ideas, I genuinely want to hear them. I'm learning as I go.

The Real Talk

Full transparency: I was anxious about this. Not imposter syndrome - I know I built something I can be proud of. But this whole space moves so fast. Everyone's using AI. Everyone's building agents. And there's this underlying current of "if you're not moving at lightspeed, you're behind."

To me, that's bs, and it's exactly why I built Clew Directive.

Not everyone learns at the same pace. Not everyone has the same goals. Not everyone should be following the same hype cycle. People need their own path. Their own pace. Their own direction.

So if you're learning AI and feeling overwhelmed? That's not a you problem. The landscape is genuinely overwhelming. But it doesn't have to be.

About the Name

I'm not in love with the name "Clew Directive" anymore. It made sense as a play on "clew" (a ball of thread, a guide through a maze), but honestly, when people hear it, they're like "...what?" If you've got name ideas, I'm all ears.

Thanks for reading. And thanks to AWS for getting behind this idea.

Now back to building. 🚀

AWS #AmazonNova #AI #Education #Learning #Hackathon #OpenSource #AIDeveloper)**

Anton Clew — Stop AI From Committing Regret

L. Cordero — Sun, 08 Feb 2026 18:16:04 +0000

This is a submission for the GitHub Copilot CLI Challenge

Anton Clew — Stop AI From Committing Regret

What I Built

Anton Clew is a deterministic, policy-driven CLI that prevents risky or unauthorized file changes before they are committed, adding enforceable safety guardrails to AI-assisted coding workflows in Git repositories.

As AI agents and automation generate changes faster than humans can reliably review them, it becomes easy to accidentally modify sensitive files (keys/secrets), touch critical configuration, or change core code paths without explicit approval. Anton Clew shifts safety left by enforcing policy as code before commits happen.

Developers define simple YAML rules (path and glob-based), and Anton Clew evaluates staged files and classifies each change as:

ALLOW — safe changes that proceed normally
NEEDS_APPROVAL — changes requiring explicit human review
DENY — changes that are blocked entirely

The core design principle is determinism: no probabilistic judgments, no hallucinations—just predictable enforcement that can be trusted in local workflows, pre-commit hooks, and CI pipelines.

How It Works

Anton Clew operates on staged Git changes. Developers define repository policies using a simple YAML file that describes which file paths are allowed, require approval, or are explicitly denied.

When the CLI is run, Anton Clew inspects the staged files and deterministically classifies each change as ALLOW, NEEDS_APPROVAL, or DENY. If any denied or unapproved changes are present, the check fails—preventing risky commits before they land.

This approach enables early, enforceable checks on staged changes, making it practical to integrate Anton Clew into local development workflows, pre-commit hooks, and CI pipelines—especially when AI tools or automation are generating code at high speed.

Demo

GitHub Repo:

https://github.com/earlgreyhot1701D/antonclew

Video Overview (NotebookLM):

https://youtu.be/VDftFjy8KGI

For the demo, I created a small Git repository with a policy file and staged changes designed to trigger all three decision paths. Anton Clew evaluates the staged files and produces clear, deterministic outcomes:

.agentpolicy.yaml and README.md → ALLOW
secrets/private.key → DENY (matches deny rules for sensitive files)
src/example.ts → NEEDS_APPROVAL (matches approval-required paths)

This demonstrates Anton Clew’s intended use case: enforcing guardrails on what is about to be committed, especially when AI tools or automation are generating code at high speed.

My Experience with GitHub Copilot CLI

GitHub Copilot CLI acted as a practical, terminal-native assistant throughout development—particularly during testing, debugging, and build stabilization.

I used Copilot CLI to:

Diagnose failing tests and edge-case mismatches
Fix TypeScript build errors (missing dependencies, implicit any issues)
Resolve Node.js ESM import and runtime issues
Apply focused, minimal patches while keeping changes reviewable
Iterate faster without leaving the terminal or breaking flow

Copilot CLI accelerated problem-solving without replacing judgment. Every change was validated with tests and builds, keeping the project deterministic and reliable.

Credits

This project was built with assistance from GitHub Copilot CLI and ChatGPT, used as development accelerators for debugging, iteration, and problem-solving during the build process.

Final design decisions, validation, testing, and responsibility for the codebase are entirely human.

The name Anton Clew is a playful reference to Son of Anton—a nod to Silicon Valley–style systems thinking, legacy, and the idea of leaving a clear “thread” (a clew) to follow through complex technical problems.

AI assisted. Human approved.

All mistakes are mine.

About Me

LinkedIn:

https://www.linkedin.com/in/la-shara-cordero-a0017a11/

Clew Quest: Intelligent Project Discovery with Algolia Agent Studio

L. Cordero — Mon, 19 Jan 2026 22:31:36 +0000

This is a submission for the Algolia Agent Studio Challenge: Consumer-Facing Non-Conversational Experiences

Clew Quest: Intelligent Project Discovery with Algolia Agent Studio

What I Built

Clew Quest is an open source project discovery tool that helps developers find GitHub repositories matched to their skill level and learning goals.

Instead of searching "machine learning" and getting overwhelmed by 50,000 results with no context, users answer 4 simple questions:

What do you want to learn?
What languages or skills do you care about?
What's your skill level? (Beginner, Intermediate, Advanced)
Search

They get back GitHub projects with specific explanations for why each one matches their criteria.

They get back GitHub projects with explanations for why each one matches their criteria.

The tool indexes 2,800 GitHub repositories and uses smart keyword matching combined with AI reasoning to understand developer intent. Each result includes: project name, star count, language, difficulty level, and an explanation of why it matches the user's goals.

Data: Github Repos dataset by Don Barbos on Kaggle.

Demo

GitHub: https://github.com/earlgreyhot1701D/clew-quest

Video: https://youtu.be/sP9eQe3xEA4

Audio Overview: https://notebooklm.google.com/notebook/0a3b7c43-1446-459f-94d1-868cbaa91f42?artifactId=04209d69-2163-4cfd-9f4c-8da7faeda29a

How I Used Algolia Agent Studio

Data Indexed

2,800 GitHub repositories from a public dataset, each with:

Project name
Star count & fork count
Primary language
Description
Difficulty level (Beginner, Intermediate, Advanced—classified via Gemini)

The data pipeline: CSV → Gemini Batch API for difficulty classification → Algolia index.

Retrieval Strategy

Algolia's Search API handles the retrieval layer by combining:

Keyword search - Matches explicit terms ("Python", "React", "machine learning")
Smart ranking - Results ordered by relevance + community signal (star count)
Filtering - Applies difficulty level and ecosystem filters

When a user says "I want to learn Python machine learning," the search understands this as: find projects related to both Python AND machine learning, ranked by community adoption, filtered by selected difficulty level.

Prompt Engineering

The system prompt for Gemini (via Agent Studio) focuses on generating specific, actionable reasoning:

For each project result, Gemini generates an explanation that:

Names the project
Connects it to the user's specific intent and skill level
Includes one concrete signal (star count, community size, or use case)

Example outputs:

"scikit-learn is ideal—top Python ML library (46K stars) with beginner tutorials everywhere"
"TensorFlow is the industry standard (182K stars) so you learn skills used by 90% of ML teams"
"Rust is perfect for systems programming—memory safety built-in, growing community"

Agent Studio Integration

Agent Studio orchestrates intelligent recommendations:

Receives user query from the React form
Sends to Algolia Agent Studio with the system prompt
Agent Studio coordinates:
- Gemini analyzes the user's intent and skill level
- Algolia Search queries the github_projects index based on that analysis
- Gemini generates specific reasoning for each recommended result
Returns ranked results with explanations
Frontend displays project cards with reasoning, star count, language, difficulty level, and feedback buttons

The integration is seamless: one endpoint, one orchestration layer, no custom backend code needed.

Fallback & Reliability

If Agent Studio recommendations aren't available, the system gracefully falls back to:

Broad keyword search using extracted terms + ecosystem filters
Smart heuristic reasoning based on project signals (stars, language match, difficulty level)

This ensures users always get results, even if the Agent experiences issues.

Why Fast Retrieval Matters

Developer experience depends on speed and relevance working together.

Speed: Algolia's infrastructure means search results appear quickly. Slow retrieval kills discovery—users don't wait for results when searching for projects.

Relevance: Semantic search means results actually match what users are looking for. If a user searches "learning machine learning," they get beginner-friendly projects, not just repositories with "ML" mentioned in passing.

Together, these create a workflow where:

Users get answers immediately
Answers are contextually relevant to their specific goal and skill level
The AI reasoning is grounded in actual project data (no hallucinations)
Users trust the recommendations because they make sense

Without fast retrieval, the agent reasoning would be slow and frustrating. Without semantic search, users would see irrelevant results despite Gemini's reasoning being correct. Algolia enables both speed AND relevance at the same time.

GitHub: https://github.com/earlgreyhot1701D/clew-quest

Portfolio: https://beyond-the-docket-489960083310.us-west1.run.app/

LinkedIn: https://www.linkedin.com/in/la-shara-cordero-a0017a11/

From Jury Services to AI Builder in 6 Months

L. Cordero — Mon, 05 Jan 2026 06:02:32 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

I'm a Judicial Services Manager at Santa Barbara Superior Court. Six months ago, I started building AI projects. I've shipped seven, won two hackathons, and learned that the fastest way to learn is to build things that solve actual problems.

The first one started from frustration. People called constantly with jury eligibility questions. "Am I eligible?" "What does this code section mean?" "Can I defer?" I'd look up the same answers in California legal code and send emails. Same questions, hundreds of times.

So I built a chatbot. AWS Bedrock, Claude AI, fed it the legal code as context so it could answer accurately and cite sources. Took a weekend. The court staff use it now.

That project proved something: I could build useful things. From there, each project solved something I saw.

This portfolio documents six months of that.

Portfolio

Everything is live and interactive. Click through the projects, expand the side quests, try the case study generator.

The 4 Main Projects (timeline view):

Jury Eligibility Chatbot (July) - RAG-powered, uses court-verified legal code, production-ready
PDF Text Extractor (August) - Cal Poly DxHub project. I was selected 1 of 100 from 1,300 applicants. Our team placed 2nd out of 14.
Janus-Clew (December) - Won AWS Vibe Hackathon. Built a growth tracker that measures technical complexity progression.
Athena-Clew (January) - Gemini 3 Hackathon entry. Autonomous debugging tool using Deep Thinking models.

Plus 10 Side Projects: Court innovation tools, hackathon submissions, creative builds. Collapsible in the portfolio so it doesn't overwhelm the narrative.

How I Built It

Tech Stack:

React 19 + TypeScript (frontend)
Node.js + Express (backend)
Gemini 2.0 Flash API (case study generation)
GitHub API (live project metadata)
Docker + Google Cloud Run (deployment)

The Feature I Built For Myself: Dual-Mode Case Study Generator

When you finish a project, you need to explain it in completely different ways depending on your audience.

For a job application, you write:
"Led development of PDF extraction engine using Python and PyPDF2. Achieved 95% accuracy on academic document extraction. Selected as 1 of 100 fellows from 1,300 applicants. Delivered 2nd place finish on high-performing team."

For a personal blog, the same project becomes:
"My teammate Cai and I had 36 hours and an insane goal. We stayed up until 1am debugging a .env file that made no sense. But Friday morning it worked. Our team placed 2nd. Here's what we learned."

Same project. Completely different narratives. I was writing both versions and it was tedious.

So I built a tool: input your project details once, then generate either mode instantly.

Blog Post Mode produces a personal narrative (your thinking, decisions, learnings). Good for LinkedIn or your blog.

Professional Mode produces a professional case study (problem → solution → technical approach → results). Good for resumes and applications.

It's a prototype showing how AI can solve the context-switching problem developers face when marketing their work. Powered by Gemini 2.0 Flash because it's fast (under 2 seconds) and produces markdown I can actually use.

Other Design Decisions

Why Gemini 2.0 Flash? Speed matters for interactive UX. Quality output means I'm not editing markdown for 20 minutes after generation. The free tier covers a portfolio demo.

Why GitHub API integration? Live data (stars, language, forks) instead of static snapshots. Makes the portfolio feel current, not frozen.

Why Cloud Run? Meets the challenge requirement, free tier works great, and the embed feature makes it trivial to show working code.

Why this design language? Editorial style (not corporate) with intentional color psychology. Tech blue for foundation, innovation purple for sophistication, achievement gold for wins, energy cyan for interactivity. Every choice serves a purpose.

How fast? Built in ~12 hours using Antigravity (Google's AI development environment with a Chrome extension for real-time browser testing). The extension was the force multiplier—caught bugs instantly instead of the typical "let me check if this works" debugging cycle.

What I'm Most Proud Of

The case study generator — I built it because I needed it. It solves a real problem (context-switching between audiences when marketing your work). It actually generates usable output.

The GitHub integration — Project cards show live data. Not static info I typed in. Real stats that update.

The design system — Editorial, intentional, purposeful. The colors aren't random. The layout has hierarchy. The animations have reasons. Nothing decorative.

The timeline narrative — Six months of progression. Not a flat list of accomplishments. You can see the arc: first project → hackathon selection → hackathon win → new challenge.

It's shipped — Not a concept or demo. Live on Cloud Run, fully functional, judges can actually use the case study generator.

Stack & Links

Built with: React 19, TypeScript, Gemini 2.0 Flash, Google Cloud Run, Antigravity

Repository: github.com/earlgreyhot1701D/beyondthedocket (MIT License)

La Shara Cordero

Judicial Services Manager | AI Builder

LinkedIn | GitHub | Blog

Tags: #devchallenge #googleaichallenge #portfolio #gemini #dev