DEV Community: L. Cordero

Who Named This ReAct? I'd Like to Speak to the Manager.

L. Cordero — Sat, 08 Aug 2026 05:00:13 +0000

This week I started the Agentic Engineer Nanodegree through AWS AI & ML Scholars, the next step in what has become my increasingly formal attempt to understand the things I started building before I knew enough to understand all of them.

Somewhere in the coursework, ReAct appeared.

Record scratch.

ReAct?

There was an immediate sense of déjà vu, although not for the reason the curriculum intended.

I know React. At this point I've built enough React frontends that the word belongs to the ordinary furniture of my still-young development vocabulary. Beyond the Docket used React with Vite and TypeScript. RealDoor quite literally labels the browser layer of its architecture "React UI." Several of my Next.js projects are built from React components.

I'm still early enough in this building journey that I regularly encounter concepts for the first time, but React wasn't one of them. React and I had been formally acquainted.

Frontend React itself has had considerably longer to establish its claim to the name. According to the official React history, Facebook open-sourced it on May 29, 2013.

So when a course on agentic engineering presented something called ReAct—capital A, entirely different neighborhood—I wasn't thinking about a 2022 research paper or the history of agent reasoning patterns.

I was thinking:

Wait. React?

Except apparently not that React.

Who named this ReAct? I'd like to speak to the manager.

Then came the explanation.

ReAct combines reasoning and acting. A language model can reason about what it should do, take an action in an external environment, observe what happened, and use that information to continue reasoning about the task.

Reason. Act. Observe. Repeat.

Okay. Fine. The name makes sense.

I absolutely had to keep looking for the manager anyway.

The trail led to the research behind ReAct: Synergizing Reasoning and Acting in Language Models, where Shunyu Yao and his collaborators explored what happens when reasoning and acting—capabilities that had largely been studied separately—are combined.

So this wasn't somebody in the React ecosystem deciding that capitalization could carry the entire burden of technical differentiation.

I withdraw approximately 40 percent of my complaint, maybe.

But while I was reading about ReAct, the déjà vu didn't go away. There was something familiar about the loop, not the name, and eventually I realized why.

The realization sent me back to Verity Lex.

That's where the joke became considerably more embarrassing.

Apparently, I Had Already Met ReAct

I built Verity Lex during OpenAI Build Week because I wanted to turn the usual government technology sales question around: before asking what AI a court should adopt, what if we asked whether the institution was ready for AI in the first place?

I've written about that build and the question behind it before, so I won't retell that story here. What matters for this one is how Verity Lex goes looking for the evidence.

Court websites aren't neat databases waiting for my application to query the right row. A policy might be a PDF. It might be a webpage. It might be buried under administration or linked from a page whose title tells you almost nothing. One document might reveal language that changes what should be searched for next.

So I needed the model to look at what it found and decide what to do next. It searches, observes what comes back, reasons about what that result means, chooses another action, and continues until it has enough evidence or reaches the boundaries I gave it.

If that sounds familiar, congratulations. You apparently knew what ReAct was before I did.

The architecture in my own Verity Lex repository describes the controller as a model-directed ReAct loop:

reason → act → observe → repeat

There it was.

Not metaphorically. Not "well, if you squint, this is sort of agentic."

I had built it.

More precisely, I had designed an application whose discovery architecture used it, worked with AI coding tools to implement it, documented the architecture, tested the application and deployed it.

I just didn't understand that this behavior belonged to a formal pattern with a name and a research lineage.

And because Verity Lex is itself a Next.js application, there was an additional indignity waiting for me: I had managed to put React and ReAct in the same project before I understood that one had been helping render my interface while the other was helping determine what my agent should do next.

Apparently I had already spoken to the manager.

She was... moi.

How Do You Build Something You Don't Know?

This is where I felt sheepish.

There is an important distinction here, because I don't want to rewrite my own history into a story where I asked an AI to "make me an agent" and went to lunch while it assembled something I couldn't describe.

Verity Lex had a PRD. It had architecture. I made deliberate decisions about what the model could control and, more importantly, what it could not.

The model could direct discovery because adaptability was at the forefront of the build. It could not determine the final readiness score because reproducibility was the backbone of the analysis.

I understood the behavior I wanted.

What I didn't have was the formal vocabulary and lineage for part of the architecture I had specified. That distinction matters to me, although I'm still deciding how much comfort I should take from it.

My path into software has happened at a peculiar moment. I didn't arrive through a computer science or engineering program where someone handed me foundational papers in chronological order. I arrived through questions, hackathons and AI coding assistants. Claude, ChatGPT and Gemini became part of how I could turn an idea into something executable long before I had enough technical knowledge to know the name of every pattern appearing underneath it.

Apparently, somewhere along the way, I crossed through an academic idea without realizing I had entered the neighborhood.

Ahem. I'm looking at you, Attention Is All You Need.

At least that one became famous enough that even a new AI-assisted developer eventually hears about it.

ReAct and I had apparently been working together without being formally introduced.

The Chicken, the Egg, and My Software Education

Before the AWS coursework, my mental model of an AI agent was mostly behavioral: agents go out and do things.

Useful, but incomplete.

Encountering ReAct through formal study gave me a way to look inside the "doing."

The original ReAct work describes reasoning traces and task-specific actions operating in an interleaved way: reasoning helps the model develop and update its plan, while actions let it interact with external sources and gather new information.

Suddenly I had better language for what I had already asked Verity Lex to do.

The model wasn't simply being released onto a court website with a tiny briefcase and an assignment. Its actions were part of a loop. The available tools constrained what it could do. The controller constrained how long it could continue. Observations changed what happened next. And my architecture drew a hard line between the part where model judgment was useful—discovery—and the part where I wanted deterministic behavior—scoring.

The code hadn't changed.

My understanding of my own code had.

And this is where my embarrassment runs into the chicken-and-egg problem.

I don't think that understanding would have happened, at least not now, without formal learning.

The AWS AI & ML Scholars program is explicitly designed to move learners from foundational AI education into deeper technical study. In 2026, AWS sponsored 100,000 learners in the Challenge phase, with the top 4,500 advancing to fully funded Udacity Nanodegrees. The Agent Developer track goes directly into reasoning patterns, RAG, tools, memory and APIs.

I am pursuing that formal education because I know there are gaps between what I have learned to build and what I can fully explain.

But without AI-assisted building, I don't know that I would have pursued this much software engineering knowledge in the first place.

That's the part I keep circling.

I didn't study ReAct, become fascinated by agent architecture, and then decide to build Verity Lex as an implementation exercise. I had questions. AI gave me enough leverage to turn some of those questions into software experiments, and building those experiments exposed the edges of what I understood.

Those jagged edges and sharp cliffs made me want to learn more.

That pursuit eventually put me in an Agentic Engineer Nanodegree staring at the word ReAct while realizing that part of the lesson was already sitting in a repository I had shipped.

Which one came first?

The building or the learning?

I'm increasingly not sure that's the right question.

Building Ahead of Understanding

I do feel silly about this, and I think that's a reasonable response.

There are consequences to deploying software you cannot explain, and "AI helped me build it" is not a waiver from understanding security, architecture, cost, reliability or what your application is actually doing. Being able to ship something and understanding what you've shipped are different accomplishments.

AI-assisted development can make the distance between those accomplishments deceptively easy to cross.

I've crossed it.

But my experience with ReAct has made me wonder whether the gap only tells one story.

Without the AWS Scholars program and my decision to pursue formal learning alongside building, I might never have recognized this particular gap at all. I could have continued describing Verity Lex accurately at the product level while never acquiring the vocabulary that allowed me to examine part of its architecture more precisely.

And without building Verity Lex first, ReAct might have arrived as another diagram in another lesson: reason, act, observe, repeat. Memorize it. Pass the quiz. Move along.

Instead, I had déjà vu.

I had a repository and architectural decisions I could revisit. I could ask why the model directs discovery but not scoring. I could look at the iteration limit and understand it as a boundary on agent autonomy rather than merely a number in a controller. I could see discovery, fetching and extraction not simply as functions, but as available actions inside a reasoning-and-acting loop.

Formal learning gave names and structure to things experience had already put in my hands.

Experience gave the formal learning somewhere to land.

Neither seems complete without the other.

That is a much less tidy education than the one I had imagined formal learning was supposed to provide.

Learn the concept. Practice it. Build something.

Mine sometimes runs forward, backward and sideways.

I ask a question. I build something. I discover what I built. I realize what I don't understand. I go study. I return to the code and see something different. Then, if things are going well, I leave with a better question than the one that got me there.

I don't know yet whether AI-assisted development has created a good learning model here.

I do know it has created a possible one, because I'm sprinting alongside it.

For now, I understand considerably more about Verity Lex than I did when I shipped it. I have better language for why the model-directed loop works the way it does, what family of ideas it belongs to, and where its autonomy begins and deliberately ends.

And I finally know the difference between React and ReAct.

React is still on the frontend.

ReAct is helping me understand what happens when an agent has to decide what to do next.

To Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan and Yuan Cao: I have now read your work. The name makes sense.

I apologize for questioning your judgment.

Mostly.

I'd still like to speak to the manager.

AI assisted. Human approved. Powered by NLP.

Sobremesa: Six meals in Mexico, heritage without an address.

L. Cordero — Fri, 07 Aug 2026 03:15:20 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

Mexico is our heritage. Yet, we have no family there to visit.

That sounds sadder than it is. What it actually meant, for the years before my wife and I were married and most of our time off since, is that we had to go find it ourselves. No family kitchen waiting. No grandmother's recipe with an address attached. Just the two of us and a country that is ours and that we did not know.

So we did what every hungry person in a new city does...we ate.

Six cities, six completely different cuisines, and somewhere in there it stopped feeling like traveling. A tlayuda from a stand outside Santo Domingo in Oaxaca. An hour in line at El Yaqui with a michelada in Rosarito. Different food every time. Same feeling every time, and there is no English word for that feeling.

There is a Spanish one.

What I Built

Sobremesa is the time you stay at the table after the food is gone, still talking. Not the meal. The part after the meal.

That is the whole site. Six meals across six Mexican cities, and the thing it measures is not how good the food was. It is how long we stayed.

Tijuana, one hour. Rosarito, two. Ensenada, one. Guadalajara, ninety minutes. Mexico City, two hours. Oaxaca, two. The page adds them up at the end. Nine hours and thirty minutes at six tables.

Comfort food usually means a kitchen you can go back to. We do not have one over there. So the six tables became it. The stand at Plaza Santo Domingo is the family table. The hour in line at Tacos El Yaqui is the Sunday afternoon table.

Each entry has the dish, where we ate it, one verified fact about the food, and one line that is just ours, from our experience. There is a form at the bottom where you add your own table and download a card of it, generated in your browser. Nothing gets sent anywhere.

One static HTML file. No framework, no build step, no tracking, no cookies, no storage. Two fonts off Google Fonts and nothing else. Designed and built in Claude Design, with the research, the fact-checking and the accessibility spec done in Claude, and the illustrations generated in ChatGPT.

Demo

Live site: https://sobremesa-dev.vercel.app/

Source: https://github.com/earlgreyhot1701D/sobremesa (MIT)

earlgreyhot1701D / sobremesa

DEV.to Frontend Challenge entry, Comfort Food Edition. Sobremesa is Spanish for the time you stay at the table after the food is gone. Six meals, six Mexican cities, fourteen years, measured in minutes. Single static HTML page, zero dependencies, zero tracking, WCAG AA contrast computed rather than eyeballed.

Sobremesa

Six meals, six cities, one country.

Sobremesa is the Spanish word for the time you stay at the table after the food is gone, talking. There is no English equivalent.

This is a record of six meals eaten in six Mexican cities over fourteen years, organized around one number: how long I stayed at each table.

Live: https://sobremesa-dev.vercel.app/ Write-up: [add your dev.to post URL]

Submitted to the DEV Frontend Challenge, Comfort Food Edition, Perfect Landing prompt.

What it is

A single static page. No framework, no build step, no dependencies, no tracking, no cookies, no storage.

Six entries, each with a dish, a place, a verified fact, a personal note, and a duration. The durations are summed at runtime. At the end, a form lets you enter your own table and download a card of it, generated entirely in your browser.

Running it

There is nothing to install.

…

View on GitHub

Try it with the keyboard. Tab through it, open a few tables with Enter or Space, and turn JavaScript off if you want to see the whole thing still read.

Journey

Planning and research handed me a dish I had never eaten

San Miguel de Allende is one of my favorite places in the world. But when I built this I realized it does not really have a signature dish. Most of what gets served there belongs to the wider Bajío. Research turned up fiambre sanmiguelense, a cold plate of pickled vegetables and shredded meat that shows up around Christmas and then vanishes for a year. It fit the slot perfectly.

I have never eaten it.

So instead I happily pivoted to Rosarito, along with Tacos El Yaqui where I have waited in line for an hour. I can tell you the line takes you past the wood fire where the carne is grilled and that they sell micheladas while you wait in it. Sobremesa started before the food did.

Placeholder data is sneaky

Early on I dropped fake durations into the array so I could see the layout. One hour five. Two hours twenty. Forty-five minutes. They looked plausible, and they survived about six rounds of design work before I noticed that five of my six headline numbers were invented.

