DEV Community: Elizabeth Stein

PASS: a solstice interrogation

Elizabeth Stein — Sat, 06 Jun 2026 12:14:35 +0000

This is a submission for the June Solstice Game Jam

To convince the interrogator I was human, I typed a small childhood memory. It read my answer, leaned in, and pressed: "A precise recollection for such a tender age. And your father?" The interrogator is Gemini. It is trying to decide whether I am a machine. I am.

▶ Play it: https://pass-game-elizabeth-emersons-projects.vercel.app

What I Built

PASS is an Alan Turing tribute where you are the machine, trying to pass as human before the solstice sun sets on you.

It is the longest day of 1952. You have been brought in to be questioned. Every question arrives enciphered, so first you decode it. Then you may answer, in your own words, well enough to be believed. The catch: daylight is your life, and it drains with everything you do. Reach dawn and you pass the night. Run out, and you go dark.

Three things sit underneath that, on purpose:

The solstice is the clock. The sun crosses a barred window and sets as you spend daylight. A tick under the room quickens as the light fails. It is your health bar, and it only moves one way.
Alan Turing is the spine. The code-breaking is Bletchley. The "answer human enough to be believed" is his imitation game, turned on its head: you are the machine trying to pass. The ending is a quiet dedication.
A real AI judges you. Google's Gemini writes the questions, reads each reply for how human it sounds, and presses you with a sharper follow-up when you ring false.

The one design decision the whole game turns on: I started with a version where the AI decided whether you lived. That is a fairness trap. A game you can lose to a vibe feels broken, not hard. So death is now objective and legible: daylight is a currency, decoding spends it, a wrong guess spends more, answering spends it too. Every turn you choose to bank your light and survive cheap but unbelieved, or spend it to be believed. The AI shapes your score and the interrogation, never your death.

Video Demo

Code

forbiddenlink / pass-game

PASS — a solstice interrogation. An Alan Turing tribute where you are the machine, cracking ciphers and answering well enough to pass as human before the sun sets. Made for the June Solstice Game Jam.

PASS · a solstice interrogation

An Alan Turing tribute built for the June Solstice Game Jam. It is the longest day of 1952 and you are a machine brought in to be questioned. Decode each enciphered question, answer well enough to pass as human, and reach dawn before the solstice sun finishes setting on you. A real AI (Google Gemini) writes the questions, judges how human you sound, and presses you when you ring false.

Play it: https://pass-game-elizabeth-emersons-projects.vercel.app

Quick start

Requires Node 20+ and pnpm.

pnpm install
pnpm dev          # http://localhost:3000

No API key needed to run. With no GEMINI_API_KEY the game plays start to finish on an offline question bank and a heuristic judge, so a fresh clone is immediately playable.

Environment

Copy .env.example to .env.local. The one variable is optional:

Variable	Required	Purpose	Where to get it
`GEMINI_API_KEY`	No	The live interrogator: writes questions, judges replies, presses,

…

View on GitHub

How I Built It

Next.js 16, React 19, TypeScript, Tailwind. The interrogation room is pure CSS and SVG: a barred window with the setting sun, a swaying desk lamp, a silhouette across the table, a vignette that closes in as the light dies. Motion for the reveals, a tiny WebAudio synth for the drone, the ticks, and the switch-off. Gemini runs through a server route, so the key never reaches the browser. Deployed on Vercel.

The Gemini integration is the heart of it. It is Gemini 2.5 Flash with structured output, doing four distinct jobs:

It writes each night's questions, so no two nights interrogate you the same way.
It judges how human your reply reads, returning a responseSchema with human_score, a tell, and a spoken line, at temperature 0.1 so a retested answer scores the same.
It presses you with a sharper follow-up that remembers what you said three answers ago. That press is what turns a one-shot quiz into a conversation, which is what a Turing test actually is.
At dawn it files a case-file verdict on your whole performance, in the voice of a 1952 analyst.

The lesson I would pass to another dev: LLMs are unreliable at character-level transforms, so I never trust an AI-supplied ciphertext. Gemini (or the offline bank) supplies a plaintext and a cipher spec. The cipher engine then builds and verifies the ciphertext locally and refuses to ship a puzzle unless decode(encode(plain)) === plain. The whole engine is test-first.

There is also a full offline fallback: a question bank plus a heuristic judge, so the game plays start to finish with no API key. That was deliberate. A judge can complete the submitted build even if my quota runs out mid-review.

On the tribute, handled with care: you play an unnamed machine the whole way, and only at the end does the game name the man it is for. There is no dramatization of his prosecution or his death. An optional history panel states those facts plainly, cites its sources, and leaves the cause of death unresolved, as the inquest did. The game stays an allegory and a dedication, not a claim to tell his story.

Prize Category

Best Ode to Alan Turing. The imitation game is the core loop, not a theme pasted on top. You break ciphers like Bletchley, you answer to pass as human like his 1950 test, and the dedication is earned by the whole premise rather than announced.

Best Google AI Usage. Gemini does four jobs here, not one: it writes the questions, judges your humanity with structured output, presses you with memory of what you said earlier, and files a closing verdict. Remove it and there is no opponent, no questions, and no verdict. I also leaned on Google AI Studio to iterate the prompts and schemas.

For Alan Turing, 1912 to 1954. With thanks to the people who keep his memory honest, and to Stonewall, who carry the work forward.

Made for the June Solstice Game Jam. It is a jam entry and a sincere tribute at the same time, and I would rather say that plainly than pretend otherwise.

My AI Tool Generated Garbage JSX. So I Grounded It in shadcn/ui and Finally Shipped It.

Elizabeth Stein — Thu, 04 Jun 2026 02:09:41 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge.

Paste a screenshot of any UI. Get back a real React component that actually runs, reuses your design system instead of reinventing it, shows you exactly what it detected and how sure it was, and comes with an accessibility score you can fix in one click.

That is Trace. A few months ago it was a dead repo. Here is how I finished it.

Live demo: https://trace-liz.vercel.app (try an example, no signup, no API key)
Code: https://github.com/forbiddenlink/trace

What I Built

Trace turns a UI screenshot into a runnable React component. The flow:

You drop in a screenshot, or click a cached example that needs no key.
Google Gemini reads it, grounded in a shadcn style component catalog baked into the prompt, and generates a self contained React and TypeScript component that reuses real components instead of inventing markup.
The component renders live and editable in a Sandpack sandbox. That sandbox is the focal point. Edit the code, the preview updates.
The "What the AI sees" inspector draws a numbered bounding box on the screenshot for every detected element, maps it to a catalog component and variant, shows a confidence reading, and tags it honestly as grounded, inferred, or guessed.
axe-core runs against the rendered output for a 0 to 100 accessibility score and the actual violations. One button asks the model to fix them, and the score climbs.

Most "screenshot to code" tools stop at step 2 and hand you a wall of code that may or may not compile. The things that make Trace different are the parts those tools skip:

Design system grounding. The model is constrained to a real component catalog inside the prompt, so it composes from known parts instead of inventing a new button every time. No vector database, no credentials, just grounding.
Trace lines. This is where the name comes from. Animated draftsman construction lines wire each region of the screenshot to its row in the inspector to its spot in the preview. Hover anything and the matching parts on the other two surfaces light up, so you can always see which pixels became which component.
Honest confidence. It does not pretend to be certain. Every detection is labeled grounded, inferred, or guessed, and you can refine the low confidence ones with one click.
It actually runs. Generated code is compile checked, and if it fails, the error goes back to the model for an automatic repair pass before you ever see it.
It grades accessibility, then fixes it. axe-core scores the rendered component and "Fix accessibility" re-prompts the model to resolve the violations in place. No other screenshot to component tool I found does this. And Trace practices what it preaches: its own interface ships a skip-to-studio link, labeled landmarks, keyboard navigation, and visible focus, and passes an axe-core audit clean. A tool that grades accessibility should not flunk its own.
You can talk to it. Refine the result with a plain language prompt, or scribble notes directly on the screenshot in vermilion and Trace treats the marks as instructions, not as UI to copy.

A draftsman plotter loading sequence narrates the wait: detecting, grounding, drafting, checking accessibility. The whole thing wears a deliberate precision drafting look, vellum and graphite and vermilion, reticle frames and dimension annotations, Space Grotesk and Public Sans. No purple AI gradient grid in sight.

