EliasWatson

The term you are looking for is probably "moving the goalposts"

What's far more exciting right now is models like DeepSeek V4 Flash and GLM 5.3 Flash. They have achieved good-enough-intelligence at extremely low prices and fast speeds. I don't have a use for Fable-level intelligence, but I do have uses for Opus-4.8-level intelligence that I can use as much as I want without worrying about the bill.

"What" comments almost always end up falling out of date or even sometimes being slightly incorrect from day one. Incorrect comments lead to confusion and bugs. If a comment says some code does X but the code actually does Y, then you don't know whether the comment is just out of date or if Y is actually a bug. But if a comment explains the intention of the code and the code contradicts that intention, then you know it's likely a bug.

Looking at the byte-array results (best case): scriptc is about 7.5x slower than Node 24, even after Claude tried making some scriptc-specific optimizations. But the executable starts up 12x faster (1.5 ms vs 18.6 ms), uses 72x less memory (2.5 MiB vs 181 MiB), and is a single 370 KB executable with no runtime dependencies.

"On a Claude subscription, Claude Code requests the one-hour TTL automatically. Usage is included in your plan rather than billed per token, so the longer TTL costs you nothing extra and only affects how long your cache stays warm. If you’ve gone over your plan’s usage limit and Claude Code is drawing on usage credits, you are billed for that usage, so Claude Code automatically drops the TTL to five minutes."

- You aren't forced to resolve rebase/merge conflicts immediately. You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later.

- Manipulating commits is super easy (especially with jjui). I reorder commits all the time and move them between branches. Of course you can also squash and split commits, but that's already easy in git. Back when I was using git, I would rarely touch previous commits other than the occasional squash or rename. But now I frequently manipulate the commit history of my branch to make it more readable and organized.

- jj acts as a VCS for your VCS. It has an operation log that is a history of the state of the git repository. So anything that would be destructive in git (e.g. rebase, pull, squash, etc) can be undone.

- Unnamed branches is the feature that has changed my workflow the most. It's hard to explain, so I probably won't do it justice. Basically you stop thinking about things in terms of branches and instead just see it as a graph of commits. While I'm experimenting/exploring how to implement or refactor something, I can create "sub-branches" and switch between them. Similar to stashes, but each "stash" is just a normal branch that can have multiple commits. If I want to test something but I have current changes, I just `jj new`. And if I want to go back, I just make a new commit off of the previous one. And all these commits stick around, so I can go back to something I tried before. Hopefully this made some sense.

Also note that jj is fully compatible with git. I use it at work and all my coworkers use git. So it feels more like a git client than a git replacement.

As for AI search, I do find it extremely useful when I don't know the right words to search for. The LLM will instantly figure out what I'm trying to say.

Prompt: "Draw a SVG self-portrait"

https://claude.site/artifacts/b10ef00f-87f6-4ce7-bc32-80b3ee...

For comparison, this is Sonnet 3.5's attempt: https://claude.site/artifacts/b3a93ba6-9e16-4293-8ad7-398a5e...

To avoid generating useless things like "++--", you could have the optimizer generate instructions that are translated to BrainF operations. So instead of ">>>--", the optimizer would generate "Move +3; Add -2".

1. Render the terrain to a separate buffer

2. Copy the terrain's depth buffer to the main depth buffer

3. Render all non-terrain objects normally

4. Smoothly blend the terrain buffer into the main buffer based on depth

This sounds similar to the method used in BotW, but allows for depth culling since the terrain is rendered first. I'm not familiar enough with Unreal Engine shaders to attempt making it there, but I made a demo in ShaderToy: https://www.shadertoy.com/view/ct3SDN

I probably spend 15 minutes total writing in Obsidian each week. I'm not writing down things that I don't have difficulty remembering or things that are very easy to search for online. Obsidian is a place for me to store info that I might want later but would have difficulty finding/remembering again.