Jamie Brown Open

Senior software engineer, Orlando. Remote or hybrid preferred.

[email protected] LinkedIn (opens in a new tab) GitHub (opens in a new tab)

Projects

yt_transcript_mcp

README (opens in a new tab) Build log (opens in a new tab) public

  • Swift 6
  • 27 issues on the build day
  • 1 day
  • in daily use since March

A Swift 6 MCP server that pulls YouTube transcripts through the InnerTube API. No Node, no Python. I built it because watching a video for information, even at double speed, is now the slow path, and turning it into text makes it something I can synthesize and act on straight away. Built in a day with a 27-issue review trail, in daily use since.

data flow

  1. Claude Codeor Claude Desktop, packaged as mcpb
  2. yt_transcript_mcpSwift 6 MCP server, runs locally
  3. InnerTube APIthe transcript YouTube already has
  4. Transcript textcached in memory, keyed by the language returned
  5. Back to the agentas text it can act on

verification

27 issues on the build day, 17 of them review findings from a second agent with fresh context, 26 closed by the end of it. Offline unit tests. SSRF designed out before the network code existed.

Shortcoming: one documented maintenance point, and it is not hosted, so it runs locally only.

Jamie Brown, self-review

chordsheet

README (opens in a new tab) Build log (opens in a new tab) public

  • TypeScript
  • 248 agent-generated tests across 17 files
  • 12 days to rehearsal use
  • 31 issues

A web app for play-along guitar chord sheets, written in TypeScript. The interesting design constraint is legal, not technical: the AI assist only ever emits chord names and positions anchored to lyrics the user already has, never lyric content, which is why it works at all where a naive prompt gets refused.

The 248 tests are agent-generated, and that was the experiment. Coverage had just gotten cheap enough to be worth spending freely on, so I let the agent go wide and used tests as a development process rather than a chore. Working out what the new tooling was actually good for, as it came online, was half the point of building this.

data flow

  1. Lyrics pasted by user
  2. Character-cell layouta monospace grid
  3. Chordsplaced over exact characters. The AI assist emits chord names only
  4. Capo and transposea display transform, never a rewrite
  5. Printliteral text rows
  6. Saved to a folderFile System Access API, Chromium only

verification

248 tests across 17 files. From a one-paragraph idea to weekly rehearsal use in twelve days and 31 issues.

Shortcomings, stated in the README: Chromium-only folder save, no mobile layout, no undo, approximate voicings for unusual chords, and the tests stop at the UI boundary.

Jamie Brown, self-review

history-heatmap

README (opens in a new tab) Build log (opens in a new tab) Live demo (opens in a new tab) public

  • 1 HTML file
  • 0 dependencies
  • AD 33 to the present
  • constant cost per viewport

This one started with a question about how ideas spread and which ones last. The same question sits under internet culture, stock moves, prediction markets and memes, and following it back far enough lands on the most durable ideas people have ever held. Christianity and Islam were the first, oldest, and most widespread dataset I could think of. Then I wanted to see it. I realized I could probably do that within moments, and I was close. I am amazed that, while thinking through the philosophy of ideas, I can now generate nearly any visual, dataset, rulebase, or set of instructions to help me reason and understand. I don't think the world understands the weight of this yet. I am still wrestling with it myself. More population categories go in when I have time for them.

An engine for visualizing historical population dynamics from AD 33 to the present, in one self-contained HTML file with no server and no dependencies. An analytical gaussian heat field evaluated per viewport at constant cost, mass-conserving anti-aliasing for city-scale overlays, and a hybrid model that blends hand-curated anchor data with logistic growth and diffusion. City lifecycle events are pure functions of the playhead, so scrubbing backward replays conquests in reverse with no extra state.

data flow

  1. Anchor datahand-curated, unaudited
  2. Growth and diffusionlogistic model between anchors
  3. Heat fieldanalytical gaussian, per viewport, constant cost
  4. City overlaysmass-conserving anti-aliasing
  5. Playheadcity lifecycle as pure functions, so scrubbing runs in reverse
  6. One HTML fileno server, no dependencies
Shortcoming, stated plainly: I have not audited the dataset's sources, and the numbers are unaudited estimates assembled from standard scholarship. The engineering I will defend, somewhat. I consider this an exercise in building software for the purpose of thinking, not for the sake of the software itself. The value is in the exercise, and in the questions and conclusions about the near future it raises. What does the world look like when every layperson can do this in moments, for any topic or interest?

Jamie Brown, self-review

Also in flight, not public

magenta_pipeline, a three-phase Python, OpenCV, and Photoshop automation chain recovering legacy sprite sheets for a Unity project. A Warmongers reboot in Unity, rebuilding a title that reached No. 20 Top Free on the US App Store. Both are private repos, cited here because their build records are the source of the case studies.

magenta_pipeline, data flow

  1. Legacy PSDsflattened under a magenta overlay
  2. Photoshop JSXrename, variants, rasterize
  3. HSV maskOpenCV, isolates the overlay
  4. Nearest-neighbor filldistance transform. Replaced inpainting, see case study 3
  5. PSB write-backpsd-tools
  6. Mask flattenJSX again, because Unity's PSD importer skips masked layers
  7. Unity