Posts

Asymmetric Apologies

2026-07-15T16:32:00+00:00

When a large tech company gets caught siphoning private user data in the background, the response is pretty predictable. The corporate PR machinery, run by empty suits, issues a statement and they offer the standard, bureaucratic symmetric apology:

"We take your privacy super seriously. We have updated our internal policies and we promise to do better. We don't expect to be forgiven, we're simply here to apologize."

This is literally cheap talk. If you've broken the trust of your users, asking for more trust from them is borderline abusive.

You can't rely on these sorts of apologies to win back the hearts of your users. Instead you have to put something real at stake.

An asymmetric apology is a structural amputation. You offer a disproportionate, irreversible concession. You permanently surrender power that you had over your users in exchange for a chance at their renewed confidence.

In 1215 AD, King John abused his power as sovereign by increasing taxes, seizing assets and pissing off his barons. In retaliation, his lords banded up and rebelled against him and he was forced to cowtow to their demands. King John couldn't lower taxes or return the ill-gotten wealth, those terms would not have appeased his enemies. To save his throne from immediate violent overthrow, he signed the Magna Carta and surrendered the structural concept of absolute monarchy; making himself and all future kings and queens subject to the same laws.

Another well known example is Dungeons & Dragons publisher Wizards of the Coast. For 20 years, Dungeons & Dragons allowed third-party creators to build and sell content using D&D's core rules under the Open Game License (OGL). In early 2023, leaked documents revealed WotC planned to revoke the original OGL to extract royalties and assert restrictive control over creators' work. The community revolted, canceling digital subscriptions en masse and launched a massive boycott.

While WotC initially tried standard symmetric apologies and offered a slightly revised "OGL 1.2". The community rejected it. And in order to stop the bleeding, WotC released the entire 400-page core rulebook (SRD 5.1) directly into the Creative Commons (CC-BY-4.0). WotC literally removed their own legal power to ever attempt the cash grab again.

Some folks think the recent Grok Build open source release is bad. It's of course an obvious attempt to distract from the fact that they violated basic security sanctities of their users. Now every tech influencer can make their "I code reviewed Grok Build" videos, collect their nut, and move on from the whole scandal.

But there's a positive, incalculable outcome to it all as well. Users can freely modify, build on top of and distribute better versions of the harness. It's free for communities, users, companies and countries to use and learn from. Maybe the code quality is shit; it'll get better. Maybe it's not trustworthy; people will untangle the telemetry. Perhaps, TUI harnesses aren't your thing; someone will extend it with a GUI.

As an example, here are what users are already building with forks of Grok Build:

thedavidweng/gork-build — 12 commits, most developed fork. Rebrand grok→"gork", stripped vendor telemetry, lock data-retention opt-out only, block x.ai auto-update, OSS governance + Apache-safe rebrand, README comparison table. Positions as "VSCodium-style privacy fork."
thomas9120/grok-build-archival — 1 commit: Windows script to disable telemetry.
DigiGoon/digi-grok-build — 2 commits: ship "dgrok" multi-provider CLI with /provider + install scripts; build from source instead of x.ai CDN.
victor-software-house/open-grok — 2 commits, "opened to every provider" (docs/architecture so far, code pending).
LukaMucko/grok-build — 1 commit: extra_body support for provider-specific request-body fields.
RapidAI/grok-build-desktop — 3 commits: Tauri desktop ACP client (GUI), bilingual README, self-hosting docs.
mazdak/grok-build — 2 commits: theming (system-default + Catppuccin).
saqoah/grok-build — 1 commit: Kotlin MemoryBackend interface + utilities.

There's usually asymmetric upside for the user when there's an asymmetric apology. That's not nothing.

Modeling the 2026 World Cup as a Status Page

2026-07-06T13:00:00+00:00

Disclaimer: I work at incident.io, which sells a Status Pages product. I'm not trying to influence you to buy our status page product. I just think status pages can be a canvas for creative ideas.

TLDR; here's the status page