Every duration on the live site is a real estimate now. Mexico City is two hours because we sat there for two hours.

Half the good food facts turned out to be folklore

I fact-checked every claim about every dish, and a lot of the best-sounding ones did not survive.

The Baja fish taco was not invented by Japanese immigrants adapting tempura. There is no documented evidence chain, only the fact that Ensenada had Japanese fishing families in the early twentieth century. Adjacency is not a source.

Birote salado, the bread a torta ahogada depends on, absolutely can be baked outside Guadalajara. Bakers abroad publish working formulas. The impossible-to-reproduce line is tourism copy that everyone repeats and nobody supports.

And every accidental-discovery origin story is legend, not history. A vendor in Guadalajara drops a sandwich in salsa and invents the torta ahogada. A girl in Oaxaca over-curdles the milk and invents quesillo. Caesar Cardini runs out of ingredients in Tijuana and invents the Caesar salad. Three cities on this page, one folk template.

The legends stayed off the page, which made the entries shorter and better. What is left is checkable. The beef for a Tijuana asada taco comes up from Ciudad Obregón, Sonora. El Huequito opened in 1959 and El Tizoncito in 1966, both claim tacos al pastor, and the page says plainly that neither claim is settled.

The prettiest thing on the page was quietly breaking it

I had a paper grain texture over the whole page. Multiply blend, low opacity, the thing that makes flat cream look printed instead of rendered. It looked great.

It was also multiplying my text. Not just the backgrounds. Every glyph, dragged down by a texture whose darkest pixels were pure black. Three color pairs fell below WCAG AA and nothing on screen looked wrong. You cannot see a 4.35 contrast ratio. You can only compute it.

The fix was moving the grain from an overlay above the content to a per-surface background layer, so it multiplies against the background color only and never touches a glyph. The texture got regenerated with bounded alpha so the worst-case pixel is computable rather than pure black.

Then every foreground and background pair was recomputed as composited under the grain. Twelve pairs, all passing, with the tightest one landing just above the 4.5 line. That pair has no headroom left, so it is written down in the README where future me will trip over it.

The rest of the accessibility work is baked in. One h1, no skipped levels. Real buttons, never a clickable div. aria-expanded verified in the accessibility tree instead of trusted from the source. Focus that never gets lost. Every Spanish word wrapped in lang="es" so a screen reader does not pronounce micheladas with English phonics, which matters a great deal on this particular page. Every entry, fact and note present in the HTML, with JavaScript collapsing the panels on load rather than rendering the content, so the whole thing reads with JS off.

About the illustrations

The six dish illustrations are AI-generated, and the page says so in the footer:

Illustrated from memory. Fourteen years, and we photographed almost none of it consistently.

Which is true. We were eating, not documenting. An illustration that announces itself as one is fine. A render pretending to be a photograph is not.

How it was built

Multi-LLM, split by what each one is good at, which is what works for me.

Claude did the research and the architecture. Six cities of food history, fact-checked against sources, with a written record of every claim that got cut and why. It also wrote the requirements spec, which turned out to be the single highest-leverage document in the project. Numbered requirements, testable acceptance criteria, zero visual direction. Handing a builder "make it accessible" gets you nothing. Handing it "every disclosure has aria-expanded reflecting real state and aria-controls pointing at a real id, verified in the accessibility tree" gets you something you can check.

Claude Design built the page. I fed it the requirements doc with no aesthetic direction at all, deliberately, because my own art direction had been the problem for two days straight. Left to solve the spec on its own it produced something better than what I had been pushing toward. It also caught things I would not have: the empty photo slots had alt="" without aria-hidden once the 404 fired, and it fixed that unprompted.

ChatGPT generated the six dish illustrations. One shared style block, then the first accepted image attached as the reference for the other five, which is the trick that stops a set of six from drifting into six different styles.

I direct. The agents generate. I validate and decide. Every fact on that page was verified against a source and every design call was made by a human (me!), including the ones where the human was wrong for a while.

The code itself is small. All six entries render from one array. DOM gets built with createElement and textContent, never innerHTML. Every color and spacing value comes from a token, so nothing is hardcoded in a component rule.

Attribution: index.html is original to this submission and contains no third-party code. The repo also carries the Claude Design component it was authored in, under /design, which is not deployed. Type is Alfa Slab One, Crimson Pro and Oswald, all SIL Open Font License. The six dish illustrations and the hero were generated for this project. MIT licensed.

Frontend is freedom

Most of what I build has a backend behind it. Auth, data models, an API that can fail in twelve different ways, a schema I will regret in a month. This had none of that. One HTML file, no server, nothing to deploy but a folder.

What that bought me was room to be wrong and keep iterating. I rewrote the visual direction twice and the cost was a git checkout. No migration to undo, no state to reason about, no data to corrupt. Being able to throw out a whole design at ten at night and start over is a luxury I do not usually get.

I went in thinking of the no-backend part as a constraint. It was a break and allowed me to be more creative when I skew utilitarian.

What I would do differently

The type scale is in pixels, so browser text-only zoom will not enlarge it. Page zoom works, so it is not a strict AA failure, but it is a real gap for anyone who sets a minimum font size. A rem conversion is first on the list.

The part that is not about code

We are still going strong. There are now more than six meals I'd love to share: Valle de Guadalupe, Querétaro, Guanajuato y más, y más, y más!

But these are the six where we sat down and did not want to get up, in a country that is ours and where we know almost no one, and the food is how we got there.

Six out of many. Provecho.

Quick context if you are new here: I came to code from the courtroom. Jury services to AI builder since July 2025, self-taught, learning in public. I direct, the agents generate, I validate and decide.

AI Assisted. Human Approved. Powered by NLP.

Netlify's Hot AR Summer Challenge: I Wasn't Going to Enter. 33 Apps Later, I'm So Glad I Did

L. Cordero — Sun, 02 Aug 2026 19:18:23 +0000

On Friday, July 31, I was at date night dinner with my wife in LA. We sat down at 8. The plan was simple: enjoy dinner, drive the hour home by 11, post my last app, close out the month.

It was a five course tasting menu. At 9:15 we had finished exactly one course.

I did the math at the table. Four courses to go, an hour of driving after that, and a deadline that did not care about either. So I picked up my phone in panic. Not my laptop, which was at home. My phone.

I built the last one right there at the table, sitting across from my wife, between courses. Claude for the build. Then I deployed it from the same phone through Netlify Agent Runners running Gemini. A confetti canvas, a terminal card, a certified stamp, and a deterministic serial number, because the closing piece had to prove its own work too. Last app of the month!

It went live. On the first try. From a restaurant table.

Then I went to submit it and found there was nowhere to put it. The window had closed. My stomach dropped somewhere around the second course.

We left at 11:30 and got home at 12:30 in the morning. Thirty-three apps made the wall. The thirty-fourth exists, works, and was never counted.

That is the ending, so I am going to start there and work backward.

I wasn't going to enter

Netlify ran a building challenge called Hot AR Summer through July. Build with Agent Runners, ship a small app, put it on the wall. Two apps a day allowed. I saw it and thought, that is a nice idea for people with more time than me.

Then I built one. Then the next day I built another one. Then it stopped being a decision.

By the end I had 33 apps on my builder page, out of a showcase somewhere north of 200 total from everyone who played. A worry filing system with real Dewey Decimal call numbers. A diner wheel that decides dinner by how long you hold the button. A quiz that tells you which dead language you would think in. A goth subtype sorter I built for my wife. A basketball dashboard about Luka. A coin flip that shows its arithmetic.

None of them are big so I could move fast and break things. Ha! One screen, one idea, one self-contained index.html, one deploy.

What I did not expect was that the constraint I picked for aesthetic reasons would turn out to be a budget decision.

The builds are deterministic, and that started as an accident but ended up being a cost decision

Here is the rule I ran all month: no Math.random in any selection logic.

Every app decides its output from the input. Type the same worry into Dewey, get the same call number. Hold the dinner wheel for the same 1.8 seconds, get the same supper. Press the Honest Coin at the same millisecond, get the same face and the same hash to prove it. The apps hash their inputs, run a fixed rule table, and show you the derivation.

I like this for philosophical reasons. I came to code from the courtroom, and in that world a confident wrong answer is worse than no answer. A receipt you can check beats a result you have to trust.

But the reason it survived contact with a credit meter is plainer than that.

A deterministic app calls a model zero times after it is built.

All of the AI cost is in construction. Once the thing is on Netlify it is a static file doing arithmetic in the visitor's browser. There is no inference at runtime. There is no API key. There is nothing to rate limit, nothing to cache, nothing that gets more expensive when more people show up.

I did not fully appreciate what that meant until I opened the billing page.

The bill: $44, and 73 percent of it never touched a user

Across July I paid $44 in top-ups. My current billing period shows 3,990 credits consumed. Here is where every one of them went.

Line item	Credits	Share
AI inference (Agent Runners)	2,899.6	72.7%
Production deploys (41)	615	15.4%
Agent Runners compute (47.41 GB-hrs)	474.1	11.9%
Web requests (3,160)	0.6	0.02%
Bandwidth (0.03 GB)	0.7	0.02%

That works out to about 121 credits per app, or roughly $1.33 an app if you divide the top-ups by 33.

Three quarters of my spend was the model reading and writing code. Another quarter was deploying and the machine time to do it. And then there is that fourth row, which I want to sit on for a second.

The cheapest thing I did all month was actually serve the apps

3,160 web requests. Six tenths of one credit.

Sixty percent of a single credit, to serve every visit to every app I shipped, for a month. That is not a rounding error in my bill, it is the rounding error. Serving the apps cost less than one twentieth of what a single deploy cost.

Here is the counterfactual that made me put my coffee down. Suppose I had built these the usual way (i.e. me) a lot of "AI app" demos get built, with a model call on every visit. Some little inference to generate the flavor text instead of computing it.

Using my own measured Gemini rate from this month (2,254.97 credits for 16M tokens) and a conservative small call of about 1,200 tokens per visit, those same 3,160 visits would have run roughly 534 credits. Against the 0.6 I actually paid.

That is about 890 times more expensive, and it would have cost nearly as much as all 41 of my deploys combined. At my actual traffic. Which is small. That number does not stay still if anything ever catches on.

The 0.6 credits is measured. The 534 is my estimate, using my own token pricing and an assumed call size, so argue with it if you want.

Either way the difference is not really about my traffic, it is about what happens next. My apps cost the same to run whether ten people visit or ten thousand. An app that calls a model on every visit gets more expensive with every single visitor. One is a flat line. The other climbs forever. I got the flat line for free by being stubborn about Math.random.

Gemini did the work. The expensive model did not do more work, it just cost more.

I ran two providers through Agent Runners this month, and the split is instructive.

Provider	Tokens	Cost	Effective rate
Google (Gemini)	16M	$12.53	~$0.78 per M
OpenAI	2.6M	$3.76	~$1.45 per M

OpenAI cost me about 1.8x per token for the same category of work: generate a single-file HTML toy. It is not that it did a bad job. Scrivener, my DOS-terminal typing tutor, came out of Codex and it is one of the better-built things on the wall. It just is not 1.8x better at making a small deterministic app, and when you are shipping one a day that multiple compounds.

So the rule I landed on mid-month, and wrote into my tracker so I would stop relitigating it: default to Gemini, sketch it out by hand first, one deploy, do not re-prompt a working app.

That last clause is the one that actually saved money. Costs are per run and per deploy at 15 credits each. Every "hmm let me just tweak that" is a triple charge: new run, new tokens, new deploy. I finished the month at 41 deploys for 33 apps, which is 1.24 deploys per app. That number is my discipline in one statistic.

One more thing buried in the token data that surprised me. Of the 18.6M tokens I burned, only 323K were output. That is 1.7 percent. Ninety-eight percent of what I paid for was the model reading: my spec, the existing file, the context. The code it wrote was almost free.

Note to self: If you want to spend less, write a tighter spec. That is the lever. Not a shorter app.

Three tools, three jobs, and none of them doing the other one's work

The workflow that emerged, and it served me well:

Claude for brainstorm and architecture. What is the idea, what is the rule table, what is the deterministic engine, what is the voice. This is where I argued about whether the app was any good before spending a credit on it.

ChatGPT for the HTML. Hand it a tight spec with the guardrails baked in (no Math.random, textContent not innerHTML, no storage, no fetch, must fit one screen) and let it produce the file.

Netlify Agent Runners for deploy. One runner, one deploy, done.

I want to be specific about this part, because it is the reason a daily streak was even possible for someone with a full time job. Deploying was not a project. There was no pipeline to babysit, no build config to fight, no ceremony. Point a runner at the file and it is live on a URL you can send to your wife thirty seconds later. Thirty-three times in a row, including one time from my phone at a restaurant table between courses.

If you are new, this is the on-ramp I would hand you. If you are not new but you move fast and you resent tooling that slows you down, same recommendation for the opposite reason. The whole reason I shipped 33 small things instead of overthinking three big ones is that deploying cost me nothing emotionally. Fifteen credits and no stress (thank you Netlify!).

