Never forget to enter the Stern Grove lottery again!

A developer built a Python script that runs weekly via GitHub Actions, scrapes the Stern Grove Music Festival website with Playwright, and auto-enters the lottery. The project was built using a coding agent and recorded with Entire, providing a complete auditable record of the development process.

It's summer in San Francisco, which means that every week I forget to enter the lottery for the free Stern Grove Music Festival https://www.sterngrove.org/ . Solution? I did what any reasonable developer would do instead of just setting a calendar reminder: I built a Python script that runs weekly via GitHub Actions, scrapes the festival website with Playwright, and auto-enters the lottery for me. The fun part is how I built it. I described what I wanted to a coding agent I've done a lot of browser automation to automate tennis court bookings, make data visualizations, etc , and Entire https://entire.io/ recorded every prompt, tool call, and output along the way, so I have a complete, auditable record of how the whole thing came together. If you want to retrace the entire build yourself, here's the live session https://entire.io/gh/elizabethsiegle/stern-grove-book-python/session/f9182a78-4e6c-4c6e-9ef6-4855f3b1d9ff . Let me walk you through it: The entire lol project began with a single message to my coding agent I used Claude Code, but any agent works I gave it the rules of the game: The Stern Grove lottery opens six weeks before each show at 10:00 AM and stays open for one full week to enter… I also handed it the exact HTML for the entry button. Stern Grove runs its ticketing through Tixologi , so the agent needed to know what it was dealing with. Then I told it about the secrets my GitHub Action would have access to: Before writing a line of implementation, the agent explored the spec, asked one clarifying question, and proposed a clean design: lottery.py browser.py state.py entered lotteries.json so we never double-enter notify.py { "entered": { "event id": "abc123", "show": "Show Name", "entered at": "2025-06-21T10:02:00Z" } } The cron schedule lives in the workflow file: .github/workflows/lottery.yml on: schedule: - cron: "0 17 1" weekly check workflow dispatch: Here's a step worth highlighting. Before touching any browser logic, the agent did a live inspection of the actual Stern Grove page — specifically window.tixologiWidget.concerts — to learn the real data shape rather than guessing. Tixologi is a ticket and event management platform. That inspection documented the precise field names, the ISO 8601 date format, and the event ID structure. One console log it captured saved a lot of debugging later: // What the page actually exposes window.tixologyWidget.concerts // → { eventId, name, startDate: "2025-07-13T19:00:00Z", ... } Grounding the implementation in real, observed data instead of assumptions is a major differentiator between code that works on the first real run and code that fails silently in production. state.py doesn't just read the JSON — after a successful entry it commits and pushes the update using a GitHub Personal Access Token PAT , so the next run knows what's already been done: php def commit state token: str - None: subprocess.run "git", "add", "entered lotteries.json" , check=True subprocess.run "git", "commit", "-m", "Update entered lotteries" , check=True subprocess.run "git", "push" , check=True When the agent added notify.py , a reviewer sub-agent immediately flagged two issues in the diff: print statements instead of the logging module. python import logging logger = logging.getLogger name resend.api key = os.environ "RESEND API KEY" initialized once def notify success show: str - None: logger.info "Entered lottery for %s", show resend.Emails.send { ... } This is the part I do genuinely find handy: I didn't have to remember how the automation got built, because Entire https://docs.entire.io/web/inspect-session captured all of it. A session in Entire is the complete record of an AI coding interaction, ie every prompt, response, tool call, and file change. You can browse mine at the session link above https://entire.io/gh/elizabethsiegle/stern-grove-book-python/session/f9182a78-4e6c-4c6e-9ef6-4855f3b1d9ff . Here's how to navigate it: Task tool, Entire captured it as its own session with its own transcript and tool calls, rolled up into the parent checkpoint's totals. That's exactly where you can see the review loop that flagged the print /logging issue. Entire-Checkpoint trailer, so you can open the matching checkpoint or the underlying commit on GitHub. The metadata itself lives on a distinct separate entire/checkpoints/v1 branch, which keeps your main history clean. So the screencast you're watching isn't the only record-- the full reasoning behind every line is sitting in that session, ready to rewind through.I'll be honest: the first real run failed. CI rarely cooperates on the first try, and this was no exception. Two environment issues bit me: 1. Ubuntu version drift. I had to pin the runner to Ubuntu 22.04 for Playwright compatibility. ubuntu-latest had quietly become Ubuntu 24.04 in 2025, and the libasound2 package was renamed in the process. 2. Chromium dependencies. I ended up installing the Chromium deps manually with the correct Ubuntu 24.04 package names instead of relying on Playwright's bundled installer. The fix went from this: before - run: playwright install --with-deps chromium to explicit apt installs plus a leaner Playwright step: after - run: | sudo apt-get update sudo apt-get install -y libasound2t64 libnss3 libnspr4 ...correct 24.04 names - run: playwright install chromium Finally, it ran cleanly. I got the confirmation email straight from Stern Grove and Resend. The stack came together nicely: