Posts

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.

(For extra fun, see the fake Hacker News discussion below)

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.6, 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.

The Greatest Hits

OpenAI

The o2 Problem

Reasoning models go o1 → o3. They skipped o2 because O2 is a European telecom brand.

OpenAI

Version Time Travel

GPT-4.1 was released in April 2025. GPT-5 came in August 2025. A model called 4.1 came after 5. It's a separate product line.

OpenAI

There Is No o4

o4-mini exists. Regular o4 does not. They released the mini without the full version.

Google

The Great Tier Rename

PaLM 2 used animal sizes: Gecko, Otter, Bison, Unicorn. Gemini switched to Nano, Pro, Ultra, Flash. The animals were never spoken of again.

Google

Nano Banana

A model called "nano-banana" appeared on LMArena benchmarks. Sundar Pichai tweeted 🍌🍌🍌. It turned out to be Gemini 2.5 Flash Image

Mistral AI

The -stral Cinematic Universe

Every product must rhyme: Code → Codestral. Vision → Pixtral. Math → Mathstral. Small → Ministral. Reasoning → Magistral.

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!

AI Simulated Hacker News Discussion

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.