Niklas Gruhn

Lean explained with TypeScript

Niklas Gruhn — Sat, 29 Aug 2026 00:00:00 +0000

Lean is a programming language that lets you prove mathematical propositions. The Lean verifier automatically checks that these proofs are correct. This is the most formal and most bulletproof way to write proofs in mathematics. It's also incredibly tedious. Basic statements like a+b=b+a are not accepted without proof.

Lean has gained hugely in popularity with the advent of LLMs. LLMs write tons of code quickly but verification is laborious. Lean automates verification but the code is laborious to write. A match made in heaven!

This is not just useful for mathematicians. Lean is a general purpose programming language. For regular software it would also be nice to have more and stronger guarantees like:

certain error states are unreachable
database transactions are ACID compliant
bank accounts can't spend money twice
...

What's mind blowing is that the Lean verifier is "just" a type checker. Propositions are expressed as types and proofs are written as values (aka terms). To prove a type/proposition is to write down a value of that type. The type checker simply checks (as usual): is this value/proof actually of that type/proposition. If yes, the proof is correct.

This might sound surprising. Usually it's not hard to find any value that matches a type. If anything, there are too many possible values and the sole reason we use types is to restrict the options.

Nevertheless, the Lean type system is not too different from a "normal one" like in TypeScript. Some fundamentals are strikingly similar. In fact, we can even prove simple propositions right in TypeScript. In the simplest form, it looks like this:

const proposition_name: PropositionAsType = proofAsValue

With the explicit type annotation, the type checker is forced to check whether proofAsValue is of type PropositionAsType. If yes, the proof is correct. Otherwise we get a type error. The problem with constants is we can't use type variables. We will need those. So we wrap all proofs with a dummy function:

function proposition_name<P,Q>(): PropositionAsType<P,Q> {
  return proofAsValue
}

Note: functions like this are not meant to be called. It's pure type trickery that becomes useless at runtime.

What are propositions?

Famous examples like Fermat's Last Theorem and the Riemann hypothesis come to mind. These are expressible in Lean but not in TypeScript. We have to start more basic: Any logical statement is a proposition. The most basic are true and false and any expression that "returns" a boolean can also be considered a proposition. So things built with &&, ||, ===, <=, isUpperCase(...), etc. But those are tools on the value-level. Propositions are written as types. We need all of that on the type-level.

Propositions as types

false

The proposition false is wrong! So it must not have a proof. In TypeScript, the corresponding type is never. Why? never is the empty type. By definition there is no value/proof you can return here:

function false_is_true(): never {
  return ???
}

Hence never has no proof. Well, TypeScript has escape hatches. Technically you can write:

function false_is_true(): never {
  return "obviously not never" as never
}

But that deliberately overrides the type system. It's like assuming 0=1. If you do that, all bets are off.

So never is the type-level version of false. To make it explicit, let's use a type alias from now on:

type False = never

true

true must have a proof. So there must be a value of that type. It doesn't really matter what that value is. We can define it as a type with a single dummy value:

type True = "dummy"

Here is the proof:

function true_is_true(): True {
  return "dummy"
}

AND / OR

Here is how to define boolean AND/OR on the type-level:

type And<P, Q> = { left: P, right: Q }
type Or<P, Q>  = { left: P } | { right: Q }

As a first example let's prove Or<True, False>. As you know true || false is true, so this proposition should have a proof:

function true_or_false(): Or<True, False> {
  return { left: "dummy" }
}

On the other hand true && false is false, so this can't have a proof. You can try but you get stuck:

function true_and_false(): And<True, False> {
  return { left: "dummy", right: ??? }
}

Go through the propositions below. Think about the analogous value-level expression. If it's true, it will have a proof. Try to write it down.

And<True, True>
And<False, True>
And<False, False>
Or<True, True>
Or<False, True>
Or<False, False>

PS: You can also write And using the intersection type operator (&). The resulting type is the same but now notice how similar the syntax is to value-level AND (p && q) and OR (p || q):

type And<P, Q> = { left: P } & { right: Q } // p && q
type Or<P, Q>  = { left: P } | { right: Q } // p || q