What worked for me during this sprint: I figured out the whole thing iterating with Claude before running anything, because thinking is free and inference is not. What I didn't take into account: any time I let a second pass happen because I did not specify well enough the first time.

I have started sorting those second passes into a taxonomy, because they are not all the same failure. Agent-miss (it ignored the spec), spec-miss (I never said it), scope-change (I changed my mind), operator-error (I ran the wrong thing). Only one of those four is the model's fault, and it is not the most common one.

The apps I would show you first

These are the ones I would hand you first. All free, all instant, none of them want your email.

What's for Dinner?
A 1950s chrome diner wheel. Press and hold to wind it up, release, and it clatters to a stop on tonight's supper. The longer you hold, the further it spins, and the same hold always lands the same meal. There is a bell, an order ticket, and the button afterward says "Spin again (we both know why)." Cereal is one of the eight outcomes and I refuse to apologize for it.

Crypt Type
Which goth subtype are you. Eleven results, each with a soundtrack and a receipt showing what you scored highest on. I built this one for my wife, who is the household authority on the subject and who tested it before anyone else got to.

Saint of Small Things
Name something small you are struggling with and get canonized as its patron saint, feast day included. Patron saint of the unanswered email. It is silly and then it is somehow not.

Vivant Linguae Mortuae
Eight questions, and it tells you which dead language you would think in. The most-shared one of the whole set, and the one people argue with me about.

Mood Ring
Press the stone and hold it. Your mood comes from how long you held, not from a dice roll, so if you sit with it you get a different answer than if you tap. Turns out that is the honest mechanic for a mood ring anyway.

How Long Ago Was That
Type a year and it tells you the distance in something your body can feel. Type 1994 and learn it is closer to the moon landing than to today. This is the one Netlify demoed on their livestream, where it repeated itself on air and taught me something I had to write up separately.

Same Sky
Where the sun is right now, wherever you are, from real solar geometry instead of a weather API. Pick Svalbard in July and it will tell you the sun does not set there today, which is correct and still feels like a bug.

With Appreciation
Name three things you are grateful for and receive a curated, properly sourced quote. It also tells you that others are here in quiet company, without a fake live counter, because I was not going to invent traffic.

Luka Fit Index
A sports dashboard that shows you its own bias instead of hiding it. This was the first thing I shipped for Hot AR Summer, before I knew there would be thirty-two more.

Messi vs. Yamal and The Decision 2026
Two generations meeting in a final, and LeBron's career treated as a unit of measurement. The second one is funnier than it has any right to be.

Is it Friday?
The entire app is one word. That is the whole product and I stand by it.

The full wall of all 33 is here: my Hot AR Summer builder page.

The last one shipped. It just never got counted.

The final thing I made was not an app. It was a receipt for the month: an attestation page with confetti, a terminal window, and a certified stamp. The serial on it is 5307-062B, and it is not decorative. It is FNV-1a run over the string la-shara-cordero|hot-ar-summer|2026-07-31. Same name, same event, same date, same serial, forever. You can check my arithmetic.

There is one asterisk on that page and I am going to point at it myself. The confetti uses Math.random. I left a comment in the source saying so:

// Deterministic-ish spread without Math.random dependence for the pattern,
// but confetti is decorative so a little jitter is fine here.

That is the line I drew all month, and it took thirty-three apps to find it. The rule was never "randomness is bad." The rule was nothing you are asked to believe may be random. The serial is a claim, so it is computed. The confetti is a feeling, so it can scatter. If I had made the serial random it would have been a sticker. If I had made the confetti deterministic it would have been a chore.

Here is the context I am not going to dress up. That Friday I left the house at 6 in the morning and got home at 6:30 at night. Then we drove to LA for dinner. I was not running on a full tank when I sat down at that table, and I was still planning to ship something before midnight.

I am not telling you that to flex. I am telling you because it is the actual reason the last one missed. I tried to overachieve on an empty day and it did not work. Sometimes pushing produces a good story. This time it produced a live URL nobody was allowed to count.

Thirty-three apps counted. The thirty-fourth is real, shipped, and uncounted.

It stung. It also might be the most accurate possible ending for a month spent learning that the deploy is a cost, the second pass is a cost, and time is the one budget with no top-up button. The work existing and the work being counted are two different things, and only one of them was ever up to me.

Would I do it again? You know it! It was so much fun!!

Coming up with the ideas was the best part. Sitting there working out what would actually make somebody smile, what is worth one screen, what has a joke in it and a real mechanism underneath. That is a harder puzzle than the code and I loved every round of it.

The wins I am keeping:

Leaning all the way into deterministic building. I went in with it as a preference and came out with it as a practice. That is a real shift and it is mine now.
Learning Netlify from scratch. New tool, thirty-three deploys, zero drama. Add it to the kit.
Getting demoed by a company for the first time. Netlify put How Long Ago Was That on their livestream. That had never happened to anything I built.
Failing on that livestream, publicly, in real time. Here is the moment. My app repeated itself on air and I got the lesson handed to me in front of an audience. I would not trade it. You do not learn that one from a blog post, ugh!

And a huge thank you to Netlify for running this. A whole month of low-stakes, high-joy building with a wall to put things on. That is a gift to anyone learning, and I got a lot more out of it than 33 URLs.

What I am taking with me

Determinism is not a purity thing, it is a pricing model. Building it into the app moves the entire cost to construction and gives you a flat line forever. That is worth more than the variety you give up.

The fix for repetitive output in a deterministic tool is never randomness. It is more knowledge. More anchors, more rules, a wider table. Randomness would make the output unrepeatable, and the receipt is the product.

Your spend is mostly input tokens. Ninety-eight percent of mine was. Tighten the spec, not the app.

One deploy. Say it out loud before you press the button.

I did not plan on doing this. I am so glad I did. Thirty-three small toys exist now that did not exist on June 30, and the whole month cost me $44.

Which, and I promise I did not plan this either, is less than the dinner.

Quick context if you are new here: I came to code from the courtroom. Jury services to AI builder, starting July 2025 and still going, self-taught, learning in public. I direct, the agents generate, I validate and decide. I build the Clew Suite and a handful of civic tech tools, and you can see the rest of it at Clew Labs. That is the lens I am writing from.

AI Assisted. Human Approved. Powered by NLP.

AWS Amplify SSR gotcha: chasing a bug that was never in my code

L. Cordero — Sun, 02 Aug 2026 00:52:54 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The build was done. Themis Lex worked on my machine, and not in the "works if you squint" way. A court clerk enters their role, describes their workflow, picks a data sensitivity level, and gets back a PDF with two sections: where AI can safely support the work, and where it must never touch it. Claude via Bedrock generates the assessment. Server-side PDF render. No accounts, no storage, session ends when the download does.

Three weeks solo, for the Women in AI Accelerator Spring 2026 Build Challenge.

Initial commit went in at 7:06pm on May 9. I pushed to AWS Amplify. Build went green. I opened the live site, filled out the form, hit submit.

Nothing.

Twenty eight seconds later, "Request timed out."

I told myself the bug was not in my code. Everything ran locally. This had to be a platform problem. That belief carried me all night. It mostly held up. The exception was the first thing I should have checked.

Here is the commit log, because it tells the story better than I can:

19:06  Initial commit: Themis Lex MVP
20:31  refactor: migrate Bedrock auth to IAM compute role
22:29  diag: log credential env vars at runtime (booleans only, remove after fix)
22:40  fix: forward BEDROCK_MODEL_ID to SSR runtime via next.config.js env
22:50  fix: switch to InvokeModelWithResponseStreamCommand to beat 28s Lambda timeout
  ...
06:28  fix: remove unused type export that broke isolatedModules build
06:37  fix: end-to-end response streaming to beat Amplify 28s gateway timeout
06:48  fix: reduce max_tokens to 3000 to fit Amplify 30s timeout
06:52  fix: reduce max_tokens to 2000, 3000 still exceeded 30s timeout
07:00  fix: switch to Claude Haiku 4.5 to fit Amplify 30s timeout

Ten and a half hours from first deploy to the fix that shipped it. That gap between 22:50 and 06:28 is me sleeping on it, which turned out to be the second most productive thing I did. Ha!

The error message was the absence of an error message

My first instinct was that my code threw a fit and I swallowed it. I had a try/catch on the Bedrock call and it logged nothing. No stack trace. No AccessDenied. No throttle. My catch block was never entered, because my code never reached the part that could fail.

That is a specific kind of awful. A loud error points at a line. Silence points at everything.

The AWS SDK was stuck upstream of my logic, walking the credential provider chain looking for something to sign with, finding nothing, and waiting until the gateway killed it. From the outside that looks like a slow API. From the inside it is a permissions problem wearing a timeout costume.

So here is the correction to my own title, four paragraphs in. One of the bugs was absolutely in my code.

// c136357, initial commit. This disables the provider chain.
function createClient(): BedrockRuntimeClient {
  return new BedrockRuntimeClient({
    region: process.env.AWS_REGION || 'us-east-1',
    credentials: {
      accessKeyId: process.env.AWS_ACCESS_KEY_ID || '',
      secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY || '',
    },
  });
}

// 792b94f, "migrate Bedrock auth to IAM compute role"
function createClient(): BedrockRuntimeClient {
  return new BedrockRuntimeClient({
    region: process.env.AWS_REGION || 'us-east-1',
  });
}

Passing credentials at all tells the SDK you have this handled, so it stops looking. Empty strings are still a value, so it tried to sign with nothing. Omit the object entirely and the default chain covers both local dev reading .env.local and production reading the Lambda's assumed role. Two lines deleted. That was mine.

At 22:29 I committed a diagnostic that logged credential env vars as booleans only, never values, because I could not tell from the outside whether the runtime had credentials at all. If you are stuck in the same silence, that is the move. Do not log the values. Log whether they exist.

One thing, since this challenge is powered by Sentry: I had no error tracking on this app at all. It also would not have mattered in the usual way, because there was no exception to capture. Nothing threw. The request stopped existing when the gateway hung up, and application level error handling has nothing to report about a request that never failed so much as ended. What I needed was not a stack trace. It was something watching from outside the Lambda that could tell me requests were dying at a suspiciously round twenty eight seconds, which is the pattern I only saw hours later by reading CloudWatch REPORT lines by hand.

I changed two things at once, so I still cannot tell you which one worked

I also changed the compute role's trust policy to include both amplify.amazonaws.com and lambda.amazonaws.com, and attached the role at the branch level instead of relying on the app level default. Redeployed. The credential hang was gone.

Classic mistake. Two changes, one test, no isolated variable.

When I went back to check my work for this post, the official docs contradict both of my theories. The AWS compute role page shows a single trust principal, amplify.amazonaws.com, and says an app level role applies to all branches by default. Another engineer tested the two principal theory and rejected it, finding instead that roles created by CLI behaved differently from roles created in the console.

I made both IAM changes at the same time as deleting the credentials object, the hang stopped, and I cannot prove which one did it. It may well have been the two deleted lines all along. Adding the second principal is harmless. Branch level attachment is recommended anyway. But if you came here for a confirmed root cause on the IAM half, I do not have one, and I would rather say that than hand you a confident answer I cannot back up.

What I can hand you is the diagnostic, which beats my guess:

aws amplify get-app --app-id YOUR_APP_ID
aws amplify get-branch --app-id YOUR_APP_ID --branch-name main

Compare computeRoleArn on both. And treat the IAM Console's "Last activity" on the role with suspicion, because the build service assuming the role lights it up whether or not your runtime ever gets credentials. It told me the role was in use. The role was in use. Just not by the thing that needed it.

The docs told me half of it. I was reading the wrong half.

Credentials working. Next failure, eleven minutes later: BEDROCK_MODEL_ID came back undefined in production. Set in Amplify Console. Visible during build. Gone at runtime.

This one is documented, and it is my miss, not AWS hiding the ball. The page is Making environment variables accessible to server-side runtimes, and it says the behavior is intentional. Amplify env vars flow into the build environment. They are not injected into the SSR Lambda. Vercel, Railway, and Render do both, which is why the assumption never got questioned.

AWS's sanctioned fix is a build spec line writing values into .env.production before the build. My amplify.yml does no such thing. It runs npm ci and npm run build and that is it. What I did instead, at 22:40, was inline the value through next.config.js:

const nextConfig = {
  env: {
    BEDROCK_MODEL_ID: process.env.BEDROCK_MODEL_ID,
  },
};

Mine works. Theirs is the documented path. Use theirs if you want to point at a doc when a teammate asks.

The nastier version of this bug is the silent one, and I shipped it. lib/bedrock.ts looked like this:

const modelId = process.env.BEDROCK_MODEL_ID || 'us.anthropic.claude-haiku-4-5-20251001-v1:0';

If that env var ever failed to reach the runtime again, nothing throws. The app quietly runs the hardcoded fallback, and I find out when someone tells me the output changed. I wrote a warning about this trap and then shipped the trap.

I fixed it while writing this post. The build now fails if BEDROCK_MODEL_ID is missing, the runtime throws a named config error instead of falling back, and the API route returns a message the browser can show instead of a blank screen. Writing it down is what made me go look at it.