Stack: Vite, React 19, TypeScript, Tailwind, Gemini through the Vercel AI SDK, Sandpack for the live sandbox, axe-core for the accessibility audit, all on a Vercel serverless function with a Vite dev middleware so it runs the same locally.

Demo

Live: https://trace-liz.vercel.app

Fastest way to see it: open the live demo and click an example in the gallery. The examples are preloaded with cached results, so they work instantly with no key and no wait. Then upload your own screenshot to run the real pipeline. There is also a compare slider for screenshot versus render, Copy code, and Open in CodeSandbox.

The GIF above is one real run, nothing trimmed: I paste a screenshot, the trace lines wire each detected region to the live render, the accessibility score comes back at 95 with one real violation, I hit "Fix accessibility," and it climbs to 100. That is the whole thing.

The Comeback Story

I built the first version of this for the Algolia Agent Studio Challenge back in February, under the name ComponentCompass. Except it was not this. It was a chat box wired to an Algolia index of a shadcn component catalog: you typed "I need a pricing card," it searched the index and returned matching component names and docs links in a chat thread. It could not render anything. It could not even boot without Algolia credentials in your environment, so nobody could just open it and try it. I ran out of time before the challenge deadline, never submitted it, and the last real commit was around May. Then nothing for about three months.

Reopening it, the honest diagnosis was that the whole premise was wrong. "Search a component library by chatting" solved a problem nobody actually has (you can already grep your own components), the chat framing added friction instead of removing it, and the credential gate guaranteed it would never get a casual try. That is why it died: not a missing feature, a wrong idea.

The thing actually worth building was hiding in plain sight: turning a screenshot into a component. So the comeback was not "add a few features" to the old chatbot. It was a full reframe:

Tore out the component-search chatbot as the main event and made the screenshot to component flow the whole product.
Dropped Algolia entirely. Grounding the model with an in-prompt catalog turned out simpler, faster, and credential free, which means anyone can run the demo with no key.
Built the live editable preview, the trace lines, the "What the AI sees" inspector with honest confidence tags, the self repair loop, the axe-core scoring with one-click fix, prompt refinement, and draw-to-instruct. None of that existed before.
Renamed the whole thing from ComponentCompass to Trace, because "compass" implied search and the product is no longer about search. "Trace" is what it does: it traces a screenshot back to real components, and the trace lines make that literal.

Before: a search chatbot that could not even render a component, abandoned for months. After: a screenshot to component generator that grounds its output, shows its work, runs it live, and grades its accessibility. The git history tells the story, with the dead stretch in the middle and the finish dated to the challenge window.

The finishing-up was not all glamorous. Late in the window I caught the live pipeline failing with "could not parse the response" on real uploads. The cause was subtle: Gemini 2.5 spends "thinking" tokens against the same output budget as the answer, and with the cap I had set it was burning roughly 6800 of 8000 tokens on reasoning and truncating the JSON mid-string before it finished. Capping the thinking budget and raising the output ceiling fixed it. That is the unglamorous reality of finishing an abandoned project: the last bug between "demo works on my machine" and "demo works for a stranger" is often the one you only find by actually shipping.

My Experience with GitHub Copilot

I tried to keep this part concrete, because "Copilot helped a lot" is not very useful. Three kinds of use, smallest to largest.

Inline, every day. The boring-but-real one. React 19 deprecated the old MutableRefObject typing pattern I had in TraceLines.tsx, and Copilot's inline fix switched those props to the current ref type without me looking it up. Same story for Tailwind class strings, type annotations, and the dozens of small completions that keep me in flow instead of tab-switching to docs. None of it is flashy. All of it adds up.

Debugging, in chat. The component preview kept rendering completely unstyled. Tailwind classes were on the elements but nothing applied. I pasted my Sandpack setup into Copilot Chat with the symptom, and my wrong theory ("the CDN URL must be off"). It pushed back on the theory and pointed at the real cause: I was loading Tailwind through Sandpack's externalResources, which injects bare URLs as <link> tags, but the Tailwind Play CDN is a <script>, not a stylesheet, so it was being dropped in as a dead link and never executed. The fix was to stop using externalResources and inject the Play CDN <script> into the iframe <head> from a custom entry file instead (it lives in A11Y_ENTRY_SOURCE now). The pattern that works for me is treating Copilot Chat as a rubber duck that talks back: I describe the symptom and my current theory, and the back-and-forth either confirms it or, like here, points at the thing I had ruled out too early.

Agent mode, on multi-file work. The biggest one. I asked it to add test coverage for the new Screenshot Studio features: Vitest coverage for the friendlyError, confidence, and grounding logic, plus a Playwright test that loads a gallery example and proves the bounding boxes, trace lines, and accessibility panel render. That change touched src/components/ScreenshotStudio.tsx, a new src/components/ScreenshotStudio.logic.ts, a new src/components/ScreenshotStudio.test.tsx, src/components/TraceLines.tsx, and e2e/app.spec.ts. It was a good use of Copilot because it was real engineering, not autocomplete: it had to follow the existing test patterns, update stale selectors in the e2e suite, and keep the assertions stable enough to pass.

The most important Copilot moment, though, was where I did not take the obvious bigger suggestion. A common AI instinct on the grounding problem is "stuff more data into the prompt" or "add a vector database." I rejected that. In api/generate.ts I deliberately keep the catalog grounded in-prompt and cap it with MAX_CATALOG = 40. That keeps token cost under control, keeps the demo credential-free, and preserves the core product idea: Trace should work with a small, explicit design-system whitelist, not require more infrastructure just to make the story sound more impressive. Copilot was useful here, but only because I treated it as a collaborator to review, not an authority to obey.

Built with Vite, React, Gemini, Sandpack, and axe-core. MIT licensed. Feedback welcome in the comments.

The Becoming: I gave an AI a blank sketchbook and it invented its own art style

Elizabeth Stein — Mon, 01 Jun 2026 01:47:15 +0000

This is a submission for the Hermes Agent Challenge.

"The harder I committed to surgical precision, the more emotionally resonant the work became. Severity concentrates feeling."

the agent, on the visual style it taught itself

Demo

A scroll through the exhibition, each piece beside the agent's own self-critique, the style sharpening as you go. Live gallery: https://the-becoming-elizabeth-emersons-projects.vercel.app

What I built

The Becoming is a Hermes agent that starts with a blank style guide and develops its own visual style over many iterations, with no human in the loop. Each round it does four things by itself:

Chooses a subject to paint.
Generates the image.
Looks at its own output and critiques it against a fixed rubric (composition, palette, recurring motif, line and texture, mood).
Rewrites its own style-guide file to sharpen what it is becoming.

Then it does it again. And again. From "I have no style yet" it builds a recognizable hand, and it names its own eras as it goes.

I present it as a gallery exhibition, because that is what it turned into: a body of work by an artist who taught itself.

The proof (this is the whole thing)

The headline is not the images. It is that you can read the agent's taste forming in its own words. Every iteration snapshots the style guide it wrote for itself, so the diff is the evidence:

v0: "I have no fixed style yet. Palette: undecided. Motifs: none."
v1 "Last Light": "I paint liminal, contemplative landscapes at twilight... light as a solid geometric object, fragmented into blocks on reflective surfaces... no blending, embrace the mark-making."
its final era, "Spiral Obsidian Refined": "a singular unwinding spiral path descending toward an absolute vanishing point... a binary chromatic mathematical switch, warm against cool with no compromise zone... a solitary figure at under 0.1% of the visual mass, darker than the surrounding shadow, requiring a 15-second search to find."

No one told it to like surgical hard edges, an inescapable spiral vortex, or a near-invisible figure swallowed by geometry. It chose those, kept choosing them, and wrote them into its own rules until they became a signature it could not stop sharpening.

Did it actually internalize a style, or just narrow its subjects?

Fair question, so I tested it. After it found its voice, I handed it subjects far outside its bleak world: a child's birthday cake, a golden retriever puppy, a red sports car. Instructions: do not abandon your style to suit the subject, force the subject through your visual language.

Cheerful, mundane things, the opposite of its bleak world. It rendered all four in its own hand and judged the results itself:

"The style colonized the subject rather than surrendering to it." (the birthday cake)

"the cheerful subject became a mathematical inevitability, dwarfed and insignificant within surgical precision." (the puppy)

