Garrett Siegel
@garrettsiegel
Creative Dev at ESPN 💻, RAD DAD 🔥, Designer and Artist 🎨
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.
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 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
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 a Codex skill called Auto Route. Use it like this: $auto-route Fix the mobile nav and verify it. It keeps tiny work local, delegates the rest to the lowest-cost model that fits, and only moves up after a real miss.
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?
My almost 6-year-old had an idea for an iPad app to help practice reading. I opened Codex and had him explain it out loud. One prompt later, we had a prototype. A few chats later: voices, sound controls, silent-letter hints, and mobile support. He's now a little project manager! 😄
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.
A Figma file is becoming an API for design intent. Auto Layout communicates behavior. Components communicate reuse. Variants communicate states. Variables communicate the system. Better structure helps the design survive the trip to production.
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?