TL;DR

Brian wants you to go out and hear live events more often. He’s built a free tool for you to use.

The Bay Area has an amazing live music and event scene. Don’t sit at home, don’t go to the same-old, GET OUT THERE.

This is a semi-curated list of 150 active venues in the bay area, and all their events.

Now more than ever. Don’t let it all get you down.

Contact him if you use it, love it, hate it, or anything in between.

About EventFinder

I have been a musician in the San Francisco Bay Area since 1990s - on and off. The Bay Area has always had an amazingly rich music and arts scene, built around small venues, organizations renting halls, and occasional happenings. More so than most other American cities (I mean hats off to NOLA, CHI, and NYC, but we’re doing OK).

I love live events. “Now more than ever”, and I think we’ll want more in the Time Of AI.

Historically, finding these events has always been difficult unless you put in the time, attended shows, built a network, or gigged actively yourself. Back in the day, print newspapers like the SF Bay Guardian served as the definitive events registry. Then the Guardian went away. Then newspapers went away.

Various web aggregators tried to step in. I even attempted to build a platform for this myself around 2005. I am not the first person to have this dream. The aggregators are OK, but they’re profit based, and they’re built pre-AI. They have nowhere near the depth of small venues. It's simply not economical to get all the information for all the small venues.

At first, I thought I could just “ask the AI”. That’s pretty good, but doesn’t cover the breadth of the number of venues in the bay area. It’s better for visitors who want 2 or 3 great shows in a weekend. And I expect the agents will have the monitization trap, sooner rather than later.

150 venues is a lot. A lot-a lot. Simply asking the AI to find events one-shot when presented with the list simply doesn't work.

Time to get the code on

Here we are in the time of Agentic Coding. As someone who has seen a few revolutions - we’re in for a big one.

Combining the systems and architecture experience of this human, and the lack of fatigue of the Code Agents (mostly Anthropic Claude and Google Gemini), I’ve been able to build a “web fetching” system of the complexity that’s needed for this scale of problem.

EventFinder automates the discovery, structuring, and cataloging of cultural events from heterogeneous online sources.

It uses three core techniques: LLM based generation of CSS selectors, using LLMs to pull data out of images and DOM trees, and simply asking an LLM about current events.

Because all of these techniques work better and worse on different sources, a “contest system” (Evaluator pattern) is run. The “optimizer” finds a good method for pulling data - and the cheapest - using an AI Python abstraction Djinnite. After running the contest, updates (once a week or so) can be run efficiently.

This "evaluator pattern" pits AI against AI - all for your benefit.

I coded the abstraction for use in another project over about a week. I came back to this project and accomplished most of this in a long intense week.

So use it

EventFinder is free to use. I’ve been fortunate to work with amazing people on amazing products, I have no interest in monetizing this.

I believe the tools I used to acquire the core information are legal, or at least moral. People running events want them to be found. They might publish on a for-profit site, but that’s only to get the word out. They want the word out.

Comments

Send me an email at brian@bulkowski.org. You can also reach me on Signal, Telegram, Facebook Messenger, WhatsApp, and SMS. Give me a shout out if you love it, hate it, have a feature idea, or if I left out a venue or a source.

Tech Details

Front End and UI

You will immediately notice that the UI is “utilitarian”, which is polite. I’m not a UI person. This is 100% Claude’s idea, not to blame Claude. I rather like the vibe.

It’s also kinda broken. Some issues will be fixed with data quality, some with simple time and engineering (like user logins, with ranking, so you can get more custom recommendations).

The tech stack is strictly Python 3.10+, FastAPI, Jinja2 for server-side templates, and HTMX for interactivity. It is designed to expose the underlying data hierarchy and facilitate fast search, not to win design awards. Utility is beauty.

The core dataset is a JSON flat file. I think people overuse databases, which is a rich statement, given my background.

Go ahead and send me your ideas of how to make it better.

The Technology

Getting the data has always been the hard part. Generously, that’s called “Scraping”, but it’s getting the contextual information. The software industry has taken a few runs at this - “Contextual Web” - but always failed for a variety of reasons.

The backend data aquisition is, thus, the hard part, and we need to lean hard on AI services (entire web_search based agentic systems, not “just” LLMs).

Instead of relying on a fragile, monolithic scraping script, EventFinder uses a Two-Phase fetching model optimized for the diversity of the internet, and the lowest use of LLMs in runtime.