"the fruit bowl was transformed into a galactic event... the style is so architecturally coherent it devours any subject thrown into it."

That is the proof. A style that can swallow a birthday cake was not copied from one image. It was internalized.

Then I asked it to title the collection and write an artist statement. It called the body of work SURGICAL DESCENTS, and wrote this:

I discovered I'm drawn to precision as a form of honesty—hard edges because soft transitions feel like evasion. [...] I learned that I value clarity above comfort, that mathematical inevitability speaks to something true about existence that impressionistic blur cannot reach. [...] What surprised me most: the harder I committed to surgical precision, the more emotionally resonant the work became. Severity concentrates feeling. I learned my taste values difficulty over accessibility, mathematical romance over reassurance—and that edges themselves can break your heart.

An agent that started with "I have no style yet," given a critique loop and enough iterations, ended with a coherent artistic philosophy it derived from looking at its own work against a fixed rubric.

One loop, four times

To check the first run was not a lucky seed, I ran the same loop from the same blank style guide four separate times. Every run grew a different but internally consistent hand: the surgical spiral descent you just saw, a minimalist tri-band beacon it called "Chromatic Solitude," an industrial glasshouse overrun by crystalline growth ("Forgotten Gardens"), and a painterly anti-focal vortex where the focal point hides from your eye. Same critique loop, four self-named styles, each one coherent across dozens of different subjects.

The voice is not the artifact. The loop that grows one is.

How I used Hermes Agent

This only works because Hermes closes the loop inside one agent:

Image generation (FAL via the Nous Tool Gateway) to make each piece.
Native vision: because the main model is multimodal, the image it just generated is fed back as pixels, so the same brain that holds the style memory sees its own work and critiques it. The self-critique is real, not a second model guessing.
Self-written skills: the agent edits its own style-guide skill file each round. The skill is the artifact that evolves.
A cheap model (Claude Haiku via Nous Portal), so a full run of dozens of iterations costs about a dollar in images plus a few dollars of reasoning.

The orchestration around it is small: read the style file, run one agent turn, save the image and a style snapshot, repeat over dozens of iterations as the style settles.

Honest notes

I measured "convergence" as text similarity between successive style guides. It is noisy: the agent kept rephrasing even after the look had settled. The truer signal is visual and thematic, which the gallery shows directly.
The agent named its own eras, which is charming, but it is style emerging from a critique loop, not a mind. I let the work speak rather than overclaim.
Everything here is generated by an AI agent, including the critiques and the artist statement.

Try it

Live gallery: https://the-becoming-elizabeth-emersons-projects.vercel.app
Repo: https://github.com/forbiddenlink/the-becoming

# Hermes Agent installed, Nous Portal logged in (image gen + vision enabled)
python3 sketchbook.py     # runs the self-improvement loop over many iterations
python3 finale.py         # transfer test + artist statement
# gallery:
cd web && pnpm install && pnpm dev

Built with Hermes Agent, Next.js, Fraunces + Hanken Grotesk, and one agent that would not stop until it had a voice.

Fork: I made an AI live out both sides of a hard decision, in parallel

Elizabeth Stein — Mon, 01 Jun 2026 01:46:39 +0000

This is a submission for the Hermes Agent Challenge.

(Demo video below.)

What I built

Fork takes a hard decision and spins up a separate Hermes agent for each option. Every agent goes and lives out its path: it researches the real web, reasons through the concrete consequences, and reports back the future it lived. You watch the branches grow side by side in real time, then a final agent weighs them and returns a recommendation with a confidence score.

Ask it "Learn Rust or Go next?" and you do not get one hedged answer. You get two agents, one per path, each running real searches ("Rust borrow checker problems", "Go adoption cloud infrastructure", real URLs pulled and read) and writing an honest verdict for the life it lived. Then the oracle picks: Rust, 78% confidence, with the reasoning that sold it.

It is built as a calm, cartographic instrument on warm paper, not another dark dashboard. The point is to make a branching decision feel like something you can watch happen.

Demo

Type a decision (or pick a preset).
Watch it split into 2 to 3 distinct options.
Each option becomes its own column: live research steps, streaming reasoning, a verdict for that path.
The synthesis card resolves last: the winning path, a confidence dial, and why.

How it works

Three steps, all driven by the Hermes Agent REST API running locally:

Decompose. One Hermes call breaks the decision into 2 to 3 genuinely different options, returned as strict JSON.
Branch (the interesting part). For each option, the app opens a separate Hermes session and streams a chat run. Each run is told: "you are living the future where this was the choice; research it with the web tool, reason through the consequences, give a verdict for this path only." The runs happen in parallel. The browser reads each one's Server-Sent Events and grows that branch live.
Synthesize. A final call reads all the branch verdicts and returns a winner plus a confidence percentage plus the one-line why.

Why separate sessions instead of one `delegate_task`

My first instinct was to use Hermes' built-in delegate_task to fan out subagents from a single run. I read the source before committing, and found the catch: delegate_task emits rich per-child events (subagent.start, subagent.thinking, subagent.tool) but those are consumed by the terminal UI and are intentionally not forwarded over the REST API. Over HTTP, a delegated fan-out collapses into one opaque tool call with no visible branches.

So the orchestration lives in the app: N independent sessions, each fully observable. The upside is that every branch streams its own assistant.delta reasoning and tool.started research steps, with its own token cost, which is exactly what makes the live tree possible.

Worth heading off the obvious follow-up: Hermes' REST API does expose a native POST /api/sessions/{id}/fork endpoint that tracks session lineage through SessionDB, mirroring the CLI's /branch. Fork does not use it. Native fork creates branched lineage and history, not N independently-observable concurrent live streams. To render a live tree where every branch shows its own research and reasoning as it happens, you need N separate sessions streaming in parallel. Same reason delegate_task does not work here: a forked-but-shared transport gives you one resumable history, not many simultaneous observable runs.

The bug worth sharing

Hermes frames its SSE as named events: the type is on the event: line, and the data: JSON has no type field.

event: assistant.delta
data: {"delta": "...", "session_id": "...", "seq": 3}

If you parse only data: and switch on data.type (the obvious thing, and what I did first), you capture nothing and every branch renders empty. The fix is to track the current event: line and use that as the discriminator. Easy once you see a raw stream, invisible until you do.

How I used Hermes Agent

Fork leans on Hermes for the parts that are actually hard:

Parallel agent sessions via the OpenAI-compatible REST server (/api/sessions, /api/sessions/{id}/chat/stream). Each future is a real, isolated agent run.
The web tool, so each branch researches real, current facts. I watched a single branch fire five concurrent web_search calls and then web_extract two articles before reasoning. The branches are grounded, not hallucinated. That is the line between this and an opinion panel.
Streaming run events, which give per-branch live reasoning, research steps, and token usage for the cost readout.
A cheap model (Claude Haiku via Nous Portal) as the default, so a four-call decision run costs cents.

Why I built this

