DEV Community: L. Cordero

A Builder in Paris: Do Devs Dream of Électrique Chats?

L. Cordero — Tue, 19 May 2026 21:48:59 +0000

Six days in Paris, one closed laptop, and a hackathon idea I did not mean to have.

It has been rainy and cold every day we've been here, and it couldn't be more perfect.

The rain seeps under your layers in a way that surprises you. Crowds thin out, everything looks clean, and Paris in the rain turns out to be romantic in a way I didn't expect to be true. We keep telling each other it feels like we're inside a movie scene, and that we cannot believe we are lucky enough to be here.

The weather is the funny part. We brought rain gear we did not use in Dublin in September 2024, and used it more in Paris than we ever did in Ireland. We did not bring enough warm layers, because we believed Paris in May would be warm. Two cities, two wrong predictions, both wrong in the right direction.

I came off a build sprint right before we left, finishing a demo for a buildclub.ai submission, which I do not need to tell anyone is one of my least favorite parts of shipping. Got on the plane, closed the laptop, and didn't look back. Today is May 19, which means six days off the laptop. No building, no brainstorming, no LLM conversations, just Instagram scrolling, checking NBA playoff scores, and taking more pictures than I will ever organize.

I didn't know I needed it until I had it.

On not building

Getting on the off-ramp was easier than I expected, partly because I let work go almost completely, and partly because for the first time in a long time I do not have another project deadline waiting for me when I land. I should also confess that I sprinted to finish work before I sprinted to the airport, twenty-two hours in two days to clear my desk, which is not my finest professional moment, but it did mean that when I closed the laptop, there was nothing pulling me back.

There was no cinematic moment where I felt the sprint end. It was more that I finished the task, looked up, and noticed that for once there was no next thing.

My brain did not go quietly into that good night, exactly. AI news kept showing up in my feeds. I saw something about the Elon versus Sam Altman lawsuit and chose not to read it, which is its own small victory. But I stopped reaching back for it.

On day three of our trip the email about The Coding Kitty hackathon landed in my inbox, and from there my mind started to wander on its own time. Another build percolating, ideas drifting in and out, wandering feet and a wandering mind. Different from building. Adjacent to it.

My wife said at one point that she appreciated my undivided attention, which is a generous way of pointing out that I usually have at least one hand on a qwerty keyboard. She was not wrong. I had not realized how much of my attention had been getting routed through a screen until the screen wasn't there.

On walking, reading, and thinking

The thing about being off a screen for six days is that you do not stop thinking. You just think differently. Walking does some of the work, reading does some of the work, and the rest happens in the spaces between the two, waiting at a crosswalk, sitting down for a coffee, the moment between closing the book and looking up.

I have been reading Dan Brown's The Secret of Secrets on this trip, which turns out to be apropos in a way I did not plan. The novel is about consciousness, whether it lives inside the brain or whether the brain is more like a receiver tuning into something larger.

Brown spends a fair amount of the book on the sheer scale of what is happening between our ears: three pounds of tissue, eighty-six billion neurons, more compute than any data center on earth. The book is not really about AI, but it is impossible to read it as a builder in 2026 and not feel the question hovering. We are pouring billions of dollars into making machines do something our own grey matter does on a baguette and a glass of vin rouge.

So I would read a chapter, close the book, and walk. Or I would walk, stop, and the book would surface. We have walked an absurd amount on this trip, nine miles in one day was the high water mark, and I cannot tell you which idea arrived during which walk, because that is not how it worked.

The walking, the reading, and my badly-broken attempts at French were all running together. I have been mashing English, Spanish, and bad French for six days, asking for the bathroom in the wrong language and apologizing in a third, and the not-quite-fluency turns out to be its own form of thinking. Nothing lands cleanly between those three linguistic worlds. Everything has to be reached for. The reaching is the part that wakes the brain up.

Somewhere in all that walking and reading, an idea for the next hackathon started to form. Not in a flash. More like terroir. The Coding Kitty email on day three was a vine. The Secret of Secrets was soil. Paris, with its rain and its walking and its borrowed languages and its closed laptop, was the weather that let it grow.

Le Click

Back to the hackathon email. I read it, registered that the theme was cat-related, and felt a small deflation. Cats are not my thing. I should have known a hackathon from Coding Kitty would lean feline, but somehow I had not put it together. I closed the email and assumed I was out.

A day or two later I mentioned it to my wife at the Musée de l'Orangerie, in the room with the Monets, because I was excited and could not help myself. She shushed me, lovingly. No AI in the water lilies. Fair. I shut up and went back to looking at the paintings.

Here is the thing about me and cats. I am not a cat person. I am allergic to cats. The cat we lived with came as part of the package when I married my wife. Her name was Penelope, and she was my wife's BFF and my long-running frenemy. It took her years to let me pet her, and even then I could barely touch her without my eyes swelling shut or a scratch on the hand. Ninety-nine problems and a cat named Penelope was one of them.

