Forem: Ashley Childress

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

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. 😇

🛡️ 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

Signing Your Name on AI-Assisted Commits with RAI Footers 🛡️✍️

Ashley Childress — Wed, 21 Jan 2026 11:46:00 +0000

🦄 I know it's been a minute (months!), but I said I wouldn't forget about the follow-up for this one and I have not! It's been nagging at me to finish, but I wanted to have something to show for it first. I got that done quick enough; however, Release Please was not nearly as straightforward to learn as I anticipated considering I set up dual packages in a mono-repo as my "simple" setup. Yes—I curse myself, but holidays were also involved in the shenanigans!

I'm going to try not to bore you with the nitty-gritty—we're all smart devs around here—but I have to finish my original thought or this outstanding post will nag at me forever. I'm not counting out a third though, because I do still have more ideas. Me and attribution deserve a break from each other after this though, so we’ll save that for future-me to consider. 🔮✨

Brief but Inspirational Backstory ✨

If you missed the original version, I’ll sum it up quickly: it’s always bugged me that AI joined the party and never had to make itself permanently known. Not responsibility—that’s on us as devs regardless—but as a co-author. So I came up with an idea to fix that and over the break I quickly threw together a working version of enforcement for both CommitLint and GitLint in Python.

I call this a RAI footer, short for Responsible AI attribution. Not policy. Not governance. Just a mechanical signal in your commit history that makes AI assistance explicit and pairs it with a human signoff. The goal isn’t to moralize commits. It’s to remove ambiguity about authorship once AI enters the workflow.

🦄 The README already explains what this is and how to use it properly, if you’re curious

Doesn’t Live Alone 🔗

I have to point out that this RAI footer is just a baby step and it does absolutely nothing to fix potential problems that may crop up from code that's committed without proper human-in-the-loop (HITL) oversight.

To make this system work as designed, I leaned on Git’s built-in functionality. The --signoff flag is an extension of legal requirements often used in open source for a Developer Certificate of Origin (DCO). This adds a literal footer to the commit stating that you, as a verified author, are also adding a layer of legal accountability. You didn’t just push code. You agreed to the project’s rules.

Which is a whole lot of legal framing for a system that has zero interest in what lawyers are doing.

My version instead says: I’m signing my name. This is correct. That’s it.

In practice, your commit looks something like this:

git commit -s -m "chore: Add trouble in spades

Assisted-by: GitHub Copilot <copilot@github.com>"

And the result you end up with when you look back at git log:

Author: Ashley Childress <6563688+anchildress1@users.noreply.github.com>
Date:   Sat Jan 17 00:32:38 2026 -0500

chore: Add trouble in spades

Assisted-by: GitHub Copilot <copilot@github.com>
Signed-off-by: Ashley Childress <6563688+anchildress1@users.noreply.github.com>

In this context, it’s really less a legal signature and more Scout’s Honor. The one -s flag is your HITL review stating you’ve personally signed off on this commit in its entirety, which includes the AI attribution footer.

When both footers are paired together in the context of a single commit, it says beyond any doubt that you—aka the verified author—were aware of the changes and approved the code AI did or did not contribute.

🦄 This gets you through the configuration, but on its own it’s not very impressive. Also, there’s really not anything new or earth-shattering I’ve done here—I simply repurposed the existing system.

One Last Tiny Helper 🧩

Generally speaking, anything that pops up on my “continuous work” radar and can be automated is eventually automated. This is no different.

I’ve commented somewhere before that I used to be the world’s absolute worst committer. Truth? I still am. Copilot, however, generally does a much better job.

I have a generate-commit-message prompt designed with this entire flow in mind, that’s designed to look at staged files by default (with fallback), create a conventional commit message, and assign its own attribution based on the chat history. It’s far from perfect, but does a decent job at getting you in the ballpark!

🦄 Help a girl out and leave a star if you find anything useful!

The Boring Future 🚧

This is really all there is to the enforcement part—at least to carry us over until the AI estimators do a better job at guessing when AI helps or not!

The future and arguably more important piece of this is reporting those stats back for your repo. It’s not good enough to state that AI helped anymore. We need to start proving that it’s not all terrible code!

From here, I envision a centralized reusable workflow that pulls a diff of all commits and roughly guesstimates the percentage of code that AI contributed. Update a static Shields.io badge (for now) on the README.

You could get really fancy with this if you wanted to, but honestly there’s other tooling that will catch up before that becomes necessary! This is just meant to hold us over until that tech emerges. Fingers crossed that point is sooner rather than later. 🤞

