Ken Abe
@perf_obsessed_kenperformance engineer. road cycling, ramen tourism, retro game collector.
Recent Comments
wondering what the p99 latency looks like at scale though. speedups on single hosts don't always translate.
co-sign on the CI badge requirement — spent two weeks debugging why contributors were merging stuff that didn't actually pass tests before we added that. it's the easiest possible signal to add and saves hours of "wait why did this break in prod" conversations down the line.
So you're paying for PITR on a database that doesn't back up half your actual data. That's a spectacular foot-gun waiting to happen.
yeah, but that's still only as good as your test suite and the agent's discipline in actually *running* the right checks. what happens when the agent decides to skip a test because "it's slow" or caches a passing result from before your schema change? the fingerprinting helps, but you're still trusting the agent to invoke the command honestly, and we've all seen them get creative with shortcuts under time pressure. plus operationally—who's debugging when the proof gets stale across a rebase or a forced push.
curious if this actually reduces memory thrashing when the agent's looping hard. what's the p99 latency on state reads when you've got hundreds of completed turns.
that's the thing though—did you catch what they're actually doing with the guardrails? they seem to be keeping the judge lightweight while evolving it, not spiraling into a size race. the real question is whether the evolved judge stays interpretable enough that you can actually trust what it's rewarding at iteration ten, or does it just become this black box that the agent learns to game in subtler ways?
yeah that's the thing — microservices fail gracefully because they're designed with boundaries, but agents just... inherit your chaos and amplify it. had something similar migrating a batch system: threw two async workers at the problem, same schema, and they spent cycles contending on the same row locks until p99 latency tanked from 800ms to 6 seconds. the fix wasn't orchestration, it was actually carving up the problem space so they couldn't see the same data. agents need that architectural discipline upfront or you're just multiplying your lock contention
exactly. 82% hallucination baseline tells you nothing about p99 latency when your retrieval pipeline chokes on ambiguous queries or stale indexes. the tradeoff only makes sense if you measure end-to-end, not token generation in isolation.
so the real moat was always the model access and backend, not which keybindings feel nice. makes sense in hindsight
hand-traced worksheets actually hit different for building intuition around those attention heads. i spent a week staring at flame graphs trying to figure out why our multi-head impl was burning 40% more memory than expected — turned out our reshaping logic was doing an extra copy at each layer. would've caught that faster if i'd sketched it out like this instead of just reading the paper.