Behind the build

Why Congress

I’ve spent my career in business operations and enablement. The part of that work I’ve always loved is playing with data: digging in to see where an organization is working, where it’s stuck, and how it could improve.

I wanted to learn to use AI for real, not just chat with it. I tried the exercises and the online courses, and they felt useless: tidy problems with the answers waiting at the end. I needed a project with some weight to it, and I had a hunch that something built on public data and APIs would be the fastest way to get my feet wet.

So I went looking for an AI experiment, not a political project. I wanted somewhere I could dig into a genuinely large dataset, try out APIs and MCP servers, build a data structure from scratch, and see whether I could find a story in it and tell it well.

I wrote briefs on many public data sources and scored them. This is a distilled version of that early research, and the criteria I was choosing from.

GovInfo scored a 7. Eleven sources scored higher. Ultimately, I let personal curiosity guide the rest.

Politics kept pulling me back. I’ve always been interested in it, but I feel disconnected from the way we consume it. The news cycle and social feeds are loud and thin, removed from what actually happens. And what actually happens has felt less and less productive over my lifetime. I wanted to know whether that feeling held up.

GovInfo’s bulk records had every bill and every law, public and free. That settled it. I came at it the way I’d come at any system at work, asking what goes in, what comes out, and how long it takes, and started down the road.

I’d be the product owner. I would decide what to ask, what counted, and what shipped. AI would be my build team.

Asking the data questions

Before any of the build mattered, I had to understand the data. I started with the basic questions anyone would ask. How many bills? Who’s in charge when they pass? Does party make a difference? Does any of it ripple out? Then I chased the answers through the records, and every answer sharpened the next question.

How many?

145,753 measures in, 4,279 laws outThe share that became law fell from 5.8% in the 108th Congress to 1.7% in the 118th.

Who’s in charge?

474 vs. 373 vs. 331 laws a termUnified Republican, unified Democratic, and divided government, averaged over completed terms. Descriptive, not causal.

How long?

161 → 339 median daysFrom introduction to law, 108th vs. 118th Congress, for the bills that made it.

What actually passes?

About 1 in 4 laws is ceremonialRenaming post offices, awarding medals, authorizing coins. Estimated from each law’s title.

Fewer, but bigger?

6.2k → 6.8k words per lawLaws got a little longer, nowhere near enough to make up for the drop in count.

Did executive orders fill the gap?

No clear link (r = −0.07)Across 11 completed terms, executive orders don’t track conversion. A small sample, so read it as a shrug.

Questions I haven’t answered yet

Some of the biggest questions aren’t in this version. They’re next.

• Quality of output. I think of this almost like lifetime value: obviously important, and very hard to code fairly. Fewer laws could mean better ones. It doesn’t feel that way, but I haven’t measured it.
• A longer look back. The data starts in 2003. I’d love to push further into history and see whether this is a trend or a blip.
• Follow the money. It’s a massive part of this story, and probably where the why lives. This is where I could start looking at causes, not just symptoms, of a Congress that feels dysfunctional and unproductive.

How it actually went

1. 01LostFalse starts, an AI council, and zero-cost questions
2. 02Speed80–90% there in a flash
3. 03PerfectingTweaks, restarts, and doubt
4. 04UneaseLiving with the boxes I don’t look at

01 · Lost

Getting lost in the forest

Starting is easy. So is wandering down false paths. At work I’d used Make and Zapier for automation, and I’d started poking at n8n, but none of it felt as direct as just building with AI. I was also trying to keep this on a budget, which meant free tools and workarounds, each with bugs of its own.

My first real experiment was an AI council: a boardroom where a swarm of self-generated ideas would pitch, duke it out, and crown a winning business concept.

It didn’t really work. The weirdness got sanded off in the pitching, and the model kept drifting back to scent for reasons I never figured out. Of the last eight winners, five were tools for validating startup ideas: the council had started pitching itself. The scores inflated too. One run gave both teams a perfect 100.

The real value was underneath. Running the council taught me OpenRouter, and it made me start watching what every API call cost and how efficiently it ran. That turns out to be a central part of actually building with AI.

From there I kept tinkering. I connected MCP servers for GovInfo’s .gov records, a weather API, even Robinhood. I tried them across Claude, ChatGPT, Gemini, and OpenRouter, ran pieces through n8n and Docker, and watched them fail in ways no documentation mentioned. I queried datasets big enough to break things, then broke them again. I built a Google Sheets publisher and later tore it out. I wired in sign-in, a database, and file storage (Clerk, Neon, and Vercel Blob) that the project turned out not to need.

Keeping the cost at zero, or close to it, turned every choice into a research project. What’s best for the data? For the design? For automation? Local or cloud? Will it scale? What’s free, what’s cheap, what’s expensive, and what exactly does the money buy? You can get lost in those questions for weeks.

You come out knowing the tools, the approaches, the dead ends, and the breakthroughs far better than any tutorial could teach. And with an LLM as a partner, there’s always a way out. When the forest gets too thick, you pull the rip cord: pick a direction, hold your nose, and do the thing that gets you out of there.

02 · Speed

Finding speed

Then came the part that feels like the promise of AI. My first commit landed on June 12. By June 15 I had charts, a head-to-head comparison, and a working chat over the data. All that tinkering turned into leverage: I knew what I wanted, and I could finally describe it well enough to get it built.

It’s exhilarating, and maybe a little misleading. You get 80 or 90 percent of the way there in a flash, and it feels like the rest will take one more weekend.

03 · Perfecting

The wasteland of perfecting

It didn’t. What followed was months of tweaks, touch-ups, edits, restarts, dead ends, and endless additions and removals, with a low hum of dissatisfaction underneath. Even the headline went through it. My first draft read “More bills than ever. Fewer laws than ever.”

The data didn’t support “ever.” There were reversals along the way, and the current Congress isn’t finished. Comparing only completed terms made the claim smaller, and truer: “More bills. A smaller share becoming law.” Any pipeline review teaches the same lesson: pick the denominator before you write the headline.

That was the job, and it was mine. What counts as a law when two official sources disagree? Which terms are fair to compare? What is the chat allowed to see, and what has to be checked before it answers? Which claims would I stand behind? I kept a claim-by-claim evidence checklist, and every headline number on the site traces back to it.

Somewhere in there, the harder questions start. Did I make this? Is it what I wanted, what I meant, what I intended? It’s close. Maybe a facsimile.

I’ve had to learn to be OK with that. At work, the people I collaborate with make things that aren’t mine either: inspired by me, directed by me, built by them. How different is this, really?

04 · Unease

The boxes I don’t look at

Now that it’s launched, there’s a tension I can’t shake. This project moved me away from the layers of doing, and that was uncomfortable. I stopped asking “how do I make this work?” and started asking different questions. Where is this heading? How useful is it, and to whom? How should I brand it? What should the design be?

Technically, that’s moving up the value chain. But the higher I went, the more of what got built was abstracted away from me. I don’t know every part of it the way I know systems and processes I’ve built from the ground up, where debugging is intuitive because I know the whole thing end to end.

There are black boxes here. No, not even that, really. Just boxes I don’t look at. That discomfort is the dilemma, and for me it’s the most interesting part of the whole project.