🛡️ The Part Where I Sign My Name

This post was written by me. ChatGPT assisted with editing and clarity. It didn’t choose the ideas, make the decisions, or approve the work. If something here is wrong, confusing, or incomplete, that responsibility belongs to the human who signed it. AI can assist. Authorship still requires someone willing to put their name on the result.

Waiting, With Intent: Designing AI Systems for the Long Game 🧭

Ashley Childress — Wed, 14 Jan 2026 12:22:00 +0000

🦄 I’m waiting for AI to mature. Very explicitly—and yes, mostly impatiently. I don’t even think we're close to imagining the future landscape with AI, and honestly pretending otherwise is neither honest or useful to anyone. This post is my attempt to explain how I think about AI from a dev perspective on a longer horizon—five, maybe even ten years down the road. The tools we have right now are still a very long way away from my baseline expectations, which my AI systems remind me of near constantly—like when I'm trying to force agent-like functionality out of ChatGPT. Spoiler: it’s not designed to handle that.

While I’m waiting, though, I’m not disengaged. I’m definitely tinkering—sometimes randomly and sometimes just as an unsatisfied AI user who’s not thrilled with the existing systems. I’m also busy figuring out what the next problems really look like by diving in and getting my hands dirty.

One of those big challenges is what I keep calling the “memory problem.” I've designed a solution for my own personal agent to manage long-term memory. Yes—I'm aware that GitHub is inevitably going to beat me to a viable solution. Again. But I'm one of those people who will attempt to solve a problem first, get it wrong at least ten different times, and then do the research to fill in the knowledge gaps. Now I just have to muster up enough oomph to actually do it. 🐉🧚‍♀️

First Principles: LLM vs Agent 🧩

At some point, if you want any of this AI talk to make sense, you have to step back, align terminology, and separate concepts that keep getting blurred together. An LLM, often called a model, is the generative part of GenAI—it accepts input and generates output. That's it. An agent is the system managing context, memory, and various tools. The agent is responsible for what information the LLM even sees in the first place.

When those two ideas get collapsed into the same thing, everything downstream becomes confused. You can’t reason clearly about limits, costs, or failure modes if you don’t separate generation from data management. Until you draw that line, every other discussion ends up muddy.

Context Is the Bottleneck (and Everyone Knows It) 🕸️

Once you make the distinction between LLM and agent, the real bottleneck becomes obvious. There is no good way to manage context today, let alone have the agent automate that job effectively. If you’re not fully up to date on the lingo: context includes a whole set of things like instruction files, workspace structure, active files in your IDE, the AI chat history, available tools, and more.

What we have now are very manual tools that do very little to solve the problem. We have to remember to tell the AI which parts currently matter—or at some point we have to clear the chat entirely and start over. If we don’t do that deliberately, AI slowly loses the point of what’s we're supposed to be working on in the first place. At worst, the entire chat thread is poisoned and the AI becomes unable to function at all. Then you're forced to start fresh and always at the most inconvenient time.

And don’t expect LLM context to scale, either. Hardware costs may go down eventually, but nowhere near fast enough to keep up with everything we keep throwing at it. So, context is very finite—especially in GitHub where context windows are smaller than normal anyway.

The agent will typically make space by compacting information. It will ask the LLM to summarize key points and then it literally drops the original full length novel completely from your active context and replaces it with the cliff notes version. The more summarization, the less accurate things get over time. So naturally you retry prompts while adding back the dropped details and you end up making more calls for a single task overall. The model has to process more and more input just to get you back to the same answer you already had—not necessarily a better one.

People know this is a problem. Tools like Toon exist specifically to minimize input impact for AI. We also have tools like Copilot's #runSubagent to help manage context within a single agent. These aren't true solutions though—they are signals. These are the problems people are trying to solve yesterday while we wait for the next AI evolution to emerge.

Why Orchestration Is Inevitable 🐙

Even if you do everything “right” and manage context like a master AI sensei, agents eventually hit a limit. The list of must-have MCPs is growing and right now those stay in the context window as long as they're enabled. Projects are starting and accumulating larger knowledge bases. Customization is becoming more and more explicit. The context an agent needs to use will continue to grow exponentially, even though LLMs aren't increasing capacity at the same speed.

The ultimate overflow state isn’t hypothetical—it’s inevitable. Once an agent accumulates enough memory, enough history, enough summarization, the LLM simply can’t keep up coherently anymore. That isn’t a failure in the system—it’s a limit.

When you hit that limit, you can't just tweak prompts or optimize harder. You wouldn't try to squeeze more juice out of the same dry orange, either. The only real long-term solution is that you split the system—you have to!

Smaller pieces of work are then sent to the LLM with only relevant context, which is when smarter agents will start to appear. This is where summarization stops and you retain the original intent at both a high-level and at the lowest-level. When we get here, AI generation stops being the problem—the new problem is coordinating all those tiny pieces of work and still accomplishing the larger goal without re-prompting anything previously stated or defined elsewhere already. Welcome to the world of true agent orchestration!

💡 ProTip: If you want a sneak peek of what this looks like, check out Verdent.ai. Of all the solutions I've worked with, Verdent is the only one that's truly designed for agent orchestration. It also excels in VS Code and wins every coding competition I've put it in.

Orchestration as a System Property ♟️

Orchestration isn’t just about sequencing work in a nicer way—it’s about changing where responsibility lives. Yes—some things are always going to be sequential, but not everything needs to be. Some things can and should run in parallel, especially if you want speed and reliability included in future agentic systems.

Validation is a fundamental part of orchestration, not something bolted on afterward. A successful agent has to be able to verify its own work without relying on prior context. It has to come in like a third party, with no knowledge beyond the repo instructions. CodeQL, lint enforcement, Makefiles, and even extra tests become the ground truth the system must consistently check itself against.

Multi-model opposition fits naturally here, too. Different models trained by different companies catch different things. Then the agent can pick one model to implement and another to review. The point is that they disagree by default and then they converge around a common goal. This is a pivotal moment in the future landscape because officially the LLM is no longer the center of gravity—the agentic system is.

🎤 ShoutOut @marcosomma wrote a brilliant article on the concept of agent convergence a while back and it's still one of my favorites. Worth the read if you missed it!

Add Another Layer of Abstraction 🪜

Now for my version of truth, which I know a lot of you are going to hate so go ahead and brace for it. Once you’re working in a smart orchestration-driven flow, there's no reason you need to keep prompting from the IDE. Wait before you jump into the debate, though—I'm not saying the IDE becomes obsolete! It just stops being the primary interface for developer workflows because you’re consistently able to work at a higher level of abstraction. In this future, developers are directing systems that generate, test, and validate the code several layers underneath you automatically.

You’re orchestrating agents that direct other agents. Some run sequentially. Others will run in parallel. Documentation is generated automatically and added to the agent's working knowledge base. Tests run continuously alongside agents implementing new code. Integration testing matters. Systems testing matters more. Chaos testing morphs from an abstract concept into a baseline requirement. The code still exists—but it’s no longer written by or for humans. AI slowly takes that over, which makes natural language the newest language you need to learn.

🦄 For the record, developers are most definitely still building and driving solutions. That will never change—we're the mad scientists thinking up wild potions you didn't know you needed! Besides, all the future advancements in the world won't give silicon the ability to invent new things. Humans create. AI helps. Period.

Trust, Then Speed (not the other way around) 🏎️

When something breaks in any of my workflows, I don’t correct the mistake in the code immediately. I start by correcting whatever instruction caused the mistake, and then I rerun it. Even when I’m busy, even when work is chaotic, and especially when I should have left it alone hours ago—I never fully disengage from this. I can’t.

This is exactly why AI doesn’t make you faster—not yet, anyway. Not because it can’t, but because the systems haven’t caught up to where speed actually emerges. If you’re learning to use AI correctly, it almost always makes you slower at first—not faster. The delay isn’t failure. It’s infrastructure lag.

Think of it like an investment. You’re learning how the models behave and how instructions actually align with them. You’re learning where the limits are, and then deliberately making the system work within those constraints. Speed comes later—after you trust that the system returns results that are validated, reviewed, and tested because you built it to behave that way.

AI evolution is a long game, and we’re barely getting started. Right now, it still feels like grade school. We’re teaching it what our world looks like, how we think, and where the boundaries are.

All the work done now—in this awkward middle state—is what makes that learning possible. Long runs of trial-and-error prompts, walls of instructions, documentation that later turns into knowledge bases—that’s the curriculum. And by the time it’s ready to graduate, it won’t just be competent. It’ll be a master. That’s the moment you realize you trust AI—not because it’s autonomous, but because you finally are. 🐉🧚‍♀️

🛡️ I Worked Until It Worked

This post was written by me, with ChatGPT nearby like an overly talkative whiteboard—listening, interrupting, getting corrected, and occasionally making a genuinely good point. We argued about structure, laughed at the mic cutting out at the worst moments, and kept going anyway. The opinions are mine. The fact that it finally worked is the point.