Krazam is starting to have this effect on me.

Kai Lentit on YouTube has been doing these mock interviews and some of them hit too close to home for me.

[1] - https://www.youtube.com/@programmersarealsohuman5909

Oh my. I just watched "Interview with 90s Computer Nerd" and am laughing so hard at the deadpan line "soundblaster 16 IRQ conflicts are a way of life"

I have been trying https://github.com/hat0uma/csvview.nvim

Its rather neat.

"The developer of the man-db, Colin Watson, decided that there was enough fun and the story won't get forgotten"

Haha! Adequate amount of fun was provided, please resume regular man activities.

"Image API: vim.ui.img"

Oh neat!

Reading the "AGENTS.md" files people write, sometimes, feels like reading "README(2).md"

echo "Read README.md" > AGENTS.md

Now if only it would be respected more often!

Pasting the generally horrible error messages is also quite effective!

Pasting? Give Claude/codex the ability to go fix it itself and have it deal with it directly.

no thank you, there are things I do not want Claude to have rwx on. like my entire f*cking system. I run llms in a docker container with just the folder I'm working in.

If you grant access to the Nix daemon socket but not writing outside the current directory, that's an effective sandbox. It allows evaluating derivations but not actually installing them.

haha technologie is moving so fast ;p

nixos updates tend to be a lot less eventful than others distro, in fact the way it largely prevent system borking when updating, is spiritually freeing.

It seem strange to me that the only way to use an llm is to fit it entirely in volatile memory from the get go.

To render movies we happily wait for the computer to calculate how lights bounce around, for hours even days.

So why not do the same with AIs? Ask big question to big models and get the answer to the universe tomorrow?

If you don’t care about turnaround time you can do that.

Most LLM use cases are about accelerating workflows. If you have to wait all night for a response and then possibly discover that it took the wrong direction, misunderstood your intent, or your prompt was missing some key information then you have to start over.

I don’t let LLMs write my code but I do a lot of codebase exploration, review, and throwaway prototyping. I have hundreds to maybe thousands of turns in the LLM conservation each day. If I had to wait 10X or 100X as long then it wouldn’t be useful. I’d be more productive ignoring a slow LLM and doing it all myself.

> If you have to wait all night for a response and then possibly discover that it took the wrong direction, misunderstood your intent, or your prompt was missing some key information then you have to start over.

If you have to wait overnight because the model is offloading to disk, that's a model you wouldn't have been able to run otherwise without very expensive hardware. You haven't really lost anything. If anything, it's even easier to check on what a model is doing during a partial inference or agentic workload if the inference process is slower.

"If you have to wait all night for a response and then possibly discover that it took the wrong direction, misunderstood your intent, or your prompt was missing some key information then you have to start over."

This exact problem exist for rendering, when you realize that after a long render an object was missing in the background and the costly frame is now useless. To counter that you make multiple "draft" renders first to make sure everything is in the frame and your parameters are properly tuned.

There's definitely use cases for this for long running tasks, like doing research, but for typical use cases they require way too much constant supervision and interaction

"VS Code has Microsoft. Cursor has venture capital."

I would have framed this as a disadvantage ;p

Because it is. Microsoft, Google, Anthropic, etc. all aim to own software production capabilities. It's quite clear.

Using free software and not giving away ones own abilities to create is as important now as it's ever been.