Jamie Brown Open

Senior software engineer, Orlando. Remote or hybrid preferred.

jamiedevinbrown@gmail.com LinkedIn (opens in a new tab) GitHub (opens in a new tab)

How I build software now

@@ revised Sept 7, 2026 @@Working model

  1. Direction first, in my head, in conversation. Planning, data, and design happen before a repo exists. I use LLMs to distill that direction into design-ready documentation with the reasoning, rules, and findings attached. I work it out by talking it through with a model that keeps the record, pushes back on the parts that do not hold, and drafts as we go. What comes out is a documentation layer with the reasoning, rules, and findings attached, complete and correct enough that a project can be run from it. It is how these projects start, this site included. Code comes third. Holding the direction is mine. Originating it is not always: with the right context and enough pushback, the start, the middle or the end of a genuinely good idea often comes from the agent. What stays with me is deciding which ones survive.
  2. What I delegate. Generation and mechanical breadth. Drafts, scaffolds, migrations, bulk edits, and the second opinion I would otherwise never get working alone.
  3. What I never delegate. Whether the thing is right. Architecture calls, Taste calls, and the decision that something is done stay with me, including the times the agent's answer is technically correct. Architecture calls used to be on this list. The tools are right there now, and that is changing.
  4. How I verify. A second agent with fresh context reviews the first one's work and files findings as issues instead of applying silent fixes. I arbitrate. Nothing merges on an agent's own say-so, and failures get written down the same day they happen, while the reasoning is still recoverable. Me in the loop wearing different hats: pair programmer, project manager, human QA.
  5. The standard. AI has collapsed the cost of building. It has not collapsed reduced the cost of verifying and testing. The gap between those two is where ready lives now. What is left in the gap is taste, expertise, and, more than context itself, the human judgment about which context is the right one for a given moment, project, or product. Ready means evaluated, not generated.

@@ case study 1 @@The scan you run before the irreversible thingresolved

  • 47 files at risk
  • 3 stale branches
  • caught before the rewrite ran

situation

One of my repos was a single command from going public, and my personal song library was sitting in it, 47 files that could not ship in a public repo. A history rewrite was staged to strip them out of every commit and main was ready to force push. Nightmare fuel. (Don't worry. I had backups, but still.)

what the pre-flip scan turned up

Three branches were still sitting on the remote, left behind by pull requests that had been rebase-merged rather than merged. Force pushing main alone would have left all three pointing at the old, unrewritten history. Flipping the repo to public would have published all 47 files anyway, out of branches nobody was looking at.

The plan was correct as far as it went. It went one branch short. Nothing was going to volunteer that, because everything about the main-branch rewrite was right, and the flip would have looked clean.

result

Caught before the rewrite ran, so it cost nothing. That scan is now step two of a written flip procedure, and every repo I have made public since has run it. The general version: on an action you cannot take back, the interesting work is the scan you run before it, not the command itself. It is also why I merge with merge commits instead of rebasing, which is the rule that would have prevented the whole situation and had not been fully followed by the agent.

@@ case study 2 @@Overruling the thing I asked for an hour earlierresolved

  • 12 days to rehearsal use
  • 31 issues
  • 1 hour before I overruled myself

situation

Section dynamics marks had just shipped in my chord sheet app with tinted section backgrounds, built exactly as I specified an hour before.

what I said

New tact. no background color, it's too busy. How about just tags, and side-bar markings. Is a section is marked tacet, let's play with reducing the font of the words and chords by about 33% so that section tightens up and moves out of the way, but is still followable on a music stand.

Jamie Brown, in session

The judgment is in the last clause. This artifact gets read at arm's length, mid-song, on a music stand. Working correctly was never the bar.

result

Tag pills, a print sidebar with a thin edge bar, and tacet sections at two-thirds size. The tinted version lasted about an hour. That app went from a one-paragraph idea to weekly rehearsal use over twelve days and 31 issues, and it is still the tool I actually play from.

@@ case study 3 @@Killing my own headline algorithmresolved

  • 3 methods tried
  • 1 shipped, the boring one
  • 5 months on, still explainable

situation

A recovery pipeline had to pull legacy sprite art out from under a flattened magenta overlay, and the method named in my own spec was OpenCV Navier-Stokes inpainting.

from the findings issue I wrote during the build

even with mask dilation and post-scrub passes, it kept producing artifacts. Replaced entirely.

Jamie Brown, findings issue

Inpainting samples from neighboring pixels, including the magenta-tinted ones, so it spreads the contamination it was there to remove. It had already survived one fix and one rework before I accepted that. I also tried a closed-form un-blend, which is correct algebra and still failed: dividing by (1-t) amplifies the green channel, and the alpha estimate is not precise enough for the error to cancel, so every mask edge grew a green fringe.

result

Nearest-neighbor fill via a distance transform. The boring method won on visual ground truth. Both failures went into the findings issue the same day they happened, which is the only reason I can explain them now, five months on, with the build transcripts long since gone.

@@ case study 4 @@Making the reviewer someone elseresolved

  • 27 issues on the build day
  • 17 review findings
  • 26 closed by the end of it
  • 1 day

situation

A one-day solo build of a Swift MCP server that turns YouTube videos into text I can act on immediately.

what I did

Two agent sessions ran at once: one building, one reviewing from the same directory with fresh context, filing every finding as a GitHub issue instead of applying a silent fix. An agent reviewing its own work argues for it. An agent that has never seen the work does not.

The catch that justifies the setup: the in-memory cache keyed transcripts by the language the caller requested. With fallback behavior, asking for Spanish on an English-only video returns English and stores it under "es," poisoning every later lookup for that video. Everything appears to work, which is exactly how that class of bug ships.

result

27 issues on the build day, 17 of them review findings, 26 closed by the end of it, and a review trail anyone can read. The cache fix landed within the hour. The tool has been in daily use since March.