DEV Community: L. Cordero

An Instagram ad promised me a free AI course. Was it a scam?

L. Cordero — Sun, 07 Jun 2026 16:50:44 +0000

A free AI course promoted by Instagram? I almost scrolled right past it.

The algorithm dropped it in my feed, and my instinct was the one I've built up over years of dodging nonsense online. Is this real, or is someone about to take my information?

Then I read the pitch. A free, one-week AI literacy course for any "American worker," taught entirely over text. "No laptop or internet needed. Just your phone." Well. I'm an American worker, I want to learn about AI, and free is very much my price point. Real or fake, I clicked anyway.

So what is it?

It's an initiative called AI Ready from the U.S. Department of Labor, and the lessons call themselves your AI 101 course. One week, ten minutes a day, delivered entirely by text message. You text READY to 20202 and it runs like a text thread with a patient teacher. A short lesson arrives, it asks you a question, you reply, and the next piece comes back. That's the whole setup. No app to download, no account to build, no laptop required.

My skeptic still wasn't satisfied. Why is the DOL handing this out for free? Why hadn't I seen a single piece of media about it? I went digging before I trusted it. It checked out, so I signed up.

A quick note for my dev.to fam outside the US

Some of you are reading from outside the US, and I want to flag this early. Enrollment runs through a US text number, so this program may only work inside the US. I haven't tested it on an international phone, so it's worth checking out. Even if it isn't available where you are, you might know someone it would reach, and a free, text-only on-ramp is a model worth seeing wherever you build.

What won me over

The first lesson landed while I was at work. A gif popped up on my screen, which is a fun way to get someone's attention, and I'll admit it worked.

The format takes the pressure off. Instead of a blank box waiting for you to know what to say, you answer with A, B, or C. Go quiet for a few hours and it sends a gentle nudge to check in. And when my first scheduled time didn't work, I used the chat to reschedule. Small thing, but it told me someone designed this with the user in mind.

The lessons themselves are short and easy to follow. Bite-size, not overwhelming, which is the part I think a beginner would appreciate most. And the topics are useful right off the bat. Lesson 4 was "the recipe for a great prompt." Lesson 5 was "put AI to work for you." Useful, not abstract. Somewhere in the week I stopped being suspicious and started being impressed.

The last message doesn't just say goodbye. It hands you links to keep going, with starter courses from AWS, OpenAI, and Microsoft, plus a career explorer. That part may matter to new learners to keep the momentum going.

What it isn't

There's a ceiling here. One week at ten minutes a day will not make anyone an AI practitioner, and it won't replace building something with your own hands. It's a door, not a destination. The goal is to get someone through the door without scaring them off, and for that it works.

It also runs through a third-party platform called Arist, and the course tells you your number is used only for the course and not sold. I always check the privacy language before I sign up, and this one names it plainly. I'd tell a family member the same thing.

Pass it on

So here's why I'm sharing a beginner course with a room full of builders.

Through your wonderful articles, I've learned that in our community most of us here are past the beginner stage. We're building, shipping, breaking things, writing about it. We may not be the audience for a ten-minute intro course. But every one of us knows someone who is. A parent, a cousin, a coworker who keeps saying they're "behind on AI" and feels it every time they open their phone.

There's so much noise pointed at people right now. Paid bootcamps, breathless ads, the steady message that they've already missed the train. A free course that lives in their text messages and asks for ten minutes a day is about the least intimidating on-ramp I've seen so far.

I think part of this work, that we're all trying to do, is reaching back and bringing someone with us. Sharing the free thing. Lowering the barrier for the person who hasn't started. This is an easy one to pass along.

If that person is in the US, tell them to text READY to 20202, or send them to arist.link/aiready.

I was impressed. I think they will be too.

AI assisted. Human approved. Powered by NLP.

My website has two audiences now. I only built for one of them.

L. Cordero — Sun, 31 May 2026 00:32:22 +0000

The conversation about who reads your website has been shifting. Agents are part of it now. ChatGPT fetches URLs. Perplexity reads content. Shopping agents try to complete purchases. Coding agents hit your API. Most of those products were built for humans, tested against humans. The agents showed up later and quietly. When they can't figure something out, they don't complain. They just bounce.

I heard the phrase "second audience" at a hackathon where you.com was one of the hosts. It stuck. That's what agents are: a second audience the web wasn't designed for and isn't being measured against.

And now, I want to build something about it. A scanner that tells you what an AI agent experiences when it tries to use your website or your API. The internal name is Perseus Clew and the public product is Agentis Lux. The split is intentional: Perseus Clew is the engine name, part of a suite of AI builder tools, and Agentis Lux is the product-facing name (Latin for "light of the agent") that describes what agent users see.

This isn't a launch post. I just finished a docs phase, and I'm about to write code. Before I do, I want to put this in front of dev.to builders and find out what I'm missing.

What it will do

Three layers:

Deterministic scanning. Twelve check categories — six for frontends, six for APIs — looking at HTML, ARIA, structured data, OpenAPI specs, error responses, idempotency patterns. Same input, same score, every time. The methodology will be published, the weights will be public, and anyone can audit it. AI-readiness scoring tools have a reputation for inflating numbers and hiding their methodology, so the trust floor is making everything inspectable. That's the foundation the rest sits on.

An AI-written verdict. After the score, a Bedrock call reads the top findings and writes one sentence about what an agent experiences. Something like: "An agent visiting this page can read your product descriptions, but can't tell which button starts checkout, so it can't finish a purchase on its own." That sentence is what a human reads first. The number is the proof underneath it.

An agent simulation. Bedrock runs structured tasks against the scanned content and reports back: here's what an agent could do, here's what it couldn't. Turns findings into a story instead of a spreadsheet.

The score is deterministic. The explanation is AI-generated and labeled as such, and the simulation is the narrative layer on top. Each layer earns its role: math where consistency is important, AI where judgment helps, simulation where you need to know whether an agent can complete a real task.

What it will look like

Here's the result view — mock data, real design. The locked palette is Lance Wyman-inspired: cream, deep teal, sienna. Typography pairs Archivo Black with Instrument Serif italic for the AI line. Score on the left as one unit.

The "AI written" tag is intentional. I want a reader to be able to see which part came from a model and which came from math.

Why B2B

Free anonymous scan is the front door. The value is the signed-in tier: track your score over time, see your delta after you ship changes, eventually run it in CI so every PR goes through Agentis Lux before merge.

I'm entered in the H0 hackathon B2B track (deadline June 29) — submission at h01.devpost.com if you want to follow along.

Stack

Next.js on Vercel. API routes handle scan initiation and direct DynamoDB reads. AWS Lambda for the scan engine. Bedrock for the AI pieces. DynamoDB for benchmark data, plus ephemeral 24-hour TTL results so shareable links work. EventBridge for monthly benchmark refresh. CDK in TypeScript for the AWS side. Docker so it all runs locally.

Two DynamoDB tables by design: a 15-minute URL-hash cache so I'm not hammering target sites, and a 24-hour opaque-id result store for shareable links. Different keys, different lifetimes, different purposes. I went back and forth on merging them. The lifetimes don't match, so separate won.

Built with Kiro.

Where I'm uncertain — and what I'd love help with

Three things I don't know:

Is the auth stub the right scope, or am I shipping too much, or too little? I'm building auth (email magic link), a user table populated on sign-up, and a scan history view that renders with an empty state, but no trend charts and no score-over-time. That sits in the middle of two clean alternatives. Smaller version: skip auth entirely, generate a per-scan email link for retrieval. Bigger version: if I'm shipping auth, ship the trend chart too because that's the actual recurring value. I picked the middle because I think it answers "who cares about one scan" without pulling trend tracking into the MVP.
Would you pay to track your score over time? Anonymous one-shot scans are easy. Recurring value is the business question. Be honest: do you, personally, building what you're building, care enough about agent-readiness to want trend tracking?
Findings only, no fix suggestions. Right now the product surfaces what agents see — "an agent can't tell your button is a button" — but doesn't tell you what to do about it, because that would mean knowing your codebase. I think this is a feature for builders who want visibility without being told how to fix it. It could also be the thing that makes a frustrated user close the tab. Which is it?

What's next

Block 0 starts this week. First end-to-end deploy: Next.js on Vercel, scan Lambda on AWS, the result hero rendering from mock data, the DynamoDB write seam stubbed in. I'll post again when the first real scan runs against a real URL.

If you're building something adjacent, or you have opinions about agent-readiness as a category, I want to hear from you.

AI assisted. Human approved. Powered by NLP.

Created for the H0 Hackathon. #H0Hackathon

I Built a Hermes Agent to Tell Me Which Hackathons to Enter. It Told Me to Enter This One.

L. Cordero — Sun, 24 May 2026 20:24:30 +0000

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

What I Built

I started AI-assisted building in July 2025. Self-taught, learning as I go. Hackathons and challenges turned out to be a big part of how I got better, structured lessons to build something inside a deadline, and the DEV challenge feed became one of my regular places to look.

But the more I leaned on it, the more I kept hitting the same question: how do I decide which challenge to enter? It is not trivial. Entering the wrong one costs days I do not get back. And you cannot always tell from a challenge page alone whether it fits the stack, tools or style I build with, whether there is enough runway left, or whether the learning is worth the hours. The feed does not sort itself by worth it. So you either check it obsessively, miss things, or enter on a hunch and hope for the best.

