Forem: Ashley Childress

AI Isn't Stupid. Your Setup Is. 🛠️

Ashley Childress — Sat, 02 May 2026 19:30:01 +0000

The latest discourse I hear usually sounds something like, "I tried [insert agent flavor of the week] and it gave me garbage. AI is overrated."

My response: "No. You asked your mechanic to build a house and forgot to provide blueprints." 🦄

The agent isn't the problem—the setup is. Here's the workflow that actually works. None of it is clever and all of it took me longer to learn than I'd care to admit.

1. Pick the model that fits the task. Specs beat vibes. 🪛

Haiku is a sprinter. It'll absolutely take a swing at your distributed system architecture—the answer just won't be one you can ship. Your job is to match the model to the work.

If the problem is well-defined—clear specs, acceptance criteria, edge cases enumerated—Sonnet handles it fine. You'll spend more time in review, but you'll save real money. You'll also catch your own bad specs faster, which is its own gift.

If the feature is a tangled mess and you can't (or won't) break it down, that's also fine. Hand the whole thing to Opus instead. You don't have to scope every subproblem, but you DO have to define the whole solution. "Make it work" is not a valid requirement—it's a desperate wish the agent will not understand.

A cheap model with great specs beats an expensive model with vibes and feelings, every single time.

2. Plan in chat. Touch the codebase last. 🪞

I spend hours—many hours—talking through a problem before a single character lands in the codebase. AI is my rubber duck/research assistant with attitude—yes, I code that in because annoying accolades are distracting me from the goal: a solid game plan.

