
UX Engineer @Microsoft | creator of those easing functions | building next-gen motion & graphics tools | formal verification, Lean, Dafny, Bend2
Brooklyn, NY
Joined October 2008
- Tweets26.5K
- Following2.4K
- Followers10.4K
- Likes81.5K
Pinned Tweet
I'm building a motion curve editor beyond your wildest fantasies.
I've been head down solving new easing equations for the last 13 months.
I promise nothing less than a quantum leap in easing technology.
The state machine renaissance
There's a renaissance happening for state machines in software development.
A prompt circulating on X this week tells coding agents to find all the implicit state machines lurking in a codebase. It's like a magic spell that brings submerged structures to the surface.
Suddenly, scattered booleans, conditional branches, and ad hoc state transitions are revealed as parts of state machines.
Once you've identified them, you can model them explicitly, constrain their transitions and eliminate entire classes of bugs.
For JavaScript and web development, XState is an excellent tool for wrangling your state into a disciplined and diagrammable structure.
Those aren't mountains, they're waves
Behind the current wave of state machines, a much bigger one is forming: formal verification.
State machines can make invalid states impossible to represent. But formal verification goes further, using mathematics and logic to prove that your code obey concrete laws.
Imagine proving that an entire class of bugs is mathematically impossible, for every valid input.
For decades, formal verification has loomed like an insurmountable mountain for ordinary developers. But with AI agents helping us write specifications and construct proofs, that mountain is becoming a wave of mathematical power we can harness.
1
3
256
Paradox: the faster things get, the slower they feel.
Crossing the Atlantic used to take weeks; now an eight-hour flight feels like an eternity.
This is the "hedonic treadmill": as we adapt to improvements, our expectations keep rising.
Patience, young hobbits. 🌲
LLMs are far too slow. It feels like the early days of the internet when you'd wait a full minute to download a megabyte of data.
3
352
Given Uncle Bob's love for automated testing and now AI, I'm waiting for him to fall in love with formal verification and start raving about it.
In 2019, Bob said "types are math" and "tests are science," declaring formal verification of behavior "intractable."
Certainly, writing formal laws and proofs for application behavior was impractical for most developers in 2019. But NASA had already been using formal verification for decades.
Now formal verification is becoming accessible to ordinary developers, as agents help write laws and proofs. And unlike tests, which check specific inputs, mathematical proofs can establish behavioral laws for all valid inputs.
It's the kind of superpowered testing Uncle Bob would love. I'm curious to see if he'll taste the sweet ambrosia of mathematical certainty.
Replying to @christianhujer
Correct. Types are formal, tests are empirical. Types are math, tests are science.
Formal verification of structure through types is tractable. Formal verification of behavior is not.
Tests are the only tractable means of verifying behavior.
8
838
Laws and Proofs vs. Unit Tests
A unit test is an example: it checks that your code gives the right output for a specific input.
But how do you prove that your code works for every valid input, like any number or any string? The parameter space could be effectively infinite.
One way to tackle this problem is by spraying the space with thousands of test cases, like thousands of torpedoes in a game of Battleship. ❗🛳️❗
This helps, but it increases your test-run time, and coverage is still incomplete.
Formal verification is a more radical approach: define mathematical laws that describe the required behavior. Then you (well, your agent) can construct rigorous mathematical proofs that your implementation obeys those laws for all valid inputs.
With sufficiently comprehensive laws and sound proofs, you can rule out entire classes of bugs by logical necessity.
The compiler verifies these proofs mathematically, without running your code. No need to fire 1000s of torpedoes when you can prove where the ships are. 🚀
5
595
After 10 days of using Bend2, I am thoroughly hooked.
Migrating core TypeScript logic to Bend's functional style, with laws and proofs, feels very satisfying.
Bend2 is a language designed for high performance at both ends:
- Verify laws fast
- Execute code fast
Bend can easily parallelize across CPU or GPU cores, because of deliberate restrictions.
teapaw.org/VictorTaelin/status/21…
I love leveling up in automated testing.
This year I've climbed up from examples to laws.
A unit test is an example. It's like firing one dot in Battleship.
But prove a law, and you sweep the field in a huge swathe of truth.
7
1,435
For overstretch, you can ask your agent for soft clamping with elastic saturation.
Design Engineering Tip:
Try giving elastic drags a limit.
Most rubber-band effects are linear, so the further you pull, the further it stretches. iOS uses a curve instead: it resists more the further you go and never passes a maximum.
const rubberBand = (x, d, c = 0.55) =>
(1 - 1 / ((x * c) / d + 1)) * d
The Real Mathematicians are vexed, terribly vexed that OpenAI did proofs without their permission.
It's math pandemonium!
ahmath.org/statements
2
5
542
It's official! Speed up dev by 6%, for the low, low cost of throwing away your regression suite.
ok it's official... AI-written unit tests and integration tests are empirically proven to be unhelpful. you should tell your agents to stop writing tests by themselves
on the deepswe eval set, banning sonnet 5.5 high from writing any tests actually resulted in slightly higher success rate (non stat-sig), with less time and token spent (stat-sig). this is pretty hard empirical evidence
across the tests that were written by the "tests allowed" baseline arm, 65% of them were unit tests, 35% were integration tests, neither bucket resulted in any improvement compared to not writing any tests at all
i also picked a random sample of 44 tasks subset where i completely disabled executing even existing tests - it also did not affect success rate at all
i spot checked many tests written in the baseline arm, and my intuition is that most tests are simply a repetition of the implementation
agent-written tests do not add any value because both the implementation and the tests were simply the agent's interpretation of our intent. the tests aren't any more accurate than the implementation itself
i suspect we can still extract some value from unit tests and integration tests if we describe them ourselves when we believe we can articulate our intent better through test cases than through requirements. but i have not proven this yet
also worth noting, during deepswe eval the agent wrote almost no e2e tests (only 17, compared to 3000+ unit/integration tests written). so this analysis does not prove nor disprove the value of e2e tests - i will do another eval specifically for that
"A React hook census found 6,900 hooks re-rendering on every keystroke."
It's like watching Hoarders: how do people let it get that bad?
We made claude.ai 3x faster in two weeks.
Here’s how we use Claude to measure, debug and improve performance. Prompts and methods included.
claude.dev/blog/how-we-made-…
3
489
#Jev AI is a non-verbal savant.
No circuits wasted on social skills.
Just 100% focus: melt that Scantron.
@typesafeai
1
3
584
Happy Penner Easing Anniversary!
25 years ago today, I published my first easing functions.
I was 23 years old, struggling to pay rent & student loans. I had no math or computer science degree. But I had Flash 5 & its amazing community.
I felt a compulsion to ease my animations with code. There was one exponential ease-out script everyone used, but it started to bore me. I needed so much more.
I wanted to wield ultimate easing power: not just ease-out, but ease-in and in-out! But which math incantations would grant me that power? There was no textbook for this.
What I spend the most time reviewing or manually working through are my custom DSLs/APIs and data formats.
I'm less concerned about the internals of a pure function (which has unit tests or property-based tests) than its interface with the larger system. Functions need to be carved into good shapes for input and output.
The debate about reading code is so infuriating.
Two things can be true at the same time:
You aren't doing enough automated review
You should still do human review
3
464
Smooth interruptibility improves interactive animations with state transitions.
Smooth Level 1: Preserve position while interrupting
Smooth Level 2: Preserve velocity
Smooth Level 3: Preserve acceleration
Level 2 is significantly harder than 1. It causes people to ditch easing functions for springs or other simulations, which have pros and cons.
Level 3 is even harder, w/diminishing returns, so it's rarely done for UI.
Math term: continuity of C0, C1, C2
Every time I test an interaction animation, I just click on it like crazy to see if I can break it.
And it breaks a lot of times or it just feels too slow or laggy.
One thing that helps a lot is to let the next animation continue from the current state instead of forcing it back to a fixed start value.
For example, when the current item is still animating and I click again, the leave animation just starts from wherever the item currently is.
And the animation should be snappy, so a bit faster.
2
3
612
For sure, but baby steps: first auto-normalize text like punctuation in phone numbers, etc.
Don't red-error bark at me to make these trivial, pattern-based edits.
Y'all need to stop SLACKING on your photo upload UIs
If I upload a HEIC, AVIF or literally any format. JUST CONVERT IT IN THE BROWSER
It's the image is too large for you, RESIZE IT IN THE BROWSER
If I drag and image anywhere in your application HANDLE IT INSTEAD OF REFRESHING THE PAGE
We have the technology! Unacceptable
1
345
It's called "Manufactured Contrast."
Instead of saying X,
LLMs invent a Y that means nothing,
just to contrast X with Y.
Tell your AGENTS.md:
"No manufactured contrast."
claude always uses these phrases or metaphors that are computationally taxing. "you're half right in a way that matters" ok great now i need to parse out which half im right about, and why that matters. why not just "one part of this is right." and "let me sharpen the decision slightly rather than just endorsing it." WHY NOT JUST "here's some extra advice" or something?? why the metaphors? why the god awful communicative devices that add nothing and make me think more?? the output is already way too long all the time, even worse you have to parse out its god awful verbosity that was programmed by some DORKS who are extremely disconnected from everything around them. the ones who made it this way are the nerds who don't use their bodies so they are DISCONNECTED from the symbols of language so badly they think this is okay. THINK AGAIN
2
349
The book is Extreme Programming Explained (2004).
TDD, pair programming, continuous integration, refactoring:
It's more applicable today than ever before.
I've been following @kentbeck's methodology for 20 years. I just do it a lot faster now.
amzn.to/45pXnP4
Extreme Programming Explained: Embrace Change
Extreme Programming Explained: Embrace Change
amazon.comwe’re in uncharted territory. there is no book that teaches you how to build software in 2026. everyone is learning from first principles
1
5
393
