Vigil Crest is the filter I wanted. It is a challenge triage agent I talk to on Telegram. I message it, it browses the live challenge feed, and it sends back a verdict on each active challenge. For every one it gives me four short fit lines, Time, Learning, Stack fit, and Timing, a paragraph of reasoning, and a call: enter, skip, or maybe.

One thing I prioritized was the over familiarization. Vigil Crest does not pretend to know me better than it does. Early on it labels its verdicts as first impressions and tells me what it is unsure about. It is built to get better at reading my judgment the more I check in with it. A verdict that knows how sure it is beats a confident guess. That is the major portion of the whole design, not a disclaimer bolted on the end.

It is named Vigil Crest because it keeps watch from a height and reports what it sees.

Demo

The whole thing happens in Telegram. Here is a full run.

It starts with the nudge. Twice a week Vigil Crest sends a short reminder to check the board. I reply when I am ready, and it goes to work: it browses the live challenge feed and reports back what it found.

Then it triages each one. Here is its verdict on the Hermes Agent Challenge itself. Notice the two gauges, STACK FIT and WORTH IT, and that it reasons about deadline and competitive angle rather than just reading the prize off the page.

It is just as willing to tell me to skip. Two of the active challenges closed the same night. Vigil Crest passed on both, and said why: a rushed entry will not compete with work done over several days.

And when something is neither a clear yes nor a clear no, it says so. The GitHub Finish-Up-A-Thon has a relaxed deadline but a hard requirement that does not map cleanly to my work, so it lands on maybe, with the reasoning attached.

Four challenges, four verdicts, each one hedged and explained. That is a single check-in.

Code

github.com/earlgreyhot1701D/vigil-crest

Vigil Crest is not a clone-and-run app. It is a configured Hermes instance. The repo gives you the recipe and the portable parts, the skills, the persona and stack templates, and the build guide. Every user supplies their own persona and stack, because the tool grades against one specific person's judgment.

My Tech Stack

Hermes Agent runs the agent, the persona, the skills, and the schedule.
AWS Bedrock (Claude Sonnet 4.6) for the model, reached through an EC2 instance role so there are no credentials sitting on the box.
EC2 (Ubuntu, t3.micro) as the always-on host for the Hermes gateway.
Telegram as the interface. I talk to Vigil Crest like any other contact.
Playwright for live browsing of the challenge feed.
GitHub public repos as the source for the auto-refreshing part of the stack file.

How I Used Hermes Agent

Hermes Agent is the whole spine of this. A few capabilities carried most of this.

The persona did the judging. Hermes' SOUL.md is where Vigil Crest learned how I pick challenges. Not a generic "rank these by prize money" prompt, but the criteria I use: that excitement is a prerequisite, that time is a genuine cost, that a writing track can lower the barrier when a build track is out of reach, that skipping is a legitimate choice. The agentic part is that the persona reasons from those principles instead of running a scoring formula.

Skills made the triage repeatable. I wrote a triage-challenge skill that browses the live feed, reads the active challenges, and produces the four fit lines and a verdict for each. I also wrote a refresh-stack skill that reads my public GitHub repos and keeps the Languages section of the stack file current. The stack file is split by provenance: the part GitHub can verify is auto-refreshed, the part it cannot (frameworks, cloud, tooling) is hand-curated and marked as such. The agent grades stack fit against that file.

The browser tool, used deliberately. Vigil Crest always browses the challenge feed directly. Search results cache stale states and will tell you there are no active challenges when four are live. The skill reads the rendered page, the active section only.

The model is Claude Sonnet 4.6, served through Bedrock. I picked Sonnet over Opus deliberately: Vigil Crest is meant to run often, and Sonnet 4.6 is strong enough for the triage reasoning while keeping an always-available agent affordable.

Not all of it worked

I built Vigil Crest to also run autonomously: a scheduled job, a change-detection pre-check, the agent waking on its own when something new appeared. It ran into a wall I could not get around. The pre-check script reads the feed with a headless browser, and a headless browser is environment sensitive. It launches fine when I run the script myself and fails to launch inside the scheduler's background process. The script's safety guardrail then correctly reports nothing new, and the scheduler discards the script's error output on a clean exit, so the failure was invisible until I dug for it.

The clean fix is an API-based pre-check, since a plain JSON request behaves the same in a shell and a scheduler. The DEV API is rich, but it does not yet expose challenges as their own endpoint, so a pre-check built on it would need some experimentation. That is a v2 item, and it is written up plainly in the repo.

What I shipped is Vigil Crest as a check-in correspondent. A browser-free nudge runs on a schedule and sends me a short reminder twice a week. The triage happens when I reply. I think this suits the project better than the autonomous version would have. An agent whose value is learning my judgment is probably better off in conversation with me than broadcasting into the void on a timer, since a check-in gives it something to learn from and a timer does not.