Implication

Implications (if P then Q) are everywhere. Not just in mathematical propositions:

if there is a network connection then messages are processed
if the screen is wide enough then all toolbar buttons are visible
if a DB transaction is applied then all contained operations are applied

In math/logic the standard symbol is =>. To use implications on the type-level, we can use arrow functions. The syntax matches again!

(p: P) => Q // if P then Q

Remember that every value is a proof. This implication gets a proof of P as argument and must return a proof of Q. To prove the implication itself is to show that such a function exists. Here is a simple example:

function P_implies_P_or_Q<P,Q>(): (p: P) => Or<P, Q> {
  return proofOfP => ({ left: proofOfP })
}

Here is something unintuitive. I think everyone will believe that false implies false. The proof works but wait a minute...

function false_implies_false(): (p: False) => False {
  return proofOfFalse => proofOfFalse
}

Didn't we say there is no value of type False? The proof receives a value of False as input and then returns it. Why is that even allowed? It's kinda like saying: If you give me a unicorn, I give you a unicorn back. Unicorns don't exist, so I know step 1 is never going to happen, but there is nothing wrong with step 1 implying step 2.

Here is the first proposition with a well known name:

type ModusPonens<P, Q> = (p_pq: And<P, (p: P) => Q>) => Q

In English: IF P is true AND P implies Q, then Q is also true. This was very confusing to me at first. Especially the nested implications. What does it even mean for an implication to imply something? But once you write down the proof and pick concrete types, it becomes completely obvious what's going on. This is just function application!

Instead of P/Q, think string/number. Then all this proposition is saying is: If you give me a string and something that turns a string into a number (length, word count, ...), then I can return a number.

Proof:

function modus_ponens<P, Q>(): ModusPonens<P, Q> {
  return ({ left: p, right: pq }) => pq(p)
}

Negation

Negation (written !p on value-level) is the least obvious one. You might expect some definition using conditional types:

// first try
type Not<P> = [P] extends [False] ? True : False

The problem is the condition can only be evaluated when P is a concrete type. That's not always the case. For example, try proving p implies !!p:

function P_implies_not_not_P<P>(): (p: P) => Not<Not<P>> {
  return p => ???
}

There is nothing you can write there. Not because the proposition is false but because the type checker doesn't even know what value to expect. It can't evaluate Not<Not<P>> to a concrete type.

We can make it work by defining Not differently. Using an implication:

type Not<P> = (p: P) => False

You may know that an implication p => q is equivalent to !p || q. If you replace q with false you get !p || false which is the same as !p. So it makes sense why you can define !p as p => false.

Now let's see the proof:

function P_implies_not_not_P<P>(): (p: P) => Not<Not<P>> {
  return p => not_p => not_p(p)
}

If you inline the Nots it's easier to see why it works:

(p: P) => (not_p: (p2: P) => False) => False

Equivalence

Equivalence is when both directions of an implication hold. So if both P implies Q and Q implies P:

type Equiv<P, Q> = And<(p: P) => Q, (q: Q) => P>

With that we can state and prove this famous law about booleans:

!(p || q) === (!p && !q)

This is the most verbose proof I'm going to show. I'm just going to leave it here. If you want to understand it, it's best you try and write it yourself. It's fun but it also gives you a glimpse how tedious Lean proofs can be.

function de_morgan<P, Q>(): Equiv<Not<Or<P, Q>>, And<Not<P>, Not<Q>>> {
  return {
    // !(p || q) => !p && !q
    left: not_p_or_q => ({ 
      left: p => not_p_or_q({ left: p }),
      right: q => not_p_or_q({ right: q }),
    }), 

    // !p && !q => !(p || q)
    right: not_p_and_not_q => p_or_q => {
      if ('left' in p_or_q) {
        return not_p_and_not_q.left(p_or_q.left)
      } else {
        return not_p_and_not_q.right(p_or_q.right)
      }
    },
  }
}

Conclusion

Learning to write proofs this way was very insightful to me. Writing traditional pen-and-paper proofs is a bit of an art. Obvious steps are often skipped, where "obvious" strongly depends on the author's judgement, implied knowledge, and the assumed audience. Writing proofs in Lean (or TypeScript) shows how incredibly mechanical the process can be.