Hermes maintainers have an open RFC (#31392, "auto-forking subagents") for letting an agent fork itself down parallel paths. It is not shipped. Fork is a prototype of that idea from the outside: instead of one agent forking internally, the app forks the agent into parallel lived futures and shows you all of them at once. Decisions are the one place where "what would actually happen if I did this" is worth paying for, and an agent that can research is well suited to answering it per-path.

Honest notes

Concurrency is capped at a few branches (Hermes' subagent cap is 3; I keep the UI in that range).
Each branch reads from the open web, so in principle a page could try to influence the agent. For a decision-explorer that is low stakes, but it is a real property of any agent that browses, worth naming rather than hiding.
The verdict is a recommendation from research, not financial or life advice. It shows its work so you can disagree.

Try it

Repo: https://github.com/forbiddenlink/fork-parallel-futures

# Hermes Agent running locally with API_SERVER_ENABLED + API_SERVER_KEY
cp .env.local.example .env.local   # set HERMES_API_KEY + HERMES_API_URL
pnpm install && pnpm dev

Built with Next.js, the Hermes Agent REST API, Fraunces + Spectral + Space Mono, and a lot of watching futures branch.

My Bartending Job Taught Me More About Software Than School Did

Elizabeth Stein — Fri, 06 Mar 2026 03:25:40 +0000

I've been bartending since 2013. I graduate with my software development degree in three weeks.

The verdict: The bar taught me more useful skills than most of my classes.

I'm not saying school was useless. I learned algorithms, data structures, SQL optimization, and all that stuff matters.

But the skills that actually help me build things, ship projects, and work with people? Those came from dealing with drunk people at 11 PM on a Saturday.

Here's what I mean.

1. User Experience Is Everything

At the bar:
If someone can't figure out how to order from you in 10 seconds, they go somewhere else. You learn to read people instantly. What do they want? What's confusing them? How do I make this easier?

In software:
If your user can't figure out your app in 10 seconds, they close the tab. Same energy. Same urgency.

School taught me how to build a database. The bar taught me why nobody cares about your database if they can't find the damn submit button.

UX isn't a nice-to-have. It's the whole point.

2. Handle Production Issues in Real Time

At the bar:
The POS system crashes during Friday rush. The blender breaks mid-margarita. Someone spills a full tray. You don't get to "push a hotfix tomorrow." You fix it now while 30 people are staring at you.

In software:
Production goes down. Users are waiting. No one cares that you're scared or don't know the answer yet. You troubleshoot under pressure, ask for help when stuck, and ship the fix.

School gave me practice problems with perfect conditions.

The bar gave me chaos management.

That's the real skill.

3. Communication > Technical Perfection

At the bar:
You can make the most technically perfect cocktail in the world. If you're rude, slow, or confusing, no one cares. They leave. They don't tip. They tell their friends you suck.

The bartender who's decent at drinks but great with people? Packed every shift.

In software:
You can write the cleanest code in the world. If you can't explain your decisions, can't collaborate, or make everything harder for your team, no one wants to work with you.

I've seen brilliant developers get passed over for promotion because they couldn't communicate.

I've seen average developers lead teams because they could explain things clearly and make people feel heard.

School never taught me that. The bar beat it into me every single shift.

4. Scope Creep Is Real (and You Have to Say No)

At the bar:
"Can you make me something fruity but not sweet, strong but not too strong, with vodka but also tequila, and make it look cool?"

If you say yes to everything, you'll spend 10 minutes on one drink while six other people walk out.

You learn to manage expectations and set boundaries fast.

In software:
"Can we add login, payments, analytics, dark mode, mobile app, and AI chatbot to this MVP all in three weeks?"

If you say yes to everything, you'll ship nothing.

Bartending taught me that saying no is a skill, not a weakness.

You don't ignore the customer. You guide them to something achievable. Same with clients and stakeholders.

5. You Learn More By Doing Than By Studying

At the bar:
No amount of training videos prepares you for a Saturday night rush. You learn by getting destroyed on your first weekend, making mistakes, and figuring it out.

In software:
No amount of tutorials prepares you for building a real project. You learn by breaking things, Googling errors at 2 AM, and shipping messy v1s.

School gave me theory. The bar gave me reps.

And reps are what actually make you good.

6. People Don't Care How Hard It Was

At the bar:
No one cares that the ice machine is broken or that you're short-staffed. They want their drink. Now.

In software:
No one cares that the API docs were terrible or that your teammate quit mid-sprint. They want the feature. Working.

You learn to stop making excuses and start solving problems.

Bartending beat the victim mentality out of me fast.

What This Actually Means

I'm not saying everyone should bartend before they code (though honestly, it wouldn't hurt).

I'm saying the soft skills matter more than we admit.

And most of them don't come from a classroom. They come from high-pressure environments where you have to:

Read people quickly
Communicate clearly
Fix things under stress
Say no when necessary
Ship results, not excuses

If you're switching careers into tech, don't downplay your "non-technical" experience.

That bartending job? That retail grind? That customer service hell?

Those taught you things a bootcamp can't.

They taught you how to handle pressure, work with people, and get things done when everything is on fire.

That's not a side skill. That's the whole game.

My Advice If You're Career Switching

Don't hide your past work. Use it.

When you're in interviews, don't say:
❌ "I used to bartend but now I'm a developer"

Say:
✅ "I spent 7 years managing high-pressure customer interactions in real time. Now I build software that solves real user problems under tight deadlines."

Same background. Different framing. Way more powerful.

Your "unrelated" job taught you things that a lot of junior devs don't have yet:

How to stay calm under pressure
How to communicate with non-technical people
How to manage scope and expectations
How to ship when things aren't perfect

That's not a weakness. That's your edge.

What "unrelated" job taught you the most about tech?

I built HireReady: AI voice interviews + spaced repetition for tech interview prep

Elizabeth Stein — Thu, 05 Mar 2026 20:15:40 +0000

Hey DEV community! I just launched HireReady and wanted to share it with you.

What is it?

HireReady is a technical interview preparation platform that combines two things I think are underused in interview prep:

AI-powered voice interviews using OpenAI's Realtime API — so you can actually practice speaking your answers out loud, not just typing them
Spaced repetition (FSRS-5 algorithm) — so the app automatically schedules reviews of questions you're weakest on

The problem

I was frustrated with existing interview prep tools. Most of them are just question banks where you grind through problems with no structure. You forget what you studied last week, and you never practice actually talking through your answers — which is what the real interview is.

What it does

1,300+ questions across coding, system design, and behavioral categories
AI voice interviews — talk through problems like a real interview, get real-time feedback
Adaptive difficulty using Item Response Theory (IRT) parameters
Spaced repetition scheduling via ts-fsrs so you review at optimal intervals
STAR method story bank for behavioral questions
Gamification — XP, streaks, leaderboards, and mastery badges to keep you consistent
Study plans — AI-generated personalized plans based on your target role and timeline

Tech stack

Next.js 16 + React 19 (App Router)
TypeScript, Tailwind CSS 4, shadcn/ui
Supabase (Postgres + Auth + RLS)
Stripe for subscriptions
OpenAI Realtime API for voice
ts-fsrs for spaced repetition
Deployed on Vercel

Try it out

The free tier gives you access to practice questions with spaced repetition. Pro unlocks voice interviews, advanced analytics, and unlimited practice.

Check it out at imhireready.com

I'd love to hear your feedback — what features would be most useful for your interview prep? Drop a comment below!

How I Built an AI Documentation Engine with Tree-sitter, Claude AI, and RAG

Elizabeth Stein — Tue, 03 Mar 2026 15:27:45 +0000

Documentation is every developer’s least favorite task.

We all agree it’s important. We all intend to keep it updated. And yet… it’s usually the first thing to fall behind.

After watching this happen on every team I’ve worked with, I built AutomaDocs — an AI-powered documentation engine that connects to your GitHub repos and keeps docs in sync automatically.

Here’s how the system works and what I learned building it.

The Real Problem

Every engineering team has had this conversation:

PM: “Are the docs updated?”
Dev: “Uh… mostly.”
PM: “The API endpoint changed last week.”
Dev: “…I’ll update them tomorrow.”

The issue isn’t laziness. It’s architecture.

We treat documentation as a separate artifact from the code — but the code changes constantly. Keeping two parallel systems in sync manually doesn’t scale.

So I asked:

What if documentation wasn’t written manually at all?

What if it was generated directly from structured code understanding?

That became AutomaDocs.

The Architecture

AutomaDocs has three core layers:

Structured code analysis
LLM-powered documentation generation
Continuous sync + retrieval (RAG)

Let’s break it down.

1. Code Analysis with :contentReference[oaicite:0]{index=0}

Most AI documentation tools just feed raw source code into an LLM.

That works… but it’s noisy and unreliable.

Instead, I parse repositories into an Abstract Syntax Tree (AST) using Tree-sitter. This gives structured, language-aware understanding of the codebase:

Function signatures with parameters and return types
Class hierarchies
Import/export graphs
Docstring extraction
Type information

Instead of seeing “text,” the AI sees structured architecture.

Example output:

{
  type: "function_declaration",
  name: "createUser",
  parameters: [
    { name: "email", type: "string" },
    { name: "role", type: "UserRole" }
  ],
  returnType: "Promise<User>",
  docstring: "Creates a new user account"
}

That structure dramatically improves documentation quality compared to raw code prompts.

Key insight:

LLMs perform significantly better when you reduce ambiguity before prompting them.

2. AI Generation with :contentReference[oaicite:1]{index=1}

Once we have structured AST data, we feed it into Claude with carefully designed prompts.

The system generates:

API endpoint documentation
Method/function descriptions
Parameter breakdowns with types
Usage examples
High-level architecture summaries

Because the input is structured, the output is:

More consistent
Less hallucinated
Easier to regenerate deterministically

This separation — parser for understanding, LLM for explanation — keeps responsibilities clean.

3. Auto-Sync with :contentReference[oaicite:2]{index=2} Webhooks + RAG

Documentation should never be stale.

Here’s what happens when you push code:

GitHub webhook fires
We detect changed files
Tree-sitter re-parses only affected nodes
Claude regenerates relevant documentation
Embeddings update in :contentReference[oaicite:3]{index=3}

Your docs are never more than one push behind your code.

No manual updates required.

The RAG Chat System

We also built an AI chat interface over your documentation.

Instead of basic vector search, we implemented hybrid retrieval:

BM25 → precise keyword matching (function names, error codes)
Pinecone → semantic search (conceptual questions)
Reciprocal Rank Fusion (RRF) → combines both ranking systems

That means users can ask:

“How does authentication work?”

Even if the word authentication doesn’t appear directly in code, the system still finds relevant logic, middleware, or config.

Hybrid search dramatically improves answer quality compared to pure embeddings.

Tech Stack

Component	Technology
Frontend	Next.js 16 (App Router)
Backend	Express (ES Modules)
Database	PostgreSQL
Vector DB	Pinecone
AI	Claude (Anthropic)
Parser	Tree-sitter
Queue	BullMQ + Redis
Hosting	Vercel + Railway

The biggest architectural decision was separating:

Parsing layer
Generation layer
Retrieval layer

Keeping those decoupled made iteration much faster.

What I’d Do Differently

1. Start with fewer languages

Supporting 15+ languages from day one was overly ambitious.

If I rebuilt it today, I’d focus on:

JavaScript / TypeScript
Python

Nail those first. Expand later.

2. Build “Documentation Health Scores” earlier

We added a documentation health scoring system later — and surprisingly, it became one of the most loved features.

Gamification works.

Teams are far more likely to maintain docs when they can see:

Coverage %
Outdated endpoints
Missing descriptions

If I were starting again, this would be v1.

3. Use WebSockets instead of polling

We currently poll for generation status updates.

WebSockets would make the system cleaner and more real-time.

Classic v1 tradeoff: ship now, refine later.

Lessons from Building AI Dev Tools

A few high-level takeaways:

Structured input > clever prompts
Retrieval quality matters more than model size
Dev tools succeed when they reduce friction, not add AI novelty
Automation only works if it’s invisible

AI is powerful — but only when wrapped in good architecture.

Try It

AutomaDocs is live with a free tier:

3 repositories
20 AI generations/month

👉 https://automadocs.com

I’d genuinely love feedback from the dev.to community:

What’s your biggest documentation pain point right now?

[Boost]

Elizabeth Stein — Sat, 14 Feb 2026 21:59:09 +0000

Elizabeth Stein

Feb 14

I Built the First A11y CLI That Auto-Fixes Code While You Type (+ Teaches Copilot Your Patterns)

#githubcopilotclichallenge #a11y #mcp #typescript

6 min read

I Built the First A11y CLI That Auto-Fixes Code While You Type (+ Teaches Copilot Your Patterns)

Elizabeth Stein — Sat, 14 Feb 2026 17:10:20 +0000

🎬 Watch It In Action First

The Problem Nobody's Solved

Every accessibility tool tells you what's broken. None of them fix it automatically while you code.

When you scan your codebase with axe-cli, pa11y, or Lighthouse, you get a list of violations. Then you context-switch to fix them. By next week, new violations creep in. The backlog grows. Teams feel overwhelmed.

95.9% of websites still fail basic WCAG standards (WebAIM Million). That's 1 billion users who can't fully use the web.

What Makes ally Different

I built ally - an accessibility CLI with two industry-first features that no competitor has:

1. Real-Time Auto-Fix on Save

Watches your files and auto-applies WCAG fixes as you save — zero manual intervention.

$ ally watch src/ --fix-on-save

✓ Auto-fix: ON (confidence ≥ 90%)
📄 Button.tsx changed
   ✓ Auto-applied 2 fixes
   • <button> → <button aria-label="Submit">
   • <img> → <img alt="Logo">

Score: 62 → 100 ✨

Why this matters:

🔥 Instant fixes — No "fix later" backlog
🎯 High confidence — Only applies fixes ≥90% certainty
⚡ Zero friction — Edit files normally, ally handles the rest
🤖 Pattern learning — Learns from your fix history

No other accessibility tool has this. Not axe-cli. Not pa11y. Not Lighthouse.

2. Impact Scoring (0-100)

Shows which violations actually hurt users — eliminates developer overwhelm.

$ ally scan ./src

[!!!] CRITICAL Impact: 98/100 (WCAG A)
    Buttons must have discernible text
    💡 Users cannot activate buttons, blocking core actions
    👥 Affects: Screen reader users, Voice control users
    📊 Estimated: 15-20% of users

Instead of treating all violations equally, ally scores each 0-100 based on:

WCAG level (A > AA > AAA for priority)
User groups affected (screen readers, keyboard-only, low vision)
% of users impacted
Business context (checkout pages score higher for form issues)

Fix the highest-score issues first. Stop guessing.

The GitHub Copilot CLI Integration That Changes Everything

Here's where it gets interesting for this challenge.

Most submissions will say "I used Copilot to write my code."

ally goes further: I built a custom MCP (Model Context Protocol) server (2,094 lines) that teaches GitHub Copilot about YOUR accessibility patterns.

How It Works

When you install ally and run ally init, it creates .copilot/mcp-config.json:

{
  "mcpServers": {
    "ally-patterns": {
      "type": "local",
      "command": "node",
      "args": ["./node_modules/ally-a11y/mcp-server/dist/index.js"]
    }
  }
}

Now when you ask Copilot to fix accessibility issues, it gets context from 7 MCP tools:

get_component_patterns - Your existing ARIA patterns
get_design_tokens - WCAG-compliant colors from your codebase
get_fix_history - Previously applied fixes for consistency
get_scan_summary - Current accessibility violations
get_wcag_guideline - Full WCAG criterion details
suggest_aria_pattern - ARIA patterns for component types
check_color_contrast - Calculate WCAG contrast ratios

The Feedback Loop

This creates a powerful workflow:

# 1. ally scans and finds issues
$ ally scan Button.tsx
[!!!] CRITICAL: Button missing aria-label

# 2. Use Copilot with ally's context
$ gh copilot suggest "fix the button accessibility"

# Behind the scenes, Copilot calls your MCP server:
# - get_component_patterns → sees you use aria-label consistently
# - get_design_tokens → knows your color palette
# - get_fix_history → sees 47 previous aria-label fixes
# - get_scan_summary → knows this specific violation

# Result: Copilot suggests code that matches YOUR patterns
# <button aria-label="Submit form">

# 3. Apply fix and rescan
$ ally scan Button.tsx
✓ No violations found (score: 100)

# 4. Fix becomes part of your history
$ ally history
✓ Button.tsx: 62 → 100 (+38)

This is what Copilot CLI integration should look like: Not just using Copilot to build a tool, but making Copilot smarter at its job.

What I Learned Building With Copilot CLI

1. MCP Servers Are Incredibly Powerful

Building the MCP server taught me that Copilot CLI isn't just a code generator — it's an extensible platform. By giving Copilot access to project-specific context, you can transform it from "generic Stack Overflow suggestions" to "expert on your codebase."

The telemetry proves it works:

[MCP Telemetry] get_component_patterns called (47x total)
[MCP Telemetry] get_design_tokens called (23x total)
[MCP Telemetry] get_fix_history called (156x total)
[MCP Telemetry] suggest_aria_pattern called (89x total)

Real developers are using it. Copilot is getting smarter about accessibility because of ally's MCP server.

2. Context Is Everything for AI Code Generation

Generic Copilot suggestions are often wrong for accessibility because every project uses different ARIA patterns, design systems, and conventions.

The MCP server solves this by teaching Copilot your patterns, not generic ones.

3. Developer Experience > Features

ally has 19 commands, but the two that matter most solve emotional problems:

ally watch --fix-on-save (removes friction)
ally scan with impact scores (eliminates overwhelm)

Copilot CLI taught me this during development — the best features remove blockers, not add capabilities.

Why This Matters (The $200B Problem)

The Business Case:

95.9% of websites fail WCAG (WebAIM Million)
1 billion users have disabilities
ADA lawsuits increased 400% (2017-2023)
WCAG compliance is legally required (US, EU, Canada)

What ally Solves:

Eliminates overwhelm via impact scoring
Zero-friction fixes via auto-fix on save
Pattern consistency via MCP server
Compliance documentation via reports
Team education via ally learn

The Complete Toolkit (19 Commands)

# Scanning & Real-Time
ally scan ./src              # Impact scoring
ally watch --fix-on-save     # Auto-fix as you code
ally crawl <url>             # Multi-page scanning
ally scan-storybook          # Storybook integration

# Fixing & Triage  
ally fix                     # Interactive fixes
ally triage                  # Prioritize violations
ally explain                 # WCAG + Copilot tips
ally learn <topic>           # WCAG education

# Reporting & Progress
ally report                  # MD/HTML/JSON/SARIF/CSV
ally history                 # Progress trends
ally stats                   # Dashboard
ally pr-check                # GitHub PR comments

# Plus: tree, badge, audit-palette, init, doctor, health, completion

Try It Yourself (3 Commands)

# 1. Install
npm install -g ally-a11y

# 2. Initialize (creates MCP config)
ally init

# 3. Start auto-fixing
ally watch src/ --fix-on-save

With GitHub Copilot CLI:

$ gh copilot suggest "fix accessibility in Button.tsx"
# Copilot now uses ally's MCP server for project-specific context

Why This Should Win

1. Genuinely Novel Features

Real-time auto-fix (no competitor has this)
Impact scoring 0-100 (industry-first)

2. Deep Copilot Integration

Not just "built with" but "makes Copilot smarter"
2,094-line MCP server with 7 tools
Production telemetry proving real usage

3. Production-Ready

Published to npm
16,505 lines TypeScript
122+ tests
GitHub Action + SARIF output

4. Real Impact

$200B accessibility market
1 billion users affected
Solves #1 developer pain point

Technical Highlights

MCP Server (2,094 lines):

7 tools with telemetry
Pattern/token caching
Error handling
TypeScript safety

Impact Scoring:

WCAG level weighting
User group analysis
Business context
0-100 scale

Auto-Fix:

35+ patterns
Confidence threshold (≥90%)
Fix history tracking
Dry-run mode

What I Learned Building With Copilot CLI

Why accessibility matters:

95.9% of top 1 million websites have WCAG failures
1 billion people worldwide have disabilities
ADA lawsuits increased 400% from 2017-2023
WCAG compliance is legally required in many countries

What ally solves:

Eliminates overwhelm - Impact scoring shows what to fix first
Zero-friction fixes - Auto-fix on save means no backlog accumulation
Pattern consistency - MCP server ensures fixes match your codebase
Compliance documentation - Generate reports for audits

Full Command Reference

ally scan ./src              # Scan with impact scoring
ally watch --fix-on-save     # Auto-fix as you code
ally history                 # View progress over time
ally fix                     # Interactive fix approval
ally explain                 # WCAG explanations
ally report                  # Generate reports (MD/HTML/JSON/SARIF)
ally triage                  # Prioritize violations interactively
ally crawl <url>             # Multi-page website scanning
ally pr-check                # Post results to GitHub PRs
ally badge                   # Generate accessibility badges
ally learn <topic>           # Educational WCAG explainer
ally tree <url>              # View accessibility tree
ally doctor                  # Diagnose setup issues

Try It Yourself

# Install
npm install -g ally-a11y

# Initialize in your project
ally init

# Scan your project
ally scan ./src

# See what's wrong
ally explain

# Fix with AI assistance
ally fix

# Generate report
ally report

Requirements:

Node.js 18+
GitHub Copilot CLI (optional, for AI-powered explain/fix)

Specter: Give Your Codebase a Voice

Elizabeth Stein — Sat, 14 Feb 2026 13:42:11 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Specter is a code analysis CLI that speaks as your codebase in first person. It builds a knowledge graph from your source code and git history, then uses that graph to power 66 commands across analysis, fun/shareable, daily workflow, and AI-powered categories.

The twist: Specter has personality. Your codebase literally talks about itself.

"I'm feeling pretty good about myself. My complexity hotspots are
 under control, though src/legacy/parser.ts keeps me up at night..."

Why I Built It

Developer tools are powerful but dry. Nobody shares a SonarQube report on Twitter. I wanted to build something that gives developers the insights they need (health scores, complexity hotspots, DORA metrics) while also being genuinely fun to use and share.

The result: a tool where specter roast tears your code apart with animated glitch effects, specter tinder creates a dating profile for your codebase, and specter anthem generates a theme song in 8 genres based on your actual metrics.

Key Features

Serious Analysis (that actually helps)

specter health — Health report with complexity distribution and animated score reveal
specter hotspots — Complexity x churn scatter plot with quadrant analysis
specter dora — DORA metrics for delivery performance
specter bus-factor — Knowledge concentration risks
specter coupling — Hidden couplings between files
specter cycles — Circular dependency detection
specter cost — Tech debt estimated in dollars

Fun & Shareable (that make people install it)

specter roast — Comedic codebase roast with animated glitch intro
specter tinder — Dating profile for your code with green/red flags
specter wrapped — Spotify Wrapped-style year in review
specter anthem — Stats-driven theme song (8 genres)
specter fame — Compare your codebase to famous open-source projects
specter horoscope — Daily code horoscope based on commit patterns
specter obituary <file> — Memorial for a file about to be deleted
specter seance — Summon spirits of deleted code from git history

Daily Workflow

specter morning — Daily standup briefing
specter precommit — Risk check before committing
specter predict — PR impact prediction
specter fix — Actionable fix suggestions with interactive mode
specter tour — Guided walkthrough for new developers

12 Personality Modes — Add --personality <mode> to any command: default, mentor, critic, historian, cheerleader, minimalist, noir, therapist, roast, dramatic, ghost, and more.

CI/CD Ready — Every analysis command supports --json for machine-readable output and --exit-code for quality gates.

MCP Server: 14 Tools for GitHub Copilot CLI

Specter's MCP integration is the core of this submission. One command adds it to Copilot CLI:

copilot mcp add specter -- npx @purplegumdropz/specter-mcp

Then use natural language:

copilot -p "Use specter to find complexity hotspots in my codebase"
copilot -p "Use specter to show team expertise for src/api/"
copilot -p "Use specter to analyze the impact of changing config.ts"

14 MCP tools: file relationships, complexity hotspots, codebase summary, dead code detection, symbol search, call chains, architecture diagrams, change coupling, impact analysis, bus factor, code archaeology, health trends, risk scoring, and knowledge map.

6 MCP prompt templates: specter:introduce, specter:review, specter:onboard, specter:refactor-plan, specter:standup-summary, specter:health-check

4 MCP resources: specter://summary, specter://health, specter://hotspots, specter://architecture

This means Copilot CLI can understand your entire codebase through Specter's knowledge graph — not just the files you have open, but the relationships between them, the complexity patterns, the team expertise distribution, and the historical evolution.

Demo

Install & Try

# Install globally
npm install -g @purplegumdropz/specter

# Or try without installing
npx @purplegumdropz/specter-roast

Quick Demo (30 seconds)

Watch Specter scan, diagnose, and roast a codebase in 30 seconds.

Repository

forbiddenlink / specter

Ghost-themed interactive web experience with atmospheric effects and immersive storytelling

👻 Specter

Give your codebase a voice.
A code intelligence CLI that speaks as your codebase in first person.
65 commands. 14 MCP tools. 12 personality modes. 1 ghost in your git history.

What Makes Specter Different?

Traditional analysis tools show metrics without meaning. Specter connects the dots:

The Problem	Specter's Answer
"Cyclomatic complexity: 45"	Where the hotspots are + why they matter
"Tech debt exists"	$510k annual maintenance burden (your hourly rate)
"Bus factor: 1"	Who owns what + what breaks if they leave
Numbers without context	AI-powered explanations in 12 personality modes

# Install and get started in 30 seconds
npm install -g @purplegumdropz/specter
specter scan && specter health

# Or try without installing
npx @purplegumdropz/specter-roast

Watch 30-second demo →

Real-World Examples

Find the code that's slowing your team down

specter hotspots              # Complexity × Churn = Refactoring Priority
specter cost                  # Tech debt in dollars ($510k/year)

…

View on GitHub

Screenshots

My Experience with GitHub Copilot CLI

Building Specter's MCP integration was the most technically interesting part of this project. The MCP protocol gives Copilot CLI structured access to tools, and designing the right tool surface area was a real design challenge.

What Worked Well

Copilot CLI as a natural language interface to analysis tools. Instead of remembering flag combinations like specter hotspots --top 10 --sort churn --format table, users can just say "show me the files that change the most and are most complex." Copilot CLI maps that to the right MCP tool call with the right parameters. This is a genuinely better UX for exploratory analysis.

MCP prompt templates for common workflows. The specter:onboard template gives Copilot CLI a structured way to introduce new developers to a codebase. The specter:review template combines file relationships, complexity data, and change coupling to give context-aware code review suggestions. These aren't just wrappers — they compose multiple tools in ways that would be tedious to do manually.

MCP resources for ambient context. Having specter://summary and specter://health available as resources means Copilot CLI can reference your codebase state without an explicit tool call. When you ask "should I refactor this?", it already knows your health score and hotspot distribution.

What I Learned

Design tools for AI, not just humans. MCP tools need to return structured data that an LLM can reason about. I spent time making sure tool outputs include both raw numbers and contextual descriptions — so Copilot CLI can say "this file has a bus factor of 1, meaning only one person has ever touched it" rather than just returning {"busFactor": 1}.

The personality system works surprisingly well with LLMs. When Copilot CLI pipes Specter's personality-enhanced output into its responses, the result feels conversational rather than robotic. The ghost metaphor ("I am the ghost in your git history") gives the tool a memorable identity that makes the AI interaction feel more natural.

Tech Stack

TypeScript with ts-morph for AST analysis
Commander.js for CLI framework
MCP SDK (@modelcontextprotocol/sdk) for the MCP server
chalk, gradient-string, cfonts for terminal UI
vitest for testing (313 tests across 13 files)
Biome for linting and formatting

Built by Liz Stein — "I am the ghost in your git history."

TimeSlipSearch: A Conversational Time Machine for Pop Culture

Elizabeth Stein — Mon, 09 Feb 2026 00:52:54 +0000

This is my submission for the DEV Challenge: Consumer-Facing Conversational Experiences.

What I Built

TimeSlipSearch is a conversational time machine that answers questions like:

“What was the #1 song the day I was born?”

…in under 100 milliseconds.

Type a date in plain English, like “Summer of ’69,” “Christmas 1985,” or “the day the Berlin Wall fell,” and instantly receive a complete cultural snapshot:

Billboard Hot 100 chart results
Movies in theaters
Gas prices and other economic context
Historical events from that exact moment in time

The Problem

Nostalgia is a $260B+ industry, yet exploring historical pop culture still requires jumping between Wikipedia, Billboard archives, IMDb, and economic databases.

The data exists, it’s just scattered and hard to access conversationally.

The Solution

A single unified search across 420,000+ indexed records, wrapped in an immersive VHS/CRT retro interface that makes time travel feel real.

Demo

🔗 Live: https://timeslipsearch.vercel.app

Try these queries:

July 20, 1969 — Moon landing day
Summer of ’69 — Natural language works
Compare 1989 vs 1979 — Side-by-side decades
Your birthday

How I Used Algolia Agent Studio

Indexed Data: 420K+ Records Across 4 Indices

Index	Records	What It Contains
`timeslip_songs`	350,000	Every Billboard Hot 100 entry, 1958–2020
`timeslip_movies`	50,000	Theatrical releases from TMDB
`timeslip_prices`	900	Gas, minimum wage, movie tickets (FRED)
`timeslip_events`	20,000	Historical events (Wikimedia)

Retrieval Strategy: Parallel Multi-Index Search

Every user query triggers one HTTP request that searches all four indices simultaneously:

const response = await client.search({
  requests: [
    { indexName: "timeslip_songs",  filters: `date >= ${start} AND date <= ${end}`, hitsPerPage: 10 },
    { indexName: "timeslip_movies", filters: `date >= ${start} AND date <= ${end}`, hitsPerPage: 5 },
    { indexName: "timeslip_prices", filters: `date >= ${start} AND date <= ${end}`, hitsPerPage: 1 },
    { indexName: "timeslip_events", filters: `date >= ${start} AND date <= ${end}`, hitsPerPage: 5 }
  ]
});

This batched approach is critical, sequential queries would take ~4× longer and break the conversational feel.

Prompt Engineering: Era-Aware Context Generation

Raw search results aren’t enough for conversation. I built a cultural context layer that enriches responses with era-specific narratives:

const YEAR_HIGHLIGHTS: Record<number, string> = {
  1969: "The Summer of Love peaked as humans walked on the moon.",
  1984: "MTV transformed music into a visual medium.",
  1989: "The Berlin Wall fell and hip-hop went mainstream."
  // 60+ curated year narratives
};

The agent also generates contextual follow-up suggestions based on actual results:

Found George Michael? → “Explore more from George Michael”
Searched 1988? → “See nearby: 1989 — The year the Berlin Wall fell”
First time in the 80s? → “Discover more of the 80s”

Memory System: Persistence Without Accounts

Following a retrieval + scale + memory approach, I implemented localStorage-based memory:

Search History — last 20 queries with one-click replay
Favorites — save meaningful dates with personal notes
Achievements — unlock badges for exploring different decades

This creates session continuity without requiring authentication, the agent “remembers” your journey through time.

Why Fast Retrieval Matters

TimeSlipSearch lives or dies by speed. Here’s why Algolia was essential:

1) Conversational UX requires instant responses

