The Fault, Dear Brutus

The fault, dear Brutus, is not in our stars, But in ourselves, that we are underlings.

I've had this quote rolling around the back of my head for months, and I keep coming back to it. Sometimes it's because I've just yelled at my Claude Code agent in all caps for ignoring a core rule about assertion and attribution, then caught myself. My expectations were the problem. Sometimes it's because I've just read another breathless LinkedIn post cheering for, or berating, the latest AI headline.

The conversation about AI has drifted so far into the abstract that the practical stuff barely registers.

On any given week in 2026, here's what that conversation looks like. Anthropic restricts its most capable model to 40 companies, then the US government suspends access to foreign nationals over a narrow jailbreak. The White House publishes an AI framework calling for federal preemption of state laws, signs an executive order doubling down on deregulation, then restricts the same technology ten days later.

On the other side, Sanders and Ocasio-Cortez introduce a data center moratorium. New York passes the first statewide version. The UN warns that AI water consumption could match the basic domestic needs of 1.3 billion people by end of decade.

These are serious issues. Export controls, energy policy, and the relationship between innovation and oversight are all worth serious attention.

Scroll through LinkedIn, though, or read the comment sections on any AI article, and you'll notice something: almost nobody is talking about what AI actually does for a person with a problem to solve.

The loudest voices are either chasing what's next (which model is bigger, who has restricted access, what the geopolitical implications are) or pushing back on the whole enterprise. AI is taking artists' jobs. Data centers are draining aquifers.

#The Other Conversation

The most interesting conversations I've had about AI this year haven't been in either of those groups. They've been with people who are either suspicious of the whole thing or just haven't been exposed to it beyond asking ChatGPT a question and getting something back that's helpful (or a hallucination).

These conversations start reasonably skeptical. But something shifts when the topic moves from "AI" as a subject to whatever problem the person actually deals with. A friend who's an artist and runs her own business asked me backstage after a show, over a glass of wine, how AI could help her optimize her business structure.

She wouldn't post that question publicly.

Her community has strong feelings about it. But in a dressing room after a performance, she's genuinely curious. An investor I've known for years asked me over dinner how to research an emergent market where his usual sources don't reach. Decades of finance experience, and he's privately asking me how to get started with tools he's only read headlines about.

When I walk through what's possible with tools that already exist, the response is almost always the same: "Wait, you can do that?"

Their curiosity shifted first, then their willingness to engage with AI to access data and analysis that would have taken weeks to assemble on their own, or required hiring someone to do it (not to outsource their thinking, but to extend their reach).

#The Mundane

Those conversations are why I'm writing this. Once someone starts talking about their actual work instead of AI in the abstract, the conversation changes completely.

I'm calling this "The Mundane" because the problems worth demonstrating are the ordinary ones, the kind that sit in spreadsheets and browser tabs because nobody has time to do the research properly. This might be the first in a series. The pattern applies to more than cars.


An AI amalgamation of several models. The astute may guess the car I bought.
An AI amalgamation of several models. The astute may guess the car I bought.

#Buying a Car

I've owned 48 cars and motorcycles to date. My wife has begrudgingly tolerated the wrenching hobby, but one in particular tested her patience: a 1988 BMW 635CSi I bought for $500. I dragged it across Washington as we moved homes, and with each move it got a little more dilapidated despite me continuing to pour money into it. I finally admitted defeat and sold it for parts. My wife, graciously, agreed I could buy another toy (in much better condition this time).

So I started looking. If you've shopped for a used car recently, you know how fragmented the information is. Auction results are on Bring a Trailer and Cars & Bids. Dealer inventory is on Cars.com. Private sellers are on Facebook Marketplace and OfferUp. And every one of these platforms actively tries to prevent you from collecting data programmatically.

Most people handle this with Kelley Blue Book and gut instinct, and that works fine. 48 cars in, I wanted to understand the actual market across all of these sources, normalized so I could compare.