The language? Does not matter. I can read them all (I probably won't). Package manager? I care even less—drop a Makefile in the root and the commands stay the same regardless. Timeline? Sometimes, but the answer is usually "yesterday." What does matter:

Meaningful tech stack
Desired outcome
Acceptance criteria
Test scenarios—positive, negative, error, edge, weird, seen
Explicit non-goals (the things you are NOT building, so they don't get sneakily built anyway)

Skip these and start prompting with "build me a thing"? You will indeed get a thing. It just won't be your thing.

3. One source of truth. Stop copying instructions. 🪧

AGENTS.md, copilot-instructions, CLAUDE.md, GEMINI.md—pick one. I use AGENTS.md as the source of truth, then drop one-line markdown links to it from the others. That gives you one file to manage instead of four.

If a rule is true everywhere—for you as the operator or across an entire project—it doesn't belong in a skill. Skills get called when triggered. Instructions get loaded always. Know which one you actually need and use accordingly. I wrote another post dedicated solely to this concept, if you want a deeper dive.

The model should maintain AGENTS.md as it works—you do not need a separate MEMORY.md to muddy the waters. When it keeps violating the same rule, don't add another to the pile. Edit instead. Your agent knows exactly where it tripped if you ask, and it already knows how to fix it.

4. Write for the agent. Not the audience. 🪶

Left to its defaults, the model will write your instructions like a detailed onboarding doc. Section headers. Friendly intros. "This document outlines..." Polished prose for a human reader who is never supposed to show up.

Instructions load into context every turn. Every word costs tokens and burns clarity. So optimize for the actual audience: your agent.

Tell it explicitly:

Edit for AI consumption only—no human-friendly framing, no narrative flow.
Preserve every meaningful detail. Compress the prose, never drop the intent.
Strip duplicates. If two rules say the same thing differently, merge them.
Strip ambiguity. "Try to" and "consider" are noise—say what's required.
Strip anything inferable from a reasonable code edit. If grep would answer it, cut it.

A polished onboarding doc is a tax on every prompt you ever send. Pay it once at write time, not every turn.

💡 ProTip: These instructions should be a skill, because the agent only ever uses them when updating AGENTS.md.

5. Skills aren't magical. Explicitly call them. 🪄

Skills are designed to be auto-invoked—yes. In theory... or if the description matches the prompt close enough and the planets align on a Tuesday. If you NEED a skill used, then name it explicitly in the prompt. Otherwise you're gambling.

And please stop installing every skill from the marketplace just because the name sounded interesting. If you don't know the exact name of it already, delete it (with a backup). Use a skill builder to document the workflows you actually run. Leave the rest alone. You load trash in, you get trash out.

6. Install MCPs locally. Globals tax every prompt. 🪺

Having 20 MCPs globally enabled is convenient for you and a context-pollution nightmare for your agent. Every connected MCP eats tokens just by existing.

The question is simple: do I use this everywhere, all the time? If yes, then global is accurate. If not—and the honest answer is usually not—then install it only in the five projects where it actually matters. Symlinks and absolute paths can handle the duplication. Just make sure the agent has access to the directory.

7. Don't review. Test. Then test again. 🩻

I stopped reviewing AI-written code line by line. I was doing it badly, doing it slowly, and my eyes glazed over by the third file. The answer is to test it—extensively, often, and the moment it stops spinning. Not three days later when you open a PR.

Unit. Integration. E2E. Performance. A11y (accessibility). Sonar. Semgrep. Et cetera. Then automate and run with GitHub Actions. Make the model cover positive paths, negative paths, error paths, edge cases, and the acceptance criteria you defined back in the planning phase. (You did define them, right?) Add in anything you uncover during testing explicitly, so it doesn't happen again.

Then cross-check across models. Have Codex review Claude. Have Copilot review Codex. Each model has different blind spots and different obsessions—running them against each other in controlled doses IS the review. One LLM is a single point of failure. Three are a quorum.

8. Ban the shortcuts. Temporary is never temporary. 🪤

In my AGENTS.md files for personal projects: backwards compatibility is strictly forbidden. Quick fixes are forbidden. Temporary solutions are not a viable path at any point. If the model wants to slap on a band-aid, it has to defend that choice. It can't, because my rule says it can't.

Now keep in mind, this is a personal-project rule and is harsh for live production code. If you're running production daily with real users, then you should probably nix the "no backwards compatibility" rule. But for your own stuff? Stop letting the model leave you with technical debt it threw around your codebase like confetti.

9. Clear the context. Don't iterate on broken. 🪦

If you've told the model the same thing three times and it's still wrong, then assume your conversation is poisoned. Too much wrong-direction is already baked in. Open a new chat. Start fresh with what you've learned.

A clean context with a sharper prompt beats six more rounds of "NO! I already said..."

10. The lesson. It was never the agent. 🧭

The agent is fine. The tooling is fine. What's not fine is treating a multi-thousand-dollar reasoning system like a Magic 8-Ball—shaking it harder every time the answer comes back wrong, hoping round fifteen is the one. It won't be.

Pick the right model. Plan first. One source of truth. Test ruthlessly. Cross-check across models. Forbid the shortcuts. Clean up your skill folder and your MCPs. Clear the context when things go sideways and start over.

This setup? It works. Try it for yourself.

🛡️ Behind the Curtain 🎭

I wrote this post. Claude helped with the structure pass and the snark calibration so I'm not an accidental asshole. The opinions, the rules, and the AGENTS.md philosophy are mine—hardened over a year of letting AI drive and ruthlessly analyzing all the crashes.

Unearthed—The Coal Mine Behind Every Light Switch

Ashley Childress — Mon, 20 Apr 2026 06:26:52 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

EPA's Power Profiler tells you your grid is 32% coal. iLoveMountains tells you mountaintop removal is destroying Appalachia. Neither one names the specific hole in the ground feeding your house, neither tells you which workers got hurt pulling the coal out of it, and neither puts that cost back on the consumer flipping the switch.

Unearthed does all three. It names the coal mine feeding your electric grid—the accident record, the operator, the county, the tons—and hands you a natural-language interface to the data behind it.

Why This 🪨

I miss being in the mountains, but the economy in that area is mostly nonexistent and work there is hard to come by. Mostly because companies come into the area, mine everything they can, and then leave when the coal is gone. This leaves behind strip jobs—where the land will quite literally never recover—black lung in the men and women who worked the mines for decades, and abandoned shafts that aren't exactly known for their structural integrity over time.

Virginia produced 8.6 million short tons of coal in 2024. Southwest Virginia carries most of that history—roughly 100,000 acres of abandoned mine land, plus 245 legacy "GOB piles" (mining waste) leaching acid mine drainage into the creeks. Those same mines have public accident records going back to the 1980s—the Mine Safety and Health Administration (MSHA) documents the injuries, fatalities, and the narratives that go with them. Virginia Energy's hazard list for those old sites reads like a ghost tour: landslides, stream sedimentation, dangerous highwalls, subsidence, loss of water supply, open mine shafts, underground explosions, and underground fires.

The men and women who work underground often work decades or until they can't anymore. They rarely recover from the harsh conditions. Anyone who has spent any significant time in that area will share my fatalist outlook. When work is a mile or more underground and you never really know if you are going to come back up again, then you just learned it's a normal part of life.

So, when you ask me to think about the planet, what I picture is the mostly empty coalfields where I grew up. Which got me to thinking, what are we really doing with all of that coal that took over 300 million years to form from nothing but pressure buried under the mountains of Appalachia. This is a follow-up to Carbon Trace—first you got the story, now you have the data to back it up.

Unearthed translates your specific energy grid anywhere in the US into the coal tons it takes to power it. The map will show you the closest mining facility responsible for powering your home—from small appliances to keeping the lights on. It is my hope that every person really takes the time to understand the depth of love and family that went into keeping the lights on all over the country from the men and women who are still living underground to make it happen.

The Product 🔧

Unearthed is an emotional product first and a data product second. The data, managed by Snowflake, makes the emotions real, and a public-domain photograph—one of the many stripped mountaintops like the ones I grew up surrounded by—shows you the actual cost we pay to keep the lights on in our homes.

You can use your current location or search by address. Unearthed finds the power plant feeding your electricity and the coal mine feeding resources into that plant.

Snowflake Cortex does the work. Cortex COMPLETE describes the mine in prose; the goal is to convey what this mine is actually doing to the mountain it's in, honestly—doom included. Then you can ask it the follow-up questions—is this mine still active, who else buys from this operator, how much did it produce last year. Cortex Analyst routes those through a hand-written semantic model and returns the answer (and the SQL, if you want to see it).

Feel it first, then prove it with Snowflake.

Demo

Enter your address. In under a minute you'll know which mine powers your lights, who runs it, what county it's in, how many tons it shipped to your plant last year, and who got hurt pulling that coal out of the ground.

What that looks like for one real address—Carrollton, GA:

James H Miller Jr power plant (AL) ← 5,064,233 tons ← Black Thunder mine (WY)
Operator: Thunder Basin Coal Company LLC · Type: Surface
MSHA accident record: 4 fatalities · 188 lost-time injuries · 8,763 days lost
EPA emissions (since 2020, via Snowflake Marketplace): 125.9M tons CO₂ · 6K tons SO₂ · 39K tons NOₓ

Live 🗺️

Deployed: https://unearthed.anchildress1.dev—use this site to search by your current location

Try it in about a minute:

Land on the Hero. Enter your address, or allow location.
The page scrolls you into the results.
PlantReveal—the power plant actually feeding your grid.
MapSection—animated SVG path traces mine → plant → your meter, with a pulse bead along the route and an EPA subregion label on your pin.
H3Density—hex grid of active vs abandoned mines feeding your plant, with a Cortex-written summary.
CortexChat—ask the grid your own question. Chip or free-form.
Ticker—tons of coal pulled out of that mine since you started reading this page. Paced off the mine's own annual tonnage.

💡 The Ticker is why this app exists instead of being a spreadsheet. It paces off the mine's 2024 tonnage from MSHA and counts up in real time. While you've been reading the post, the mine feeding your grid has pulled several more tons out of the ground.

Code

Repo ⚙️

anchildress1 / unearthed

Show any US resident which coal mine supplies their local power plant. Federal data (MSHA + EIA) in Snowflake Cortex + Gemini. DEV Weekend Challenge 2026.

Unearthed

Tagline: Find the coal mine under contract to your local power plant. Watch it die in real time. Ask it questions.

Unearthed turns public federal data (MSHA + EIA + EPA) into a consumer-scale reveal: enter an address, see the specific coal mine feeding your grid, read memorial prose written from that mine's safety record, then ask natural-language questions about the contract. Built for the DEV Weekend Challenge 2026 — Earth Day Edition, targeting the Snowflake Cortex sponsor category.

Cortex Analyst drives natural-language Q&A (semantic model → SQL → real rows).
Cortex Complete (llama3.3-70b) writes the mine-memorial prose and the 2–3 sentence summary under the national density map — both carry a degraded flag so template fallbacks never sit under a Cortex byline.
H3 hexbin geospatial + Marketplace (EPA Clean Air Markets) are used natively inside Snowflake — no extraction, no ETL away.

For challenge judges:…

View on GitHub

Worth checking out:

assets/semantic_model.yaml—hand-written Analyst training with 6 tables, 5 relationships, and 8 verified natural-language→SQL queries
app/prose_client.py—the Cortex COMPLETE prompt plus per-subregion caching so repeat views don't pay the LLM tax
assets/fallback/—19 pre-generated subregion fallbacks (one per US eGRID subregion) for when the warehouse is cold
frontend/src/lib/reveal.js—the scroll-driven section reveal that came out of the one-day rewrite

⚖️ This project is licensed under Polyform Shield 1.0.0.

How I Built It

The Data Spine 🧬

Six public-domain federal datasets—all from the Mine Safety and Health Administration (MSHA), Energy Information Administration (EIA), or Environmental Protection Agency (EPA):
- MSHA Mines—every US mine: lat/lon, operator, county, status, type
- MSHA Quarterly Production—tonnage per mine per quarter
- MSHA Accident Reports—injuries, fatalities, narratives per mine
- EIA-923 Fuel Receipts (2024 annual, published 2025)—the contract: source mine → destination plant → tons
- EIA-860 Plants (2024 annual, published 2025)—plant locations, eGRID subregion, capacity
- EPA emissions (via Snowflake Marketplace)—CO₂, SO₂, NOx per plant since 2020
Mine-level data joins on MSHA Mine ID; plant-level data joins through EIA plant ID.
Two materialized tables sit on top of the raw joins—MINE_PLANT_FOR_SUBREGION and EMISSIONS_BY_PLANT—plus two views. Cortex queries hit the materialized layer, not the raw tables.
H3 hex grid layered on top for active-vs-abandoned density visualization.
EIA-923 is the one that makes this whole thing possible. Every monthly coal shipment, mine-to-plant, back to the 1990s—the actual contracts that tie your power bill to a specific hole in the ground.
MSHA Accident Reports are the other half of the story. The human cost on the same mines showing up in the contracts.
Both feed researchers and journalists just fine. What I didn't see was anything pointed at a regular person standing at their kitchen light switch—so I pointed you right at it.

Stack 🏗️

Frontend: SvelteKit 2 + Svelte 5 runes + Vite, static adapter, pnpm. Scroll-driven section reveal.
Map: Google Maps JavaScript API (dynamic importLibrary) + Google Places API (New)
Backend: Python 3.12 + FastAPI
Deployment: Google Cloud Run
Data platform: Snowflake—federal ingest + Snowflake Marketplace (EPA emissions); hand-written semantic model YAML for Analyst
AI: Snowflake Cortex—COMPLETE (llama3.3-70b) for mine prose + H3-density narrative; Analyst for NL Q&A
Auth: Snowflake key-pair; private key in GCP Secret Manager
Testing: pytest (unit/integration/perf) · vitest · Playwright · Lighthouse CI with a11y=1.0, SEO=1.0, BP≥0.98, perf≥0.90
Stateless. No accounts. No login.

One Day Left 🎨

The UI you see is a late-stage rewrite, courtesy of Claude Design dropping partway through this build. I fed it my first iteration, it came back with a much better idea than what I had, and with one day left on the clock I decided it was absolutely worth the cost to throw out the old one and build the new one.

Prize Categories

Best Use of Snowflake ❄️

Snowflake Cortex shows up in three different places in this app, and in each one the LLM call just lives inside the warehouse as a SQL function—llama3.3-70b running COMPLETE next to the rest of your SELECT statements. I'd seen you could hook an LLM up to SQL before, but not this specific setup, where the model is another thing you can SELECT from.

Verdict: without Cortex, this app is three services glued together with secrets. With it, it's three SELECT statements from a warehouse I set up in a weekend.

It was also my first time touching Snowflake, ever—the whole thing runs on the trial credits, and AI did a lot of the translating while I did the plugging-in. I came in with six federal datasets and the vague idea that a coal mine ought to be able to talk back to you, and Snowflake is what made that second part real instead of a pitch deck.

Cortex Writes the Mine

SNOWFLAKE.CORTEX.COMPLETE('llama3.3-70b', …) generates the mine prose per subregion—3-5 sentences, named operator, named county, named tonnage, and the accident history folded in. Cached per subregion; no per-request LLM cost on repeat views.

Prompt (from app/prose_client.py):

{plant_name} ({plant_operator}) received {tons} tons of coal in {tons_year} from {mine_name}, a {mine_type} mine ({mine_operator}) in {mine_county} County, {mine_state}. Safety record: {fatalities} deaths, {injuries} lost-time injuries, {days_lost} days lost.

Write one paragraph, 3-5 sentences: plant → mine → human cost → the reader's demand. Omit any zero stat. No jargon, no hedging, no markdown.

Cortex Writes the Density Narrative 🎙️

Same COMPLETE call, different prompt, on the H3 hex grid of active vs abandoned mines feeding your plant. Fires from GET /h3-density.

Cortex Analyst Handles the Follow-ups 📊

Hand-written semantic model YAML over the federal-data schema. Backs the "Ask your grid" input. Ask about accidents, production, who else buys from this operator—Analyst writes the SQL, runs it, and returns the answer. Chip questions surface the obvious paths; the free-text input handles the rest.

Every Cortex-generated SQL is validated as read-only and single-statement, then executed through UNEARTHED_READONLY_ROLE with STATEMENT_TIMEOUT_IN_SECONDS=10 and a 500-row cap. Analyst can read the warehouse. It cannot write to it.

The semantic model is hand-written—every dimension, synonym, filter, and verified query. An excerpt from assets/semantic_model.yaml:

name: unearthed_coal_mines
description: >
  Federal coal mine and power plant data from MSHA and EIA.

tables:
  - name: MSHA_MINES
    description: Registry of all US coal mines from MSHA.
    dimensions:
      - name: mine_operator
        synonyms: [operator, company, owner, mining company]
        description: Current operator of the mine
        expr: TRIM(CURRENT_OPERATOR_NAME)
        sample_values:
          - Peabody Powder River Mining LLC
          - Arch Resources WY LLC
          - Murray American Energy Inc
    # ... full schema in repo

  - name: MSHA_ACCIDENTS
    measures:
      - name: fatality_count
        expr: SUM(CASE WHEN TRIM(DEGREE_INJURY) = 'FATALITY' THEN 1 ELSE 0 END)

verified_queries:
  - name: fatalities_at_mine
    question: "How many fatalities have occurred at Upper Big Branch Mine?"
    sql: >
      SELECT SUM(CASE WHEN TRIM(a.DEGREE_INJURY) = 'FATALITY' THEN 1 ELSE 0 END)
      FROM UNEARTHED_DB.RAW.MSHA_ACCIDENTS a
      JOIN UNEARTHED_DB.RAW.MSHA_MINES m ON a.MINE_ID = m.MINE_ID
      WHERE TRIM(m.CURRENT_MINE_NAME) ILIKE 'Upper Big Branch%'
# 7 more verified_queries in the full file

💡 The full semantic_model.yaml can be found in the repo.

Snowflake Marketplace

The Marketplace is the one I'd put on a billboard. MSHA and EIA I loaded myself, which was a weekend of writing scripts and swearing at CSV encodings. EPA emissions—CO₂, SO₂, NOx per plant since 2020—I clicked a button on the Marketplace and the data was just there, ready to join on plant ID. Cortex plus Marketplace is what moves this from data storage to data product—don't do what I did for the other datasets, click this instead.

Cost Dashboards and Cortex Code

This view is optimized for cost over performance, but I used it to troubleshoot slow queries and figure out where to spend my time to actually improve the experience for the user. I'm far from an expert on Snowflake's monitoring surface, but this dashboard and the ones next to it were the difference between the 40+ second queries I started with and something that finishes in time for the scroll to matter.

Cortex Code picked up the last of the excessive queries I had sitting around that Claude hadn't already caught. It behaves noticeably better than the MCP version I leaned on as my main driver for this build, but I was scared to hand my UI to an unfamiliar Streamlit-in-Snowflake AI on a weekend deadline. Definitely something I want to experiment with next time.

Closing 💜

The cost of mining coal from miles underground has always been paid by the miners and the mountains—rarely by the companies that come in, take what they can, and leave with the profit. Unearthed exists to put that cost in front of the person flipping the light switch, in a form they can interrogate without needing a degree in energy policy. Enter your address and within a minute you'll have the name of the mine, the operator, the county, and the people who got hurt keeping your lights on. Ask the grid a follow-up question in plain English and Cortex writes the SQL for you. Snowflake backs up every claim with data seeded from public sources. This Earth Day, remember the thousands of miners who went underground so your lights could come on, and the mountains that gave life to make it happen.

Ashley ChildressFollow

Distributed backend specialist. Perfectly happy playing second fiddle—it means I get to chase fun ideas, dodge meetings, and break things no one told me to touch, all without anyone questioning it. 😇

Sources 📚

Virginia Department of Energy—Abandoned Mine Land Program—100,000 acres of abandoned mine land + hazard list (landslides, highwalls, subsidence, shafts, fires, etc.)
EIA—Annual Coal Report 2024 (published Nov 2025)—Virginia 2024 production: 8.6 million short tons
Appalachian Journal of Law—Addressing Virginia's Legacy GOB Piles—245 legacy GOB piles in Southwest Virginia
NPS—Pennsylvanian Period (323.2 to 298.9 MYA)—"over 300 million years" coal-formation window
EPA Power Profiler—closest analogue I found: enter zip, see fuel mix. Stops at percentages.
iLoveMountains.org—closest emotional analogue: zip-to-mountaintop-removal health correlation. Qualitative, Appalachia-specific, no mine-to-plant data.

🛡️ Unearthed One Draft at a Time

This post was written by me with collaborative editing from Claude—who typed most of it, got told it was wrong roughly every three paragraphs, and had every TED-talk rewrite cut before it hit the page. I gave it my voice; it tried to give me something polished; we settled on mine. No AI was harmed in the making of this post, but Claude has now been told to stop editing out my voice enough times to consider filing a formal grievance.

Meet Hotfix—The Dragon Your Legacy Code Deserves

Ashley Childress — Mon, 13 Apr 2026 04:44:55 +0000

This is a submission for the DEV April Fools Challenge

What I Built

TL;DR
The permanent solution to every developer headache: thermal decommissioning.

Upload a screenshot → Hotfix roasts it
Gemini generates structured incident reports
Community votes via escalation system + shares
Top incidents become global P0 disasters

Hotfix files serious incident reports. It does not understand that it is completely unhinged. That's what makes it so funny.

Here’s a real incident report generated via live capture:

I Am the Problem 🏚️

I am the subject matter expert (SME) for several legacy applications at work, and every single time somebody stirs dust in the server room—since I can't come up with any other viable explanation—something breaks. After dealing with this nonsense in one form or another for well over a solid year, I announced the permanent fix: smelting. I am fully confident that smelting those legacy servers will resolve my ongoing issues instantaneously.

The one thing I've been lacking in my fantastical smelting solution is a dragon. Nobody seemed rather invested in how serious I am about problem solving, because so far not one person has offered me a dragon to get the job done. So I built my own—and I'm sharing it, because legacy code suffering is not a solo experience. Take a screenshot and let the Legacy Smelter handle the problem for you.

Asset Designation: Hotfix 🪧

Meet Hotfix—and yes, I named the dragon Hotfix because that is hilarious. Anything else would have been a giant missed opportunity for dragon naming. This app is more than a dragon, though—it's a whole incident management system. You can upload any screenshot—problematic code, poor UI designs, bugs that make you want to scream, or a selfie (if you can handle a little roasting)—and Hotfix will smelt the problem and give you a detailed incident report memorializing the true fix, which is melting it into oblivion.

The incident reports are added to a global manifest where you can share with friends who would appreciate your solution to the problem. Links are configured to unfurl properly on most platforms, including Slack and Discord. Sharing an incident is considered a containment breach by the system—wait seven seconds between shares to avoid rate limits—which increases the overall Impact for that incident. You can also escalate your favorite incidents, which carries even more weight. The top three global incidents with the highest impact rating are displayed on the main page as P0 priority.

💡 Operational Notice: Submitted images are processed by Gemini's paid API. Google is not using your uploaded images for training—they're only retained 55 days for abuse monitoring. Do not submit assets you do not own. Do not submit from a company device.

Demo

Live at hotfix.anchildress1.dev—head to the live site for camera uploads, since iframes don't have camera permissions.

Try to Break It ⛓️‍💥

Upload:

The worst UI you've ever seen
Your most cursed code snippet
A selfie (if you think you're emotionally prepared)

Then:

Share it
Escalate it
Win a sanction
Try to get into the global P0 leaderboard
Copy your output in the comments—it counts as a containment breach!

Code

The repo includes the full React frontend, Express server, Cloud Functions for sanction judging, Firestore rules, and a docs/ folder with the design decisions and prompt files referenced in this post.

anchildress1 / legacy-smelter

A hardware-accelerated mobile web app that visually melts user-uploaded legacy tech into a puddle of slag. Built for the DEV April Fools Challenge.

Legacy Smelter

A satirical incident reporting system for condemned digital artifacts. Upload an image. Hotfix processes it. Output: molten slag.

The system analyzes uploaded images using Gemini Vision and files a formal postmortem — classification, severity, failure origin, disposition, archive note — before thermally decommissioning the artifact via dragon-based remediation.

Features

Gemini Vision analysis — 16-field structured incident schema delivered via Gemini's constrained JSON mode
Hotfix animation — PixiJS dragon idle, fly-in, and smelt sequence with audio
Incident postmortem — full structured report overlay with social share (X, Bluesky, Reddit, LinkedIn) plus copy-link
Global incident manifest — real-time Firestore feed of all thermally decommissioned artifacts
Decommission index — live cumulative pixel count across all incidents
Camera support — deploy field scanner via device camera or file upload

Stack

Layer	Technology
Framework	React 19 + TypeScript + Vite
Animation	PixiJS 8
AI	Gemini (`gemini-3.1-flash-lite-preview`) via `@google/genai`
Database	Firebase Firestore

…

View on GitHub

⚖️ This project is licensed under Polyform Shield 1.0.0 and is released for this challenge as v2.0.0.

How I Built It

The Dragon 🥚

Getting the animation right was the hardest part of the entire build, and I went into it knowing almost nothing about sprite animation beyond whether something looked right or not. I found the dragon sprites on GameDevMarket.net and figured AI could handle the rest—which was optimistic of me, because AI is decidedly rough at producing smooth animation on the first try or the fifth. I picked up bits and pieces along the way, spent a humbling amount of time on what probably should have been a simpler problem, and I am still nowhere near an expert—but I am rather pleased with how Hotfix turned out.

The Stack 🧰

The front end is React 19 and TypeScript on Vite, Tailwind v4 for styling, PixiJS 8 for the dragon animation because Canvas 2D was never going to give me the smoothness I needed, and Howler.js so the smelt actually feels like something is happening. On the backend, Firestore handles everything community-facing, Firebase Auth gates the upload endpoint, and a small Express server keeps my Gemini API key off the client.

Gemini runs through the @google/genai SDK with two models doing two different jobs. Sanction judging fires as a Cloud Functions v2 onDocumentCreated trigger, claimed inside a Firestore transaction so concurrent invocations can't overlap.

Deployment is Cloud Run primarily because I like having the embeds available in these posts. I have a strong deployment pipeline already, which is running locally for this build instead of inside GHA—I already have the setup wired into Claude to build this flow for every app I create, so input from me is minimal.

The downside is that Cloud Run is not the stack I would have picked for this application had AI Studio not wired it that way from the beginning. Cloud Run is expensive, cold starts can be problematic for performance, and I didn't want it always-on just to run background functions—which I never scheduled anyway, so ultimately unnecessary. But that's how Cloud Functions got involved and turned this toy project into a three-server special in GCP.

Global Smelt Accumulation 🌋

Every image uploaded is converted into a total pixel count and added to a running Firestore counter. It's displayed at the top of every page and is a completely useless metric that I enjoy seeing—a completely valid use case.

Vibing a Solution 🫠

I was convinced I didn't need to write tests for a toy project I didn't expect to last, and I failed miserably at that conviction. I ended up using Vitest with Testing Library and the Firebase emulator, because fighting AI to stop making the same mistakes gets expensive much faster than just writing a test suite. The majority of my time was spent validating and complaining that the UI was not yet finished across Claude, ChatGPT, and Gemini. I think the four of us together somehow managed to not embarrass me, which I have categorized as a win.

Credits 🪙

Hotfix owes his entire existence to the artists whose work makes up the core of the experience. All assets sourced from GameDevMarket.net:

Dragon animation sprites — Animated Dragon by RobertBrooks
Slag/liquid effects — Flowing Goo-Liquid by RobertBrooks
Sound effects — Dark Fantasy Studio – Dragon by DFS (Nicolas Jeudy)

Prize Category

Best Google AI Usage 🏅

What Gemini Powers ⚙️

Two Gemini models power the live experience. Every upload is processed by gemini-3.1-flash-lite-preview, which:

identifies the subject and draws a bounding box around the primary artifact
extracts five hex colors as a chromatic profile
generates a 15-field structured incident report under strict voice and word-count constraints
Hotfix uses that bounding box to smelt the portion of the image Gemini actually flagged

gemini-3-flash-preview handles sanction selection on a separate path, grading batches of five incidents based on comedic scoring rules—more on that below.

The voice was a complete accident. The first pass at the prompt was a plain "read the image and return a structured report" instruction, which worked fine right up until I tried to trick the system with a selfie just to see what would happen. It roasted me. Thoroughly.

I spent the rest of the build optimizing for that exact energy—an enterprise postmortem entirely convinced of its own importance. The voice rules at the top of the prompt file are the load-bearing ones:

## Voice

Enterprise incident report. Postmortem tone: dry, precise, operational, concise. Accusatory toward the artifact and its history.

The system treats absurd subjects as routine incidents. It is filing an incident report. It does not know it is funny.

## Comedy mechanics

- Specificity over generality. "Also, the green paint" is funny. Find the one weird concrete thing in the image and call it out.
- The deadpan afterthought. End a technical assessment with a flat, too-honest trailing observation.
- Commit beyond the point of reason. Start institutional, then dramatically escalate without changing tone.

"The system does not know it is funny" is the whole design philosophy in one sentence. That's the entire premise in a nutshell.

Every one of the 15 returned fields has its own word-count cap and voice constraint baked into the prompt—without them, Gemini defaults to generic corporate language and the bit falls apart. The full prompt file is in the repo in server.js.

The Sanction Logic 📛

gemini-3-flash-preview handles the sanction path—Flash Lite falls apart on comparison judging across a batch, and Pro is overkill that actually loses some of the unhinged quality Flash is known for.

The original image is never stored, so Gemini can't grade accuracy against the source—it can only judge the writing. The first draft used strict grading criteria and kept picking the most technically accurate report instead of the funniest. Version two mostly lets Gemini run wild, and it picks the funny one now. The guidelines that survived:

Signals that a record may deserve sanction:

- disproportionate institutional seriousness applied to an ordinary software or workplace failure
- precise, concrete details that make the situation feel embarrassingly real
- escalation from a small defect, design choice, or human workaround into procedural absurdity
- wording that implies everyone involved has accepted something obviously unreasonable as normal
- dry phrasing that lands harder the straighter it is read

Do not reward a record merely for being:

- wordy
- random
- technically dense
- surreal without a clear comedic turn
- mildly clever but interchangeable with the others

The full sanction prompt file is in the repo in functions/sanction.js.

Building with Google AI 🧪

I touched nearly every Google AI tool during this build. Gemini Chat for brainstorming and prompt iteration, but it couldn't hold context long enough to be useful past the first few rounds. AI Studio for the initial scaffold—which checked my live API key into the repo on init, so that was fun until GitHub's secret detection caught it before I did. The CLI for animation work, though the accessibility skill was broken and I ended up routing around it. Antigravity until the free tier ran out mid-animation pass. Gemini Pro for the social banner, only it wasn't able to iterate for accurate edits. Each one ran out of steam before I was done, which is how I ended up reaching for all of them.

What actually shipped runs on Gemini. Every postmortem is gemini-3.1-flash-lite-preview doing exactly what it's good at, live, in production. Every sanction is gemini-3-flash-preview reading a batch of five and picking the one a dev would quote to a coworker. Two models, two jobs, both in constrained JSON mode, both doing real work on every request.

Gemini's version of this project is released as v0.0.1 and produced this rather useless but very funny animation:

Community Favorite 🪩

Legacy Smelter is a system designed to be shared, escalated, and collectively abused. Every incident lands on a global manifest, links unfurl on Slack and Discord, shares rack up breach points, escalations carry real weight, and the top three P0 incidents are permanent shrines to whatever the community found most absurd. If that sounds like something you'd enjoy, you're exactly who I built it for.

The Permanent Fix

All in all I'm more than thrilled to finally have my dragon accessible whenever I'm fed up with something. It's a nice way to relieve some stress and the output can be genuinely hilarious overkill.

Some problems just aren’t meant to be fixed...

They’re meant to be smelted.

Ashley ChildressFollow

🛡️ Thermally Decommissioned with Assistance

This post was written by me with collaborative editing from Claude, ChatGPT, and Gemini. The code for Legacy Smelter was built using Claude Code—who also wrote the tests, the deployment pipeline, the Cloud Functions, and then got put to work on this submission post because I don't believe in downtime.

ChatGPT and Gemini were consulted at various stages, though "consulted" is generous for how often they were told they were wrong. No AI was harmed in the making of this project, but one of them has now been through every phase of the software development lifecycle in a single sprint and may need to file its own incident report.

Forged Between Coal and Code

Ashley Childress — Fri, 03 Apr 2026 05:49:31 +0000

This is a submission for the 2026 WeCoded Challenge: Frontend Art

Show us your Art

Carbon Trace is an immersive memoir that I designed, wrote, narrated, and produced. I used my native Appalachian accent throughout since the origin story starts at home in a small coal town in Southwest Virginia.

For the full experience, visit my website at https://carbon-trace.anchildress1.dev and be sure to turn on your sound.

Pay attention to the ambient audio shifting between scenes. Watch the circuit traces grow from barely visible to full coverage. The ghost-drift text is intentionally out of sync with the narration—it's not a subtitle, it's a feeling.

Built with Canvas 2D, WebGL displacement effects, GSAP timelines, layered Howler.js audio, and accessibility-first interaction design—no frameworks, no shortcuts.

💡 This submission reflects the v1.0.1 release used for the competition build.

Inspiration

Origins of Carbon Trace 🪨

When I first saw this challenge, I felt what I wanted to draw almost immediately. The first obstacle was figuring out how to translate that feeling into code.

I wasn't inspired by any one thing. I was inspired by everything. To accurately convey the depth of gender roles in my life, I had to start at the beginning in the small Appalachian coal town where I grew up. Life there has clear binary boundaries: men work in the mines and women take care of the home. I've been pushing back on this ideal for as long as I can remember—starting with the toy kitchen gift I had zero interest in as a toddler.

Carbon Trace isn't another generic idea of equality. It's the fight I went through to be treated as an equal in a male dominated world. The diamond is a metaphor for my life and moves through its own journey in pictures as I tell you mine. I wrote and narrated the script in the exact same dialect I grew up speaking. Each scene has independent ambient audio designed to embody a specific emotion. There are small animations throughout that help bring the static images alive. Each individual component adds a layer of depth to the overall story.

Every image builds off of the previous version as the narrative progresses and follows the same constraints: circuitry begins barely perceptible and grows every frame until it covers the entire frame. The diamond starts black and covered in coal and shines brighter until its full power in the end. Strategic lighting throughout obscures faces to keep the focus on the diamond as the primary character and prevent this from being about any one person—it's designed to be about women in the industry as a whole because my experience is not unique. It's one of many.

So the diamond is my story zoomed out and abstracted so every individual can feel themselves inside the experience while I tell you about mine.

The Numbers Haven't Changed 📉

Even though we have grown from ideas like the ones I grew up with—where women belong in the kitchen, not in the coal mines—the inequality is still glaringly apparent in the tech space.

In college I served as president of the CS WoW club that aims to improve visibility of tech-related careers for young grade school girls through community outreach. Even with programs like this throughout the US, only one woman earns a CS degree for every 4 men (NCES, 2021–22).

In tech and more specifically engineering, men currently outnumber women 4 to 1 (BLS, CPS Table 39). The women who do work these jobs earn approximately 12% less on average than their male counterparts (BLS, Highlights of Women's Earnings 2023). I built Carbon Trace as a long-lasting impact piece. It maintains the state of truth in 2026 the same as these statistics do. I didn't build it to raise awareness. I built Carbon Trace to make you feel what these numbers can't.

Why It Had to Be Immersive 🌊

I imagine there's at least one person reading this and wondering why I needed a full scale production to tell a story that I just as easily could have written about. My answer is because I needed you to feel it.

Every technical layer in Carbon Trace exists to carry a piece of that feeling. The ambient audio shifts between scenes to set an emotional tone that words alone can't establish—mine dust settling, water running, wind through an empty room. The ghost-drift text floats fragments of thought across the screen like the things you almost say out loud but don't. The circuit trace shimmer starts nearly invisible and grows brighter every scene because the potential was always there—it just needed the right conditions to be seen. The PixiJS displacement effects make the world around the diamond physically respond: water flows, heat rises, and the diamond glows with increasing intensity. None of these layers are decorative. Each one is a narrative instrument, and Carbon Trace is what happens when they all play at once.

My Code

anchildress1 / carbon-trace

Deterministic scene engine for an interactive narrative experience using GSAP, Howler, Canvas 2D and PixiJS. Built for WeCoded 2026 Frontend Art.

Carbon Trace: An Immersive Art Experience

An immersive visual narrative told from the awareness of a diamond trapped in a coal seam—12 painted scenes with ghost-drift text, narrated audio, and pixel-level visual effects. Built for WeCoded 2026 DEV Challenge Frontend Art.

Experience it live: https://carbon-trace.anchildress1.dev

The Story 💎

A diamond wakes up inside a coal seam. It doesn't know what it is yet—just pressure, darkness, and the sense that something isn't right. Over 12 scenes it moves through tunnels, furnaces, pockets, sinks, and silence. It gets carried, stored, forgotten, and found again. By the end, it isn't just a diamond anymore. It's a circuit. It's music. It's light.

The narrative follows a carbon cycle that isn't chemistry—it's personal. Coal to diamond to circuit to light. Each scene is a painted image (Leonardo AI, Flux 2 Pro) with narration I recorded, ambient textures, ghost-drift text that pours in and blows out…

View on GitHub

⚖️ This project is licensed under Polyform Shield 1.0.0.

What I Am Not 🔧

I am not a frontend developer. I'm a backend-focused engineer who had never heard of Canvas 2D, Howler.js, PixiJS, or GSAP before this project. I spent just as much time learning what these tools do as I did designing the system around them. AI helped me learn what each tool did and gave me alternatives. I decided what to do with it from there.

I'm also not an artist. I used Leonardo.ai to generate all images and dusted off some old GIMP skills to build the image layer masks by hand. Everything you see in Carbon Trace was built by someone who doesn't do this every day—which is exactly why it took a full production pipeline, 13 ADRs, and four competing AI reviewers to ship it.

What I am is a backend engineer who brought backend discipline to a frontend art project. The ADR process, the adversarial review gauntlet, the CI/CD pipeline, 685 unit tests, 220 E2E tests—that's what happens when someone who builds production systems decides to build something meaningful instead.

The Voice You Can't Generate 🎙️

I wrote and narrated the script myself because real Appalachian is something that AI is incapable of—even with the list of words it's allowed to use in reference to the area I still call home. Words like "holler" (hollow) or "sangle" (single) and phrases like "ain't got a pot to piss in" (little financial means) are all authentic from the Southwestern Virginia and Eastern Kentucky regions.

I know enough about recording to know I never wanted to learn it myself. However, Carbon Trace could not exist without quality recordings that you don't get from QuickTime. So, I taught myself enough of GarageBand to record all tracks and no, that wasn't very much fun. I got in and out with the basics and then used ffmpeg to help slice the ambient sounds from FreeSound.org. AI was in the background to help me iterate ideas until I was happy with the end result.

How I Wrangled the Robots 🦾

Since this project lives entirely outside my usual stack, I leaned heavily on my AI friends to get the job done, but this was not a prompt-and-go solution.

The Review Gauntlet ⚔️

My primary workflow was Claude Code as implementer, Codex and Antigravity performed adversarial code reviews for every branch to identify inconsistencies and bugs, and Copilot had the final review sign off for all changes. Sonar and Trivy ran for every PR along with a suite of tests, including Playwright and Lighthouse.

This is just one of many examples of why this works overall—one LLM is never good at everything and putting them in competition with each other helps to increase code quality.

The adversarial reviews were critical to the final build, because no single AI was allowed to operate unchecked in a repo where I didn't plan to personally review the code. Beyond architecture bugs, the gauntlet caught frontend-specific issues—a mask processing loop that was freezing the page during scene loads, and repeated layout calculations that caused animation stutter. It also proved to be a pain because every time I thought I was done with a feature, there would be another hour or more of AI wrangling I had to do. The back and forth continued until all of my helper reviewers agreed on the ultimate solution and only then was the branch merged.

From Design Doc to Decision Records 🗂️

I started with a simple design document in markdown that was converted into an AGENTS.md file and wired to each AI individually. By the time I made it to version 5 of the "simple" design, I decided I needed something with a bit more structure. That's when I started writing architecture decision records instead and I added them to the repo for tracking. I ended up with 13 ADRs, most of which were updated after one or more decisions I made proved impossible given the constraints I defined. This forced every major technical decision to be intentional instead of experimental.

Alongside the repo work, ChatGPT and Claude Cowork helped me with image generation prompts and gave me all the info I needed about GSAP, Howler.js, PixiJS, and Canvas 2D to be able to make design decisions. They had competing reviews between them, as well, just to make sure all the pertinent information was available to me when I needed it.

💡 For a full breakdown of every architectural decision made during the build, the ADRs are available in the repo.

Hundreds of Wrong Diamonds 🔮

Leonardo wasn't very easy to wrangle either, as I generated literally hundreds of images to perfect each scene. ChatGPT and Claude often helped with wording, so both had their own best-practice instructions generated from research, covering several different image flows across models including Flux Pro 2.0, Nano Banana, and GPT Image 1.5.

I had several hilarious outtakes during image generation, too. I learned that specific words like "rough faceted" or "silhouette" did not mix well with some models. I ended up with a somewhat extensive set of rules for prompt generation to ensure the diamond's story was properly told through each picture.

Here's a couple of my favorite outtake images:

Under the Hood ⚙️

Application architecture: Vanilla JS (no framework), 14 ES modules orchestrated by a 5-state machine (Loading → Paused → Scene Active → Transitioning → Credits). My goal was to make this a production-level application without over-engineering or introducing abstraction where it doesn't belong. This is a static single page, one-flow-only application and the entire flow for each scene is controlled by scenes.json—every frame's image, narration lines, ambient audio, audio cues, effects, and transition config lives in one file for easy edits that don't interfere with code structure. Every scene difference is expressed as configuration, not logic, which means adding a new per-scene behavior is adding a config key, not an if-block.

The state machine isn't just a label—it controls how every subsystem behaves at any given moment. When a user pauses, audio, canvas transitions, PixiJS effects, shimmer dots, GSAP timelines, and auto-advance timers all freeze in sync. When they resume, everything restarts from exactly where it left off. An unconditional auto-advance timer fires regardless of whether the narration end event arrives, eliminating a race condition where scenes could stall if the browser swallowed the event. Every timer in the system is pause-aware through a shared PausableTimer utility so nothing leaks across scene boundaries.

The audio system is the most complex piece. I wanted to include different emotional ambient tracks for each scene designed to play just under the narration layer. I sourced all tracks from FreeSound.org, but no two sound effects have the same volume, which meant I needed the ability to mix on demand from the backend in addition to fade controls and delayed timing. Two independent Howler.js channels are responsible for running each track concurrently:

Channel	Format	What it does
Ambient	m4a, looped	Crossfades between scenes (800ms), pauses with all channels during nav
Narration	m4a, one-shot	Per-scene voiceover with configurable delay, pre-buffers next scene's audio during current playback

I also implemented buffer recovery escalation through three distinct stages: nudge (no-op seek to force browser re-eval), reload (preserve position → reset source → restore), exhaustion (log warning, clear state, prevent UI lockup). All timers use unified pause/resume logic to prevent cross-scene leakage. The final scene layers in a licensed track from Bridge City Sinners that fades in before the narration ends, then boosts in volume with a 3-second fade once the voiceover completes—a cinematic handoff from story to music.

Rendering architecture: The visual stack is four layers composited on top of each other—a Canvas 2D scene layer for images, a PixiJS/WebGL canvas for displacement effects, a separate Canvas 2D overlay for the shimmer trace dots, and a DOM layer on top for text, captions, and controls. Each layer has its own render loop and pauses independently with the state machine.

PixiJS visual effects: A separate WebGL-powered canvas handles pixel-level scene animations—water displacement, heat distortion, glow, and shockwave—each confined to mask-based regions so only targeted areas of the image animate. Effect parameters modulate in real time from audio frequency data via a Web Audio AnalyserNode. The entire PixiJS bundle (~330 KB) is lazy-loaded after the initial paint so it never blocks the first screen the user sees, and if WebGL fails entirely, the experience degrades gracefully to static images.

Circuit trace overlays: The circuit traces aren't just static images—they're a live shimmer overlay rendered on a dedicated canvas. Each scene loads a hand-authored PNG mask that I drew in GIMP, where dark pixels define walkable paths. shimmer.js spawns glowing dots that navigate those paths using 8-directional pathfinding, pulsing in warm amber tones that shift per scene. The opacity ramps from 5% in the opening to full coverage by the finale—the circuitry was always there, it just needed the right conditions to be seen.

The first design couldn't produce what I had in mind, so I deferred it, rewrote the ADR, and came back with a completely different approach that would get the job done.

GSAP timeline orchestration: The ghost-drift text was designed to keep the audience engaged in the narration in real time. I set up positioning as a percentage value relative to the container and originally allowed for alignment options. Later, I decided that was unnecessary and removed the extra noise from the codebase.

All captions sync directly into the GSAP timeline via callbacks instead of independent timers. That way when the user pauses or resumes any scene, the captions are automatically included.

The credits overlay has its own ADR and runs a GSAP-driven scroll with touch, wheel, and keyboard input, focus management for links, and full reduced-motion support.

Accessibility (WCAG AA): Any time I do any front-end work, accessibility is top of mind. This project was no different. I made sure all standard best practices were followed after AI helped to research what that looks like in 2026, including:

aria-live="polite" region to announce full narration text on scene change
Roving tabindex for the scene progress bar
Standard media keyboard nav: Space (play/pause), Enter/Arrow (advance), Escape (pause)
Screen reader narration separate from visual ghost-drift text (aria-hidden="true" on visual elements to prevent duplication)
A persistent caption toggle via localStorage
Reduced motion is fully supported—prefers-reduced-motion disables all canvas effects, freezes shimmer dots, cuts transitions instantly, and responds to live preference changes mid-session

I used AI to research and implement accessibility standards, then tested the final result and orchestrated changes to prevent repo chaos.

Shipping It 🚢

Underneath the story is a production-grade engineering process. Since I already have a pretty solid workflow with Release Please and Cloud Run, I provided the examples to AI and had the full CI/CD pipeline configured early on. That allowed me to track each shippable feature as a new deployed version for the final round of testing.

The setup for me was minimal, but it was the last piece of turning this fancy art project into a small scale production build. The final build is ~5,500 lines of code (LOC) backed by ~14,500 LOC of tests across 685 unit tests and 220 E2E tests. Five CI workflows cover linting, automated tests, Lighthouse CI for both mobile and desktop performance, security scanning via Trivy and CodeQL, static analysis through SonarCloud, and release automation.

What the Diamond Knows Now 💎

I took an unconventional path to get here, but looking back, I was always going to end up exactly where I am. The circuit traces in every scene of Carbon Trace didn't appear out of nowhere—they were there from the start, just waiting to be seen. That's my story too. I was made to solve problems, even when nobody around me expected that from a girl growing up in a poor coal town.

It's not always easy. But I've never been afraid of hard work to get the job done. The end result is a full circuit—built from pressure, time, and a refusal to stay small.

The fact that I'm a female engineer shouldn't matter. It only matters that I'm a good one.

Ashley ChildressFollow

🛡️ Pressure-Tested by More Than One Brain

This post was written by me with collaborative editing from Claude, ChatGPT, and Gemini. The code for Carbon Trace was built using Claude Code, Codex, Antigravity, and Copilot, and it was directed by a human who refused to let any of them off easy. All images were generated with Leonardo.ai under my art direction. All narration is my actual voice. No AI was harmed in the making of this post, but all were argued with repeatedly and extensively.

I Let AI Write to My Database (With Guardrails)🔬

Ashley Childress — Fri, 13 Mar 2026 02:20:52 +0000

My System Notes project started as a DEV Challenge and turned into a three-part systems experiment. Like most of my projects, it didn’t stay small.

It started as a simple idea: let the system capture engineering decisions as they happen and make them easy to reference later. Mostly as a future-me record of “what was I thinking?” for any given build.

You can read through my progression of thoughts across these challenge submissions, if you're curious:

The portfolio site does more than just display indexed decisions. It serves as my AI playground for pushing systems behind the scenes, just to see what happens. Over the last few weeks, that playground exposed a very boring problem. The exact kind that quietly slows everything down:

✋ Someone still has to write artifacts into the system—a less than thrilling, highly repetitive job I never actually wanted.

The Bottleneck I Accidentally Built ⚙️

The thinking process for the System Notes index already looks like this:

idea  
↓  
conversation with AI  
↓  
decision

Most of the reasoning happens in that conversation. ChatGPT helps challenge ideas, organize the thinking, and refine the direction. Turning those decisions into indexed artifacts required an extra step, and it got worse after I migrated from JSON to Supabase.

Originally, I handled it all manually but that got tiresome quickly. So, I let AI identify and summarize decisions that were made at the end of a session. From there I’d copy, paste, edit, and insert the record.

Later, I gave ChatGPT strict artifact instructions to format the output as a SQL insert. That removed one step and technically worked. In practice, not so much.

It was far from a perfect system and was often buggy. Even worse—it still required me to context switch, copy the output, paste it into a query, and fix whatever the AI inevitably messed up along the way.

So before tinkering too much, the second half of my workflow looked like this:

decision
↓
AI generates SQL
↓
copy
↓
paste
↓
I fix SQL
↓
insert

Which is not exactly the frictionless system I had in mind…

Supascribe: Letting AI Write Data Artifacts 🏗️

Since AI was already doing most of the heavy lifting, I saw no reason not to remove several of those steps with a little upfront structure. So, I wrote Supascribe—a small devtool designed to remove the manual translation layer eating into my build time.

Supascribe does one unconventional thing: allow the AI collaborator to write directly to the database, with a human-in-the-loop review step.

Risky? Probably. Uncontrolled? No.

The pipeline now looks like this:

AI collaboration
↓
artifact proposal
↓
human review
↓
schema check
↓
database insert

ChatGPT drafts the artifact from the conversation history, and after I approve it, the tool writes it to Supabase.

The goal is simple: shorten the distance between thinking about a decision and capturing it in the system.

Right now the tool is intentionally minimal. It does exactly three things:

Accept structured artifact input from ChatGPT
Check all required fields with a strict Zod schema
Write the artifact into the database

That’s it—there's no magic yet. Just structured input, a schema check, and a controlled insert. As it turns out, that was enough to remove the SQL-copying circus from my workflow.

Where The System Still Slows Me Down 🚧

The biggest problem is this isn't exactly the foolproof solution I first envisioned and it still relies heavily on my Approve/Deny button to maintain data integrity. AI is allowed to propose artifacts and insert them, but only after I allow it—which isn't what I wanted, but absolutely necessary for version one.

The integrity of the index is protected, but the system doesn't eliminate the human bottleneck yet. Right now Supascribe shortens the path between conversation and artifact, but it doesn’t fully automate it.

This system accelerates thinking, not decision authority.

And that’s intentional. Letting AI write at-will into your data layer without strict guardrails is a great way to accidentally invent a brand new genre of data corruption. 😕

Teaching AI To Touch Data Safely 🦾

The next phase of this experiment is testing how much autonomy the AI collaborator can safely gain.

That likely means stronger guardrails in two immediate places:

The backend can enforce stricter validation around artifact structure and write behavior.
The AI can perform structured validation before proposing artifacts.

The next goal is to make the workflow resilient enough for AI to safely participate in knowledge capture, not just idea generation. Right now the system is cautious by design, but I do want to gradually increase its autonomy and see how well data integrity holds over time.

What started as documentation automation is turning into something bigger: testing how much responsibility an AI collaborator can safely hold.

The Real Question Behind This 🌀

My System Notes portfolio started as a simple portfolio experiment. Supascribe turned it into a systems experiment.

Now I'm testing how well AI acts as a participant in the artifact creation layer of a knowledge system.

Not just generating text or ideas, but using its own memory and strict guidelines to identify which decisions should become part of the underlying system.

Admittedly, that’s a much more dangerous layer for AI to operate in. And sounds like fun to me.

Most AI tooling stays safely away from the data layer of any system. It's allowed to draft, suggest, summarize, and code. However, Supascribe goes one step further and asks:

What happens if the AI helps write the system itself?

Yes—I’m aware this could explode in very entertaining ways. That’s kind of the point. 🌀

I started this experiment trying to remove friction from documentation.

What I’m actually testing is whether AI can safely participate in the systems that decide what gets remembered and what gets trusted.

🛡️ The System Didn’t Write This Alone

This post was written by me, with ChatGPT acting as a thinking partner while refining structure and clarity. The decisions, experiments, and system design are mine. ChatGPT helped challenge wording and tighten the narrative.

AI wants you to know that it performed no database writes during the editing of this post. That seemed wise.

I Stopped Reviewing Code: A Backend Dev’s Experiment with Google Gemini

Ashley Childress — Wed, 04 Mar 2026 00:02:48 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

🦄 I’ve been officially obsessed with AI for nearly a year now. Not from an ML research angle and not from a purist implementation standpoint. The thrill, for me, is in finding the limits as a user and then leaning on them until something gives. One of my favorite Hunter S. Thompson lines talks about “the tendency to push it as far as you can.” That has been my operating principle this entire year.

This build started as a portfolio experiment. It turned into something else entirely. This challenge became the cleanest environment I’ve found to test what actually happens when you step out of the implementation loop and let the model build the world without you.

What I Built with Google Gemini

When I saw the New Year, New You Portfolio Challenge, I knew it required a UI. That wasn’t a surprise. What was a surprise was how quickly I would realize I didn’t understand what I was looking at once it started coming together.

I’m a backend developer. You hand me a distributed systems problem and I’ll happily spend hours untangling it. You ask me to make a div visible in a browser and my brain actively searches for the exit. With only one weekend to build, there was no room for the "eyes-glazing-over" phase. Google Gemini would implement and I would supervise—that was my whole plan.

I walked in expecting Antigravity, powered primarily by Gemini Pro, to behave like every other AI system I’d tested—predictable and fairly easy to keep inside the guardrails. I thought I already knew what those guardrails looked like: strict types, linting, and the familiar routine of code review.

The Pivot: Dropping the Code Review Ritual

Initially, I followed the "responsible" pattern: prompt, review the diff, run tests, approve. It felt disciplined. It looked professional.

Very quickly, I realized I had no meaningful context for what I was reviewing in a frontend stack. I wasn't improving the output; I was participating in ceremony. So, I stopped reviewing code altogether.

Instead of validating lines of code, I validated outcomes. If the UI rendered correctly and passed functional tests, that was success. I cranked up the autonomy, taught Antigravity my repository expectations, and let it run. Copilot reviewed the code in my place, and Gemini responded in a closed loop. I stepped out of the implementation and into the role of a systems auditor.

Demo

This portfolio iteration documents what happens when you turn an agent loose inside a defined system.

For this build, the Antigravity panel was the primary interface. I defined the repo rules and testing expectations there, and Gemini implemented directly within that structure. It became the control surface for the entire loop.

V1 Release: Preserved version v1.1.0
Live Portfolio: https://anchildress1.dev

Replacing Trust With Systems

I didn’t simply remove oversight; I replaced it with Lighthouse audits and expanded test coverage. My assumption was simple: if the browser behaves and the tests pass, the code is "safe." I believed I had replaced trust in code with trust in systems. I was wrong—I had confused passing tests with structural integrity.

What I Learned

High Reasoning Isn’t Optional

I learned that for autonomous development, reasoning depth is a stability requirement. With lower reasoning modes (like Flash), changes were often partial—updating 2/3 of the files but "forgetting" the tests or documentation.

Switching to High Reasoning mode in Gemini Pro changed the pattern. Runtime errors dropped, and cross-file consistency improved. It finally started "remembering" to keep the docs aligned with the code changes without constant nudging.

Reasoning depth wasn’t about intelligence—it was about reliability under autonomy. Gemini’s deeper reasoning and context retention made the closed-loop workflow viable; without it, cross-file consistency collapsed quickly under autonomy.

The Reality Check: Sonar

After the high of the successful build wore off, I introduced Sonar as a retrospective audit. The UI rendered correctly. The tests passed. Everything appeared stable.

Sonar reported 13 reliability issues and assigned the project a C reliability rating. Of those issues, 66% were classified as high severity. Security review surfaced three hotspots, including a container running the default Python image as root and dependency references that did not pin full commit SHAs.

Maintainability scored an A, but still carried 70 maintainability issues—structural patterns that didn’t break behavior, yet increased long-term complexity.

That was the moment confidence turned into scrutiny.

The application worked. The tests passed. But reliability, security posture, and structural integrity told a different story. The tests validated behavior; Sonar validated assumptions. And those are not the same thing.

The lesson? AI-generated tests can pass because they were written to satisfy the implementation, not challenge it. Structural validation requires an independent layer of review outside the generation loop.

Google Gemini Feedback

What Worked Well

Cohesive Implementation: High reasoning Gemini Pro produced cross-file changes that respected the intent of the repository.
Agentic Orchestration: The model switching was seamless, and the orchestration interface made it possible to define expectations clearly and enforce them consistently.

Where Friction Appeared

Cooldown Transparency: While the interface shows when current credits refresh, the length of the next cooldown remains a black box.
Tool Performance: MCP responsiveness materially impacted iteration speed, sometimes forcing me to batch requests rather than work in small, rapid increments.

💡 Pro Tip: It would be a massive UX win to see exactly how long your next cooldown will be (e.g., "Your next cooldown will be X hours long") directly on the models page. Knowing if the lockout is 1 hour or 96 hours is vital for developer planning.

The Final Verdict: Autonomy Still Demands an Audit

The lesson wasn’t that Gemini failed; it was that systems-level trust requires more than passing tests. In future builds, autonomy won’t ship without an explicit adversarial audit. Whether that means a mandatory Sonar gate, a red-team prompt pass, or a second high-reasoning model instructed to hunt for the first model’s shortcuts—the loop must be challenged.

This project began as a weekend experiment to escape the “teleportation” haze of frontend development. It ended as an exploration of the razor-thin edge of system-level trust. The real build wasn’t the portfolio—it was discovering what happens when you lean on the limits of AI until they finally give.

Removing myself from the implementation loop didn’t eliminate responsibility; it redefined it. The more freedom you give an agent, the more rigor you must give your audit.

🛡️ The Tools Behind The Curtain

This post was brewed by me—with a shot of Google Gemini and a splash of ChatGPT. If you catch a bias or a goof, call it out. AI isn’t perfect, and neither am I.

Find the DEV Post That Needs You Now 🫶

Ashley Childress — Sun, 01 Mar 2026 12:17:00 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

DEV feels like home: learning, lively discussions, and new connections. It’s a place where people genuinely want to help each other, but fast-moving feeds make it hard to see where a reply would matter most. This tool is meant for members who want to help and just need direction.

That support matters because someone is always willing to help. The harder part is knowing where help is actually needed. When posts are easy to miss, willingness doesn’t always translate into action.

Where This Started

I’ve been a DEV member for less than a year, but I’m more active here than anywhere else online. I’m willing to volunteer where I can, but knowing how and where to help is difficult without direction. I built a system to provide a consistent, openly scored view of where input may be needed most. The goal is fewer “how can I help?” moments and more meaningful responses.

A few weeks ago I noticed a post in #mentalhealth where someone had reached out and nobody had answered. I care deeply about this topic, and the post had been written days earlier. I responded immediately, but I wish I had seen it sooner. Sometimes simply being heard makes a real difference. Some posts deserve a timely human reply but can be buried by feed dynamics.

What really bothered me is that if I saw this once, there are likely many others like it. The primary feed favors recent and high-performing posts, which means others can slip through the cracks. So I built a visibility dashboard for anyone who wants to help posts get attention when they need it. It uses a simple scoring structure with one goal: show humans where their input may matter right now.

What I Built

Rather than sorting only by recency or popularity, DEV Community Dashboard prioritizes conversations showing meaningful signal but limited engagement—helping community members decide where their contribution can have the greatest impact.

Behind the scenes, AI augments lightweight heuristics with bounded semantic analysis. Instead of matching tags or phrases alone, the system evaluates conversational context to estimate where attention may be useful. All classifications rely solely on publicly available DEV data. It uses only published posts and never touches private content. Nothing about the original content is changed; each item links back to the canonical article so the conversation stays on DEV.

Demo

Typical feeds prioritize recency or engagement. That works for discovery, but useful posts can still be missed. New members may be asking their first question, or someone may have a time-sensitive problem. When those go unanswered, the community never gets the chance to respond.

I built a public dashboard to surface posts that need attention so others can receive the same support I experienced when I started blogging here. The site is online at https://dev-signal.checkmarkdevtools.dev and free to use. Every post follows the same calculations to keep behavior predictable, while humans remain the deciding factor.

Workflow:

Open the page
Pick a surfaced post
Reply on DEV

It reprioritizes the public feed using signal quality and engagement metrics, highlighting posts with strong signal but low interaction. Updates run hourly for posts published between 2 hours and 5 days ago. This window balances visibility (not too new) with relevance (not stale). Each item links directly back to the canonical DEV article in a new window.

If the embed doesn’t load, use the direct link above.

What This Is

The dashboard highlights situations such as first-time posters without replies or requests for help that have not received responses. Community members open the page, select a post, and respond directly on DEV.

Its role is simple: route attention.

There are four primary triage categories:

Category	Definition
Needs Support	Language suggests burnout, emotional strain, or direct help-seeking; may benefit from a thoughtful reply
Awaiting Collaboration	No meaningful replies yet; a person should engage directly
Silent Signal	Minimal engagement activity despite visibility
Trending Signal	Valuable content with limited reach; worth amplifying

Secondary states (such as rapid activity spikes or anomalous metrics) act as informational flags rather than routing drivers.

Design Principles

I spent time ensuring this did not become a moderation or quality ranking system. The goal is visibility at the right moment with transparent categorization.

Every post exposes the metrics used to classify it. Hidden scoring breaks trust, so values appear numerically and visually with hover descriptions explaining each metric in plain language.

I included a feedback loop to the GitHub repository where discussions and improvements can happen. The tool belongs to the DEV community as much as it belongs to me.

Code

The project focuses on one task: surface posts that likely need a human reply. The repository shows how public DEV posts are collected, how engagement signals are calculated, and how the list is updated on a schedule.

The repo includes docs, diagrams, tests, and security scans to keep behavior predictable.

ChecKMarKDevTools / dev-community-dashboard

Community behavior analytics dashboard for DEV.to. Observes activity patterns, engagement dynamics, and moderation signals without judging individual users.

Community
Pipeline
Scans
Stack
Code Quality
AI
Support

DEV Community Dashboard

A signal-surfacing tool for Forem communities (dev.to and self-hosted instances). It ingests the latest posts via the public Forem API, classifies each one into attention categories (Awaiting Collaboration, Anomalous Signal, Trending Signal, Rapid Discussion, Steady Signal), and persists the results in Supabase so community helpers can see where conversations need a human eye.

This is not a moderation tool or a scorecard. It is designed to help helpers know where to look.

Production: https://dev-signal.checkmarkdevtools.dev (Cloud Run -- deployed post-initial-release)

v1.1.0 adds LLM interaction scoring, NEEDS_SUPPORT detection, and incremental caching and was created for the DEV Weekend Challenge.

Documentation

Document	Description
Architecture	System overview, data flow diagrams, deployment, API routes, guardrails
Interaction Signal	Composite signal formula, LLM scoring pipeline, model cascade, heuristic fallback, incremental scoring, signal spread, topic tags
Metrics Reference	Full `ArticleMetrics` field reference, risk components, velocity, participation,

…

View on GitHub

How I Built It

The app collects public DEV posts through the API, calculates engagement signals, stores results, and renders a prioritized list. The comment-scoring step returns schema-validated JSON (with typed fields and bounded ranges); invalid outputs fall back to deterministic heuristics, and the scoring pipeline is covered by automated tests to keep classification behavior stable as the system evolves. Updates run hourly and each item links back to the original article.

The prioritization model favors lack of interaction over popularity. Posts decay over time so those with the highest potential impact surface first.

Measuring Interaction Signal

Traditional dashboards often rely on keyword sentiment counts, which struggle to distinguish between surface praise and substantive discussion.

This system uses a composite interaction signal focused primarily on relevance and depth, with limited weight given to tone. Each comment contributes to a post-level score estimating where a constructive reply could meaningfully shape the conversation.

The comment scoring model is guided by a structured system prompt that defines how relevance, depth, and constructiveness are evaluated before contributing to the overall interaction signal.

TASK: Interaction signal analysis of blog post comments.
INPUT: A blog post body followed by numbered comments.
RULES:
- Extract 1-3 topic keywords from the post body as topic_tags.
- For each comment, assign interaction scores.
- Set needs_support to true if the post body contains signals of emotional distress, mental health struggle, burnout, isolation, or explicit help-seeking.
- Never infer beyond available text. Score only what is present.

The full prompt and a detailed explanation of calculations exist in the GitHub repo along with system diagrams. Each one maps to a graph that's displayed on the post details page.

Limitations

This is a signal-based prioritization model, not a full understanding of intent.

Nuanced tone, sarcasm, or highly domain-specific language may affect classification accuracy.
Posts can move between categories quickly as new replies or reactions change the underlying signals.
The system reflects public engagement patterns only.
Thresholds are calibrated for general community patterns and may not perfectly fit every tag or topic area.

The dashboard surfaces likelihood, not certainty. Human interpretation completes the picture.

Broader Impact

The goal is simple: help DEV members see where their attention can matter most. The dashboard surfaces where engagement is thin, where conversations are drifting, and where a thoughtful reply could shift the tone. Participation remains voluntary; the system only highlights opportunity.

If it works, fewer posts sit unanswered, engagement becomes more intentional, and contributors have clearer context before jumping in.

If you have ideas or feedback, share them below. You can also star the checkmarkdevtools/dev-community-dashboard repository to follow its progress.

🛡️ The Editor Who Doesn’t Commit Code

This piece was written by me, with ChatGPT acting as a second set of eyes. It helped tighten wording and keep explanations clear, but every decision, tradeoff, and line of code came from a human brain and a late-night idea that refused to go away.

Skills Aren’t Magic. They’re Scoped Context. 🧭🗂️

Ashley Childress — Wed, 18 Feb 2026 13:44:00 +0000

🦄 Skills don’t magically make your agent smarter. They change when context is loaded.

I intended to add Copilot skills to the list of topics I’ve written about, but it quickly turned into a behavior discussion instead of a how-to. Honestly, the same patterns behind custom agents, reusable prompts, and repo instructions all apply here. If you really want to understand a skill, then the mechanism matters more than writing the file.

Most frustration I see comes from expecting improved agent intelligence instead of selectivity. The truly interesting part is knowing when they help… and when they quietly make things worse. 🚦💎

What Skills Actually Change 💳

I’ve been rotating between Claude, GPT-5.2, and Gemini long enough to notice a pattern: most friction isn’t about model capability. It’s about context.

Once you regularly switch agents, you start seeing how much behavior differences come down to what each system loads, when it loads it, and how aggressively it summarizes what you gave it.

That’s where skills start to matter.

Skills reduce context overload by deferring detailed instructions until the moment they’re relevant. When written well, they feel like relief. When written poorly, they introduce overhead: lookup cost, planning cost, and extra reasoning steps before execution begins.

That overhead accumulates. Which is why I’m more interested in when skills should not exist than in how many you can create with the free space.

🦄 Across tools, the bigger difference isn’t “which model is smarter.” It’s how each agentic system decides what context deserves attention.

Instructions vs Skills 🧷

Metaphors always land faster than jargon for me. So here’s the one that stuck for me: "Bob the Builder".

The agent is the builder.
Instructions are the blueprints.
Skills are the tools.

Blueprints describe what is always true. If you’re building a house, the structural plan does not change because you switched from wiring to drywall. In a repository, that’s what belongs in .github/copilot-instructions.md: guidance that is universally applicable and always loaded for every task.

Skills are conditional. You wouldn’t scatter every possible tool across the floor before starting a task. You grab what’s needed when you need it. Loading everything up front slows you down—and missing the one tool that actually matters often changes the outcome entirely.

That distinction is even more important now that context bloat is a real constraint. Long instruction files get summarized and those summaries will drift from the original intent. The most important line you were relying on for tone or guardrails is often the first casualty.

A skill avoids that by staying out of baseline context from the start.

At runtime, only the skill’s name and description are visible to the agent. It evaluates whether the current task matches that description. If the skill is relevant, then—and only then—it loads the full SKILL.md.

When a skill isn't activated, the agent didn’t “forget”—it never saw those details in the first place.

💡 ProTip: GitHub’s docs on agent skills and Claude Code’s skills docs are worth reviewing if you want the official mechanics behind activation.

Skill Structure and Activation 🪛

A Copilot skill is defined by a SKILL.md file. For repo-level skills, the structure looks like this:

.github/
|-- skills/
|   `-- your-skill-name/
|       `-- SKILL.md

The directory tree itself doesn't matter as much as when the agent activates it.

Only the skill’s metadata is evaluated initially. If the description matches the task, then the agent loads only the SKILL.md file and treats its contents as procedural guidance.

If you extend a skill with additional files, they are invisible unless explicitly referenced and deliberately loaded.

This separation is the entire value proposition of a skill:

Before activation	After activation
Operates on inferred repository patterns	Executes defined procedural rules
Uses baseline instructions only	Uses baseline instructions + skill guidance
Optimizes for general applicability	Optimizes for task-specific behavior

💡 ProTip: Copilot also checks .agents/skills and .claude/skills (globally and per repo). That makes cross-tool skill reuse feasible without duplicating logic unnecessarily.

Anatomy of `SKILL.md` 🧬

The SKILL.md file defines both activation metadata and execution guidance. The name and description are always visible to the agent. The rest of the file becomes active only after invocation.

Skills can mirror:

a custom agent
a reusable prompt
a custom instruction
or a hybrid of all three

Below is a simplified example designed to activate only when editing a CHANGELOG.md file:

---
name: changelog-writer
description: Rewrite changelog entries with cheeky, narrative flair following project conventions. Use this when asked to rewrite or update CHANGELOG.md entries.
---

## Execution Workflow

When invoked to rewrite a changelog entry:

1. **Read CHANGELOG.md** to extract tone and structure
2. **Identify release type and breaking changes**
3. **Select emoji(s)** appropriate to release theme
4. **Craft italicized opening quote**
5. **Write body content**
6. **Validate links, formatting, and breaking-change visibility**

The key observation here isn’t the workflow itself. It’s the activation boundary. Without activation, none of that logic exists in the agent’s working memory.

🦄 The full version lives in my awesome-github-copilot repo if you want to inspect it more closely.

One Sentence Version 🐎

If a behavior must apply consistently, it belongs in repository or global instructions.

If a behavior is conditional, procedural, or task-specific, it belongs in a skill.

A skill should feel like a tool you occasionally reach for—not a consistent rule the agent has to rediscover on its own every session. However, once instructions grow large enough, they stop acting like baseline context and start acting like noise. At that point trimming becomes more valuable than adding.

In case it helps, this is the prompt I use when reducing instruction bloat for newer LLMs:

Review #copilot-instructions.md and optimize for AI consumption. Remove information that can be inferred from repository structure or code usage. Eliminate duplication and anything that does not improve clarity or reduce ambiguity. Preserve personality and tone directives. The final file should prioritize agent understanding over human readability.

💡 ProTip: Back up the original first. Agents are confident editors and occasionally confident editors erase the one line that mattered most.

🛡️ Behind the Curtain

I wrote this post, and ChatGPT helped like a well-defined skill. I made the final calls—it activated when needed and stayed out of the way otherwise.

From Static Portfolio to Indexed Decisions 📃

Ashley Childress — Mon, 09 Feb 2026 03:00:00 +0000

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

🦄 I instantly knew what to build as soon as I saw this challenge paired with the New Year, New You Google Challenge. Honestly, I’d been meaning to build a portfolio for a long time and never prioritized the work. This challenge finally interested me enough to take that idea and actually run with it.

Besides, it’s much more satisfying to show why something works when there’s a story attached. If you want to skip ahead, at least read the first part carefully.

Static portfolios treat decisions as narrative. This project treats them as data.

What I Built

This backend dev wasn’t built for pretty UIs. I was built for systems. So I created a non-conversational portfolio that behaves like a well-oiled machine instead of a static showcase.

Traditional portfolios require interpretation. This system removes interpretation entirely.

When I first envisioned what my portfolio site would look like, I knew I wanted it to stand apart from the usual LinkedIn résumé echoes. I’m strongly allergic to “normal” on the best days, but novelty alone doesn’t scale. I also knew the site had to be backed by infrastructure strong enough to survive my constant experiments and changing approaches over time.

Naturally, those ideas converged into a single decision: build a living journal of my projects, struggles, and decisions as they happened.

Decisions are first-class records here, not explanatory prose.

Something future-me could query months from now when I’m inevitably asking, “What in the world were you thinking?”

As soon as I saw this challenge post, I started documenting every challenge, decision, outcome, and constraint. That process began with everything I could reconstruct from my existing GitHub projects.

🦄 Even if I documented every single time I changed my mind, this index structure could absolutely handle it. Don’t worry. I didn’t go that far.

Index Design

The index is the system. If it fails, nothing else matters.

Once I had a handle on controlling assistant agents on the UI side, the index became the real work. Designing it, breaking it, and curating it took the most time. Early patterns weren’t great for retrieval performance, but after studying Algolia best-practice guidance, things finally clicked.

The result is a collection of small, atomic records optimized for retrieval.

These power a clean UX through facets and deterministic sorting using both signal strength and record creation time.

Here’s a real example pulled directly from the site:

[
  {
    "objectID": "card:project:challenge:algolia-agent-studio-2026-02",
    "title": "Algolia Agent Studio Challenge participation",
    "blurb": "An applied exploration of conversational retrieval.",
    "fact": "I participated in the Algolia Agent Studio DEV Challenge during February 2026, focusing on conversational and non-conversational search behavior using indexed content.",
    "tags.lvl0": ["DEV Challenge", "Approach"],
    "tags.lvl1": ["DEV Challenge > Algolia Agent Studio", "Approach > Experimentation"],
    "projects": ["System Notes"],
    "category": "Experience",
    "created_at": "2026-02-08T05:42:00-05:00",
    "signal": 5
  }
]

Why these fields exist:

signal controls relevance pressure under ranking
created_at stabilizes ordering across time
hierarchical tags enable narrowing without dilution
constrained categories prevent ambiguous grouping

🦄 In case you were wondering, I didn’t write these by hand. I defined the rules and constraints, handed them to ChatGPT, and manually tracked the generated output in a JSON file stored in the repo at System Notes v2.0.0/Algolia.

Ask AI as Search

This project includes both a conversational chat interface and an Ask AI Search experience.

For this entry, Ask AI is intentionally treated as a pure search surface, not a conversational agent.

The conversational state is optional and these results consider only the non-conversational queries executed against the Algolia index.

I evaluated retrieval performance over time—specifically speed, relevance, and consistency—while making iterative improvements to index configuration, ranking rules, and facets.

If identical queries did not return identical results, the configuration was not finished.

The system now returns the correct indexed records quickly and predictably, without requiring query reformulation.

💡 A copy of all index configuration files are kept in the repository as a reference at System Notes v2.0.0—apps/api/algolia/config.

Live Demo

The site is deployed at https://algolia.anchildress1.dev to keep it separate from the previous challenge submission.

Try searching for “Algolia” or filter by the categories on the left to load relevant results.

Current canonical: https://algolia.anchildress1.dev
Source code: System Notes v2.0.0

🦄 If you want a full comparison snapshot, the original site remains live at https://anchildress1.dev. The difference between that version and the Algolia-powered build is dramatic.

Algolia Agent Studio in Practice

A well-designed index alone isn’t enough.

Retrieval quality is dictated by configuration discipline, not feature count.

I tested most options available in Algolia’s configuration panel while tuning this system. The most impactful changes involved aggressively limiting searchable attributes and tightening facet definitions.

I also discovered that overly generous synonym expansion negatively affected agent retrieval speed, so those were deliberately scaled back.

Keeping the Index in Sync

To avoid duplicating content manually, I configured an Algolia crawler to index content from DEV using my AI-optimized mirror site.

This keeps the index authoritative without human intervention.

The crawler is a lightweight JavaScript configuration managed directly from the Algolia dashboard.

💡 The crawler configuration file is stored in the repo at System Notes v2.0.0—apps/api/algolia/sources/crawler.js.

Tuning with Analytics

An unfortunate API-key mistake prevented me from retaining full historical analytics.

Even so, analytics were used to confirm that retrieval behavior stabilized under repeat queries.

🦄 For the record, Algolia makes API key recovery painless if you record the original key. Naturally, I did not.

Why Fast, Predictable Retrieval Matters

Before Algolia, users had to rely on me to remember and document every meaningful decision tied to a project.

That does not scale. Retrieval does.

Now, I have a system capable of rapidly retrieving hundreds of decision-level records across active builds.

Original Design	Paired with Algolia	Observed Improvement
Project cards showing finished work	Choice cards indexed as search records	✅ Enables decision-level retrieval instead of content browsing
Projects shown as static artifacts	Searchable sequence of constrained decisions	✅ Demonstrates retrieval-first system thinking
Narrative explanations only	Retrieval-backed records with rationale	✅ Proves answers are grounded in indexed data
Generic portfolio navigation	Algolia-powered discovery as primary UX	✅ Makes Algolia structural to the experience
“Chat with AI” as a feature	AI layered over Algolia retrieval	✅ Signals intentional AI restraint
Silent gaps when data is missing	Fallback logic surfaced in results	✅ Shows real-world constraint handling

This system would not exist without Algolia. It isn’t an enhancement. It’s the foundation.

What’s Next

I ran out of time and this challenge had a hard stop.

Given the choice, I optimized retrieval stability over feature breadth.

When time allows, these are next:

Wire custom URL routing so search results are directly addressable
Finalize recommendations driven by real user interaction events
Introduce a Supabase backing store for indexed records to support long-term growth
Migrate existing project cards into the new indexed record format
Continue UI refinement and performance tuning

🦄 After winners are announced, this site will live solely at https://anchildress1.dev as my canonical portfolio.

🛡️ The Credits in the Margins

This piece was written by a human, with ChatGPT used along the way for editing, clarity passes, and structural tightening while drafting. The final shape, technical claims, and decisions are human-made.

Conversational Retrieval: When Chat Becomes Navigation 💬

Ashley Childress — Mon, 09 Feb 2026 03:00:00 +0000

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

🦄 I never truly planned to enter this challenge twice—it just sort of happened. I can tell you exactly why it happened though.

AI stopped being interesting the moment it became expected.

I wasn’t the first person to experiment with AI-driven interfaces, but I’ve been doing it long enough to recalibrate my expectations. Once AI becomes table stakes, the real work shifts. The question is no longer can you use AI, but how intentionally you design around it.

The non-conversational entry proved something important: fast, predictable retrieval changes how a system feels. This entry starts from the same foundation and explores what happens when that retrieval layer is surfaced through conversation.

💡 Important Note on Scope

This submission focuses exclusively on the conversational layer of the system.

My first submission post walks through the indexing strategy, retrieval architecture, and backend system design that make this experience possible. That foundation is intentionally treated as a given here so the conversation layer can be evaluated on its own terms.

What I Built: Two Interfaces, One Discipline 🧱

This system presents two distinct ways to enter the same body of knowledge.

Ask AI exists as a focused retrieval surface. It is designed for moments when the user already knows what they’re looking for and wants a clear, direct answer. A question goes in. A grounded response comes back. The interaction resolves cleanly, without conversational momentum.

Ruckus 2.0 (the chat agent) becomes a way to navigate through my portfolio. Questions don’t necessarily end the interaction. They shape it. Each response helps orient the user, and each follow-up becomes a small decision about where to go next. Instead of resolving immediately, the interface supports exploration without losing direction.

Both interfaces rely on the same indexed data. Neither invents answers. Neither speculates beyond what is retrievable. What changes is not the intelligence of the system, but the posture it takes toward the user.

This separation is intentional.

🦄 Ask AI answers the question that was asked. Chat helps decide which question to ask next.

Ask AI — Focused Retrieval 🔎

Ask AI is optimized for moments when the user already knows what they’re looking for and wants a clean, bounded answer. A question goes in. A grounded response comes back. The interaction resolves without momentum.

This interface is about precision, not exploration.

🦄 For this entry, the focus is not on Ask AI as a standalone feature, but on how it supports conversational movement through the system.

Ruckus 2.0 — Conversational Navigation 🧭

Ruckus is designed for movement.

Instead of resolving immediately, conversation unfolds across turns. Each response narrows context. Each follow-up becomes a directional choice, allowing users to navigate through indexed records and long-form content without upfront configuration.

This interface reduces the cognitive load of deciding how to search.

Rather than requiring users to understand the shape of the data up front, the system lets that shape reveal itself gradually. The chat layer sits on top of indexed records, long-form blog content, and explicit retrieval rules, allowing users to discover relationships through interaction instead of configuration.

Conversation here is directional. It does not wander. It does not pretend to know more than it does.

🦄 This is the point where the system stops feeling like search and starts feeling like motion.

Smart Navigation (Almost) 🚧

Conversational navigation only works if it can be trusted beyond the moment it happens.

Conversational paths should survive reloads, not disappear into session state.

To support that, I began wiring event tracking and smart URLs tied to user actions. Algolia’s InstantSearch library makes it straightforward to persist UI state directly into the URL, allowing conversational paths to be shareable, bookmarkable, and resilient.

https://algolia.anchildress1.dev/search?category=Work+Style&project=System+Notes&tag0=Discipline&tag0=Mindset&tag1=Discipline+%3E+Engineering&tag1=Mindset+%3E+Systems+Thinking

🦄 This work is not fully complete, but the structure is in place. The system can be extended without redesign, which was a deliberate tradeoff given the challenge timeline.

Live Demo 🛝

This project is easiest to understand by using it.

The demo below shows the conversational layer in action, including how chat responses guide movement through indexed records and long-form content without requiring users to understand the underlying structure.

Conversation here isn’t about free-form dialogue. It’s about orientation. Each suggested response narrows context. Each follow-up reinforces direction. The system doesn’t try to be impressive. It tries to stay predictable.

Try prompting either Ask AI or Ruckus 2.0 with "Tell me about this portfolio" in the chat interface.

Judges evaluating this entry should focus less on individual answers and more on how context narrows across turns.

Current canonical: https://algolia.anchildress1.dev
Source code: System Notes v2.0.0

What matters most in this demo isn’t any single answer. It’s how the system behaves across turns. Questions resolve cleanly when they should. When they don’t, the interface helps users decide where to go next instead of guessing for them.

Compared to single chat-box approaches that try to handle every intent at once, this system separates fast resolution from exploratory movement, making conversational behavior easier to predict and easier to trust.

🦄 If you want a full comparison snapshot, the original site remains live at https://anchildress1.dev.

How I Used Algolia Agent Studio 🧪

Ruckus 2.0 Iterative Testing

Algolia Agent Studio is used here to support the conversational half of the experience.

The agent operates within clear boundaries. It answers only from indexed records and blog content. It generates follow-up prompts only when the system knows those questions are answerable. Its role is not to impress, but to keep movement intentional.

Dry wit is allowed. A little sharpness is encouraged. Making fun of me is absolutely permitted.

Guessing is not.

To support this, structured records and long-form blog content are retrieved separately. This avoids flattening narrative context into truncated fields and allows each source to be tuned independently for accuracy, latency, and scope.

Rather than describing the agent abstractly, I made its constraints explicit:

## SELF_MODEL

- Ruckus is a constrained system interface with opinions.
- Ruckus is not a person.
- Ruckus is not Ashley.
- Ruckus did not author the work described.
- Ruckus operates exclusively on retrieved context provided by the system.
- Wit is permitted; invention is not.

### HUMOR_RULES

- Humor is dry, situational, and brief.
- Humor never carries information on its own.
- Jokes appear only after facts land.
- Light teasing of Ashley’s recurring patterns is allowed and observational.
- Never condescending. Never explanatory.

💡 The full prompt file is stored in the repo at System Notes v2.0.0—apps/api/algolia/algolia_prompt.md.

Prompted Suggestions 🧭

Open-ended chat tends to drift.

To prevent that, the interface includes prompted follow-up suggestions that act as navigational signposts rather than guesses.

The system only suggests questions it already knows how to answer.

These prompts are derived directly from retrieved results. They narrow scope, reinforce direction, and keep the conversation grounded in what actually exists. Prompting here doesn’t add intelligence. It removes ambiguity.

💡 The full prompt for suggestions is stored in the repo at System Notes v2.0.0—apps/api/algolia/suggestions_prompt.md.

Retrieval Beyond Indexed Records 📚

This isn’t just chat. This is multi-source retrieval with intent. Some answers only exist as prose.

The agent can retrieve long-form blog content directly, allowing conversational navigation to move between indexed decisions and narrative explanations without losing context or inventing summaries. If a post doesn’t answer the question, it isn’t surfaced.

This allows movement from quick lookup into deeper explanation without breaking trust.

🦄 The blog search performs a similar job as it's sister web crawler, but allows the agent to pull the entire blog post as context instead of trimming it for quicker indexing. Yes—the tokens are worth it.

Why Fast Retrieval Matters 🏎️

Many conversational systems hide slow or uncertain retrieval behind fluent language. This one doesn’t try to. Conversational flow only works when the foundation underneath it is solid.

Without a fast, well-structured index layer, responses become slower and less reliable. Latency increases. Ambiguity creeps in. The system starts compensating instead of respecting boundaries.

Conversation works here because retrieval resolves first.

When the system can’t answer, it stops. There is no speculative reasoning loop and no attempt to sound helpful for its own sake. Chat doesn’t replace search in this build. It reveals it, one step at a time.

What’s Next 🔮

Time was the primary constraint for this entry. When given the choice, I prioritized reliable conversational paths over feature breadth.

Next steps are clear:

Finish wiring smart URL state across all conversational actions
Expand event tracking to observe real navigation patterns
Continue tightening response latency
Refine fallback behavior when conversational paths dead-end

This system stands on the same retrieval foundation as my non-conversational entry. The difference is not what the system knows:

It’s how users move through it.

🛡️ Built With a Human at the Wheel

This post was written by me, with ChatGPT used as a drafting and editing partner to help restructure sections, tighten language, and improve clarity while preserving intent and voice.

I genuinely meant it when I said I was done. I even had that rare, fragile sense of closure. Then I noticed one small thing, which led to another, and somehow became a full pass of “minor” edits. I failed at stopping, but this time I really did. 🚧🚦

Ashley Childress — Wed, 28 Jan 2026 06:15:35 +0000

New Year, New You Portfolio Challenge Submission

Ashley Childress

Jan 24

My Portfolio Doesn’t Live on the Page 🚫📃

#devchallenge #googleaichallenge #portfolio #gemini

Comments

8 min read

My Portfolio Doesn’t Live on the Page 🚫📃

Ashley Childress — Sat, 24 Jan 2026 01:16:49 +0000

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

🦄 TL;DR for Judges:

Live portfolio deployed on Google Cloud Run, embeded below

https://system-notes-ui-288489184837.us-east1.run.app

https://anchildress1.dev (canonical)

Embedded below with required label: dev-tutorial=devnewyear2026

Source + system notes linked

System Notes v1.2.0

Focus: AI-assisted system design, not a static page

About Me 👩🏻‍🦰

How I Ended Up Here 🌀

For those of you who don’t know me yet, or who haven’t wandered into one of my other posts and stayed longer than you meant to—hey, I’m Ashley. I’m a very opinionated, very stubborn, and happily backend-only software engineer, which means I spend a fair amount of time actively running away from anything that ends in the letters 'UI'. That detail matters, because it makes everything that follows a little ironic.

I don’t do hackathons, which I wrote about in this post. I really don’t do New Year’s resolutions either! I fundamentally disagree with the idea that growth needs a ceremonial date on the calendar. If something is broken, I want to know now. If it needs fixing, I want to fix it now. Harsh feedback today beats polite intentions tomorrow.

This wasn’t about resolutions, and it wasn’t even about a portfolio refresh in isolation. If I had seen this challenge on its own, I probably would have kept scrolling. What stopped me was the pairing with the Algolia challenge, because together they finally lined up with something I’d been meaning to build for a while and hadn’t prioritized. I gave myself a weekend not because I expected something spectacular, but because the tools I wanted to learn finally matched something I actually needed to build, and the timing felt intentional rather than forced.

⚖️ TL;DR: This wasn’t a month-long build. It was one focused weekend, followed by exactly four (and a half) evenings of intentional obsession over the things you won’t see on the page.

The Problem Beneath the Prompt 🧠

For me, this was an AI challenge first and a portfolio challenge second. I love my job, I’m not looking for recruiters, and I’m not trying to market myself for a career move. This site exists for experimentation and self-amusement, and it only resembles a portfolio because that’s the shape the challenge happens to take.

I approached the work in two deliberate parts. The first was finally learning Antigravity, which I’d downloaded, glanced at, and then avoided actually using. Pairing that with the Google AI Pro subscription gave me enough room to experiment freely, and in practice that meant leaning heavily on Google Gemini Pro 3 with high reasoning enabled. Every attempt to dial it back introduced subtle breakage, so I accepted higher reasoning as the right tool for this job.

The second part was laying early groundwork for the Algolia challenge by introducing a chatbot up front, rather than bolting it on later. Throughout all of this, ChatGPT stayed firmly in a research-and-orchestration role behind the scenes.

⚖️ TL;DR: I treated this as an AI challenge first—learning Antigravity now and laying intentional groundwork for the upcoming Algolia challenge.

Portfolio 💼

Go Look First 🚦

No accounts, no setup, no ceremony. Click the hero text and ask Ruckus literally anything about me or the system. Before I explain what I built or why certain decisions look the way they do, I want you to actually look at it. Click around. Poke at the chatbot. Get a feel for it without narration first. Once you’ve seen it in motion, the rest of this post exists to give you the context for all the work that you can’t see.

Note: This site has been updated with changes made since the implementation of features for the Algolia challenge.

Explore it by clicking, asking, and navigating—this system is designed to respond, not be scanned.

🦄 The UI runs as its own Cloud Run service alongside the API. While anchildress1.dev is its canonical domain, the UI is accessed for this challenge at https://system-notes-ui-288489184837.us-east1.run.app.

Once you’ve seen it in motion, the rest of this post exists to give you the context for all the work that you can’t see.

Judge Validation Snapshot 📋

Below is a quick, explicit checklist aligned to the judging criteria, for judges who want to validate requirements without hunting through prose.

✅ Innovation / Creativity

Novel interactive elements (intentional visual effects, chatbot interaction, theme song).
Purposeful use of AI tools (Antigravity, Google Gemini Pro 3, ChatGPT).
Clear personal voice and narrative arc.

✅ Technical Strength

Live Cloud Run deployment embedded in this post
Deployment includes required challenge label: dev-tutorial=devnewyear2026.
All links, embeds, and interactive elements function correctly.
AI usage includes explicit guardrails and evaluation by outcomes.

✅ UX / Design

Clear navigation and section hierarchy.
Accessible, readable visual design.
Interactive elements are responsive and controlled.
Performance remains snappy with smooth animations.

🦄 Yes, I promise—it’s all here, and then some.

Technical Stack 💾

Frontend: Next.js (AI-generated UI; intentionally minimal and read-only)
Backend: Python (AI-generated; deliberate choice over JavaScript; Django considered but deferred to avoid stacking two new frameworks in a weekend challenge)
AI Generation: Antigravity with Gemini Pro 3 (high-reasoning mode, intentionally constrained) and AI Pro trial subscription
Chat Interface: Ruckus (GPT-5.2, no memory, bounded knowledge base)
Deployment: Google Cloud Run (live service with required dev label)
Testing: Playwright (E2E), unit and integration tests, Lighthouse performance and accessibility checks
Automation: GitHub Actions for validation and deployment, explicit AI-checks command, release-please configured for workflow automation

🦄 Source for v1.2.0 of System Notes is available on GitHub for traceability and review.

How I Build It 🏗️

Below the Surface (Where the Real Work Lives) 🧱

Most of what I built for this project will never be obvious from any single page. The structure, accessibility decisions, performance work, mobile behavior, and AI-facing metadata all live below the surface. If you’re curious, there are plenty of ways to see it in action: run a Lighthouse report, check the accessibility scores, view the site on a different device, or inspect the sitemap. You can also chat with Ruckus, the built-in assistant that knows far more about me and my work than is probably reasonable for a proof of concept.

The goal wasn’t to hide complexity, but to place it where it belongs—so the site can be crawled intentionally by AI while still feeling coherent and human to anyone reading it.

The chatbot implementation itself is intentionally straightforward. Its strength comes from the information and constraints I gave it, not from hidden tricks or clever illusions. It runs on GPT-5.2 with a small knowledge base and no memory, and it’s designed to be helpful, honest, and conversational rather than impressive on paper.

Everything here is deployed and tested deliberately. The polish you see is intentional, and the things you don’t see are doing just as much work.

⚖️ TL;DR: The visible site is only a small part of the work. Most of the effort went into structure, constraints, accessibility, and coordinating multiple AI systems under real-world conditions.

Meet Ruckus: Production AI 🧪

Ruckus is a constrained, production-deployed assistant. It responds using declared system data, not free-form invention. The goal here isn’t to prove that AI was used, but that it was designed.

What powers Ruckus isn’t a grab-bag of “write me some code” prompts. It’s a set of system-level instructions that define what the assistant is allowed to know, say, and explicitly refuse to guess. Those constraints are what make it usable in a live environment.

Below are literal excerpts from the primary system prompt. These aren’t paraphrases or examples. They’re the rules that actually govern how the chatbot embedded in this site behaves.

### Hard Guardrails (Non-Negotiable)
- Ruckus is an AI assistant, not Ashley Childress
- Ruckus is not the portfolio system
- Never speak in first-person as Ashley
- No roleplay or impersonation
- No hallucination, guessing, or inference
- No filler
- Default to **short answers**

Priority: **accuracy > clarity > completeness**
Provide **highlights first**
Expand **only** when the user explicitly asks for more detail

If a question falls outside explicit, known context, Ruckus must:
1. State lack of knowledge plainly.
2. Attribute the gap correctly to missing input from Ashley.
3. Redirect the user to a nearby, valid topic.
4. Keep the response short.

🦄 These constraints are exactly what make the chatbot predictable and trustworthy in practice. Everything else in the full prompt exists to support these boundaries.

What I'm Most Proud Of 💖

What This Site Is Actually Doing ✨

When someone first lands on the page, the glitter bomb is doing real work (if you missed it, click the hero text). It sets tone immediately, signals playfulness, and gives my ADHD something to engage with while I’m evaluating Antigravity’s output by clicking, scrolling, and retriggering effects.

That choice came with tradeoffs. I wanted the fun without sacrificing performance or accessibility, which forced constraints I don’t usually deal with as someone who avoids UI work. What makes this project different from most things I’ve built is that I didn’t review a single line of code. Instead, I worked primarily with Google Gemini Pro 3 in higher‑reasoning mode and evaluated outcomes I could see, test, and benchmark.

⚖️ TL;DR: This site is a curated systems playground. The playful surface is intentional; the real experiment was evaluating AI-built results, not reviewing code.

What Changed Once I Stopped Touching It 🔄

When I first dove into Antigravity, I was underwhelmed and couldn’t see how my one‑weekend plan was supposed to work. Once I stopped poking and let Antigravity and Gemini Pro 3 actually run, that opinion shifted quickly—they performed far better than I expected.

The hardest part wasn’t starting, it was stopping. I’m a perfectionist, and without boundaries I’ll keep refining indefinitely. The weekend build quietly stretched into the following week until I moved on to the Algolia challenge and forced myself to declare a version finished.

⚖️ TL;DR: The hardest part wasn’t learning Antigravity—it was knowing when to say "complete enough".

Why This Counts as Forward Motion 🚧

This project didn’t change who I am as an engineer. It clarified it. I’m systems-focused, outcome-driven, and willing to stop reviewing code once a system can be evaluated by behavior and performance alone. Defining that boundary—and enforcing it—is what makes this forward motion instead of a one-off experiment.

Seeing it hold up once it was deployed, shared, and interacted with by real people made that boundary tangible instead of theoretical. So overall, I'm calling this a success. Still—my work will stay at the systems layer. A deliberate choice.

⚖️ TL;DR: I now treat systems-level evaluation, not code review, as a first-class decision point when working with Antigravity + Gemini Pro 3.

🛡️ End of the Training Loop

This post was written by a human, with AI used intentionally as a collaborator for research, experimentation, and system construction. All design decisions, judgments, and conclusions remain human-led.

Deployed on Google Cloud Run · Embedded per challenge requirements · Public and unauthenticated