I did not go looking for that reframe. I went looking for a workaround and found a better design instead.

As for this challenge:
Vigil Crest looked at the feed, weighed it, and said enter. I am taking its advice.

AI assisted. Human approved. Powered by NLP.

Build Club Week Four: the part of Themis Lex I never explained

L. Cordero — Sat, 23 May 2026 19:00:21 +0000

I shipped an AI readiness self-check for California court staff, ThemisLex.org. Here is the why behind it. The problem, the design choices, and what four weeks of building in public actually gave me.

I've written a few posts about building Themis Lex. The deploy war story got the most attention. What I never did was stop and explain why the thing exists in the first place.

So before the Women in AI Accelerator wraps, here it is. Why Themis Lex. Why I built it the way I did. And what four weeks of building in public actually gave me.

The problem

I work in California courts. I'm a Judicial Services Manager at SBSC. The data my colleagues handle every day is some of the most regulated in the state. Case parties. Witnesses. Victims. Jurors. Sealed records. Personnel files.

Every think piece this year tells court staff we should be using AI. Not one of them mentions what we actually touch.

Generic AI guidance is written for a marketing team or a software engineer. It says "redact PII" and moves on. It does not know what a Judicial Assistant does in a courtroom. It does not know that chain of custody is a legal concept with real consequences, not a best practice you can bend. It does not fit the procedural and ethical context that defines court work.

So a court employee reads the guidance, looks at their actual desk, and still has no answer to the only question that matters. Which part of my job can this help with, and which part must it never touch.

Themis Lex is the thing I wished existed when I sat down at my desk.

What it does

Three inputs. One output. Nothing stored.

You pick your role, one of three California Superior Court classifications. You describe your workflow in your own words. You pick a data sensitivity level. Themis Lex gives you back two columns. Where AI can safely help you. Where AI must not touch your work. Every item comes with the reason behind it and a plain-language guardrail. Not "redact PII." Instead, "don't paste case numbers or party names into the AI."

The result downloads as a PDF you can hand to your supervisor.

No account. No login. No data stored. You arrive, you get your answer, you leave.

Why I built it this way

A few choices were deliberate. They are the ones I would defend in a room.

Stateless, on purpose. No database. No accounts. No session storage. For a tool that asks court staff to describe their workflow, "we keep nothing" is not a missing feature. It is the feature. Trust is built into the architecture instead of promised in a policy.

The output is the product. Not the website. The PDF. Court work runs on paper artifacts and approvals, so Themis Lex produces something a court employee can hand to their supervisor without apologizing for how it looks. It was built to belong in a courthouse.

Real role context, not generic advice. Under the hood, every assessment combines three things: California judicial branch AI governance principles, the actual public job description for the role you picked, and your own description of your workflow. The job description is what keeps the output from drifting generic. It tells the model what your role actually involves, so the guidance lands on your real job and not an invented one.

Honest scope. Three roles in version one, not thirty. The rest are visible in the tool with a clear "pending" label. I would rather ship three roles that are right than thirty that are guesses.

What four weeks of building in public gave me

Here is the part I did not expect.

I am not a traditional engineer. I am self-taught. Two years ago I worked in jury services and could not have told you what an IAM role was. Building this alone, the technical decisions were the scariest part. Is the architecture sound. Is the output structured the right way. Am I missing something obvious that a trained engineer would catch on sight.

The Build Club community is what carried me through that. Posting every week meant I was not deciding in a vacuum. People asked the technical questions I did not know to ask myself. They helped me think through the architecture and the shape of the output. And it mattered more than I expected to hear that the project resonated with people, that the problem was real to them too.

Building in public sounds like a marketing tactic. For me it was not. The weekly check-ins kept me honest and kept me moving. The feedback made the product better. The community made the technical fear smaller.

That is what I am taking from these four weeks. Not "I shipped a tool," although the tool is real and I am proud of it. The thing I will keep is the proof that I do not have to build alone to build something worth using.

Try it

Themis Lex is live at ThemisLex.org. If you work in or near a court, pick your role and run it. If you don't, run it anyway and tell me where the logic breaks.

One honest note to set expectations. This is a proof-of-concept MVP, not a finished product. Three roles, one court's job descriptions, a single model call. It does the core thing well and it stops there on purpose. I would rather you meet it as what it is than have me oversell what it isn't. Feedback is welcome, the critical kind most of all.

Built solo for the Women in AI Accelerator with Build Club. Thanks to Annie Liao and Caroline Ciaramitaro, who run a community that is generous with its time and sharp with its feedback. And thanks to my wife, who kept asking "are you almost done" with exactly the right amount of love.

AI Assisted. Human Approved. Powered by NLP

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.