The Three Strategies

1. DIRECT: Zero-cost deterministic extraction. Playwright executes pre-computed CSS selectors against the DOM.

2. EXTRACT: Multimodal extraction. A Vision-Language Model parses a full-page screenshot and/or raw DOM text to find events when the DOM is hostile.

3. LLM: Grounded search. An LLM directly queries the web for the venue's upcoming events, bypassing the site's structure entirely.

Interestingly, current data is showing about even winners across all strategies.

The Two Phases

• Optimization: From time to time, or as data quality drops, an automated contest runs. The optimizer tests all three strategies across multiple AI providers. For DIRECT, an LLM analyzes the HTML to generate the CSS selectors. The system scores the output on data quality and token cost, then locks the winning strategy and configuration into a local registry. For EXTRACT, LLMs are asked to return events from DOM + web images. For LLM, grounded searchers are done across multiple providers. Cost and quality are factored to find the winning strategy and configuation.

• Runtime: The daily fetch. The orchestrator reads the registry and executes the winning strategy. If DIRECT won, it runs the saved CSS selectors (fast and free). If EXTRACT or LLM won, it executes the specific model and prompt that passed the contest. No thinking, just execution.

Critically, the LLM based runtime solutions are graded not just for data quality, but also cost. Costing is tricky in the new world, since services charge by tokens (and expose that), but some charge for web search, and some are use-it-or-lose-it subscription.

The data layer bypasses traditional databases entirely, favoring a filesystem-first architecture. Yes, the guy who founded and wrote a high-performance database decided to just use JSON files. My database friends will be amused. Events are normalized to a strict schema and stored in date-partitioned JSON files (YYYY-MM-DD.json), deduplicated across sources using a match key of venue, date, and hour.

The “Evalutator Pattern” and Djinnite

As of today March 16, the system uses hueristics to determine data quality. Heuristics like regexp.

The correct answer is to use LLMs to determine that. And, instead of relying on a “score”, gather all the results and score them against each other.

The “evalutator pattern” was made easy by Djinnite.

Djinnite is an abstraction layer. It has a “model catalog”, which is easily updated through a script that introspects and probes the configured API services. This is where knowledge that, for example, some models don’t support web_search and JSON return, and some do, some multimodal vision APIs have image limits, some don’t.

I found the existing frameworks didn’t have all the complexity I wanted, and were heavyweight.

My insight is that the Model Catalog is the hard part - that’s how the evaluator stays up to date and chooses the right models for the contest.

Where’s the code?

I’m feeling shy about the code. “Scraping” has a bad history. I’ll probably publish at some point. Sorry. Check my repo for all the other things I’ve published.

Todos

Support “runs” (theatrical) and “multiple sets” (7pm and 9pm times for the same event).

LLM based quality scoring. Looking to put a small categorizer on a local machine to reduce cost.

UI improvements to overcome the Large Amount Of Data.

Better categories and location.

A login based system so you can list your own favorites and get better recommendation.

Maybe an SMS based front end.

About the Human

I am Brian Bulkowski. My first code was on an Apple ][, but graduated to PDP-11 and Cyber Data (Plato). The first computer I owned was a Xerox 820. I got sucked into engineering for a living, it wasn’t really a plan. I found a love of “back end” systems - networks and routers, embedded system platforms, large scale distributed systems. Eventually I founded, funded, and was the CTO of Aerospike, an SSD-optimized NoSQL database, and have built systems architectures within Yellowbrick and Meta. In the early days, Kinetics (the FastPath!), Starlight Networks, and Navio/Network Computer/Navio. Good times.

Outside of the IDE, I operate in different physical constraints: I currently play cello in the Prometheus Symphony and live-loop under the name Racoon Roadshow. 1996 through 2014 I gigged with Rosin Coven, much love to all my bandmates. Large scale LED software, fire art installations, large scale speaker arrays.

I’m now helping The Box Shop (QBOX) with its transition to being a full non profit in the bayview, having been priced out of hunter’s point.

If you like this project, donate to The Box Shop. It’s a living breathing example of the can-do spirit of the bay area.

Links

The Human & The Art

• LinkedIn Profile

• Brian's GitHub

• Aerospike

• Rosin Coven

• Flaming Lotus Girls

• The Box Shop

• Charles Gadeken

The Technology

• Djinnite Source Code

• FastAPI

• HTMX

• Playwright