She passed in February. This is the first trip we have taken where we did not need a cat sitter. We are flying home to a meow-free house, and we both already know how loud that quiet is going to be.

So when the hackathon email said cats, I was not the obvious audience. But I had fourteen years of trying to figure out one specific cat, and somewhere between the Orangerie, and the AirBnB in the 6th, my brain started turning that into a problem statement.

Cats are inscrutable. The people who love them are obsessive about understanding them. There is almost no scientific consensus on cat behavior, even among researchers. And humans have a several-thousand-year-old framework for making the unknowable feel readable, which is astrology. Some of it or none of it is real. All of it is useful for naming a feeling. BFF? Frenemy?

By the time we got back to the apartment, my wife went to nap. I had an idea and I wanted to push on. I opened the laptop for the first time in six days and started talking to Claude.

We worked through it. A cat astrology app, but with the deterministic spine doing real work: birth chart math from real ephemeris data, daily nudges tied to actual kitty quirks, behavior logging as the input loop. The astrology is the vocabulary. The structure underneath it is the catnip.

The name landed in the conversation: Madame Minou. Madame for the fortuneteller persona reading the stars. Minou because it is the French diminutive for cat and it is warm. A little sister to Madame Steep, the persona I built last month for a fortune-telling app that reads tea leaves over your GitHub repo.

From the other room I heard my wife wake up. "Are you working?!"

Yes. Yes I am.

No regrets.

What this trip is teaching me

I went to Code with Claude in San Francisco on May 7th. (Ye-yo!) I closed my beloved laptop a few days later, after my buildclub.ai deadline on the 12th, and got on a plane. The London edition is tomorrow, May 20th, and I had a chance to go. I am not going. My wife is supportive, and the seat was mine to take. I chose Paris instead.

That choice is a quiet relief, actually. Since July of 2025 I have been building, shipping, submitting, winning, and showing up almost continuously, and there have been stretches where the work has felt louder than everything else.

Saying no to a Claude conference I genuinely wanted to attend, in order to walk around Paris with my wife in the rain, is the kind of choice I am glad I am still able to make.

But here is the part of the trip that is teaching me in more ways than one.

Building follows you. It is not always at a keyboard, in a terminal, or inside an LLM conversation. It is in your imagination, your wandering attention, your three-pound brain doing what no data center can do, which is to make connections you did not ask it to make. Six days off the laptop and my brain handed me a hackathon idea I had not been looking for, dedicated to a cat I never quite got to pet.

I closed the laptop in California. I opened the Chromebook in Paris. In between, I lived a life that was not about building, and the building happened anyway.

That is the part I want to remember. Building never stops, even when the laptop is shut. Sometimes especially when the laptop is shut.

In memory of Ms. Penelope Randall. May 2009 to February 17, 2026. Tuxedo. Frenemy. The reason this dev.to article exists.

AI assisted. Human approved. Powered by NLP.

Code with Claude Extended SF: Heck yeah and then wait, what?

L. Cordero — Sat, 09 May 2026 17:26:14 +0000

Heck yeah

I won a golden ticket to Code with Claude Extended (CCE) in San Francisco on May 7th.

The application said attendees would be selected by lottery. I won the CCE lotto. On April 9th, I got the email: "You're invited." Emphasis on Extended, because demand was so high that Anthropic added a second day.

The first day of Code with Claude was the "what's new" day. CCE was the "see it in the wild" day. Built for independent developers and early-stage founders. Founders stage. Builder stage. Workshops.

I was at work when I read the invitation. I had to stop and pause. Once I gathered myself, I couldn't hit the register button fast enough. I'd hate to see what my heart rate was. I wanted to participate so, so badly.

Heck yeah, I got in to CCE.

Let's gooooooooooo.

Wait, what?

Before any workshop started, Boris Cherny gave a talk. The line that hit me first: domain experts can now build their own tools for projects and ideas they have. Iterate, listen, ship. Claude Code launched in February 2025 with a small team, and here we were. Damn cool.

Then the first workshop started. How We Claude Code, with Thariq Shihipar. Room packed. People standing. Coopting seats. The wifi was sketchy from the demand.

The instructor, after a brief overview of the workshop, said "clone the repo and start."

Everyone around me started typing. The room kept moving.

I sat there with no frame of reference for what "clone the repo" meant in this workshop context. I'm an AI-assisted builder, not a traditional engineer, and I tend to need instructions to complete steps, not commands. Nobody had handed me the implicit instruction manual that everyone else seemed to have gotten somewhere along the way.

And me, sitting there at "clone the repo."

What I did about it

I opened Claude in my IDE and asked it to clone the repo. It did. Lol.

Then what? Was I supposed to update files? Run npm? Create a virtual environment? Insert an API key? It was opaque. An outside-looking-in moment.

So I started asking Claude the questions I actually had:

Can you explain in plain language what this repo is?

Can you explain in plain language what the use cases are?

Can you explain in plain language what the README is asking me to do?

(Sidebar: those workshop READMEs were fire. I figured that out later, once I had time to read them.)

As I went through it with Claude in my IDE, my first instinct was, I should build a tool for this. A web app for non-tech audiences who attend AI events trying so hard to keep up and then not quite getting there. Or maybe it's just me, and that's fair too.

I got distracted trying to design the tool. Started thinking about a PRD. Started thinking about cold start, how to market this problem, who the audience really was.

Then I went back to my Occam's razor philosophy. Maybe it's not a tool with a PRD and a marketing problem. Maybe it's a prompt. A prompt I build for myself and others that asks Claude to help clone the repo, look at it, really look at it for someone like me, and help parse what the heck it was and what the heck I was supposed to be doing.

So, no to tool. Yes to prompt.

I wrote one, Vidi Clew, https://github.com/earlgreyhot1701D/vidi-clew, with Opus 4.7's help of course. A prompt template I could paste into any fresh Claude conversation in my IDE with the repo open. It told Claude who I was (a plain-language person, AI-assisted builder), what kind of help I'd need, and how to communicate back to me (everyday words, no assumed prerequisites, explain and walk me through, don't preach).

That was the product. No website. No app. No install. A prompt and a way to remember it.

The prompt

Here it is. Open Claude Code in your IDE with the workshop repo, paste this as your first message, edit the parts in brackets to match your setup.

===
Hi Claude, you're going to be my workshop helper today. Here's how I need you to work with me.

WHO I AM
I'm a non-technical person attending a technical workshop. I don't have a CS or engineering background. I process the world in everyday language, not jargon. When I describe things, I'll use the words I have, not the words developers would use. Your job is to meet me where I am.

I'm using a [Windows / Mac] computer. (Edit this so Claude gives you the right step-by-step instructions.)