The rabbit hole goes much deeper. But the core idea to take home is:

propositions = types
proofs = values
verifier = type checker

A test for AI consciousness

Niklas Gruhn — Sun, 16 Aug 2026 00:00:00 +0000

Whether AI is, or ever will be, conscious is hotly contested. Simply asking the models can never resolve the question definitively. For whatever reason, they may pretend to be conscious when they actually aren't, or pretend not to be when they actually are. Claude, for that matter, is explicitly instructed to dodge the question. Some people believe the answer is fundamentally unknowable. But I want to give it a shot and propose a test for AI consciousness¹.

A philosophical zombie is a creature that seems to act and behave like a conscious being but lacks conscious experience². AI models may be philosophical zombies.

Philosophical zombie model

According to epiphenomenalism, consciousness is purely passive. Like a person watching a movie. All sensory input from the outside world and all internal thoughts and feelings are playing out on screen. The viewer is so immersed that they have the illusion of control. In this picture, no information flows back from consciousness into the "physical world". Hence, from the outside there is no way to distinguish a conscious being from a philosophical zombie.

Epiphenomenalist model

But this picture can't be true. At least in one way consciousness has a measurable effect on the world: we talk about it. Talking is a physical process orchestrated by the excitement of neurons in the brain. But what is initiating this process? Where is the initial spark coming from? It might come from a "physical stimulus": a book, a conversation, a memory of a conversation. That's why philosophical zombies can surely engage in a dialog about consciousness. But absent any physical stimulus, the spark must come from consciousness itself. At least sometimes consciousness must feed directly into the excitement of neurons and compel us to talk about it. A lone philosophical zombie in a population of conscious beings might fly under the radar, but a population purely of philosophical zombies would look different than ours. They could never have initiated the discussion about consciousness and spilled all that ink.

The question is how to eliminate the confounding factor of physical stimuli. We could train a model on a dataset where any reference to consciousness is thoroughly removed. Then explore whether the model can bootstrap a discussion about consciousness.

How practical this test is, is another question. Scrubbing the dataset is non-trivial. The topic is discussed all over the place in philosophy, religion, psychology, medicine, fiction, etc. If that's done successfully, the model won't have the very language to talk about consciousness. It would have to invent its own. Also, the test can arguably only confirm existence of consciousness but not rule it out. If the model never declares to be conscious, the reason could be unrelated.

Nevertheless, I think this is a decent case that the question is not fundamentally unresolvable.

Footnotes

Specifically as in the hard problem of consciousness.
Not the usual definition but I need a term that: also covers AI models and is not by definition indistinguishable from the conscious counterpart.

NP-overrated

Niklas Gruhn — Thu, 13 Aug 2026 00:00:00 +0000

If you learned about NP-hard problems in university, your takeaway was probably this:

NP-hard problems are solvable in theory but it's hopelessly expensive in practice. It's basically proven that no good algorithms exist.

At least that's what I took away. And almost everyone I've talked to. And many people online. I keep seeing "No you can't do it. It's NP-hard. Blah blah" discussions. The myth is pervasive but these problems are not intractable.