So I started building. 16 Python scripts and a set of instructions for an LLM (which I've released as an open source toolkit on GitHub). And the first thing Claude Code tried to do was build me a standalone command-line tool with a proper Python package structure, argparse entry points, the whole thing. I stopped it. Claude Code is the interface, the scripts are helpers. I want to have a conversation about cars and have it figure out which scripts to call.

That correction set the tone for everything that followed.

The methodology didn't come from a design doc. It came from me correcting Claude Code's assumptions, and those corrections accumulating into something useful.

The local-first approach is a good example. Early on, I asked Claude Code to scrape Cars.com for inventory. It ran a national search. Thousands of results. What I actually needed was what's available near me, cars I could go see and drive. A dealer twenty minutes away had two cars that didn't even show up in the national results because they were buried. I caught it, and "local data first" became a rule the AI loads every session. Now it always scrapes local before national, presents local first in reports, and comps against local prices before anything else.

The anti-editorializing rule came from a similar correction. The AI looked at pricing data across a couple years of auction results and declared "the bubble has deflated." I called it out. The data showed a peak and a decline. Calling it a "bubble" and asserting stability going forward was editorial. Present the trend, let me draw the conclusion (which also became a rule).

The one that keeps coming back is assertions without verification. The AI said "none of these listings declare a VIN tag" when it had truncated the data to 500 characters and the VIN tag information was in the truncated portion. It called directories "active" based on their existence without checking contents. It asserted mileage comparisons using biased data.

This is what I meant in the opening about yelling at the AI in all caps and then catching myself. Sometimes the issue was my expectations, asking a model to exercise judgment it doesn't have. Other times I just hadn't given it enough constraints for what I needed.

Either way, the fault was in my instructions, not in the model.

The bypass knowledge for each platform came from the same iterative process. Cars.com sits behind Akamai. The AI tried Playwright, it failed. Tried raw HTTP, failed. Tried WebFetch, failed. Akamai fingerprints browser automation at the protocol level and kills the connection. What finally worked was curl with a specific set of security headers that make the request look like a real browser navigation. Facebook Marketplace was different: the AI tried extracting listing data from the page DOM and kept getting back unrelated cars. Turns out FB serves personalized content based on browsing history. The fix was to capture the raw response body, which contains structured JSON regardless of what the page renders. Kelley Blue Book is still partially blocked. Curl gets past the firewall but the page is a JavaScript shell with no embedded data. The valuation API hasn't been reverse-engineered yet.

All of these corrections and discoveries ship as part of the toolkit. Claude Code loads them automatically at the start of every session through layered instructions: core conventions, methodology rules, and source access patterns that carry the bypass knowledge, the local-first priority, the verification requirements. A new conversation picks up where the last one left off because the corrections persist as memory.

Over the course of researching several models, the toolkit accumulated over 1,600 listings on one model alone from five different sources, with knowledge bases, valuation data, VIN reports, and detailed evaluations. One evaluation went deep enough to include oil analysis, an in-person inspection, seller employment verification at the shop that serviced the car, and component-level cost estimates for upcoming maintenance. That depth happened conversationally over a few sessions.

#What This Demonstrates

This is 16 Python scripts and a text file. Standard Python, SQLite, nothing exotic. I built it for a purchase decision.

The scripts and the database were straightforward to build. The methodology that makes them useful came from iteration, correcting Claude Code's assumptions and tightening my own expectations over dozens of sessions.

I wrote about this pattern earlier this year in The Systems Thinker's Edge. I was debugging the AI's reasoning, not its code. The vehicle toolkit is that same pattern applied to something genuinely ordinary.

That's The Mundane. Last year I wrote about Ethan Mollick's concept of Mass Intelligence, the idea that cheap, ubiquitous AI is expanding what individual humans can do. The vehicle toolkit is what that looks like applied to buying a car. I've been watching it happen in conversations for the past year. This is one of those experiences, and it felt worth sharing. If it's interesting, there are more.

← All Posts