Garrett Siegel

Graphic designer turned production engineer at ESPN. I share the decisions behind interactive stories, frontend systems, and practical AI workflows—what worked, what broke, and what I learned. If that's your corner of the internet, follow along.

NEW PROJECT: 30 seasons of the WNBA: How women's basketball has grown - As the league celebrates its 30th season, a visual look at its growth on the court, as a business and as a global influence. www.espn.com/espn/feature...

Someone using ChromaKit described their color workflow and a workaround in a GitHub issue. I added the requested parsing support. I’d like more of that context before choosing what to build next. How do you hear from the people quietly using your projects?

If you handed off an illustration and someone wanted to use AI to make part of it move, what would you want them to ask you first? I can see the creative possibility. I can also see why “I only animated it” might not feel like a small change to the person who made it.

The less polished reason I became a developer: I was tired of seeing hours of thinking end with “I don’t like it” or “make it pop.” I wanted my reasoning and problem-solving to be visible in the result. What’s the personal, frustrated, or complicated reason you chose your work?

Working as a developer changed how I design for the web. A page isn’t one perfect frame. It has to survive wrapping, loading, errors, keyboard focus, zoom, touch, reduced motion, and widths I never mocked up. What part of web design only clicked after you built it?

I built an animation that looks like live 3D, but the browser never sees the 3D scene. Blender supplies the rendered appearance. The browser supplies the movement, scale, timing, and interaction. The effect looks expensive. The delivery is mostly a convincing fakeout.

I keep changing how I work with AI. Some things stick without much thought. Some feel useful for a week. Some just become another system I have to maintain. I’m curious what everyone’s setup looks like after the experimenting settles down. What has actually stayed?

I’m starting to think “Does this need an agent?” is the wrong first question. Usually I get further by asking what the task actually needs: one instruction, a repeatable skill, a few decisions, or access to another system. Where do you draw the line between a useful agent and extra machinery?

AI tools keep arriving that look genuinely impressive—and strangely familiar. With so many people building in parallel, I wonder how often a good idea becomes “old” before it ships. Is that market pressure, or are the same feeds pushing us toward the same problems?

The most useful line in my MCP learning prompt is: “Do not build the whole server at once. Teach one step, explain why, show how to verify it, then pause.” I add TypeScript, the current spec, and a URL to data I am allowed to use. I want to understand the repo I end up with.

MCP only started sticking when I stopped trying to absorb the whole spec at once: beginner video, architecture video, current spec, tiny build, then explain it back in plain English. The build exposed every gap in my understanding faster than more reading did.

I am building one MCP tool for work and another for myself. At first, the whole thing felt strangely mysterious. Then it clicked: the server is a connector with a specific boundary. Making something callable is one part. Deciding what it should be allowed to reach is the real design work.

I keep seeing Figma vs. Photoshop framed as a winner/loser thing. I use Figma for web design and Photoshop for print or heavy image editing. Different decisions, different tools. The browser still gets the last word on responsive behavior.

A component can look finished when the example content is perfect. Then it has to load, show nothing, fail, or hold text that refuses to fit. I’m trying to treat those as the design system, not edge cases added after the polished version.

It's easy to keep polishing an idea because polish feels like progress. But a better font, smoother animation, or stronger image can't rescue something people don't understand. Before I make it look finished, I need to know: does the idea make sense yet?

I keep noticing a gap between documenting a design system and explaining its intent. An AI can follow the colors, spacing, and components exactly, then make the next decision feel completely wrong. What does your design system explain well beyond the tokens?

A polished interface can look finished before it actually works. A passing build can still hide a broken page. Smooth motion can still fail when someone scrolls, taps, or uses a smaller screen. For me, design engineering includes checking the result where someone will actually use it.

The more frontend work I learned, the more useful my graphic design background became. It changes the questions I ask, how I explore an interaction, and how I talk through an idea with other people. I like the work most when the creative and technical parts are solving the same problem.

A design tool has to protect the behavior it promises. Codebase Rescue passed my tests. Agents still broke its audit-only boundary in four ways. I fixed each problem and added tests for the promise, not only the first implementation. github.com/garrettsiege...

The part of graphic design I use most in software is deciding what someone should notice first. A screen can be polished and still feel unclear when every button, section, and message asks for equal attention. Hierarchy is a decision about what matters now and what can wait.

I use tools like Leva when a number in the code does not tell me enough. A duration slider lets me replay an animation at 0.2, 0.3, or 0.5 seconds and see what each value actually feels like. The panel is temporary. The decision still ends up in the code.

I built Codebase Rescue for messy or inherited codebases. It maps the project, checks whether the tests can be trusted, and writes a recovery plan before changing product code. Then it stops for review. github.com/garrettsiege...

I kept trying to make coding agents read the live web: Claude for Chrome, Playwright, and Chrome DevTools MCP. Firecrawl helped. Crawl4AI made the split clearer: search finds pages, it reads known URLs, and the browser handles clicking and visual checks. docs.crawl4ai.com

Well said

A design can look finished before it has met real copy, a smaller screen, changing data, or the next person who has to work with it. That is the part of frontend work I like most: finding out whether the visual idea still holds when the conditions get less perfect.

I've been thinking about what I want AI to take out of learning. Getting unstuck? Great. Repeating boilerplate? Fine. But if the code is something I'll be changing next week, I still stop and trace it. Otherwise I get a working answer and a weird little gap in my own understanding.

I kept getting stuck on which model to use before I had even started the task. So I made Auto Route. It starts with the smallest route that can probably finish, then spends more only when the work proves it needs it. Mostly, I just wanted to stop turning model choice into the first task.

I went looking for more tools like Leva and realized I was mixing together a bunch of different jobs. Tuning values, testing components, editing animation, changing CSS, and managing content all need different tools. I made myself a map.

I made this because I kept choosing the biggest GPT-5.6 model first and working backward. Now I start with Terra + medium, move down when the task is obvious, and move up when the work is messy or risky. What do you start with?

When I switch coding agents, I do not need everything they said. I need what changed, what was verified, and what remains open. A useful handoff feels more like a shift-change note than a transcript. What context disappears first in your workflow?

The best improvement I made to my coding-agent instructions had little to do with the agent. I made the next action explicit, recorded decisions, and showed how to verify the work. The result was better documentation for me, too. What project rule still lives only in someone’s memory?

I’m starting to think about design systems as context, not inventory. Tokens can describe type, color, spacing, and motion. The useful part is explaining why those choices belong together—and where variation is welcome. Which design decision does your system leave undocumented?

Useful AI tip for parents: I connected only Google Calendar to ChatGPT, not Gmail or my email. Then I had it add every school break, teacher workday, holiday, student day off, and the first/last day from our district calendar. Much easier than copying every date manually.

The AI conversation feels stuck between hate and hype. I’m less interested in either extreme. The better question is: What is actually useful? Does it save real time? Can I verify it? Does it improve the work? Do I understand the tradeoffs? That middle ground is where useful discussion happens.

Interesting www.reddit.com/r/ClaudeAI/s...

Found what is basically an app store for AI agent skills. AwesomeSkill.ai collects open-source skills for Claude Code, Codex, and ChatGPT across browser automation, testing, planning, UI review, and more. Worth checking before writing another skill from scratch: awesomeskill.ai

By Friday, I could never remember everything I changed that week. Now each project has a /docs/weekly folder. Hooks keep the current note updated with changes, decisions, verification, and open work. Then I ask my agent to summarize the week. Has anyone built a similar developer work log?

🔍 Diving into #React performance tooling and came across **React Scan**. Has anyone tried it? Curious about real-world wins, pitfalls, and setup tips. #WebDev #Performance #ReactScan github.com/aidenybai/re... youtu.be/3EnathFYgz8?...

Found this gem of a website on Instagram. You can watch local TV channels from all over the world. tv.garden

Anybody using OKLCH colors in their #CSS? evilmartians.com/chronicles/o... Interested to learn more on it

Really good video about #Figma variables: youtu.be/425aMhpDTSY?...