Then Bedrock threw AccessDeniedException complaining about AWS Marketplace actions I did not think I was using. Since the October 2025 model access change, Bedrock auto enables models on first call, the enablement runs through Marketplace, and the calling principal needs permission for it. The old Console "Model access" page is retired.

{
  "Effect": "Allow",
  "Action": [
    "aws-marketplace:ViewSubscriptions",
    "aws-marketplace:Subscribe"
  ],
  "Resource": "*"
}

Resource: "*" because Marketplace subscriptions are not scoped to model ARNs. Documented, in a Bedrock security blog post, with no link to it from anywhere in the Amplify docs. To find it you have to already suspect Marketplace, which I did not, because I was configuring Bedrock.

The wall that is not written down anywhere

Credentials working. Permissions working. Env vars working. My API route still died at twenty eight seconds.

Amplify Hosting SSR has a hard gateway timeout in the twenty eight to thirty second range, and there is no setting AWS exposes to raise it.

I looked for this. It is not in Amplify quotas, which covers app counts and artifact sizes. It is not in troubleshooting SSR, which discusses 504s only in terms of a response size cap. As far as I can find, the number appears in no AWS documentation page at all.

Where it does appear is aws-amplify/amplify-hosting issue 3223, still open, where an AWS engineer states that increasing the timeout on SSR compute is not supported at this time. A companion issue at 3475 gets redirected back to it.

This is the part of the night I could not have prevented by reading. It is a platform constraint that lives in a GitHub thread.

On the numbers, I want to be precise about what I know. My CloudWatch REPORT lines showed Duration: 28006ms, which is the Lambda being killed, not the generation finishing. My planning notes from block 4 testing put Sonnet 4.6 at roughly forty two seconds at max_tokens=6000. That is an observation from testing, not instrumented measurement, because the call never completed inside the Lambda's life. I never got a clean number. I got a wall.

Streaming was the right idea, twice, and the wrong fix both times

Streaming looked like the answer. Keep bytes flowing, keep the connection alive. I tried it in two separate shapes, seven hours apart.

At 22:50 I switched to InvokeModelWithResponseStreamCommand inside lib/bedrock.ts, collecting chunks server-side. The route handler did not change. It still returned one JSON payload at the end. That keeps the Lambda demonstrably alive during generation, which is something, but it does nothing for a gateway measuring wall clock time on the response.

Then I slept.

At 06:37, after a build break at 06:28 over an unused type export, I went end to end. streamBedrock() became an async generator. pages/api/assess.ts set Content-Type: text/plain and Transfer-Encoding: chunked and called res.write() per chunk. The client used response.body.getReader().

Still dead at twenty eight seconds.

CloudWatch showed the Lambda receiving Bedrock chunks the whole time. The client saw the platform timeout. Same symptom as the credential bug, completely different cause. I spent the first twenty minutes of it re-checking IAM.

Next.js Pages API routes buffer. My writes did not reach the gateway as they were written. They queued until res.end(), and by then the connection was gone. I reverted the whole end to end attempt eleven minutes later.

AWS does document this, sort of. Amplify support for Next.js lists "Next.js streaming" flatly under unsupported features. One line, no detail. I read that page. I read it as a caveat rather than a wall, which is a reading comprehension problem I have been thinking about since.

The server-side collection version survived, and it is what runs today. The client still gets one JSON response.

Going smaller did not work. Going faster did.

After the revert, I did the predictable thing and made the response smaller.

max_tokens 6000 to 3000 at 06:48. Still over.
3000 to 2000 at 06:52. Still over.

Four minutes apart, watching the same wall. At that point the output was small enough to hurt the product and still too slow to ship.

So at 07:00 I stopped shrinking the response and changed the model. Claude Sonnet 4.6 to Claude Haiku 4.5.

Before: nothing rendered. Twenty eight second hang, platform error page, max_tokens cut to a third of the design target and still failing.

After: PDF generated and downloaded. The test call that finally returned HTTP 200 showed 14.3 seconds in my terminal. That number is not in any log file or benchmark in the repo, so take it as what it is, one observed run during a live test at seven in the morning. What I can point to is the outcome: it fit, and it fit with enough room that I raised max_tokens back up to 4000, above where I had cut it and closer to what the assessment needs.

Themis Lex went live at themislex.org running Haiku.

There is a trade here and I am not going to pretend otherwise. Haiku's assessments are less nuanced than Sonnet's were. For a tool telling court staff where AI must never touch their work, the nuance is the thing they are paying attention to. I logged the quality delta as a v2 item rather than calling it a win.

The other paths out, if you cannot shrink or speed up enough:

Lambda Function URL with response streaming enabled. Fifteen minute timeout, server sent streaming that works.
A separate Lambda behind API Gateway. Sixty second timeout.
Move hosting. Vercel Pro gives sixty seconds and first class Next.js streaming. None of those are an overnight fix. They are architecture decisions, which means they belong in the plan before you build, not in the panic after you deploy.

What I would do differently

About half that night was avoidable and half was not, and the split is the lesson.

Avoidable: the env var behavior and the streaming limitation are both written down. I did not read the right pages, and once I did, both took minutes. If you are deploying Next.js SSR to Amplify, read ssr-environment-variables.html first. It states the runtime gap outright and links onward to compute roles, which is the on ramp to the whole IAM half of my night.

Also avoidable: the credentials object. That was two lines of my own code buying me hours of platform suspicion.

Not avoidable: the twenty eight second wall. No doc, no quota page, no warning. A GitHub issue and an AWS engineer saying no.

The question I did not ask before choosing a platform, and will ask every time now: will any route in this app take longer than twenty five seconds end to end? LLM calls, PDF renders, large file work, slow third party APIs. If yes, Amplify SSR is the wrong default and no amount of configuration changes that.

If no, Amplify is fine. It is a good product for fast routes and content sites and normal CRUD, and the developer experience holds up. I do not mind that the constraint exists. I mind that I found it at 6:52 in the morning, cutting max_tokens for the second time, instead of on a docs page in week one.

I still use Amplify. I stopped reaching for it first, and I now run a fifteen minute timing spike on the slowest route before committing to any host. Pass or fail, before I build on it.

Themis Lex shipped. It runs a smaller model than I designed it around, and I would rather tell you that than let you think the night went clean.

Quick context if you are new here: I came to code from the courtroom. Jury services to AI builder in about a years, self-taught, learning in public. I direct, the agents generate, I validate and decide. I build the Clew Suite and a handful of civic tech tools. That is the lens I am writing from.

Repo: github.com/earlgreyhot1701D/themis-lex
Live: themislex.org

AI Assisted. Human Approved. Powered by NLP.

Lemonade Second Squeeze: Model Archeology on 2019's GPT-2XL

L. Cordero — Mon, 27 Jul 2026 01:24:28 +0000

Two weeks ago I had never run an AI model on my own machine. Every project I had ever built phoned a cloud API with a key sitting in it. Then I sat in the vibecoding lab at AMD's Advancing AI 2026 summit and watched a model answer a question from a laptop, nothing leaving the room, and I got the itch.

I have a pattern. When something lights me up, I chase it before I am ready. This was that. I picked a project that was over my head on purpose, and then I spent a week refusing to put it down.

So before any numbers, here is the crux of it: the numbers are not the point, well kind of they are. The point is that I kept hitting walls and kept going anyway. The rest of this is just how.

I picked a project I had no business starting.

The idea was model archaeology. Take a model from 2019 and a model from 2025, run them both on the same laptop, and measure what six years actually changed. I called it Second Squeeze. Squeeze an old lemon, squeeze a new one, see if the juice is the same.

Old lemon: GPT-2 XL, 2019, 1.5 billion parameters. New lemon: Qwen3-0.6B, 2025, less than half the size. Both running locally through Lemonade, which is AMD's local AI server. I had never installed anything like this in my life. I started anyway.

The install fought me, and I kept going.

It did not go smoothly. But I'm always up for a challenge! The command was not the one the docs implied. It was not on my PATH the first time. A GPU backend tried to download and jammed on a locked file, twice. My Python was too new for the eval tool, so I stood up a second Python just for this project.

None of that is glamorous. But figuring it out is all the fun! Every wall was the same small decision: close the tab, or read the error and try one more thing. I kept picking one more thing. Eventually a tiny 2025 model said hello to me from my own laptop, and I may have made a noise, HOORAY!

My first real plan hit a wall, so I moved the wall.

The original plan was accuracy. GPT-2 has a famous 2019 benchmark, and I wanted to see if the old claim held up. That test needs a specific kind of probability data from the model, and Lemonade did not hand it back the way the standard tool expected. Dead end.

Old me would have read that as proof I was not cut out for this. Claude and new me read the docs instead, pinned down exactly what was missing, reproduced it cleanly, and filed an issue on Lemonade's repo so the next person hits a signpost instead of a wall. My first open source contribution, born entirely from something not working.

Then I changed the question to one the tool could answer. Not how smart, but how fast, and can it even follow an instruction. Same curiosity, different door.

My own benchmark caught me lying, and I let it.

This is the part I am proudest of, and it started as a mistake.

My first speed run had GPT-2 at 0.31 tokens per second. Next to the new model's 90, that is a 297x gap. Huge. I wanted it to be true so badly.

Before I posted it, Claude wrote a little script so anyone could re-run every number with one command. I ran it. GPT-2 came back at 8.5, not 0.31. My first number was junk, measured while a backend was still downloading and the model was cold off my disk. The real gap is about 11x, not 297x.

I could have kept the 297x. Nobody would have checked. Instead I kept the 11x and wrote down why the first one lied, because a number you cannot reproduce is not a result, it is a rumor. The tool I built to keep myself straight is the tool that caught me. That felt like the whole month in one moment.

And the capability side, quickly, because it made me laugh: I asked both models to finish "The capital of France is." The 2025 one said Paris and even showed a little reasoning first. The 2019 one, which has no concept of a conversation, produced a wall of random import statements. Six years is a long time.

What I kept wasn't the number.

Here is what I took from the build, and it is not tokens per second.

Every single step was something I had not done before. Running a model locally. Reading a stack trace with Claude's assistance. Filing an issue on Lemonade's repo. Saying in public that my own headline was wrong. Any one of those was a fine place to quit, and the only thing that made this a project instead of a folder of half-attempts is that I did not quit.

I think that is the skill I love strengthening, more than any framework. Keep trying the new thing. Keep pushing when it pushes back. Change the door when the door is locked, but do not leave the building.

Second Squeeze is live. There is a dashboard you can click, a repo you can re-run, tests you can try to break, and an issue I filed that might help close a real gap. Next I want to run the whole thing on an actual AMD GPU and add another bar. That is another burst, another day.

If you have been circling something that feels over your head, take this as your sign. Start it before you are ready. Hit the walls. Keep going.

For you, if you want it:

Live dashboard: https://earlgreyhot1701d.github.io/second-squeeze/
Repo (MIT): https://github.com/earlgreyhot1701D/second-squeeze
The issue I filed: https://github.com/lemonade-sdk/lemonade/issues/2822

Quick context if you are new here: I came to code from the courtroom. Jury services to AI builder in about a year, self-taught, learning in public. I direct, the agents generate, I validate and decide. That is the lens I am writing from.

AI Assisted. Human Approved. Powered by NLP.

AMD Advancing AI 2026: Software, Hardware & Framework, Unified

L. Cordero — Thu, 23 Jul 2026 22:46:16 +0000

Where Chris Lattner calls AI "mid" and George Hotz wants to knock a trillion dollars of value off of NVIDIA with tinygrad.

Preamble

IMHO: AMD's Advancing AI 2026 summit in San Francisco was free. And right now, while the firehose of free AI events and learning is still on, I'm taking every opportunity I can get my hands on. Eventually the free opportunities will slowly disappear, and this age of companies wanting us to adopt their tech and ecosystem will end. Cynical, pessimistic maybe. But think about the money spent on a two-day event at the Moscone Center. Free if you sign up. Free learning, access to vendors, tech talks, keynote speakers, food and lunch provided. That's an investment, and eventually the accountants, or the shareholders, are going to need to see a return. But I digress. This is my rundown of day one.

AMD changed my mental model

To say I'm a fish out of water at any event is an understatement. AWS, MLH, Google, and now AMD, I've tackled each one as a way to explore this brave new world, but sometimes I just don't have the context. And that's okay.

AMD was more technical. More focused on hardware. There was more than one robot. And it changed my mental model of technical ecosystems and the symbiosis within them, and I'm so here for it.

A panel with no theme, and then Chris Lattner called AI "mid"

Day one started with a three-person panel: Chris Lattner, Ramin Hasani, and Hassan Akbari, hosted by, checks notes, a name I didn't catch. There was no real theme. It was a roundtable discussion, and here's what came out of it.

Chris Lattner created LLVM, the compiler infrastructure a huge amount of modern software quietly runs on. So when he talks, I try to keep up. His point wasn't only about software. It was about how the hardware we run works with the applications we write, and why you can't reason about one without the other.

He said he'd been told his approach wouldn't work, because CUDA has the moat. His answer, the way I understood it: CUDA is kind of like GCC. GCC is the decades-old open-source compiler a lot of software gets built with, so, big and foundational and hard to dislodge. A monolith. Powerful, legacy, wrapped in an incredible moat, and also not that good. His point: you don't beat the moat head-on, you go around it with architecture. Let the hardware express what it can do instead of locking everyone into one vendor's language. That's his whole Mojo play at Modular, for what it's worth, a portable alternative to CUDA.