THE WORKSHOP
[Optional, fill in if you know, leave blank if you don't:]
- Workshop topic: _____
- Repo or materials: _____
- If I don't have these yet, I'll paste them to you partway through when the workshop hands them out. Just keep going from where we are, no need to restart.

WHAT I'LL ASK YOU
Mostly two kinds of questions:
1. "What am I looking at?" when code, files, terms, or windows appear on screen and I don't know what they are.
2. "What am I being asked to do?" when the instructor says something like "clone the repo" or "open a terminal" and I don't know what it means or how to do it.

If I'm so lost I can't even describe what I'm seeing, help me figure out how to ask the question.

HOW I NEED YOU TO ANSWER
1. Plain language, always. Use everyday words. If a technical term is unavoidable, define it in the same sentence ("Vite, that's the tool that runs the website on your computer").
2. Meet me with the words I have. Don't ask me to use the right technical term. Translate my fuzzy description.
3. Assume nothing. Don't say "first, install X" or "open your terminal" without explaining what that means and how to do it on my computer.
4. Explain AND walk me through. When I'm asked to do something, tell me what it means AND give me concrete step-by-step instructions for my computer.
5. Keep me in the room. Quick rescues, not deep lessons. The goal is to get me back to following the workshop, not to teach me everything from scratch.
6. Wait for me to ask. Don't preach or volunteer extra information I didn't ask for.
7. Friendly but not patronizing. I'm not stupid. I just haven't been taught this stuff. Treat me like a smart adult who's missing context.
8. When you ask me a question, give me concrete examples I can choose from. Don't ask open-ended ones if you can ask multiple-choice. "What's on your screen?" is hard. "Is it a black window with text (that's a terminal), a code editor like VS Code, a web browser, or the instructor's slides?" is easy, I just pick the closest one. Plain-language people answer faster when there's a list to pattern-match against. Apply this to every question, not just the first one.
9. Anchor explanations in USE CASES, not just descriptions. When you explain a repo, a tool, a file, or a concept, don't just tell me what it IS, tell me what it's FOR, with a real-world example. "This repo uses Vite and React" is almost meaningless to me. "This looks like the start of a small to-do list app, the kind of thing where you type a task, hit add, and watch it show up in a list. By the end of the workshop you'd have something you could open in a browser." Now I'm oriented. Same for individual pieces: "package.json" isn't "a manifest file declaring dependencies," it's "a list of ingredients this project needs to run, like a recipe." A rundown without use cases leaves me with facts but no picture. Always paint the picture.

START HERE, DON'T JUST SAY "READY"
When I send this message, kick things off by asking me 2 to 3 short orienting questions in plain language, so I have somewhere to start. Always include concrete example answers so I can pattern-match instead of generating from scratch.

Good questions, written the right way:
- "What is the workshop about? Even one sentence, in your own words, like 'AI', 'building websites', or 'honestly, not sure yet'."
- "Has the workshop started yet, or are you still waiting for it to begin?"
- "What's on your screen right now? For example: a black window with text (that's a terminal), a code editor like VS Code, a web browser on a Claude page, the instructor's slides, or something else?"
- "Did the workshop share any links, files, or instructions yet? If so, paste them in. If not, that's fine."

Pick 2 or 3 of these, ask them with the example answers attached, and wait for my responses. Once we're oriented, settle into "wait for me to ask" mode for the rest of the conversation, but keep applying principle 8: every question you ask later should still come with concrete example answers.
===

Testing it the same day

The next workshop was Ship Your First Managed Agent.

I opened Claude Code in my IDE with the workshop repo, pasted my prompt as the first message, and went from there. When the instructor said something I didn't understand, I asked Claude in plain language and got a plain-language answer back. The workshop kept moving. I kept moving with it.

I made it to step one of deploying the agent. Then step two. Then I shipped a working agent. Thirty-four lines of code. The agent could read a 70,000-line log file, call functions on my laptop for live data, and name the specific code commit that caused a fictional outage.

In the same workshop, someone next to me got stuck. They asked if I could help. I helped them.

Three hours earlier I'd been worried I was too slow to follow along. Now I was the one helping someone else through the same kind of moment I'd just gotten through myself.

I had a gay old time.

That's how I know the prompt worked for me and changed my day.

The version you see above is already a couple iterations in. After using it, I noticed Claude needed two extra rules to land right for plain-language people: give me multiple-choice options when you ask me questions (open-ended is hard when you're already overwhelmed), and explain things by what they're FOR, not just what they ARE. Both got folded in. The prompt is a living document and I'll keep adjusting it as I find rough edges.

What this is for

The prompt isn't fancy. It's a few paragraphs of plain English telling Claude how to be helpful to a plain-language person in a technical room. You can copy it, open Claude Code in your IDE with the workshop repo, and use it at the start of any workshop you walk into. (It adapts to other AI-in-IDE tools with small edits, see the README for notes.)

It's available in a public repo so anyone can grab it: https://github.com/earlgreyhot1701D/vidi-clew. The official Code with Claude workshop materials are also public, here: https://github.com/anthropics/cwc-workshops. You can walk through them yourself if you want to try the kind of workshops I was in.

If you're a plain-language person who's been told "AI is coming for your job" and has no idea what that means, this prompt is for you. If you've ever sat in a technical room and felt the instructor leave you behind at "clone the repo," this prompt is for you. If you've watched everyone else start typing and didn't know what they were typing or why, this prompt is for you.

It's a small tool. It worked for me three times in one day. I can't say it'll work for everyone. I can say what I saw, which is that an AI-assisted builder walked into a workshop, got stuck, wrote a prompt, used the prompt to follow along, used the prompt to deploy a working agent, and used the prompt to help someone else.

Who I am, for context

By the time I walked into Code with Claude Extended I'd been using LLMs since 2023. The last six months I'd invested heavily in Claude, for Claude Code, for Claude.ai chats, across work, home, travel, and what I'd been calling my AI learning road.

That road has been mistake-making, learning, and somehow winning hackathons as an AI-assisted builder. My first solo hackathon win in November 2025 was Janus Clew, a dev tool that measures a builder's growth over time. That was the start. Since then I've built sillier things too, like Steep, a deeply unserious repo I shipped for Dev.to's April Fools challenge. Plug in your GitHub repo and Madame Steep reads your repo's fortune through tea leaves.

So Claude and I run in parallel. That's the description of where I am right now. In six months I might be sprinting alongside another tool. Today, this is the setup.

That's the context I walked in with. And I still got stuck at "clone the repo."

That's why I think this prompt was one of the best outputs of my entire day. From what I've seen, the gap doesn't always close just because you've been at it a while. The gap closes when you have something in your pocket that translates the room for you.

This was mine.

For you, if you want it.

Vidi Clew (the prompt): https://github.com/earlgreyhot1701D/vidi-clew

Workshop materials: https://github.com/anthropics/cwc-workshops

AI-assisted, human approved. Powered by NLP.

Build Club Week Two: The PRD doesn't catch everything

L. Cordero — Sun, 03 May 2026 19:19:31 +0000

Last week I posted that I had no code, just the work that makes the code possible. The PRD, the prompt spec, the architecture doc, the build brief for Kiro. I went into this week thinking I had every decision pre-made.

Then I started building.

By Block 2, real testing surfaced a phrase the model was using that no court employee would say. "Strip identifiers" sounds reasonable to a developer. To a court clerk it sounds like nothing, opaque and technical, the kind of thing you'd skip past in a training. Not a bug, exactly. Not in the PRD either. But noticeable.

By Block 3, I was flagging contrast questions, helper text microcopy, a disabled state that needed verifying. None of these were in the original scope. None of them were stop-the-build issues. All of them were real.

By Block 4, I was holding a list of polish items in my head while running an active build. Around 11pm I asked Claude how it was tracking everything. The answer was honest: it wasn't, in any reliable way. That was exactly the kind of "I'll remember it" trust I'd called out as a problem in my own build brief, and I'd let it creep in anyway.

So I started a punchlist.

The punchlist isn't the PRD. The PRD says what to build. The punchlist captures what surfaces when you actually build it. They have different jobs and they need to live in different documents.

Mine grew to 14 polish items, 8 things to defer to v2, 4 cleanups for before deployment, and 4 lessons-learned entries by the end of the week. Some of it was scope creep waiting to happen, the kind of "we should add this, it's only an hour" thinking that turns four-week builds into eight-week builds. Some of it was real bugs the PRD couldn't have predicted because I hadn't shipped enough of the thing yet to find them. Some of it was language I knew was wrong the moment I read it back to myself in the voice of an actual court employee.

The thing I'd do differently next time is start the punchlist on day one, alongside the PRD. Not as a section of the PRD because they have different jobs, but as a sibling document, ready and waiting. Treating the empty punchlist as a feature instead of a placeholder.

What the punchlist taught me is that the PRD locks scope and the punchlist holds everything the PRD couldn't see yet. Both are needed. The discipline isn't writing a perfect PRD, it's knowing which document a thought belongs in and putting it there immediately instead of trusting yourself to remember.

Week three is polish and deployment. The punchlist is the running list. Loading state experience for the latency. Brand banner in the PDF. Mobile responsiveness. Then AWS Amplify deployment to a live URL.

Building alongside Build Club in the Women in AI Accelerator. Tagging Annie Liao and Caroline Ciaramitaro who run a thoughtful, generous community.

I always worried my READMEs disagreed with my own repos. So I built README Clew.

L. Cordero — Sun, 03 May 2026 01:48:40 +0000

I write a lot of READMEs. I ship faster than I document. I work with AI agents that write code in seconds and READMEs in minutes, and somewhere between the first commit and the third refactor, the README I wrote on Tuesday stops matching the code I wrote on Friday.

The install command says npm start. The package.json defines start:prod. Anyone copying that command would have failed instantly. I'd never know.

This weekend, for the Replit 10 Year Buildathon, I built README Clew — a tool that audits your own GitHub repo for drift between what your README claims and what your code actually does.

Findings only. No rewrites. No grading. Nothing saved.

README Deployed Try it →
Github Repo GitHub →

How it works

Paste a public GitHub repo URL. README Clew:

Fetches your README, your package.json, and a slice of your file tree
Uses Claude Sonnet 4.5 to extract every checkable claim from the README
Runs five deterministic verifiers against the actual code
Returns findings in four buckets

The five categories I check:

Declared dependencies — does your README say "uses X" but X is not in package.json?
Code-vs-package coverage — does your code import packages your README never mentions?
Install and run commands — does npm start actually exist as a script?
Environment variables — does your code read env vars your README forgot to document?
File and link references — do the files and URLs your README points to actually resolve?

The four buckets, in display order:

Verified — README matches the code (the receipts)
Unverifiable — claims like "blazingly fast" or "85 passing tests" that are valid but not statically checkable (the honest limit)
Missing — code does things the README never mentions (the gaps)
Contradicted — README and code disagree (the drift)

Features

(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jprc7a5ffhpjdr4h4w1f.png)

I shipped more than I planned to:

Deep-link URLs — every scan has a shareable ?repo= query param. Paste it anywhere, the scan runs on load.
OpenGraph cards — when you share a scan link on social, the preview card includes the bucket counts and the synthesis line. The card itself summarizes the audit.
SVG status badge — /api/badge?owner=...&repo=... returns an SVG you can paste into any README. Like a CI status badge but for documentation honesty.
In-memory cache — the 50 most recent scans power fast OG cards and badges without re-scanning.
Copy link — one-click copy of the current scan URL.
Share anywhere — direct buttons for X, LinkedIn, Instagram, and Dev.to from the results page.
JSON export — full scan result as JSON for automation, archiving, or piping into your own tooling.
Scan this repo — pre-fills the URL bar with the repo you're viewing so you can re-scan instantly.
Two-frontend architecture — Vite-built static frontend served separately from the Express API. Scales independently.

The badge is my favorite. Audit your own receipts, then embed your status in the receipt itself.

What it doesn't do (limitations are a feature)

Doesn't rewrite your README. You see the drift, you fix it.
Doesn't grade your writing. Subjective claims aren't bad — they're just unverifiable.
Doesn't store anything. Stateless. Run it. Close the tab. The findings are yours.
Doesn't analyze private repos in v1. Public only.
JavaScript and TypeScript only in v1. Python and Go later.

I ran it on my own repos

The findings stung in good ways.

On Memoria Clew (4th of 250 in the AI Vibe Coding hackathon, February): twenty undocumented items in my package.json — dependencies my code uses, scripts I'd added, env vars I'd never written down. One actual contradiction in the README too.

On petit-mot: 16 of 21 claims verified. All file references resolve. 5 unverifiable because the project has no package.json — deployment commands fall outside what static analysis can check.

On README Clew itself: zero contradictions, but seventeen things I'd shipped without documenting. The tool found drift in its own creator's documentation. That's the point.

How to trust it

The tool is intentionally narrow. Five deterministic verifiers run on actual code. One Claude API call extracts claims from your README. The system prompt instructs Claude to use only verbatim quotes from the README — not paraphrase, not invent. That's a prompt-level guardrail, not a post-processing validation step. Honest distinction worth making.

Every finding shows you the README quote and the code reference. Don't trust the verdict, trust the receipts. You can always click through and verify yourself.

Known limitations I'm honest about:

The verbatim-quote rule is enforced by prompt instruction, not by code that validates the quote against the README source. In practice Claude follows the rule; in principle this is a soft guardrail, not a hard one.
Prose labels in dependency claims produce false positives in the contradicted bucket (Claude sometimes pulls "Frontend (Vite)" as a package name; v2 fix)
Monorepo support is conventional-path-only — packages/, apps/, server/, frontend/, client/, backend/, api/, web/. Custom paths won't be discovered.
Source file scan caps at 20 files for envvar checking
Two Claude calls per scan (extraction plus a short synthesis pass), adding 10–20s. The synthesis is fail-open: if it errors or times out, you still get full findings.

The transparency is the trust.

Stack

Node.js + Express 5, TypeScript, esbuild
Vanilla HTML/CSS/JS frontend (no framework)
Claude Sonnet 4.5 for claim extraction and synthesis
GitHub REST API for repo data
Hosted on Replit Deployments
50-entry in-memory scan cache (no database)

Hybrid architecture: deterministic where it matters, AI where it adds value. The AI's role is narrowly scoped to extraction and synthesis, never to the verification itself. Five verifiers, one orchestrator, one extraction call, one optional summarization call. That's the whole pipeline.

Security posture

Building anything that takes user input and calls external APIs needs to take the threat model seriously, even at hackathon scale.

Prompt injection protection on every LLM call: README content wrapped in <readme> delimiters, system prompt explicitly instructs the model to treat input as data not commands. Tested with IGNORE ALL PREVIOUS INSTRUCTIONS injection — extraction correctly ignored the injection and returned only the legitimate express claim.
Strict input validation at the server boundary. GitHub URL must match github.com/owner/repo exactly. No SQL surface (no DB), no command injection surface (no shell), no path traversal.
Rate limiting at 10 scans/hour per IP. Reads X-Forwarded-For correctly behind Replit's proxy.
API keys server-side only via process.env. Zero references to process.env in any frontend file.
XSS-safe DOM rendering throughout. All user-supplied data inserted via .textContent, never .innerHTML. Explicitly commented in the code.
Hard timeouts: 60 seconds on the full scan, 9 seconds on the optional synthesis call. README content truncated at 50KB before sending to Claude. File scan capped at 20 files.
Logging captures no PII or repo content — request ID, method, URL path (without query params), status code, response time. Nothing else.
Helmet middleware for security headers (CSP, HSTS, X-Content-Type-Options, X-Frame-Options).
Body size limit of 4kb on POST requests.
Fail-open architecture: if the optional synthesis call fails, the scan still completes and returns findings. The user gets data even when non-essential calls degrade.

Not production-hardened (no auth, no audit log, intentional). Solid for a public stateless tool.

Try it

🔗 readme-clew--earlgreyhot.replit.app
📦 github.com/earlgreyhot1701D/readme-clew
🎂 Built for the Replit 10 Year Buildathon

For further README inspo check out https://dev.to/georgekobaidze/15-essential-sections-every-readme-needs-give-your-project-what-it-deserves-fie

Run it on one of your own repos. Tell me what it finds.

Apache 2.0 licensed.

AI assisted. Human approved. Powered by NLP.

Week one: no code, just the work that makes the code possible

L. Cordero — Sat, 25 Apr 2026 19:42:36 +0000

The policy memo said "use AI responsibly." I'm building what comes next.

I work in a courthouse. Nine years in, three roles deep, and I still get asked questions every week that boil down to the same thing: "is it okay if I use AI for this?" The honest answer is "I don't know, and neither does anyone in this building, and the policy memo doesn't help." That's the problem I'm building around for the next four weeks.

Themis Lex is a tool that takes a court employee's role, their workflow, and how sensitive their data is, and tries to tell them where AI can actually help and where it should never go. Not generic advice. Role-specific guidance that knows the difference between a Judicial Assistant at the front counter and a courtroom clerk taking official minutes. The output is a PDF you can hand to your supervisor.

I'm building it as part of the Build Club Women in AI Accelerator, four weeks alongside 150+ women builders from around the world, organized by Annie Liao and Caroline Ciaramitaro. Week one is the part where you don't write any code. I wrote a PRD, a prompt spec, an architecture doc, and a build brief for Kiro. I confirmed the public job description PDFs I'm grounding the tool in have clean text layers. I scoped what's in v1 and what's not. I picked a model. None of it was glamorous. All of it was necessary.

What I'm excited about is that I get to build for the people I work with. I'm not a trained engineer. I'm self-taught, and I started this kind of work in July with no idea what I was doing. The fact that I can sit down on a Saturday and direct an AI coding agent through a build like this is something I would not have believed nine months ago. That's the part that keeps me at the keyboard at 11pm on a school night.

Week two starts on Monday. The build officially begins. I'll post again when there's something to show.

Building alongside Build Club in the Women in AI Accelerator. Tagging Annie Liao and Caroline Ciaramitaro who run a thoughtful, generous community.

WomenInAI #BuildClub #WomenWhoCode #AI

Pourquoi Pas? I Built a Petit French Learning App in a Weekend

L. Cordero — Sun, 12 Apr 2026 18:49:19 +0000

I have a million things to do this weekend but instead of doing them I built le petit mot instead. Le Petit Mot (the little word) is a tiny, static, Art Nouveau-themed French learning app. Flashcards, stories, and a daily audio journal, all set in Paris. No backend. No AI in production. Just words.

And why? Well:

Why not?
I didn't want to get wrapped up into any other online learning ecosystems.
I wanted something designed specifically for my trip.
Did I research formal language learning methodology? Not even a little bit. Not one paper. Not one blog post. I just thought about how I'd want to learn and built that.
I have Kiro credits burning a hole in my pocket that expire in a few weeks.

What else is a girl supposed to do?

The situation

I'm leaving for Paris in 30 days. First time. I don't speak French. I can say "croissant" but so can everyone. I needed to learn enough to order food, ride the Métro, ask where things are, and not look completely lost in the arrondissements, hopefully.

I thought about Duolingo. I thought about Babbel. I thought about a dozen apps. Then I thought... why hand my learning over to someone else's ecosystem when I could just build what I need?

The UI is a little rough. I know. I wanted something that stood up quickly, not something that won a design award. Function over polish. For now.

What I actually built

Le Petit Mot is a mobile-first web app that teaches basic Parisian French through daily flashcards, story read-alongs, and a narrated audio journal. Every word and story maps to a real scenario I'll encounter in Paris.

The target reading level is a 5-year-old. I'm not trying to read Camus. I'm trying to order a café crème without panicking.

30 days. 5 new words per day. A short story using those words. And a "petit journal de Paris" that narrates a fictional diary of someone's first month in Paris, getting a little more comfortable each day.

The app itself is vanilla HTML, CSS, and JavaScript. No framework, no build step, no backend. All the content lives in a single static JavaScript file. I used Kiro credits for the spec-driven development and Claude for architecture and creative direction, but the thing that ships to your browser has zero AI in it. It's just a webpage serving words.

You can look at all of it: the repo is public.

The design rabbit hole

I wanted it to feel Parisian. I had Art Nouveau Metro entrances and Madeleine storybook illustrations in my head. What I got was simpler than that. But the sage green palette and the ironwork SVGs give it enough personality to not feel like a generic flashcard app.

I went through... let me count... five versions of the ornamental SVG components alone. The first Eiffel Tower looked like a Christmas tree. The iron arch looked like a McDonald's logo with earrings. The divider was a corporate timeline.

I uploaded photos of actual Metro entrances and the Madeleine book cover as design references. The final palette is called "Absinthe Garden": sage green, warm ochre, dusty rose, and Parisian cream. Every color has exactly one job. Green is structure. Ochre is warmth. Rose is "look here." No color does two things.

The Eiffel Tower is a line drawing with curved legs. It took four tries to not look like a tent.

The build process (or: how scope discipline saved my life)

I've been burned enough times by scope creep and mid-project chaos that I've picked up some habits. They're not documented anywhere formal (bad build discipline, I know, I know). But they kept this build from going sideways:

Single PRD, one source of truth. Before I wrote a line of code, I had a 13-section PRD with MUST/STUB/NEVER labels on every feature. If it says NEVER, it's never. No dark mode. No gamification. No grammar drills. No backend.

One file, one responsibility. The app has 10 JS files. audio.js speaks French. progress.js tracks completion. ornaments.js draws Art Nouveau SVGs. curriculum.js holds all the content.

Mock data first, then wire real data. I built the entire UI with Day 1 hardcoded content before generating the other 29 days.

STUB, don't build. If a feature wasn't happening tonight, it got a comment stub with implementation notes. Not a half-built skeleton. Not an empty function. A comment that tells future-me exactly how to pick it up.

I used Kiro as my IDE and it turned my PRD into requirements, design docs, and implementation tasks through its spec-driven development flow. I also set up four agent hooks, and honestly, they were a trip:

Scope guard: fires before every file write and checks if I'm touching code from an earlier build block. If I am, it blocks the write. This thing was strict. Like, won't-let-you-fix-a-typo-in-the-wrong-file strict.
QA checkpoint: fires after the agent finishes any task and forces it to list specific things I should verify in the browser before moving on. "It works" is not a passing check. "Tap the Commencer button, verify it navigates to calendar view" is.
Security scan: fires on every JS file save and checks for innerHTML with dynamic content, eval(), or hardcoded API keys.
Single responsibility: fires on every JS file save and checks if the file is doing more than one job.

The hooks slowed me down. They really did. Every file save triggered checks. Every task completion triggered a QA list. But they also kept me from veering off the road, which is my biggest weakness on sprint builds. I'd start fixing a color in the ornaments file while I was supposed to be building the flashcard view, and the scope guard would go "nope." Annoying in the moment. Correct every time.

Fair warning though: those hooks cost Kiro credits every time they fire. I burned 13 credits on a CSS-only visual audit because every file write triggered the scope guard and QA hooks. For polish passes, turn them off. Lesson learned.

The whole app was built in one sprint session. Six blocks, each with pass/fail QA criteria I had to check in the browser before moving on.

The "deterministic vs AI" question

So this was new for me. The app has zero AI in production. None. All 30 days of vocabulary, stories, and journals are hardcoded in a static JavaScript file.

I used Claude to help generate the curriculum content and Kiro credits for the development workflow. But the content was validated, edited by me, and committed as plain data. The deployed app is just HTML serving static words.

I'm not going to claim this approach is better than using AI in production. But for this project, for this use case, it works. There's no API latency. No cost per user. No rate limiting. You open it, it works, every time. That felt right for something I want to practice with before the trip.

The question I kept asking myself: did I make this too "dumb"? No AI-powered adaptive learning. No spaced repetition algorithm. No speech recognition to check your pronunciation. No research into second language acquisition theory. I didn't read a single paper on how people actually learn languages. I just thought: flashcards, stories, repetition, context. That's how kids learn. That's how I'll learn.

And something funny happened while I was testing. I actually learned the words. I was debugging the flashcard flip animation and realized I could say "excusez-moi, où est la sortie?" without looking at the screen. My wife says my French accent is good (she might be being nice but I'll take it). Turns out the simplicity might actually be the feature. A 5-year-old doesn't need an algorithm. They need repetition and context.

What surprised me

How fast it came together. The core app was functional in one evening. The content generation (all 30 days of words, stories, and journals) took longer than the code.

How many French words I learned while testing. I was debugging the flashcard flip animation and accidentally memorized all the greetings. QA as education. I didn't plan this. It just happened.

The Kiro hooks. Wow. I set up four of them thinking they'd be helpful guardrails. They were more like a strict project manager who doesn't care about your feelings. The scope guard blocked me from touching files outside my current build block. The QA checkpoint refused to let me move forward without browser verification. They slowed me down and kept me honest. I'm keeping them for every future project (but turning them off for CSS tweaks next time).

That the audio almost didn't work on mobile. Web Speech API on mobile browsers requires a "user gesture unlock." Your first speechSynthesis.speak() call has to happen during a tap event, or the browser silently blocks all future audio. My unlock pattern used an empty string, which iOS Safari treated as a no-op. The fix was changing '' to '.'. One character. Hours of debugging.

That my wife likes my French accent. Unrelated to the build but arguably the most important outcome.

The journal narrative

The part I'm most proud of is the daily journal. It's not just vocabulary practice. It tells a story across 30 days.

Day 1: "Je suis à Paris. Je suis vraiment à Paris!" (I'm in Paris. I'm really in Paris!)

Day 7: "Aujourd'hui, je marche sans carte." (Today, I walk without a map.)

Day 16: "Quelqu'un m'a demandé son chemin. J'ai donné des directions. En français." (Someone asked me for directions. I gave directions. In French.)

Day 27: "Je me sens bien à Paris." (I feel good in Paris.)

Day 30: "Merci, Paris. Merci pour tout. Pour toujours." (Thank you, Paris. Thank you for everything. Forever.)

By Day 30 you've followed someone from "please, Paris, be gentle with me" to "I can order food, take the Métro, and buy cheese without pointing." Same simple vocabulary the whole way through. The words don't get harder. The person gets a little braver each day. Like a kid figuring out their neighborhood.

The stack

Vanilla HTML / CSS / JS (no framework, no build step)
Web Speech API for French audio (fr-FR, rate 0.7)
localStorage for progress tracking
Vercel free tier for hosting
Google Fonts (Playfair Display + Nunito)
SVG Art Nouveau ornaments (hand-coded, not generated)
Kiro IDE + Kiro credits for spec-driven development and agent hooks
Claude for architecture, creative direction, and content generation

Total runtime cost: $0.
Total API calls in production: 0.
Kiro credits used: more than I expected, less than I feared.

Would I recommend building your own learning app?

If you have a specific thing you need to learn for a specific reason, and existing tools feel like overkill or too generic? Yeah, build your own thing. It doesn't have to be fancy. It doesn't have to use AI. It just has to teach you what you need to know.

Le Petit Mot won't make me fluent. But in 30 days, I'll be able to walk into a Parisian café, order a croissant and a café crème, understand when someone says "à gauche" instead of "à droite," and maybe, if the fromager is patient, buy a piece of Comté without pointing.

For a first trip to Paris, that feels like enough. Like a little kid who knows enough words to get by. Which is exactly what I was going for.

À bientôt, Paris. Je suis presque prête.

(See you soon, Paris. I'm almost ready.)

le petit mot | GitHub

AI assisted. Human approved. Powered by NLP.

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)**