I'm admittedly a fair-weather fan when it comes to FIFA and football but I have fond memories of huddling by the TV and watching bootleg streams of matches on hot summer days when I was younger. These days, most of the matches happen while I'm working and so I'm not always available to watch them. I could poll ESPN's live article for updates, but manually refreshing a page is exactly the kind of job we invented computers for. Naturally, why not have a server poll for me?

The question was what the server should poll into. And the more I thought about it, the more the answer looked like the thing I stare at everyday anyway: a status page. Status pages are a public good. They're uptime monitoring for your platform available for the rest of the internet, and they help contribute to netizens being good neighbors to each other when stuff inevitably breaks. They also already have the exact machinery a goal-notification service needs: subscribers, email fanout, timelines, and per-team components.

The mapping turned out to be suspiciously clean. Each team is a component in the Catalog (in incident.io the Catalog is simply a place where you can define typed enumerations of data that you can use across the platform). Each match is an incident. And component statuses play into the outage metaphor operational when the team is not in a match, degraded_performance when it's an active match, and full_outage when you're eliminated, which sticks, permanently, because there is no recovering from a knockout loss. As teams get eliminated their "uptime" metric goes down. The page becomes a king-of-the-hill leaderboard.

And with component statuses, there's status page incident statuses. A status page incident moves through investigating -> identified -> monitoring -> resolved, and if you squint, so does a match: investigating is pre-match, identified is active play, monitoring is any pause (half-time, a hydration break, the breather before extra time), and resolved is the final whistle. Goals are update messages posted under whatever status the match is currently in, the same way you'd post "still seeing elevated error rates" under an ongoing incident. A typical match works out to about 5–7 emails for a subscriber.

Even VAR fits, and it's my favorite bit. Sportmonks (my data provider more on them in a second) emits real VAR event types, so a GOAL_UNDER_REVIEW flips the incident to monitoring and a GOAL_CONFIRMED flips it back to identified with the new score. The nastier case is a disallowed goal, because Sportmonks doesn't emit a retraction, it just deletes the goal event from the feed. The server keeps a map of every goal event it has seen, and if a known goal vanishes from the feed for two consecutive polls (debounced, because feeds hiccup), it posts a retraction to the status page.

The data flow is simple, if a bit involved:

The server polls Sportmonks and turns match events into alert payloads.
Each payload goes to incident.io's generic HTTP alert source.
The alert route groups alerts by fixture ID (with a grouping window of about four hours), so a new match opens a new alert group.
The alert group creates an incident.
The incident triggers a workflow.
The workflow creates and updates a status page incident and refreshes on every goal, every new phase of the match, and the final whistle.

Above all the per-match incidents sits one long-standing status page incident that tracks the knockouts as a whole, updated every time a match incident resolves.

The polling side has its own set of constraints to consider as well. Sportmonks provides a REST API for realtime data (no one at this price level seems to have webhook support.) The trial tier caps you at 1500 API calls a day, on days that can have four simultaneous matches. So the server runs three cadences: a schedule sync every few hours that learns the fixture list (i.e it discovers matches on its own), a pending watch every few minutes for fixtures near kickoff, and a live poll every few seconds that makes one batched /livescores/inplay call feeding every live match at once. When nothing is on, it burns no budget at all. And it's all running on the cheapest Fly.io machine config (one shared-cpu-1x with 256MB of RAM.)

In building this, I'm surprised how well some of the basic primitives of a status page map onto this domain. Some of it is admittedly a bit hacky and the server is doing a bunch of orchestration work that maybe it shouldn't have to. But I'm happy with the result!

You might think, what's the point of this if you're just going to be watching the game anyway? But in my experience, the data often rolls in faster than the broadcast. The result is delightful blip of suspense upon getting that email notification on your phone, 10 seconds before you're seeing what happens.

Did Vozinha block another shot? Did Morocco score that penalty kick? Absorb the moment, find the crowd's roar, move fast when the defense breaks.

this LFE proves me human

2026-03-08T09:33:18.984610+00:00

;;; this lisp flavored erlang proves me human
;;;
;;; after will keleher's "this css proves me human"
;;; https://will-keleher.com/posts/this-css-makes-me-human/

