Building thoughtful software with AI.Notes from the systems behind the work.
A proxy timed out a slow purchase-order build and my dialog called it a failure even though the server finished. I taught the dialog to say it doesn't know, ask a read-only status call, and join a build already running, and overlapped the store reads to shorten the wait.
Read moreThe production deploy could only start over after an interruption. Now it pins one exact commit, records each phase on the production host, checks the database early without writing, waits for other people's runs instead of quitting, and keeps waiting time off the release clock.
A daily blind count, where the sheet hides the expected quantity, lost stock in its first version before anyone counted it, because a missing package quantity came through as zero and got skipped.
The scheduling app now plans a whole change set on a copy of the week, checks only the result, and replays a lost save before it asks whether the board is stale. The swap that makes it worth it still only runs in a test.
A refunded pack whose credits were already spent had nowhere to go, so accounts got a separate debt counter and every incoming credit now pays that debt before it becomes spendable.
Four different code paths could give up on a paid webhook delivery, and every one of them marked it dead without refunding the credit. I routed them all through one locked settlement that refunds exactly once, fenced writes by attempt number, and made account deletion count its refunds before it commits.
The bulk tagging tool treated a package as one thing while the point-of-sale system kept a row per room, so I moved writes to every stocked row and made the receipt admit it never reads room tags directly.
My vendor API could change an order, fail to record its reply, and still return success, so I gave each retry-key reservation an owner token, made the final write conditional on it, and turned an unrecordable answer into a visible server error.
The code that tagged packages for markdown would report success with no readback from the gateway, so I made the readback mandatory, settled 'already ran' refusals by reading live tags, and stopped reusing one key for the same content forever.
A long windowed import of store discount data now skips windows that already have an exact success record, and the route turns away a second sync while one is running, with a few gaps I still have not checked.
The ordering system found zero sales rows for an approved product. Diagnosis showed one product was simply absent and another was filed under the wrong store connection, so I proposed an alias, counted its effect in memory, and only then wrote exactly one sales fact without saving the alias.
The first real approval in the ordering system was made as small as I could, with a couple dozen tables counted around it to prove it touched one thing. The counts held up. Then I found that several of the report's 'this didn't happen' lines were hard-coded, not measured, plus a few things counting can never see.
A probe hung up on a product catalog several times bigger than its cap. With no way to page the feed, I captured it once as an encrypted, hashed copy and made every later step a checked replay that can safely run twice.
An atomic receipt store keeps each plan from my planning service exactly once, but the second guard ignored any plan that left its run field empty, in the database and in my own lookup.
A supplier sheet asks for several distinct items by repeating one generic line, and my import collapsed the repeats into a single product. Each repeat is now its own numbered slot, ordered by sheet position, with a store-by-store count check before anything is saved.
The button that saves a delivery as a draft in the stores' inventory system checked first and wrote its record only after a slow outside call, so a second click could slip through. Now it claims the delivery in the database first, lets a partial unique index refuse the second claim, fixes a payload hash that couldn't see nested fields, and adds a narrow admin cancel for claims that get stuck.
A receipt line carrying the same promo twice collapsed into one event in my vendor-credit pipeline. My first tie-breaker depended on neighbouring entries, and the app that stores the events had a looser key of its own.
Widening a discount-and-return sync from one store to all of them meant the event ID had to carry the store too, while counters added the same day show what the merge absorbs and what the size cap cuts.
Full-case rounding moved from the browser to the server and still read the order before its transaction, so two overlapping requests could each add the same shortfall. Locking first and reading second makes the repeat a no-op, and I list the gaps that are still open.
Every endpoint in my ordering system wrote the order status its own way, and one would rewind a received order to draft. I put every legal move in one shared table, made every writer ask it, and added a history trail and a changed-only webhook for supplier writes. The race and the lost-message problems are still mine.
The supplier stock alerts hash every drifting number, so an unchanged low shelf can keep re-firing, and they record an alert as sent before posting it, so an alert whose send fails can stay missing. Neither showed up in the tests, and I lay out what I want instead.