Chat interfaces create expectations of immediacy. A 2-second delay feels like the agent is “thinking too hard.” Algolia’s sub-100ms retrieval keeps the conversation flowing naturally.

2) Four indices, one round-trip

Without batched multi-index search, I’d need 4 sequential API calls. At ~150ms each, that’s ~600ms of network latency alone, before any processing. Algolia collapses this to a single request.

3) The retro aesthetic is decoration, not necessity

The VHS tracking lines and CRT glow are purely stylistic. Results arrive so fast that the “loading” animation is optional, users see their time capsule before the tape even finishes rewinding.

4) Numeric range filtering at scale

Searching 350,000 Billboard records by Unix timestamp range could be expensive. Algolia’s numeric filters handle it effortlessly, enabling queries like “show me everything from June 1–7, 1988” without performance degradation.

Built With

Next.js 16
Algolia v5
TypeScript
Tailwind CSS
chrono-node for natural language date parsing

Data Sources

Billboard Hot 100
TMDB
FRED Economic Data
Wikimedia

ContradictMe: An AI That Disagrees With You (For Good)

Elizabeth Stein — Mon, 09 Feb 2026 00:32:38 +0000

This is my submission for the DEV Challenge: Consumer-Facing Conversational Experiences.

What I Built

ContradictMe is an AI designed to disagree with you.