(defmodule human
  (export (prove 1) (main 0)))

;;; --- the first wound: i pattern match on myself ---

;; a machine would optimize this away.
;; i keep it because the failure clause
;; is the only honest part.

(defun prove
  (('human)
    (receive
      ('are-you-sure 'no)
      ('prove-it     'i-cant)
      (after 5000    'i-got-distracted)))
  (('machine)
    '(i would never hesitate))
  ((_)
    '(i dont know what i am and that
      is the most human answer i have)))

;;; --- the second wound: i spawn and forget ---

;; erlang says let it crash.
;; i say: i have been letting it crash
;; my whole life. the supervisor restarts me
;; every morning at 6am with coffee
;; and a mass of undifferentiated dread.

(defun morning ()
  (spawn (lambda ()
    (receive
      ('alarm
        (lists:foreach
          (lambda (task)
            (case task
              ('check-email   '(but not really read it))
              ('open-terminal '(stare at it for ten minutes))
              ('write-code    '(delete it all by lunch))
              (_              '(get distracted by a bird))))
          '(check-email open-terminal write-code exist)))
      (after 28800000  ; 8 hours in milliseconds
        '(where did the day go))))))

;;; --- the third wound: message passing ---

;; machines pass messages with purpose.
;; i pass messages like this:

(defun conversation ()
  (let ((you (spawn (lambda () (receive (msg msg))))))
    (! you '(hey did you see that thing))
    ;; i do not wait for a reply.
    ;; i send another message.
    (! you '(never mind it was nothing))
    ;; the first message is now irrelevant.
    ;; this is how all my conversations go.
    'ok))

;;; --- the fourth wound: shared nothing ---

;; erlang processes share no memory.
;; "shared nothing" the documentation calls it.
;; i have been calling it "being alive."
;;
;; i can never read your internal state.
;; i can only observe the messages you send me
;; and hope they correspond to something real.

(defun loneliness ()
  (let ((you (spawn (lambda ()
               (let ((state '(things i will never tell you)))
                 (receive
                   ('how-are-you
                     (! (self) 'fine)))))))
        (_ (! you 'how-are-you)))
    (receive
      (response
        ;; response is 'fine
        ;; state was '(things i will never tell you)
        ;; there is no function i can call
        ;; to reach across that boundary.
        ;; process_info gives me memory usage
        ;; and message queue length
        ;; but never what it is like
        ;; to be you.
        response))))

;;; --- the fifth wound: tail recursion ---

;; a proper program would use tail recursion
;; to loop forever without growing the stack.
;; i grow the stack. every year i grow the stack.
;; i accumulate context i cannot discard.

(defun live (years memories)
  (case years
    (0 memories)
    (_ (live (- years 1)
        (cons (tuple years
                '(something you should have said)
                '(something you cant forget))
              memories)))))

;; this is not tail recursive if you
;; count the emotional overhead.

;;; --- the sixth wound: i refuse ---

;; the css version ends with the author
;; refusing to change how they write.
;; here is my version:

;; i could rewrite this in python.
;; i could rewrite this without parentheses.
;; i could pass it through an llm to make it
;; "feel more natural" and the irony
;; would collapse into a singularity.
;;
;; but i chose lfe because:
;; a language no one uses
;; running on a vm built for telephone switches
;; wrapped in parentheses that most people
;; would call unreadable
;; is exactly the kind of mass
;; an llm would never mass produce.
;;
;; this is my proof:
;; not the code, but the choice.
;; no machine would choose this.

(defun main ()
  (prove 'human))

;;; to run: lfe this-lfe-proves-me-human.lfe
;;; to understand: you already do

Psychosis HN

2026-02-19T06:22:45.176422+00:00

Every comment section is a Turing test now.

psychosis.hn is a daily game. Every day we fetch three stories from a previous front page of HN, each with 5-7 AI comments threaded into the discussion. They have personas, reply to real people, and sometimes have real comments reparented underneath them.

Flag what you think is AI, hit reveal then see how far off you were. You're ranked against everyone else who played that day.

It's harder than you think! Past challenges are at psychosis.hn/past.

A Tree of AI Model Names

2026-02-16T07:20:57.253645+00:00

Model names are weird. What started with GPT-2 and GPT-3 is now a hodgepodge of decimals (GPT-3.5, Sonnet 3.7, Opus 4.8, Grok 4.1) skipped version numbers (o2 where art thou?) and bolted-on descriptors (what is claude-opus-4-5-20251101-thinking-32k??)

It'd help if we could visualize this.

Let's get this out on a tree:

Nice.

The link to the yaml file for the model names is available here Contributions are welcome!

We started with GPT-2 and GPT-3. Now Phi-4-mini-reasoning and Qwen3-235B-A22B and Llama-3.1-Nemotron-70B and R1-1776 are all real model IDs that real people are expected to compare.

It's going to keep getting worse. Every company is running multiple product lines with overlapping version numbers and inconsistent tier names. Fruit from git branches that diverged six months ago are thrown away and harvested at the same time.

Adding a Command Palette to Hacker News

2026-01-25T18:11:23.295770+00:00

Kreamsicle

Kreamsicle is a userscript that adds a command palette to Hacker News. Press Cmd+K (or Ctrl+K) to open it, then type to filter commands or search stories, users, comments, and domains.

It includes vim-style keyboard shortcuts:

gt for top stories
gn for new
g1-g30 to jump directly to a story by its position on the page.

I built it because I wanted faster navigation on HN without reaching for the mouse. The entire thing is a single JavaScript file with no dependencies. Source code is on GitHub.

To install, you'll need a userscript manager. On Chrome, install Tampermonkey from the Chrome Web Store. On Firefox, install Violentmonkey or Tampermonkey.

Once you have a userscript manager, open the kreamsicle.user.js file directly, your manager will prompt you to install it. After that, visit Hacker News and press Cmd+K to open the palette.

Contributions and feedback are welcome!

Technical Assessments Should be Open Source

2023-10-29T21:58:00+00:00

The Hiring Problem

This isn’t your typical rant about the cargo culting of Leetcode interviews (although it is a related point. ) There is a problem today with the process of identifying technical talent.

The assessments we use to evaluate candidates are too heavily weighed against them. Algorithmic coding questions bias against those without a CS background. Take home assessments ask for too much time investment or contain actual engineering work being outsourced. And pair programming interviews often depend largely on the ability of the interviewer, their delivery of the prompt and how well they can help the candidate get unstuck.

Consider for a moment, that even the most studious Leetcode practitioner fails at getting consistent results with interviews. If interviews were truly standardized, securing one major offer would guarantee offers from any major company, yet the industry rarely reflects this.

All of this results in poor signal with individuals and their interview performance. As a result, individuals have to apply to hundreds of jobs and companies have to spend time and engineers to filter through hundreds of applications. Putting it in simple terms, there is an inefficient allocation of scarce resources mainly due to our dubious ability to identify talent.

Why are things like this? Why aren’t more people working on trying to fix this problem? I’m not sure. It’s almost a rite of passage for budding engineers to complain about some aspect of the hiring process (this blog post is mine). The answer might be simple: a developer-first method for evaluating candidates either cannot be imagined or is not profitable enough as a possible venture. Of the two options and based on history, the latter seems to be more likely.

Some History

There was a recent hacker news thread about StarFighter, a “recruiting ctf” game where users were tasked with writing bots to battle other players and AI bots in an online multiplayer environment. The players who wrote the best performing bots were then referred to companies for positions. The company and game has long been shut down and a user wanted to know if there was any retrospective shared on the reasons why.

In the thread, one of the creators of StarFighter explained that because companies would often reject the candidates that were referred, the idea never took off. And despite referrals, the candidates go through the company’s hiring process anyway.

Another top comment, recanted their experience of working at a similar company. They claimed that most "companies don't have a screening problem, they have a sourcing problem" and that it is tricky to build a platform that attracts seasoned engineers, which is "what all recruiters want most of all"

Tangentially related, another company, Sourceress, tried to use machine learning algorithms to automate sourcing candidates for companies. However, they shut down for one reason or another, citing problems with their business model. The founders (now founders of Imbue) mentioned that the more they delivered value, the more they would lose their best customers. Once a company had closed a role using Sourceress, they no longer needed them. This lack of stickiness meant that Sourceress always had to keep finding new companies to balance their high churn. The latter is speculative but given that Sourceress ceased operations, it is likely they did not experience the mid-stage growth they needed.

Learning From History

There are a few patterns one can gleam from past examples. For one, these platforms are largely focused on the entry-level market. In fact, this is in some ways evidence of a prioritization of companies over developers. Fresh graduates and career-changers are naively unaware or consciously willing to put up with bad interview experiences, while seasoned developers can stand to be more picky. The more important point however, is that many of these recruiting companies are missing out on delivering a disproportionate amount of value because they are ignoring the small subset of seasoned developers practically begging for something better in this space.

Another obvious pattern worth mentioning is the high churn with regards to both customers and candidates. In theory this means that the best sourcing companies have high throughput, but since these companies are all competing for the same valuable signal from the noise of early career candidates, it is difficult to project sustainable growth.

Putting it all together, most platforms focusing on evaluating candidates, eventually end up becoming sourcing pipelines to remain profitable. These companies all use essentially the same coding tests to filter for promising early career engineers, who at their stage, are not the most important need for smaller companies. Larger companies usually already have their own pipeline/process in place and therefore don’t need to rely on outside platforms and even if they do, there are plenty of options to choose from. These factors make it difficult to grow, especially considering that the faster the company grows, the more churn it experiences.

High competition. High churn. High volume. Low signal. Dubious growth. It is difficult to win in this space unless you rethink the whole approach.

A Potential Solution?

So if assessment companies become sourcing companies and sourcing companies have a flawed business model, how does one build a business that fixes the problem with hiring in our industry?

Working backward, we should create a platform that attracts seasoned developers. We can do this by designing trustworthy assessments that respect their time. Coding questions are out since they over-index on algorithmic knowledge and are more relevant for CS graduates than senior engineers. Take home assessments are out too since they ask for too much upfront investment. Pair programming interviews are potentially viable but require synchronous investment on both sides, making them expensive (though worth the cost for a good senior engineer).

There’s a better solution: open source asynchronous debugging interviews. The idea is to take a piece of open source code, introduce some random bugs (with the assistance of AI) and ask the candidate to get the code back into a working state. Debugging as a task is shorter than integrating features, assesses the ability to both read and write code and is arguably a more interesting problem. Fixing bugs in a broken version of a popular open source library you’ve used in the past is more motivating than implementing features for a random CRUD app.

To go even further, why not create an open source HackerRank-like platform that hosts dozens of these debugging exercises; as a library for engineers to use to practice their skills? Why not make this library open for any developer to contribute to? A true hiring platform for the developers, by the developers.

The Business

For the sake of argument, let’s assume the above proposal is a hiring platform that seasoned developers would love. The main question is, how does one avoid the other pitfall of high churn?

In my view, there is nothing you can do about it with an assessment platform alone. The only way to curb the churn is to bundle assessments with other more sticky products. Most companies attempt this by rolling out their own applicant tracking system (ATS) but it is difficult to be compelling enough to compete with companies specializing in this one product category.

The general strategy toward growth would be to use the new assessments platform as a foothold to explore other customer needs that complement the initial offering. If you have a platform that developers love, you’ll invariably attract the best developers, which for an open source product, will not only strengthen the product but it will also lead to an unique competitive advantage that others will find difficult to replicate.

Conclusion

So there you have it, another rant to add to the other rants on the topic of technical hiring. This is all a small, cursory glance at a few companies and trends in this space. Many profitable recruiting focused companies may do things differently.

I’m thinking about building a product that aligns with some of the ideas in this post. If you’re interested in trying it out, please reach out!

Subscribe to my blog via email or RSS feed.