greenstevester
Joined 10 months ago
Karma
146
Submissions
9
Member since
Dec 30
Recent submissions
Comment · 1 month ago
Comment · 10 months ago
I start another claude session, working on other tasks I need to finish. I keep a running list of todos in Obsidian pick them off one by one while claude is doing its thing.
Comment · 10 months ago
Actually I wrote the first and last part and it filled in the middle.
Comment · 10 months ago
You are absolutely right!
Comment · 10 months ago
It started with a bug.
I was trying to get a unrelated typescript project running, when I hit an issue with one of its dependencies... license-checker. No big deal, I thought. I'll just check if there's a more recent version to fix the bug.
Last commit: January 2019. Weekly downloads: 760,000+. Open issues: 96. Maintainer activity: crickets
WTF. C'mon.
This package is used by Puppeteer. Playwright. Cypress. Angular CLI.
And nobody's home.
"I'll just fork it and fix the bug," I said... like an i d i o t who thinks time is an infinite resource.
Three hours later, I was knee-deep in a CommonJS codebase with no tests, questioning my life choices.
That's when I decided to bring some backup: Claude Code.
The coding Savant (who occasionally bullshits you) Working with CC on a codebase migration is... an experience.
Hour 1: Claude analyzes the codebase. Creates a sensible migration plan.
Hour 3: We've converted half the files to TypeScript. Claude is methodical. Professional. Sometimes lies, like "all tests are passing" - Really I say, check again with a retort "you absolutely right".
Hour 6: Claude has created a todo list with 47 items. I did not ask for this.
Hour 12: Claude has started writing marketing copy for the project. It has opinions about our "market positioning."
Hour 18: We have a fully working TypeScript codebase with tests. Claude suggests we "track competitor packages."
The Bigger Question This experience made me realize something: there's a LOT of critical infrastructure running on abandonware.
What if "AI + motivated human" could be a model for OSS sustainability?
The AI handles:
Tedious migrations Boilerplate code Documentation generation Test scaffolding Performance profiling (yes, Claude got really into benchmarking) The human handles:
Judgment calls Architecture decisions Community interaction Deciding when the AI is being too enthusiastic So my fellow coders, the crusade begins
I'm calling this the OSS Crusade: one dev and one AI, rescuing abandoned packages from the npm graveyard.
1. A critical review of a (my) PostgreSQL schema. 2. A visualiser that shows how (possibly) hundreds of tables connect.
Nothing did both, so I built it....in a mid-Late 2026 moment (I know what you're thinking).
Anyway, then I ran it on the GitLab schema... cause why not right - its opensource? (nothing against gitlab btw, used it for years without a hitch, even hosted it myself)
I found missing keys, unindexed foreign keys, junction tables that allow duplicates, money in floats, relationships whose cardinality does not match what everyone believes, and a structural visualiser good enough to understand the relationships and the coupling in a schema of a few hundred tables.
So I built both into one tool, called it archlens-postgres, and to see whether it holds up I ran it over seven open-source products whose schemas are public: Temporal, Miniflux, Listmonk, Matrix Synapse, Sourcegraph, Cal.com and GitLab.
The review half parses the DDL with libpg_query (PostgreSQL's own parser as WebAssembly) and runs 23 deterministic checks; each finding carries the cost,the fix and usually the SQL. The visual half is a 3D explorer: one island per domain, every foreign key an arc, click any table or arc for its detail, mute the sheaf into the hub table with one click.
GitLab is 1,429 tables and 1,861 foreign keys; its projects table is referenced by 371 others, namespaces by 353. You can see that coupling in about two seconds in the explorer and not at all in a diagram.
https://greensill.net/postgres-schema-gallery/gitlab/schema-...
Some of what the review found:
Synapse: 109 of the 137 tables in its published full schema have no primary key.
Sourcegraph: 270 foreign keys with no index. 157 of them are the same tenant_id column, added to every table by their multi-tenancy work.
Cal.com: 205 timestamps without time zone (Prisma's default), one price stored as a float.
Temporal: zero foreign keys across 38 tables, by design.
TO BE CLEAR: I am not trying to fatshame or doxx any OSS project here here, just calling it how the tool (for better or worse) found it.
Telling the deliberate findings from the accidents is also hard.
The tool's answer is a narratives file: a human records "this is intended, here's why" once, and the next run treats it as a claim to check rather than a finding to repeat.
It's packaged as a Claude Code plugin because that judgment half is where an AI pair helps; the script runs on its own without it.
Schemas are fetched at pinned commits from each project's own repository; nothing is committed or edited by hand.
The gallery's build is at:
https://github.com/greenstevester/postgres-schema-gallery
and the reviewer at
https://github.com/greenstevester/archlens-postgres (both MIT).
Which schema should go in next? It needs a plain-SQL PostgreSQL schema in the repo, or a Prisma schema; the build can emit SQL from that.