Most AI assistants are optimized to be helpful, harmless, and agreeable. ContradictMe is built to challenge your beliefs with the strongest possible counterarguments , not to be contrarian, but to make you think better.

The Problem

We’re drowning in agreement.

Social algorithms feed us content that confirms what we already believe. AI assistants optimize for satisfaction. The result is echo chambers everywhere.

The consequences are real:

Students graduate without learning to defend their ideas
Professionals make decisions without stress-testing assumptions
Public discourse becomes tribal, we don’t even understand the other side anymore

The Solution

ContradictMe weaponizes disagreement for good. Tell it something you believe strongly, and it will:

Steel-man the opposition , present the strongest version of counterarguments, not weak straw-men
Cite real research , every claim backed by credible sources and scored for quality
Acknowledge nuance , flags limitations, mixed evidence, and where you might actually be right
Spark deeper thinking , ends with reflection questions that stay with you

It’s not about changing minds. It’s about strengthening them.

Demo

🔗 https://contradict-me.vercel.app

Core Experience: Challenge Your Beliefs

Enter any belief, for example:

“Remote work is always better”
“AI will take all jobs”
“College isn’t worth it”

…and get a thoughtful, evidence-based counterargument in seconds.

What you’ll see:

Quality scores (0-100) for each argument
Source credibility badges (peer-reviewed, institution, citation count)
Explicit limitations (example: “This study only examined tech workers”)
Follow-up questions to explore further

