blundergoat

fortran > cobol

The actual license issue is pretty specific. Kimi K2.5 ships under a modified MIT that has one extra clause: if you exceed 100M MAU or $20M/month in revenue, you must prominently display "Kimi K2.5" in your UI. Cursor almost certainly clears that revenue threshold. So this isn't a "you can't use it" situation - it's "you can use it, you just have to say so." The fact that they didn't is the interesting part. They could have been fully compliant and just... put a line in their model picker. That they chose not to tells you everything about how they want Composer 2 to be perceived.

The detail about Hoare sitting in the front row at conferences taking notes on specialized topics (after retiring from Oxford, after a Turing Award, after decades of foundational work) is the part of this piece that will stick with me. There's a certain kind of senior figure who stops learning once they reach eminence. Hoare clearly wasn't that. Meyer's phrase "a combination of pride and humility" nails it.

The real win here isn't TS over Rust, it's the O(N²) -> O(N) streaming fix via statement-level caching. That's a 3.3x improvement on its own, independent of language choice. The WASM boundary elimination is 2-4x, but the algorithmic fix is what actually matters for user-perceived latency during streaming. Title undersells the more interesting engineering imo.

We treat webhooks as at-least-once delivery over an unreliable transport and design for duplicates and out-of-order events.

A few rules that have saved us:

- Persist before responding. Never process inline. Write payload to DB, return 200 fast.

- Idempotency key required. Either provider event ID or hash the payload.

- Async worker processes from queue. Exponential backoff + max attempts.

- Dead letter queue + dashboard. Humans need visibility.

- Alert on backlog growth, not single failures. One failure is noise. A growing retry queue is signal.

- Relying on provider retries alone has bitten us more than once.

Duke Nukem 3D was my first experience urinating in a video game. Hail to the king, baby.

Author here. After years building healthcare software, I noticed most teams treat code review as a quality gate—reviewers re-checking functionality, hunting bugs, re-verifying requirements.

That's duplicated work. The developer wrote it, the tester verified it. The reviewer's job is different: make sure the next developer can understand and maintain it.

The framework boils down to three questions: 1. Can I follow this? 2. Can I find this later? 3. Is this where I'd expect it?

Curious how others handle the tension between thoroughness and velocity. We landed on "one business day max to respond" as a forcing function—what's worked for your teams?

Happy to discuss the framework or where it breaks down. The TL;DR: ~90% single AI, ~10% signal-triggered multi-AI escalation. The hard part is knowing when to escalate - I use three gut-check signals (Loophole Detector, Annoyance Factor, Sniff Test).