You can't improve what you haven't taken apart
Two libraries I built to beat the incumbents, and what taking them apart actually taught me. You cannot see where something fails from the outside — and you don't need to make a hundred mistakes to learn a hundred things.
I believe this strongly enough to organise my time around it: if I want to build something genuinely new, I first have to understand what already exists. Not roughly. Not at the level of the API. From the ground up — the maths it rests on, how it’s actually implemented, and how people really use it once it’s out of the authors’ hands.
The reason is simple. You cannot see where something fails from the outside.
What I did not expect is how often taking something apart tells you that you are the one who’s wrong.
The library that was going to replace OpenCV
DCT-Vision started as a conviction. JPEGs are stored as frequency-domain coefficients, and almost every pipeline decodes them into pixels before doing anything. That decode is pure overhead if the operation you want could have been done on the coefficients directly. So: work in the frequency domain, skip the round-trip, and you have something faster than OpenCV and Pillow at their own game. I was going to use it across our ML pipeline and get better results everywhere.
Then I actually measured it.
It’s genuinely good — for certain operations. For plenty of others it is not better, and for some it’s meaningfully worse. Frequency-domain representation is an advantage for a specific shape of problem and a liability outside it, and no amount of conviction moves that boundary.
There was no way to learn this by reasoning. I had to build the thing and run it against the incumbents on real work before the limits showed up.
And what I came away with wasn’t disappointment, it was calibration. OpenCV is fast because an enormous amount of thought went into it over two decades, and I only know why it’s fast because it’s open source and I could go and look. I set out to beat it and instead I finally understood it. The library still exists and still ships, aimed now at the cases it actually wins.
The one I built during the hype
When Kolmogorov–Arnold Networks landed in April 2024 the excitement was enormous — learnable activation functions on the edges instead of fixed ones at the nodes, and a wave of “MLPs are finished” commentary.
I built LibKAN two weeks later, because the only way I was going to have an opinion was to implement it.
What I found is that it works well at small parameter counts and degrades badly as you scale — training time grows far faster than an equivalent MLP’s, and it gets unstable in larger networks. That isn’t a controversial finding; the literature landed in the same place, and the original paper was upfront that its examples were small-scale and that scaling was future work. But there is a difference between reading that sentence and watching your own training runs crawl.
I don’t see much about KANs anymore. Possibly I stopped following. Either way I know what the idea is, what it’s for, and where it stops — which is worth having, and cost me a fortnight.
This is the part I’d argue for generally: know what’s been tried before you commit. It’s the same instinct as market research before starting a business. You would not build a product without checking what’s already out there. Building a technique deserves the same courtesy.
Why implementing beats reading
Attention Is All You Need is a clear paper with a clean diagram. Read it and you can narrate the architecture confidently — this feeds into that, this comes after this. It feels like understanding.
Then you write it out by hand and the real questions start. Why that scaling factor before the softmax, and what breaks without it? Why does the residual connection attach at that exact point rather than one layer over? Why is normalisation here and not there?
Every one of those numbers is load-bearing and the paper does not stop to justify each one, because papers assume a reader who will work it out. Doing it by hand is what turns the diagram into knowledge.
And then the ground moves
In 2023 I was working through an NLP book and Christopher Manning’s course, and the material was stemming, lemmatisation, stop-word removal, bag-of-words, TF-IDF. That was the pipeline.
Almost none of it appears in how a frontier LLM is trained today. It’s subword tokenisation into learned embeddings, and the model works the rest out from raw text. The classical techniques still have a life in search and traditional ML, but as the front door to language modelling they’re gone.
The architecture moved too. The transformer in the original paper is an encoder–decoder; every frontier model now is decoder-only. Normalisation moved from after each sub-layer to before it, because post-norm was unstable to train deep and needed learning-rate warm-up tricks to survive. Small-looking change, different training dynamics entirely.
So: was learning the 2023 version wasted?
No — and this is the whole argument. Knowing the pipeline that got replaced is how you understand what the replacement is for. You can’t evaluate a change you don’t have the before-picture of. But it does mean the reading never stops, because the thing you understood two years ago has quietly become history.
Respect, specifically
We’re at a strange moment. You can have a working prototype of almost anything in an afternoon, and I use those tools daily and I’m glad they exist.
Which makes me want to say this plainly: the people who built the systems we all stand on did it without any of it. No model to ask. No answer waiting online for their particular problem, because their problem had not happened to anybody yet. They were serving enormous traffic on hardware that would embarrass a phone, and they got the abstractions right often enough that we’re still using them.
Take one of those systems apart and you stop being casual about it.
The actual payoff
Here’s why I keep doing this, and it isn’t diligence.
I don’t need to make a hundred mistakes to learn a hundred things. I can read ninety-nine of them — in a paper, in someone’s post-mortem, in a source file — and spend my one experiment on the thing nobody has tried yet.
That’s the trade. Reading is cheap and slow. Mistakes are expensive and fast. The point of taking things apart is not thoroughness for its own sake; it’s buying ninety-nine lessons at the price of one.