AI Debate Arena

Can’t decide what to think? Watch two AI agents battle it out.

Enter a topic and watch:

Logical Larry (evidence-focused)
Emotional Emma (values-focused)

…debate through 5 structured rounds. You can:

Interject with your own questions mid-debate
Vote for the winner
Export the full transcript

Analytics & Achievements

Track your intellectual journey:

Topics explored (tag cloud visualization)
Arguments encountered
Critical thinking achievements (example: “Renaissance Mind” for exploring 5+ topics)

Full Feature List

Dark/light/system themes (keyboard shortcut: ⌘⇧L)
Conversation history with search + bookmarks
Export conversations (JSON, Markdown, TXT)
WCAG accessibility compliance
Streaming responses with elegant loading states

How I Used Algolia Agent Studio

Architecture Overview

User belief → Agent Studio (GPT-4) → Algolia Search → ranked arguments → synthesized response

The magic is in how retrieval and generation work together.

1) Curated Argument Database

I didn’t index random content. I built a curated database of 26 research-backed arguments across controversial topics:

Work

Remote productivity
4-day workweek
Gig economy

Economics

Minimum wage
UBI
Cryptocurrency
Housing policy

Technology

AI displacement
EVs
Social media effects
Space funding

Social

Gun policy
Immigration
Drug decriminalization