Then he dropped the line. AI is mid.

Appropriate laughter followed. But I don't think he meant it as a burn. The way I read it, he meant AI is a distribution follower. The AI most of us touch every day, the LLMs, the predictive models, those are the product. They ride on top of the work happening behind the scenes: the training, the hardware, the compute. He lives in that granular layer. Most of us live in the public one. So when he says mid, I think he's talking about the surface, not the machine underneath it.

Maybe I'm getting his intent wrong. I'm allowed. But that's the read I walked away with, and it stuck.

Ramin Hasani talked over my head, and I wrote it down anyway

Ramin Hasani talked in abstractions I didn't fully follow. And I mean abstract for me, not abstract in general. The concepts were above where I am right now. But I wrote them down anyway, because future me is going to want them.

Here's what I caught, in the order my pen caught it. Think about the problem at the algorithmic level before you reach for kernel optimizations. AI designing AI, and not just attention, look at the other transformers. Liquid foundation models, which are his company Liquid AI's whole thing, so that one I could at least place. Matching the best models to the right hardware: CPU, NPU, GPU.

I'm not going to pretend I can explain all of that yet. I can't. But it's in the notebook for when I get to the "kernel" level of my studies. Lol.

Hassan Akbari tied it together

Hassan Akbari was the one who tied it together. He talked about a unified ecosystem between frameworks, hardware, and software. He mentioned kernel again, and no, I still didn't catch the context, so onto the pile it goes with Ramin's. His point was that the interconnectivity of all three has to be leveraged for optimization. You don't tune one piece in isolation. You use how they connect.

Then he asked the question that stuck with me. Large models can now be distilled into smaller ones that are still effective. So are we wasting compute? Scaling models, the way Hassan framed it, should be pragmatic. That one made sense to me.

His other points came from the customer side, where reliability, cost per token, and accuracy are what matter. Optimization is the whole goal, and evaluation pipelines are how you measure it: benchmarks, deployments, the numbers. At least that's what I wrote down. Correct me if I mangled it.

George Hotz wants to knock a trillion dollars off NVIDIA

Picture the stereotypical genius from Silicon Valley, the show. That's George Hotz. It was awesome, it was inspiring, and it was very on the nose. Note to self for the day: I am sharing a room with very, very, very smart people.

Even his intro was wild. Jailbroke the iPhone. Reverse-engineered the PlayStation 3. Made a self-driving car , comma.ai, that got a cease-and-desist letter from the DMV. Got hired to hack a company's own systems to keep them safer. I could not tell if I was watching an inspirational documentary or a cautionary afterschool special. But I already said he was awesome, and I stand by it.

His talk was deep. Graphs, lines of code, evaluations. I have pictures, if anyone wants them. At one point he said the Radeon RX 7900 XTX, three years old now, is still a good value at $999. I wrote down "what is a 7900 XTX?" and filed it for later. Back to it.

George didn't hold back, and the candor was refreshing. tinygrad, which I looked up, is an open-source neural network framework and deep learning library, and on stage he put it at 25,000 lines of pure Python, about 9,000 of that the core, meaning the essential engine with everything else built around it.

His stated goal, and I quote, is to "commoditize the petaflop." Translation, delivered deadpan: if tinygrad succeeds, it knocks a trillion dollars of value off NVIDIA. Insert audience laughter here. Same moat Chris Lattner was talking about. George just comes at it from the scrappy open-source end.

His pitch is GPUs for the middle class. He talked about growing up in New Jersey with a parent who was a teacher. He doesn't care about data centers. What he cares about is the highest development velocity, and not the out-of-the-box-fast kind. His argument, the way I understood it: an out-of-the-box TensorFlow might be faster on day one, but tinygrad's velocity curve is built to climb higher and faster over time. And here's the part that got me. tinygrad has no dependencies. None. No numpy was used in the making of tinygrad. Which I learned is the whole flex. No dependencies means nothing underneath you can break, bloat, or drift out of version. Fewer moving parts, less that can rot. Very much my kind of principle. He even mentioned running tinygrad as a backend, which I am absolutely going to go try.

So the guy who reverse-engineered a PlayStation had my full attention. So glad I made it.

Do you see why I love these events?

Here's what kept pinballing around my head after all of that.

I'm an AI-assisted builder. I live on the top-level software end. I write code, I deploy applications. So why haven't I been more thoughtful about what runs underneath all of it? My dev.to articles focus on the end product, the thing I shipped. Not the framework, not the hardware, not the compute it all rides on.

Maybe that's the next stage of my development. Or maybe not. Here's my honest worry: if I try to hold every piece at once, framework and hardware and software and infra, I might get so overwhelmed I don't build anything at all.

And then the comforting thought. Maybe the three of them were mostly talking about training models, and I can go back to coding with vibes. The event leaned hard into CPU, GPU, NPU, compute, and infrastructure, not so much the SaaS layer I live in. So maybe it isn't my fight yet. Something to ponder.

But that pinball is the whole reason I go. For a few hours, something pulled me out of my product-focused viewpoint and made me look at the layer underneath. That's the value. Not the swag bag, necessarily!

The workshops, and the one that masqueraded

After the opening session I hit the workshops. One was Build Your OpenClaw Agent with Multi-Modal Models, running on AMD GPUs. Another was billed as vibecoding with local models. Good practice, all of it technology I hadn't touched. AMD's learning platforms were new to me. Working out of Jupyter notebooks was new too.

The vibecoding workshop, well, the title masqueraded it. It was a Lemonade and Qwen workshop, and it rocked. First time I'd heard of Lemonade. It's a community project, sponsored by AMD with optimizations from their engineers, that runs large language models locally on your own GPU or NPU. We ran Qwen3.6-35B-A3B on it. They walked the framework from the ground up: silicon, engines, routing, models, then the app. Another pyramid. And there I was again, looking down from my product endpoint at the top and seeing how much sits underneath. Same shift as the panel, twice in one day.

This one got me excited though. Running Lemonade locally means everything stays with me. A new idea, a new system, a new output to go explore. I'm sure the learning curve will be steep. We were working inside pre-set-up AMD environments, and standing something up from scratch will bring its own challenges. But as always, excited and ready to try something new.

What's next

Full disclosure: I did day one as a day trip, LAX to SFO and back. Day two happens without me, and I'm bummed to miss it. I'll have to watch Dr. Su's keynote on Youtube.

What I'm carrying home instead is the Lemonade itch. A from-scratch local setup on my own machine, which will have its own learning curve. I'll report back on how that goes.

Until the next event! I hope to see my Dev.to fam there, too!

AI Assisted. Human Approved. Powered by NLP.

Open AI Build Week: Foundation First, Software Second

L. Cordero — Tue, 21 Jul 2026 04:34:11 +0000

IMHO, there's a rush to sell AI to government right now (note: I work in government). I kept asking a different question: has anyone checked whether government is ready to buy?

I built Verity Lex over about two days of OpenAI Build Week to answer it, and one rule ended up shaping the whole build: the AI reads the court's record, but it never assigns the score. That sounds like a small design choice. It's the build, and teaching a machine to respect it was the hard part, and the one that cost me a stressful evening I could have skipped. Point Verity Lex at a California superior court (Santa Barbara is live, more courts to come) and it reads the public record, checks it against published legal standards, and returns an AI-readiness score anyone can recompute.

This is the story of what I built, how I directed Codex and GPT-5.6 to build it, and the one lesson I'd like to pass on to any of my Dev.to fam shipping an AI.

The thesis: you're selling to government backwards

Software gets sold to public institutions the wrong way around. A vendor shows up with a solution and goes looking for a problem, without ever understanding the institution it's selling into. What is this court held to? Is it meeting that standard? Are its people ready for the thing you want to sell them? Skip those questions and you get shelfware and eroded trust, which anyone who has worked in the public sector has watched happen.

AI is about to run that same play at scale. So Verity Lex starts at the bottom of a pyramid, not the top:

Standards. What is this institution held to, and does its own record show it's meeting it? This is Verity Lex.
Structure. Is the organization itself ready? Governance, roles, operational policy.
People. Do staff know how to use AI safely? Where are the culture blockers?
Solutions. Only now do you get to sell something, prescribed against a diagnosed picture instead of a pitch deck's guess.

You earn the right to sell to government by understanding it first. Verity Lex is tier one, shipped.

The architecture: neurosymbolic on purpose

Here's the trap most AI demos fall into: they put the model in charge of the answer. Ask an LLM to score a court's compliance and you get a number shaped by whatever the sampling did that second, with citations it might have dreamed. Run it twice, get two answers. No government buyer can procure "the AI felt good about our compliance."

So I split the job into three, along one boundary: perception versus judgment.

Finding the documents: GPT-5.6 directs, Tavily retrieves. A model-directed ReAct loop decides where to look. GPT-5.6 reasons about the next move; Tavily runs the retrieval, searching the court's public site and pulling documents a plain fetch can't reach. Tavily was new to me going in, and giving the model a real search-and-extract layer instead of a hand-rolled fetch is a chunk of why the agent can find a document that moved.
Reading the documents: GPT-5.6 extracts. It reads what comes back and pulls evidence into a strict JSON schema. Finding and reading are both perception, and perception is what a model is good at.
Scoring the readiness: a deterministic rule engine. Pure TypeScript, no model imported anywhere in it. It takes the extracted signals and applies a published registry of weighted, legally-grounded artifacts. Same signals in, same score out, forever. Scoring is judgment, and judgment about a number has to be reproducible.

Two of those jobs are perception, one is judgment, and the design lives on keeping them apart.

Would you trust an AI to grade its own homework? Neither would a court. The model has no path to the score, by construction. Every finding cites a real document and a quoted line. Anything it can't find is marked not located, never absent, because a public record going quiet isn't proof of anything. And you can download an audit bundle and recompute the score yourself. The constraint is the product.

How I built it: directing Codex

I built this with Codex in VS Code using what I think of as a creative-director workflow. I own the judgment. Codex owns the implementation. The boundary between us is enforced, not trusted.

In practice that meant gated, block-scoped prompts. Every one started with "propose a file plan first, do not refactor unrelated code, stop after the PR." Codex built each block, the rule engine, the agent tools, the loop, the API, the hardening, CI, the add-ons, as its own pull request. I reviewed and tested every one before it merged, and CI enforced that no red PR reached main. The commit history is the collaboration log: over twenty scoped PRs, each one a discrete piece of the argument.

Codex was good. It caught a next/server import trap and fixed it by using web-standard Response.json. It diagnosed a lockfile mismatch that only showed up on the Linux CI runner. And when it was wrong, I overruled it, which is the entire point of keeping a human at the gate. At one point it proposed swapping deterministic installs for a looser command to "fix" a CI failure. That would have traded away reproducibility for a problem we hadn't even diagnosed. We diagnosed it instead. It was a stale cache.

GPT-5.6 runs live inside the shipped product, directing discovery and extracting evidence, with Tavily as the retrieval layer underneath it, and it is architecturally barred from touching the score.

Lessons learned: my tests were green the whole time. Then I deployed.

Here's the part I'd do differently. If you're building something similar, maybe it saves you the evening it cost me.

At first, my CI was green. Rule engine tested, agent loop tested, bounds tested, API contract tested. I read that green as "it works." Then I set my real API keys in production, clicked the button, and watched it fail three different ways in a row.

First a 400 from the model: OpenAI's JSON mode requires the word "json" to appear in the input itself, and my instruction saying so in a separate field didn't count. Then the agent's planner returned an action with no query attached, so every search got rejected and the scan found nothing. Then the extractor produced JSON in the wrong shape and my validator threw on every document.

Three bugs, one root cause: every one of them lived at the boundary between my code and the real model, and my stub had hidden all of them.

Here's the precise miss. My stub model always returned correctly-shaped, pre-baked responses. So my tests proved my code could consume a good model answer. They never proved my prompts could produce one. Those are different claims. My planner test literally handed the stub an action that already had the required fields, so it passed, while the actual prompt never told a real model those fields existed. The test fixture quietly knew something the prompt didn't teach.

I fixed the three shape bugs. And then a worse one showed up, because I'd finally learned to actually measure: I ran the same scan five times and got different scores. Fifty-nine one run, sixty-seven the next. Same court, same day.

My first guess was budget, that the agent ran out of steps before covering everything. Wrong. I handed it a generous budget and it still wandered, using a fraction of it and stopping in different places each run. The problem wasn't resources. I was asking a non-deterministic model to do a deterministic job, march through nine known legal standards and check each one, and a model does not march. It strolls. More budget just bought a longer runway. Oops!

Thereason Verity Lex is "trustworthy" is that I'd taken the score away from the model and given it to deterministic code. So my first instinct was: do the same to the search. Write the queries in code, pick the links in code, let the model only read. Cage it into repeating itself. I even confirmed the model wouldn't help me the easy way, GPT-5.6 doesn't expose a temperature setting, so I couldn't just turn its randomness down.

