In fact, vertices seem to disappear during the *start* of the animation (when we want higher density to counter the distortion), just to reappear later on when we no longer really need them.

What's weird is that upon closer inspection, the subdivision of the mesh does change during the animation, just not in a way that's helpful.

My working hypothesis is that in order to achieve an elastic effect, the bottom vertices of the mesh are animated faster towards the target rect, while the ones towards the top lag behind. This would explain the stretch at the bottom.

All others are either static, or stagnant enough to sneak into the training set from one iteration to the next.
x.com/andrewprife...

Instead of text-davinci-003 generating JSON for individual tool calls editing the document (which it was really bad at), I had it generate code that called these tools and the results were crazy. One of my biggest career regrets is that we didn't end up using this even though we had the solution.

Insane in hindsight that this 3 year old commit of a bounding box tool not only uses a naming convention that only appeared 1-2 years later, but looks almost exactly like @vercel AI SDK tool definitions.

It saves me an enormous amount of time and brain cycles, but what it doesn't save me from is having to do the thinking.

I feel like the folks who claim it does, are the same ones who previously thought visual programming would be the death of CS degrees.

Not because it is dumb, but because it doesn't have a clue what I need without specific instructions. Whether I'm reviewing code it writes, or telling it what to do, I still have to do all the work aside from typing out the code.

Say, if you're a small startup and you'd normally pay 10k a month to OpenAI (assuming a couple ten thousand users and normal usage), now you're also paying 500 / month to OpenRouter, which is larger than your Slack and Cursor bills combined.