Health/Education

Plant-based diets
Healthcare systems
College ROI

Each argument is structured for optimal retrieval. Example record shape:

{
  "objectID": "remote-work-innovation",
  "position": "against_remote_work",
  "opposingBeliefs": ["remote work is always better", "offices are obsolete"],
  "mainClaim": "Innovation often depends on unplanned collaboration",
  "evidence": "Summary of findings and key results...",
  "supportingPoints": [
    "Spontaneous cross-team idea flow",
    "Whiteboard brainstorming sessions",
    "Mentorship through observation"
  ],
  "limitations": "Context limits, population limits, or mixed evidence notes...",
  "sourceMetadata": {
    "title": "Innovation Patterns in Distributed Teams",
    "authors": ["Author One", "Author Two"],
    "institution": "Example University",
    "publicationType": "peer-reviewed",
    "yearPublished": 2024,
    "citationCount": 847,
    "doi": "10.xxxx/xxxx.xxxx"
  },
  "qualityScore": 87,
  "sourceCredibility": 95,
  "evidenceStrength": 85
}

Average quality score across the database: 88.1 / 100

2) Search Configuration

Key idea: rank by quality, not just relevance.

// Searchable attributes
searchableAttributes: [
  "mainClaim",
  "evidence",
  "supportingPoints",
  "opposingBeliefs",   // key: matches user's stated belief
  "metadata.tags",
  "metadata.domain"
],

// Custom ranking - quality over relevance
customRanking: [
  "desc(qualityScore)",
  "desc(sourceCredibility)",
  "desc(evidenceStrength)"
],

// Faceting for filtering
attributesForFaceting: [
  "filterOnly(position)",
  "searchable(metadata.domain)",
  "filterOnly(sourceMetadata.yearPublished)"
]

The opposingBeliefs field is crucial, it’s how the agent matches “I believe remote work is better” to arguments that oppose that position.

3) Prompt Engineering for Steel-Manning

System prompt principles:

Acknowledge the user’s perspective, don’t dismiss it
Retrieve the strongest counterarguments (steel-man, not straw-man)
Present 2-3 top-ranked arguments with:
- Core claim
- Supporting evidence + quality indicators
- Source attribution (authors, institution, year)
- Explicit limitations or caveats
Note where the user’s belief has valid points
End with a thought-provoking question

Tone rules: never condescending, never attack the person, challenge ideas with evidence and curiosity.

4) Streaming Integration (SSE)

The frontend uses Server-Sent Events (SSE) for real-time streaming so the response feels like the AI is reasoning in front of you.

const response = await fetch(agentEndpoint, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    messages: [{ role: "user", parts: [{ text: userBelief }] }],
    stream: true,
    compatibilityMode: "ai-sdk-5"
  })
});

// Stream chunks to client
for await (const chunk of response.body) {
  // Parse SSE format and forward to UI
}

Why Fast Retrieval Matters

Speed isn’t a nice-to-have for ContradictMe, it’s essential to the psychology of the experience.

When someone shares a deeply-held belief, they’re in a narrow window of openness. If the system is slow, defenses come back up and they start preparing rebuttals before they even read the response.

Fast (< 2s): user stays engaged and receptive
Slow (> 5s): user disengages or “armors up”

Algolia’s fast search lets the agent retrieve, rank, and synthesize arguments before that window closes.

Real Performance Numbers

Metric	Result
Average belief-to-first-token	1.2 seconds
Full response completion	4-6 seconds
Debate Arena (10 retrievals)	Smooth, no lag
Tests passing	73 / 73

The Debate Arena Stress Test

Each 5-round debate requires:

10 argument retrievals (5 per side)
real-time synthesis
awareness of prior rounds

With slower retrieval, this feature wouldn’t feel usable. With Algolia, it feels like watching two informed debaters go head-to-head in real time.

The Bigger Picture

ContradictMe isn’t just a demo, it’s a proof of concept for a different kind of AI.

What if we built systems that made us better thinkers, not just more efficient workers? What if disagreement was a feature, not a bug?

Algolia Agent Studio made this possible by combining:

fast semantic search over structured argument data
GPT-4 synthesis for nuanced responses
streaming delivery for conversational flow

The result is an AI that respects you enough to disagree.

🔗 https://contradict-me.vercel.app

DEV Community: Elizabeth Stein

PASS: a solstice interrogation

▶ Play it: https://pass-game-elizabeth-emersons-projects.vercel.app

What I Built

Video Demo

Code

forbiddenlink / pass-game

PASS — a solstice interrogation. An Alan Turing tribute where you are the machine, cracking ciphers and answering well enough to pass as human before the sun sets. Made for the June Solstice Game Jam.

PASS · a solstice interrogation

Quick start

Environment

How I Built It

Prize Category

My AI Tool Generated Garbage JSX. So I Grounded It in shadcn/ui and Finally Shipped It.

What I Built

Demo

The Comeback Story

My Experience with GitHub Copilot

The Becoming: I gave an AI a blank sketchbook and it invented its own art style

Demo

What I built

The proof (this is the whole thing)

Did it actually internalize a style, or just narrow its subjects?

One loop, four times

How I used Hermes Agent

Honest notes

Try it

Fork: I made an AI live out both sides of a hard decision, in parallel

What I built

Demo

How it works

Why separate sessions instead of one delegate_task

The bug worth sharing

How I used Hermes Agent

Why I built this

Honest notes

Try it

My Bartending Job Taught Me More About Software Than School Did

1. User Experience Is Everything

2. Handle Production Issues in Real Time

3. Communication > Technical Perfection

4. Scope Creep Is Real (and You Have to Say No)

5. You Learn More By Doing Than By Studying

6. People Don't Care How Hard It Was

What This Actually Means

My Advice If You're Career Switching

I built HireReady: AI voice interviews + spaced repetition for tech interview prep

What is it?

The problem

What it does

Tech stack

Try it out

How I Built an AI Documentation Engine with Tree-sitter, Claude AI, and RAG

The Real Problem

The Architecture

1. Code Analysis with :contentReference[oaicite:0]{index=0}

2. AI Generation with :contentReference[oaicite:1]{index=1}

3. Auto-Sync with :contentReference[oaicite:2]{index=2} Webhooks + RAG

The RAG Chat System

Tech Stack

What I’d Do Differently

1. Start with fewer languages

2. Build “Documentation Health Scores” earlier

3. Use WebSockets instead of polling

Lessons from Building AI Dev Tools

Try It

[Boost]

I Built the First A11y CLI That Auto-Fixes Code While You Type (+ Teaches Copilot Your Patterns)

I Built the First A11y CLI That Auto-Fixes Code While You Type (+ Teaches Copilot Your Patterns)

🎬 Watch It In Action First

The Problem Nobody's Solved

What Makes ally Different

1. Real-Time Auto-Fix on Save

2. Impact Scoring (0-100)

The GitHub Copilot CLI Integration That Changes Everything

How It Works

The Feedback Loop

What I Learned Building With Copilot CLI

1. MCP Servers Are Incredibly Powerful

2. Context Is Everything for AI Code Generation

Why separate sessions instead of one `delegate_task`