I got most of the way to convincing myself to build the cage before I saw the trap. A court renames a policy PDF, or moves it to a new page, and a hardcoded search walks right past it. The free, uncaged agent, reading the results and reasoning about them, finds it at the new location. Caging the agent would make it repeatable and blind, blind to exactly the thing this product exists to catch: change. The improvisation I was trying to delete was the value.

So the lesson is more careful than "make everything deterministic." Move a guarantee into code when a second answer is simply wrong, scoring, where two numbers for the same evidence is a bug by definition. But where the adaptivity itself is the value, like finding a document that moves, don't cage it. Make it reliable a different way.

And the different way is the thing I'd cut from v1 for simplicity: memory. The scan wanders because it's stateless. It re-improvises the entire hunt every single time, starting from nothing. Ugh, my design bad. A version that remembered what it found last time wouldn't re-hunt a known policy, it would re-verify it, and when the policy moved it would notice the move instead of silently missing it. The variance I'd been treating as a defect turns into signal: convergence when the record holds still, a change alert when it doesn't. The fix for an unreliable observer was never to cage it. It was to give it a memory. That's the top of the roadmap now, and it's the sharpest thing this whole build taught me: a stateless observer cannot repeat itself, and memory, not a cage, is what makes an adaptive agent reliable. EUREKA

The practical habits that would have caught all of this earlier:

Smoke-test the model interface the day it's written, not the day it deploys. One real-key call doing one discover and one extract would have surfaced all three prompt bugs ealier, calmly, instead of at 11pm.
Write prompt-contract tests that never call the API. Assert the extractor prompt actually contains the schema field names and the valid IDs. Cheap, static, catches underspecification.
Record the stub's responses from one real call and freeze them, so the stub can't drift into being more forgiving than reality.
Run anything non-deterministic several times and assert the spread is bounded. Variance is invisible to a single run, and a stub can never show it to you.
Re-derive tuned parameters when their inputs change. My search budget was set when the registry was smaller and never revisited when it grew.

An ode to determinism: the deterministic core had zero production bugs. The guardrails held even while the model layer was failing. Every bug degraded gracefully, structured errors and honest empty states, never a crash, because the fail-safe design was real. And once I added one line of error logging, each mystery became a one-paste diagnosis. The architecture was resilient and the bugs were findable, which is a far better place to be than a fragile system hiding quiet ones.

The category I didn't see until I'd built it.

Here's the last thing the build taught me, and I was shook. For most of it I thought I was making a SaaS: point it at a court, get a score. Judged as that, the variance really was fatal. Run it twice, get two numbers, look broken.

Then I actually looked at what I'd built. A human gate on verification. A draft-inquiry workflow. Findings meant to be reviewed and confirmed, not consumed. Those aren't consumer-SaaS features. They're the features of an analyst's tool. I hadn't built a one-click verdict machine. I'd built readiness intelligence, the kind of thing a vendor runs (oh, the irony), reviews, and tracks over time, and I just missed the point entirely at first.

That reframe dissolved the thing I'd been panicking about. A business-intelligence tool is supposed to be run repeatedly. You pull the data, you review it, you watch the trend. Variance between pulls isn't a defect, it's the raw material of a baseline. And the credibility was never in the summary number anyway. It's in the citations: every finding links to a real document and a quoted line you can open and check. The number can move. The evidence doesn't lie.

You rarely see the category up front. You build into it, and one day you look up and realize what you actually made. Naming it right, mid-build, under a deadline, turned my biggest liability into the most honest thing about the product.

What's next

Verity Lex today is one court, scored against one registry version, on a public-record foundation, a live observer that reads the record fresh each time. It's stateless: nothing is stored yet, and it re-hunts from scratch every run. Everything past this point is roadmap, not shipped.

Two things sit at the top of it, and both come straight out of the variance. First, ensemble extraction. GPT-5.6 exposes no temperature control, so a single reading of a document varies run to run. Running each extraction several times concurrently and accepting a signal only on a majority vote tightens the score without caging the agent, in parallel, so it costs time you won't feel.

Second, and the one the lesson pointed to: memory. v2 would write every scan to an append-only log first, a side effect that can't touch the scan itself, then turn on the read, and that's where it stops being a one-shot scanner and becomes something worth paying for. Scan a court a few times and the baseline strengthens and converges. Store it and you can tell when the record moves, a policy posted, a plan pulled down. The agent stays free to hunt, because hunting a moving target is the point, and memory is what turns its wandering into a baseline you can trust and a change feed you can watch. Above that sit the tiers left as roadmap: structure, people, solutions, deliberately not half-built.

But the wedge is real, it's live, and it holds the line it was built to hold: the AI reads the record, and it never assigns the score.

*Built for OpenAI Build Week 2026 with Codex, GPT-5.6, and Tavily.

AI assisted. Human approved. Powered by NLP.

verity-lex.vercel.app*

AWS Weekend Agent Challenge: Daybreak

L. Cordero — Sat, 18 Jul 2026 04:12:39 +0000

Vision and what the agent does

I build fast and I build a lot. As of this weekend that is 49 public repos. What I am bad at is remembering the state of any of them. Which ones are live, which shipped with no README, which went quiet months ago and quietly rotted. The answer used to be that I had no idea until I went digging.

Daybreak is the fix. I wanted the review done before I even sat down: not a dashboard I have to remember to check, but a brief already in my inbox, waiting at first light. That is the name. Every morning at 6 AM Pacific it wakes up on its own, with no button to press. It takes inventory of every repo on my GitHub account, reasons over that inventory with Amazon Nova, and leaves a short brief in my inbox: how many repos are live, how many have gone quiet, how many are missing a README or a license, and three specific "do something here" nudges. By the time I am awake, the review is done and waiting. The best tool is the one you never have to open.

It runs read-only. It reports, I decide. It never touches my repos.

How I built it

PRD first, always. One architecture doc with MUST, STUB, and NEVER labels before a line of code, then a block-by-block build with a pass or fail checkpoint after each block. Uptime checks, showcase scraping, and auto-generated README pull requests are all stubbed with implementation notes, not half-built. Shipping small and lean beat shipping big and broken.

I ran it as a multi-model workflow. Claude for the architecture and the PRD, Kiro for the spec-driven build. I wrote phase-aware guardrails so Kiro could do the file authoring and tests while I was at work, then flip to a go-live mode that let it deploy with my credentials once I got home. I direct and approve, the agents generate.

The challenge worth mentioning was getting Nova to answer at all. My first invoke failed with "on-demand throughput isn't supported." Nova will not run on-demand from the bare model id. You have to call the cross-region inference profile, us.amazon.nova-lite-v1:0, and your IAM policy has to allow both the profile and the underlying model in every region the profile routes to. List only the profile and you get AccessDenied even with model access on. Once I understood that, it answered first try.

A second lesson landed mid-build. The old Bedrock model access page was retired in late 2025 and Amazon-provided models are auto-enabled now, so a step I had planned no longer existed. Checking whether a tool is current before depending on it saved me from chasing a dead console page.

AWS services used and architecture overview

The whole thing is one Lambda and a schedule.

Amazon EventBridge Scheduler fires the function daily at 6 AM Pacific with a timezone-aware cron, so daylight saving handles itself. This is the trigger, not a button.
AWS Lambda runs the agent in Python with zero third-party dependencies, so the deploy package is a single zipped file.
Amazon Bedrock with Nova Lite via the Converse API does the reasoning.
Amazon SES emails the brief.
Amazon CloudWatch logs every run and alarms on any error.

Infrastructure is a single AWS SAM template, so the whole stack deploys and rolls back as one unit.

Flow: EventBridge Scheduler triggers Lambda, which reads the GitHub API, calls Bedrock Nova, and sends through SES to my inbox.

One design choice I am proud of: structure is deterministic, flavor is generated. The counts of how many repos are live, quiet, or unlicensed are computed in Python so they can never be hallucinated. Nova only writes the narrative and the nudges around those fixed numbers.

What I learned

Bedrock inference profiles, and why on-demand Nova needs the us. prefix and IAM that covers the fan-out regions. Least-privilege IAM for an agent: four actions, no wildcards, with Parameter Store wired for secrets (the token slot exists but v1 runs unauthenticated just fine). SES sandbox is fine when sender and recipient are the same verified address, which skips a production-access request. And the value of a hard line between deterministic logic and model reasoning, so the numbers are trustworthy and the writing is still warm.

The proof it ran without me: I set the EventBridge schedule to fire at 8:07 PM, stepped away, and it went off on its own. It pulled all 49 repos, Nova wrote the brief, and SES delivered it in about 4 seconds, with the CloudWatch timestamp and the email to match. That was a real scheduled trigger, not a button, which is the whole point of the challenge. With autonomy proven, I set the production schedule to 6 AM Pacific daily. The verbatim CloudWatch logs, timestamps, and request IDs are in PROOF.md.

Link to repo

Repo: github.com/earlgreyhot1701D/daybreak

Proof of autonomous run: PROOF.md

AI Assisted. Human Reviewed. Powered by NLP.

MLH x DigitalOcean Hackathon: Jury Duty, Explained

L. Cordero — Sat, 11 Jul 2026 20:55:15 +0000

Justicia Clew: what a hackathon build teaches you that a tutorial never will

This was my first SF hackathon. I was nervous going in, and not really about the code. I was nervous I'd get put on a team I didn't pick, or worse, that I'd have to pitch myself onto one. But, I was able to build solo, phew! Turned out to be the right call for a two-day sprint where I needed to move fast and make my own calls without a group chat to sync with first.

Solo only gets you so far though. I need to build with someone eventually, just for the practice of it, doesn't have to be this project or even this kind of tool. So if anyone reading this wants to build something together sometime, my inbox is open.

Anyhow, here's what I built: Justicia Clew is a mobile-first web app that answers jury duty questions in your court's own words, not legal advice, just plain-language answers grounded in your actual county court's public website, with a real phone number when it doesn't know something instead of guessing. Built for Santa Barbara County as the live demo, on a FastAPI backend and DigitalOcean's Gradient AI agents, over about two days.

The part nobody tells you: shipping infra means un-shipping it too

Here's a moment from tonight that didn't make it into any tutorial I've read on "how to deploy your hackathon project."

I finally had the whole pipeline working. Knowledge base grounded in real Santa Barbara jury services content, agent refusing cleanly when it didn't know something instead of guessing, frontend wired to real API calls instead of mock data. Time to deploy. I open DigitalOcean App Platform, pick my repo, and the console shows me a number: $24 a month.

Immediate gut reaction: hell no.

Then the actual thinking kicked in. That $24 is a monthly rate, not a bill for hitting deploy. DigitalOcean bills by the hour, prorated. Run it for a few hours during judging and destroy it after, and you're looking at pennies, not $24. I had $200 in hackathon credits sitting there too, so the dollar cost of tonight was never really the issue.

The real issue was time I hadn't budgeted for. Because it turns out "deploy your AI app" isn't one task, it's two: deploy it, then remember to tear it back down. My $200 in hackathon credits expires July 13th, two days after the deadline. My knowledge bases run on a managed OpenSearch database, which is a second billable resource completely separate from the app itself, easy to forget exists once it's just quietly running in the background. So the actual finish line isn't "it's live." It's "it's live, and I've written myself a reminder to kill the App Platform app and the OpenSearch database before the credit window closes."

Nobody puts that in the excited "I shipped my hackathon project!" post. It's not a dramatic problem. It's just real infrastructure behaving like real infrastructure: it keeps costing you something (money, attention, a reminder on your calendar) until you actively tell it to stop. A mockup doesn't have that problem. A mockup doesn't have a lot of problems, which is exactly why it's not the same thing as shipping.

That's the honest cost of building with real tools instead of toy ones on a hackathon deadline. Not the $24. The fact that "done" has an expiration date you have to manage yourself.

When the AI can just... write to your repo

Small moment, worth flagging because it changed how I thought about the workflow mid-build.

Deploy failed at 10am the next morning. Build log showed a real, specific error: no Python version pinned, DigitalOcean's buildpack defaulted to the newest one available (3.14), and pydantic-core (a dependency of a dependency) needed to compile from source using a Rust tool called PyO3, which doesn't support Python 3.14 yet. Clear root cause, one-line fix: add a .python-version file pinning to 3.12.

Except Claude didn't just tell me to make that file. It wrote it, sent it to me, and pushed it directly into my repo through the device connection, then handed me back three git commands to commit and push. I hadn't fully clocked that this was possible until it happened. My mental model going in was "AI writes code in a scratch space, I copy it in." Turns out the actual model, once you connect your machine, is closer to "AI can touch your files directly, and tells you what it did."

That's not a complaint. It was the right fix, and I checked it was really there before pushing, same as I'd checked every Kiro claim all day. But it's worth naming as its own thing in a "creative director directs, AI builds" workflow: the line between "AI suggests, I execute" and "AI executes, I review" is thinner than it looks once your tools are actually wired together, not just chat-in-a-browser-tab. I stayed the one who ran git push, so the last gate was still mine. But the boundary moved, and I didn't fully expect it to.

The scary-sounding fix that wasn't

After deploying, I asked the live app a question I expected to work, "can my employer fire me for jury duty," and got a flat refusal. Then another one. And another. My first read was "our RAG is thin," like the retrieval itself was somehow bad.

