← all writing

A small PR, a maintainer quote, and the part of AI-assisted development the industry undersells

#The moment

This morning a maintainer at 1Password merged a small PR I filed eleven days ago. The review note was short: "Thanks for the fix on this. Approved!"

The PR was a case-sensitive struct-tag matching fix in config_helper.go in their Go SDK. If your tag literal didn't exactly match the casing of the section or URL label you were looking up, the field silently dropped. strings.ToLower comparison where strings.EqualFold belonged.

Bug class — confused-deputy-shaped. The function read your tag correctly, looked at the actual data correctly, then quietly failed to match because of a case mismatch nobody could see from the outside.

#The fix

One line.

// before
if name == strings.ToLower(s.Label) {
    // ...
}

// after
if strings.EqualFold(name, s.Label) {
    // ...
}

The maintainer had pre-approved this direction in issue #99 — strings.EqualFold was their explicit recommendation. So the fix itself wasn't novel. It was the canonical answer to a known bug, applied in one place.

#The part that's actually interesting

I could have shipped a PR that fixed exactly one site. Looking at the diff scope, that would have been the safest move: minimal blast radius, easy review, fast merge.

But the same bug class — case-sensitive matching on user-provided struct-tag content — was probably elsewhere in the same file. Probably. Reading top-to-bottom, I would have missed it. Files like config_helper.go are mid-sized; if you're not actively looking for a pattern, your eyes skim.

So while I was in the diff, I scoped a Claude Code session to one task: "find every place in this file that does case-sensitive matching on struct-tag content."

It surfaced four more sites. Plus an inline comparison in setValuesForTag I would absolutely have missed.

All four were the same shape — name == strings.ToLower(s.Something). All four were silent-data-loss bugs waiting for a user with a case mismatch. All four got the same strings.EqualFold swap in the same PR.

#Why this matters

This is the part of AI-assisted development I think the industry undersells.

The discourse is mostly about "the AI wrote the fix." Models that generate code. Tools that complete functions. Pull requests opened by bots.

The fix here was a one-line swap. The AI didn't write it; I did, in a single character of cursor movement. What the AI actually did was help me see the pattern across the file faster than I could have caught it solo.

That's not "AI replaces engineer." It's "AI is a focused-attention augmentation for engineering pattern recognition." Different framing entirely. Less marketing-friendly, more accurate.

#Test discipline

32 unit sub-tests + 1 end-to-end test. Race-clean. All five sites covered, plus regressions for the cases that work correctly so the swap doesn't break anything.

The reason I always over-test on drive-by PRs is that strangers' PRs are the kind of thing maintainers reject by default. The bar is "the test discipline has to prove the change is safe to merge without the reviewer reading the code carefully." 32 tests for a five-site swap looks excessive until you remember the maintainer is reviewing fifty PRs that week and yours has to be reviewable in the first thirty seconds.

It worked. Merged eleven days after submission with one approving review.

https://github.com/1Password/connect-sdk-go/pull/104

If you've got a strings.ToLower comparison in a function that reads struct-tag content somewhere in your own codebase, that's your homework.


← all writing