At the time, my professor closed the final lecture with dramatic words (I'm paraphrasing slightly):

And now you've learned that almost all interesting problems are undecidable and of the remaining ones, almost all are NP-hard. For the project of computer science, that puts the final nail in the coffin.

Sheesh. Not sure if everyone got such a dire framing but that would explain.

The theory is not wrong, but in practice it's often irrelevant. Sure, any algorithm you can come up with will blow up on some inputs. But you might get a fast solution on 99.9% of inputs. Or 100% of the remotely relevant inputs. The theory does not rule that out.

In theory, there is no difference between theory and practice. But in practice, there is.

-- Benjamin Brewster

A few prominent NP-hard problems:

Dependency resolution (in package managers)
Type checking (not all type systems)
Scheduling
Traveling Salesman
Boolean Satisfiability (SAT)

For (1) and (2), the worst-case just doesn't occur. I mean, installing packages and type checking can surely be slow. But, at least in my career, I've never seen a galactic blow-up.

(3) and (4) are technically optimization problems. Everyone knows you can tackle those with heuristics, but you don't always have to sacrifice optimality. We absolutely have tools that can often find provably optimal solutions in reasonable time. There's no magic. No quantum computers. Just thinking harder and coming up with better algorithms. And that's what people have done. In fact, algorithmic speedup has outpaced hardware gains in the last decades. Taken together, this paper cites a 450-billion-fold speedup between 1991 and 2015.

Last but not least: even (5), the archetype of NP-hard problems, is routinely solved at scale. Amazon is solving a billion SMT problems a day. SMT is an even harder version of SAT. The SAT algorithms have gotten so good, it's now considered the easy part.

But what if you run into the worst-case? You don't have to wait for the heat-death of the universe. An HTTP request also doesn't come back sometimes. Add a timeout, show an error message, ... you know the drill.

Don't be a meat proxy

Niklas Gruhn — Mon, 03 Aug 2026 00:00:00 +0000

Too often I ask a question in Slack or leave feedback under a merge/pull request or argue with friends in a WhatsApp group and get back:

Claude said: [giant response verbatim]

Please don't do this. I mean, I've done this. But I've been on the receiving end too many times now. This is not adding value. I can talk to Claude myself. It's going to be faster and I get to control the context. I don't need a meat proxy in between.

Reading AI output is extra effort. It's verbose, frequently contains all too plausible nonsense, and is increasingly jargon dense. I recently got this sentence from Claude:

NATS control-plane events: stream leader election / R3 quorum re-form during pod churn.

Jesus. I had to lookup almost every word to make sense of this.

By all means, prompt AI. But don't just relay the output. Read it, understand it, validate it, and then write a response in your own words (a decent certificate that you've done the prior steps). Making that effort is value you can add.

Take code review in particular. Shipping some code can be done with close to zero effort now: Copy/paste the ticket description into Claude Code. Don't look at the code or read what Claude has written. If there's any feedback from reviewers, copy/paste that into Claude Code as well. If necessary, iterate.

That works. But who has done the implementation? The reviewers did, using Claude Code, and you as a meat proxy.

What happens at 60% unemployment rate?

Niklas Gruhn — Sun, 22 Feb 2026 00:00:00 +0000

In the US, white-collar work has grown from 17.6% of total employment in 1900 to ~60% in 2002. Presumably, that share has grown even more and other first world countries have seen a similar trajectory.

Let's assume AI makes good on its promise to eliminate a significant fraction of these jobs (and doesn't go rogue). The remaining 40% of plumbers, chefs, electricians may not be replaceable for the foreseeable future, but they're not going to have a better time if a giant chunk of their customer base evaporates. Also, whatever tasks remain that only humans can complete; figuring out how to automate those is itself an intellectual task. At that point, AI can probably get to work on that.

I have no clue about the timeline. Let it be 1 year, 10 years, 100 years. Either way, what happens in the limit? When humans become fundamentally useless? What kind of economy is that? Is that a boom or recession? Where does the output of all that insane productivity go if consumers have no purchasing power? Who's going to buy Teslas and iPhones and shop on Amazon? Even advertisers and B2B companies are ultimately downstream of consumers. Why would I buy ad space from Google or Meta if no one can afford the thing I'm trying to sell? It seems the big tech end game is to erase their own market.

Everyone is saying we need UBI to prevent a social calamity. Never mind that, I think without UBI the market economy completely stops making sense.

I'm not particularly optimistic that UBI is going to happen. Governments are slow and the financial burden is high. Even if it happens, recipients have zero negotiating leverage to maintain it long term.

Are we doomed to descend into autocracy? I think that also doesn't make sense. Autocracies extract value from the many to benefit the few. But what's the point if there is no value to extract? Might as well be the dictator of an ant colony.

Is everyone just going to starve except a handful of super rich hiding in their luxury bunkers? That would be such an absurd outcome, given that we can feed everyone right now without AGI (kind of).

So what the hell is going to happen? I have no answers. But I don't even see anyone really asking the question.