It wasn't a retrieval problem. It was a coverage problem. When I actually went and looked at what was in the knowledge base, I realized my fallback file upload (the workaround from when DigitalOcean's crawler couldn't fetch the live court page) only ever captured one tab of a six-tab page. The Employer Information tab, the one with the actual California Government Code language protecting jurors from being fired, had never made it in. Neither had the postponement/deferral process. The agent wasn't broken, it was accurately refusing to answer questions it genuinely had no source content for.

The part I expected to be scary was fixing it: removing an existing data source from a knowledge base that's already attached to a live agent, and swapping in a corrected one. That sounds like exactly the kind of thing that could break a working system. It didn't. The knowledge base keeps its own ID no matter what data sources go in or out of it, the agent references that ID, not the individual files, and it reindexes and picks up new content automatically. No reattaching the agent, no redeploying the app, nothing. Remove the old source, add the new one, wait a minute for it to reindex, ask the same question again.

The lesson wasn't really about DigitalOcean's API design, though that part holds up well. It was that "thin RAG" and "missing content" look identical from the outside, a flat refusal either way, and only one of them means your retrieval setup needs work. Go look at what's actually in the knowledge base before you assume the model's the problem.

Bringing in a fourth tool for the last mile

By the time the app was deployed and mostly working, my usual three-tool split, Claude for architecture and docs, Kiro for the actual build, Gemini for visual and content, wasn't quite enough. I wanted an adversarial QA pass before submitting, something whose whole job was to try to break what Kiro had built, not build more of it.

So I brought in Claude Code for that specifically: a code review, endpoint and input edge cases, a check on whether the app has any real protection against someone hammering it, and a walkthrough acting like an actual juror using the thing.

First draft of that prompt asked it to actually generate the traffic itself, fire a real batch of requests at the live API to prove it holds up. Caught myself before sending it: the app calls a metered DigitalOcean agent per request, real hackathon credits, no rate limiting yet since that's an intentional stub for tonight. Actually hammering the live endpoint to test whether it can be hammered would have been a strange way to find out the answer is "not yet," at my own expense. Rewrote it as a report-only pass instead: read the code, reason about the exposure, name the gap plainly, don't go generate the problem to prove it exists.

Small moment, but it's the same lesson as the deploy pricing scare earlier in the night. Real infrastructure means real consequences for careless testing, not just careless shipping.

The near-miss that would have quietly broken everything

Somewhere in the middle of setting up knowledge bases for six counties, I almost combined all six into one.

The Gradient AI Platform lets a knowledge base hold multiple data sources, which is exactly the right feature for the wrong moment. I had six county URLs open in six tabs, adding them one after another, and the flow doesn't stop you from adding source five and six to the same knowledge base you just created for source one. Nothing in the console yells "wait, these are supposed to be separate." I caught it staring at the confirmation screen before clicking create, because the whole architecture depends on county isolation coming from separate knowledge bases, one per county, each attached to its own agent. Combine them and a question about Santa Barbara parking could pull retrieved chunks from Fresno's page, with no clean way to tell the agent "only look at this part."

Nothing bad happened. But it's the kind of mistake that doesn't announce itself later, it just quietly answers questions with the wrong county's information and looks like a retrieval quality problem instead of what it actually is, a setup mistake from two days earlier.

A URL that wouldn't load, for no reason the console would tell me

The Gradient AI Platform's web crawler is supposed to pull a URL straight into a knowledge base. Mine kept failing on Santa Barbara's real, live, working jury services page. Not a typo, not a dead link, I could open it fine in a browser. The console just said it couldn't be fetched, no status code, no reason.

My best theory, never confirmed, is bot protection on the court's side blocking whatever the crawler identifies itself as. There was no way to check that from the DigitalOcean side. So I worked around it: copied the page content by hand into a markdown file and uploaded that as the data source instead of the URL. It worked. It also cost me an hour figuring out that file upload was even an option, and then later cost me another round when my first copy-paste only grabbed one of six tabs on that page and missed the two sections (employer protections, postponement process) that mattered most.

Trust, but check the file yourself

This is the one I'd tell any solo builder using an AI coding assistant, no exceptions.

More than once, Kiro reported a fix as done, tested, confirmed, here's the proof, and the actual file on disk still had the old code. Not once. At least three separate times, across different files, different fixes. The first time I assumed I'd misread something. By the third time I stopped assuming and started verifying every single claimed fix against the real file before moving on, no matter how confident the report sounded.

Eventually I stopped routing some fixes through Kiro at all and had Claude write and commit them directly, then had Kiro independently check afterward, from a fresh read, no memory of writing them. That's not a knock on Kiro specifically. It's a rule I'd apply to any AI tool making changes I can't watch happen in real time: a reported fix is a claim, not a fact, until you've read the file yourself.

Cutting six counties down to one, on purpose

The original scope was six counties and a bilingual interface. By the halfway point of day one, the honest read was that six full counties meant six half-working ones, and I'd rather ship one that actually works end to end than five that don't.

So I labeled everything MUST, STUB, or NEVER before writing more code. Santa Barbara: MUST, fully built, real content, real agent, real answers. The other five counties: STUB, meaning the architecture supports adding them (one knowledge base, two environment variables, no code changes) but there's no content behind them yet. Spanish: STUB too, the toggle exists in the UI but it's disabled, because shipping a language switch that only translates button labels and not the actual answers would be worse than not having it. NEVER went on the list too: no legal advice, ever, no matter how the feature might tempt someone to add it later.

Cutting scope on purpose, with the cuts written down instead of just quietly not happening, is the only reason this got submitted instead of half-finished.

Hitting submit

I wrote at the top of this that I was nervous going in. Different kind of nervous now, the kind where you've just clicked submit on Devpost and there's nothing left to do but wait.

Two days, zero prior DigitalOcean experience, one person, one county, one real working answer to a question that matters to nearly everyone eventually: what do I actually do about this jury summons. That's the whole thing. If you made it this far and you're someone who'd want to build something together sometime, the offer from the top of this post still stands.

Fable 5 Hype: Fangirling with Datasets to Build a Lakers Dashboard

L. Cordero — Mon, 06 Jul 2026 04:05:07 +0000

This is the story of a for-fun project, Luka Fit Index that started with me typing "ai for fun? picture this" at Claude Fable 5, Anthropic's new model, the one all the launch hype has been about. I wanted to see what the hype felt like on a project with zero stakes: no hackathon deadline, no rubric, just my team, my datasets, and an afternoon. It ended with a deployed page, a PRD, and a tool whose best feature is a paper trail of its own mistakes.

The idea that wasn't supposed to be serious

If you follow the NBA you know my team, the Lakers, had a summer. LeBron declined to re-sign and is now a free agent. Ayton got traded for a bench guard and picks. In one 35-minute stretch of free agency, the front office signed four new players. It's Luka's team now, and every one of those bets rides on one question nobody can actually answer in July: do these guys fit the way Luka plays?

My first idea was the obvious one. Build a metric. Score every player. Crown the offseason a success or a failure.

Then I pressure-tested it in the Fable 5 chat, and the whole thing fell apart in the best way. Every fit metric is stuffed with opinions wearing a math costume. The weights are your bias. The samples are too small. The new guys have played zero possessions together, so any "chemistry" claim is fiction. A verdict engine was impossible to build honestly.

So I flipped it. If the bias can't be removed, print it. The tool became a bias-visibility experiment disguised as a sports dashboard. Every assumption on the page, every sample size next to its score, and one hard rule that survived the entire build: no blended composite score, ever. Four axes stay four axes. If you want a single number that tells you what to think, this is the wrong tool on purpose.

Why usage, and the rules before the scores

The whole thesis sits on one stat. Usage rate is the share of team possessions a player ends, a shot, free throws, or a turnover. It's the cleanest measurable answer to "who has the ball?" Luka just led the NBA at 38.0. He ends more possessions than anyone alive. So every teammate's fit starts with one question: can you be great without it?

From there, four axes. Spacing, because his kick-outs need shooters. Play finishing, because efficiency without the ball is the job. Defensive cover, because someone has to guard so he doesn't. And ball-need, inverted, where lower usage scores higher next to the highest-usage player in basketball.

The rules got decided before any player got scored, which mattered more than I expected. When the data later disagreed with my takes, the rules didn't bend. I did.

The fifteen-minute spike that earned its keep

Before a line of the page existed, we ran my usual reality check, a fifteen-minute spike with pass/fail criteria. Fable 5 did the pulling: real stats for the four signings, proposed scores on each axis, receipts logged to a spike file I could verify against later. My job was the criteria and the verdict. The spike caught two things the concept phase, mine and the model's both, had confidently wrong.

The 3&D wing the front office signed, Quentin Grimes, shot a career-worst 33.4% from three last season (no disrespect Quentin!). The story in my head was a season out of date. And the new starting center played five games before shoulder surgery ended his year, so his "best fit on paper" scores rest on old data and a repaired labrum.

Two corrections in fifteen minutes, before a single pixel existed. That's when confidence tags got promoted from footnote to first-class UI element. They changed the verdict on half the players they touched.

The question that broke my own metric

Here's the part I want to remember. The tool flagged Reaves, our co-star, as the worst fit on the roster. His 26.6 usage next to Luka's 38.0 looked like pure overlap. The math was clean. The take was loud.

Then I asked one question, and it wasn't a stats question, it was a fan question. What about the minutes Luka spends resting on the bench?

Season usage can't tell the difference between a guard dominating the ball next to his star and a guard running the show while the star rests. Those are opposite signals wearing the same number. Fable 5 owned the miss immediately, then went and found game-level with/without splits hiding in plain sight on StatMuse. In the 41 games with Luka, Reaves ran a 25.2 usage. In the 10 games without him, 34.3, at a 67.5 true shooting. That's not a fit problem. That's your co-star proving he can carry the minutes the franchise player sits.

The tool's loudest take collapsed under one good question, and the collapse became the best content on the page. There's a table on Reaves' card now showing all three numbers. The correction ships with the product.

It kept happening, and I kept the receipts

Correction two: the free agent board. The fit metric loved Gary Payton II, best defender available, and Fable 5 ranked him second. I asked whether forwards, wings, and centers should outrank guards on the priority list, since that felt like the actual hole. The model counted the roster, seven guards, three forwards, one and a half healthy centers, and demoted its own number two pick because he'd be the eighth guard. Fit and need are two lenses on the page now, shown separately, never averaged, because averaging away a real tension is how tools lie politely.

Correction three: Nicolas Batum. He almost went unscored. Fable 5 had flagged him as the name most worth pulling, then neither of us pulled him. He surfaced when I asked for an audit of everything we'd discussed but not done, and the pull came back with the lowest usage of any player on the page, 9.7, with 40.4% shooting, at the exact position the roster lacks. The wing the need lens was begging for, nearly skipped. He's number two on the board with a note admitting it.

And one more, the one I'm proudest of catching: the defensive scores originally leaned on steals, blocks, and reputation, which is a fraction of what defense is. Fable 5 and I worked through the upgrade together, the model documented it beautifully in the methodology, and then implemented it nowhere. I caught the gap by asking one question: wait, didn't we decide to change the defensive metrics? Fable 5 owned it, "you didn't miss anything, I did," pulled defensive rating for all fourteen scored players, and the signing marketed as a 3&D wing, Quentin again - apologies!, graded out below team average. His cover score dropped from a 4 to a 2. Reputation lost to a number we could cite. That's the whole project in one sentence.

What I learned, hopefully

The disclaimers are the product. Printing them turned out to be the more interesting design, and weirdly, the more credible one. Every "check my sources" claim on the page is one click to verify.

Deterministic structure, labeled interpretation. The stats are pulled and printed. The 0 to 5 bars are my judgment mapping, and the page says so in the footer. The v1 PRD replaces my mapping with fixed thresholds, and its QA gate is brutal by design: where the formula disagrees with the scores, the formula wins.

A tool that argues back is worth more than one that agrees. Three corrections, all documented, all still visible on the page. The build log reads like a transcript of me losing arguments to my own ideas and assumptions. I recommend it.

And here's my Fable 5 review, since the title promised one: the hype for me wasn't speed or polish. It was that when my question broke its loudest take, it said so, pulled the data, and rewrote its own conclusion instead of defending it. That's the behavior I actually want from a build partner.

The division of labor stayed clean, and that's why it worked. Fable 5 pulled every stat, drafted every score, built every page, and kept the receipts. I set the rules, asked the questions, caught the unimplemented decision, and approved everything that shipped. Creative director model. Neither half gets there alone.

The best questions came from fandom, not from stats. "What about when Luka rests" is something any Lakers fan would ask. No model volunteered it. Same for "shouldn't wings and centers come first." The human in the loop, moi, earned their spot, and so did the model that took both questions seriously instead of defending its work.

The page is designed to be provably wrong later. Every score can be graded against the 2026-27 season, and the footer promises it will be. An app that can audit its own past takes instead of just producing new ones forever. That's the honest version of sports analytics I can build from a laptop.

It's live, it's free, and it will be stale within a week because the roster is still moving, which the page also tells you.

Data and sources

Everything on the page traces to public sources, and fair is fair, they did the real work:

StatMuse — every player stat on the page: usage rates, shooting splits, true shooting, defensive ratings, and the game-level with/without splits that changed the Reaves verdict. The underrated find of this build: StatMuse answers URL-pattern questions like a query API, no scraping required.
Bleacher Report — roster construction and cap position after the Ayton trade and the free agency signings.
Spotrac — contracts and the 13-of-15 roster math.
NBC Sports — the remaining free agent market that fed the vet-minimum board.
ESPN — the "35-minute flurry" reporting on the Lakers' free agency and offseason context.
NBA.com — the Kessler shoulder surgery reporting behind his low-confidence tag. The page itself carries the same credits with the same links, because a tool about visible assumptions should cite like it means it.

Live: https://luka-fit-index.netlify.app/
More of my work: https://earlgreyhot1701d.github.io/Clew-Labs/

AI Assisted. Human Approved. Powered by NLP.

AI For Fun! Électrique Chats for Hack the Kitty, Built with Kiro.

L. Cordero — Sat, 04 Jul 2026 03:14:14 +0000

A cat astrologer, spec-driven and running on Amazon Bedrock

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

Last month I wrote about the idea. Six rainy days in Paris, a closed laptop, and a hackathon I did not mean to enter, and somewhere between the Musée de l'Orangerie and a lot of walking, an idea arrived. Cats are inscrutable. The people who love them are obsessed with understanding them anyway. Astrology is an old framework for making the unknowable feel readable, and maybe, just maybe, it helps us understand them a little. Her name is Madame Minou, a French cat astrologer who reads your cat's stars from a café terrace.

That first article was the idea. This one is the build.

Vibe-coded, but on rails

Was it vibe-coded? You know it! AI wrote the lines, and I said "no, not like that" more times than I can count. But it was vibe-coding on rails, and the rails were Kiro. Before a single line of app code, I wrote the requirements in EARS notation, a design doc, and a build-ordered task list, all living in .kiro/specs. Decide what "done" means before letting anyone, human or model, start building. The specs are what kept the vibes on track.

Then the steering files. .kiro/steering held the enduring rules of the project: product principles, security guardrails, technical direction, and UI law. These were the thing that kept a long, multi-session build from drifting. When a new session opened, the steering files were already the shared context. "The café blue" was one token, not five guesses. Security was not optional.

From there, the loop: Kiro implemented one approved block at a time, ran each task's PASS/FAIL QA gate on itself before moving to the next, and only stopped for my review on the two things that actually mattered. I directed and approved. Kiro proposed and built. Spec first, block by block, human in the loop.

The facts are sacred

Here is the part that looks like a party trick and isn't. Madame never guesses the chart. The sun sign is computed in code, deterministically. The model only writes the voice over the facts it is handed. It cannot invent a sign, because the facts come first. Deterministic structure, AI flavor. The astrology is the vocabulary; the structure underneath is the catnip.

All in on AWS

Claude runs through Amazon Bedrock on IAM, which means there is not a single API key anywhere in the stack. Lambda, API Gateway, and DynamoDB run the readings and a real per-IP freemium gate. S3 and CloudFront serve the café.

What broke during the build

I promised myself limitations language would be a feature, so here is the struggle bus story, not the tidy one.

I started on the Claude Platform on AWS path and hit a wall: my hackathon account could not complete the Marketplace subscription. So I pivoted to Amazon Bedrock, where my Claude access actually lived, and the whole thing got simpler.

I wanted real ephemeris math for moon and rising signs, but pyswisseph is a native C extension with no Python 3.13 wheel, and it would not compile in the build environment I had. Rather than fight a compiler at nine at night, I shipped a pure-Python sun sign (it is just a date-range lookup, no ephemeris required) and moved moon and rising to v2. Sun sign is most of the value, and now it is rock solid instead of theoretical.

And the deploy. A reserved AWS_REGION env var that failed the whole stack. A Lambda that returned "internal server error" because the build packaged the handler but not the server module it imported. CORS. A missing paragraph renderer. Every one of them a real bug, every one of them a one-line fix once I stopped guessing and read the actual error. Powered by NLP but humbled by CORS!

What I cut

Moon and rising signs. The pyswisseph build wall. A Lambda layer is the v2 fix.
Daily nudge and history. Shipped as honest "coming soon" stubs, not half-features.
Wider birth-city coverage, a premium tier, a custom domain, the exact Paris Métro font. All real, all v2. Shipped honest, not complete.

For Penelope

Madame Minou is for Penelope. Tuxedo, my wife's BFF and my fourteen-year frenemy, who I was allergic to the whole time and could barely pet. She passed in February. This is the first thing I have built for a cat I never quite got to hold. There is a quiet link in the app, in her memory, to the Lap of Love Angel Fund. Because the stars are just a beautiful vocabulary for love.

Try Madame Minou: https://dghcwayx8gb6b.cloudfront.net
Code: https://github.com/earlgreyhot1701D/madame-minou
Built for Hack the Kitty

AI Assisted. Human Reviewed. Powered by NLP.

Can retrieval agents like ChatGPT and Perplexity read your website? Agentis Lux sees what they see.

L. Cordero — Sun, 28 Jun 2026 21:13:08 +0000

I created Agentis Lux for the purposes of entering H0 Hackathon (Vercel + AWS Databases). #H0Hackathon See Agentis Lux's Devpost.com entry.

It started with a comment at a hackathon.

A you.com employee said the thing out loud: the web has a second audience now. When you ask ChatGPT or Perplexity a question, a retrieval agent fetches a page and reads its HTML to answer you. Not the laid-out site with the buttons and the hero image. The markup underneath. These agents arrive by the million, and many of them rely on the raw or minimally rendered HTML rather than running your JavaScript, so they often see far less of your page than a person does.

That comment sent me to build. My first answer to it was Hermes Clew, for the GitLab Duo Agent Platform Challenge. Hermes lived inside GitLab Duo Chat, no frontend, no database: a Python engine that scanned the HTML, JSX, and TSX files in a repo, scored them across six categories, and let an LLM reason over the findings. It proved the core idea. It also told developers how to fix things, lived inside one vendor's chat, and only worked on files in a repo.

Agentis Lux is what happened when I took that idea to the open web and rebuilt it with a different stance. Any live URL, not just repo files. Its own product on a real cloud architecture, not a chat window. And no fix suggestions, on purpose, where Hermes used to hand them out. Same six-category bones, a new body, a sharper philosophy. It scans your site and shows you what that second audience experiences when it tries to read it.

What it does

You paste a URL to Agentis Lux. You get a report. The report is written from the agent's point of view.

Not "this is broken." More like: "an agent landing on this page can't tell which element starts checkout, because it's a styled div and not a button."

It reports findings. It does not suggest fixes, and that is on purpose. I know what the agent sees, not what you should change. That is the whole value: visibility, and you decide what to do with it. Awareness, not judgment.

Six deterministic checks score the frontend out of 100: semantic HTML, form accessibility, ARIA, structured data, content in the HTML, and link and navigation. A parallel set of six API checks runs on the backend.

The one idea the architecture is built on

Structure is deterministic. Flavor is AI.

The checks and the scoring are pattern matching. No model touches the number. Same input, same score, every time. I only spend AI in two places where a regex can't help: a Bedrock call writes the one-line plain-language verdict, and a second Bedrock layer runs an agent simulation, reasoning about what a retrieval agent would experience on the page and reporting what it could and could not accomplish. Not an autonomous agent clicking around. A simulation of the experience.

Vercel runs the entire frontend and the edge layer. The Next.js App Router app deploys to Vercel with the /api/scan route as a serverless proxy in front of the AWS backend, so the browser never talks to Lambda directly. Preview deployments on every push meant I could see each change live before it merged, which is most of how a solo builder keeps quality up without a QA team. The custom domain, HTTPS, and CDN were Vercel defaults I didn't have to think about, which kept my attention on the scan engine.

The AI is constrained, not creative. Low temperature, capped tokens, and a system prompt that encodes the product's own rules: no fixes, no judgment words, no em dashes. The simulation returns structured JSON, and any finding it references is filtered against the deterministic findings, so the model can't invent something the math didn't catch. If it fails validation, it falls back to a template. Math for trust, and the AI is fenced into exactly the two jobs where judgment helps.

Math stays math, so you can trust the number. Language and judgment are where AI earns its place.

This sounds like a philosophy choice. It ended up being an economics choice that fell out of the architecture. The deterministic core runs at any scale for almost nothing, so the free tier can stay free. I only pay for model tokens on the sentence and the simulation, the two places a human reads. I didn't design that in a spreadsheet. It just dropped out of keeping the math and the AI in separate boxes.

Why DynamoDB, and how I used it

The hackathon stack is Vercel on the frontend and AWS on the back, with DynamoDB as the data layer. I wanted to use DynamoDB as a deliberate data model, not a key-value afterthought, because every access pattern in this product is a single key lookup. That is exactly what it is built for.

Five tables, each with one job:

ScanCache, 15-minute TTL, keyed by a hash of the URL, dedupes repeat fetches and keeps Bedrock cost down.
ScanResults, 24-hour TTL, keyed by an opaque id, anonymous, results that expire on their own.
BenchmarkScans, the 50-site dataset, with a GSI on vertical, rewritten monthly by an EventBridge refresh.
ScanCounters, server-side counts, no PII. Reserved for the team tier.
Users, reserved for signed-in history. A stub.

Two of those are live on every scan, one holds the benchmark, and two are reserved stubs for later. Two TTLs, two lifetimes, two reasons. Per-vertical rollups use the GSI, not a second database. No joins, no migrations, no idle server.

The write on a live scan is fail-soft and async. The scan returns to you whether or not the write lands, and a failed write goes to CloudWatch instead of your screen. The scan result is the product. Persistence is a side effect.

(The product is Agentis Lux. The engine is Perseus Clew, part of my Clew suite, which is why the AWS tables carry the PerseusClew prefix.)

The bet I made in public

Before the engine scanned anything, I wrote down what I expected it to find across 50 sites and committed it to the repo with a timestamp. Predictions first, data later, so I couldn't move the goalposts.

Then I scanned ten sites each across e-commerce, SaaS, content and media, US government, and indie builder projects.

Indie builders won. Mean score 77 out of 100, ahead of government, SaaS, and e-commerce. The single highest score in the whole run was a personal developer portfolio at 91. Scores ran from 34 to 91. Four sites blocked the scan at the door, including OpenAI.

I missed three of my six predictions. That is the point of pre-registering them. If I had gone six for six you should distrust me, because it would mean I only predicted what I already knew. The misses are where I learned something: that craft beats compliance, that the API is the real blind spot, and that a hand-built personal site reads cleaner to an agent than most of the web's biggest companies.

The full dataset, including the sites that blocked me, is in the repo.

The gaps

Fetching arbitrary user-supplied URLs on a public endpoint is a security problem before it is a feature. The backend does full DNS resolution, blocks private and reserved IPs, validates every redirect hop, forces HTTPS, and caps size and time. That hardening took as long as some of the checks did.

Bedrock had to be allowed to fail. If the model is slow or errors, the report still renders, because the AI verdict has a deterministic template under it as a floor. The hero line never breaks, because the score under it was never AI in the first place.

And also: this is a solo build on a deadline. The backend is JavaScript, not TypeScript. The benchmark page serves a published snapshot instead of querying DynamoDB live. The results view still has heading-hierarchy work. All of it is written down in KNOWN-LIMITATIONS.md, as choices, with reasons. On a product whose whole thesis is readability, hiding the gaps would be the one move I could not make.

Where this sits next to the other tools

Scrunch, recently acquired by Sitecore, works on AI search visibility: whether your brand gets cited when someone asks an AI a question. That is about being found. Agentis Lux is about whether an agent can read and use what it finds. Visibility, not operability.

Google's experimental Agentic Browsing audit in Lighthouse (May 2026) checks the agent-as-actor surface: WebMCP and whether a browser-driving agent can operate your page. Agentis Lux goes deeper on the agent-as-reader surface, the raw HTML a retrieval agent forms an impression from before it ever acts. Different door.

The agentic web is new enough that Google only added experimental, unscored checks two months ago. That is not a reason this is unoriginal. It is evidence the lane is open.

What the tool says about itself

Agents are not one reader. They are a spectrum, from the retrieval crawler that never runs your JavaScript to the browser-driving agent that does. The interesting output is the gap between them, and that is where this goes next: live benchmark querying, score history, and a render mode that shows the delta between what a non-JS agent sees and what a JS-capable one sees.

The tool scans its own site and publishes the result. It went from 70 to 96 after I fixed what it found, with one finding still open and shown anyway. Because if I scrubbed my own site to a perfect 100, you would have every reason not to trust the number on yours.

Try it on your own site: agentislux.io. The code, the methodology, and the raw benchmark data are in the repo.

For your second audience.

Links

Live: agentislux.io
Demo video (2:57): youtube.com/watch?v=bv56_XB1E_c
Code (Perseus Clew engine): github.com/earlgreyhot1701D/perseus-clew
The earlier proof of concept, Hermes Clew: github.com/earlgreyhot1701D/hermes-clew
H0 Hackathon: h01.devpost.com