Have a list of things you do, go one by one over them. If new task appears add at the loop "gap".

I found that the worst thing is chasing the bunny: Oh wow. This finished. I should chboing oh another agent that's probablboing... - completely unsustainable.

The loop is very similar to old way of things. You just don't pay attention to notifications. Also it's worth grouping loop to minimal że context switching or ease context switching (e.g. task on project a, task on project a+b, task on project b, task on project a+b, etc.)

In order to get to looping part I use self-approval modes for agents. It's slightly uncomfortable but I built own agents with own permission reviewers and they are quite good. These can be used to run agents in the background. And if you do a loop and find agent still spinning - it's a good moment to take a five for yourself.

The deep focus is still there but somewhere else. Usually in coordination and integration.

I'm not saying that optimization isn't valid, what I'm saying is that Quicksort shouldn't be optimized over randomized per run data set.

Quicksort is supposed to be an algorithm that has O(n) to O(n²) performance and O(n log n) being only an average performance case. Test was made on random data coming from different archs (so I doubt it's characteristic would be remotely identical).

Given input size of 50M it means that performance could be between 50M (5e7) up to 2.5e15. That's like performance instability of 8 orders of magnitude.

I'm not sure here if we can't write instead that "Your code is fast if you picked fast case for it" especially since fix of 6 OOM is smaller than algorithm's performance range.

As for transition - I always was somewhat of an UNIX guy, so I replaced Swiper/Occur/Consult with delegating to shell. Kakoune has just enough utilities to create a on-keystroke-updated-buffer so I'm happy with that. In some languages I go as much to create "find functions" special mode - composition with shell is easier than Lisp - I rarely have to read documentation.

For Git I use Jujutsu (so I stopped using Magit long time ago) but Kakoune has a very nice "!commmand" utilities. It's nothing more than a "C-u M-!", but positioning of feature differs.

So the transition is mainly about delegation, not sticking to one application, but instead finding utility that does it and use that instead.

Took a picture (only a single frame) and a 1s movie and threw it toward GPT 5.6 Sol (High):

Frame took 9m30s to decyper and GPT 5.6, it returned: WRITTEN IN GHOST FONT. Weird because I can only see "GHOST FONT" on the demo... but extracted data from image (I saw the highlited one) definitely looks like the "Ghost Font".

--

Video is more amusing, because after 3m GPT 5.6 figured it's motion-defined and asked to run QuickTime. At one moment I got:

> The animation is a motion-defined illusion. I’ve confirmed there’s no readable static OCR layer; I’m decoding its optical-flow field so the letter shapes become explicit.

At 4m it got extracted motion image that was in shape of letters but analyzed for 9 more letters and returned (at 13m36s) "GHOST FONT"

--

So:

    a font...             - FALSE - not a font, but video effect
    ...humans can read... - FALSE - I can't read it from image (but AI can!)
    ...but AI cannot      - FALSE - it can

Edit: https://imgur.com/a/SHlGu4O - work-in-progress images

Finding, reading outdated, writing, updating, grooming documentation is so much more expensive than just throwing LLM on repository (or multiple ones) with a "Go Fetch" quest.

Sure, it's ephemeral, but with assumptions of $50/h earn and assumption that non-naive piece of internal documentation takes 8h of work time and will be read ~100 times that comes in at $4 at read which I think is much more expensive than straight token-API costs (and probably much much more expensive than subsidized subscription costs).

And this is generous. Looking at Jira's stats from my past work, many long documents in small (but specialized) team were read 10-20 times boosting the (assumption-average-costs) to $20-$50 per read.

But wait, there's more (;-))! That's all assuming that knowledge absorption is 100%, what if only 50% of document is relevant. What if it's 25% etc.

In the end today there might as well be no documentation for code and LLMs could extract it raw from code. Raw - because I don't think indexers/RAGs/compressers are useful. I found that spending time on building such is fruitless: Indices can (and will) go stale just as materialized documents and lower context saturation results in more hallucinations in the end.

(There are out-of-code documents which obviously have no other source than then themselves so there's no other around it, though)

For example I've been using Jujutsu exclusively (as a Git frontend) for years and I don't think about it, I just use it. I reflected on this couple of years. It's existence is completely transparent to me.

I, however, don't agree with sibling commenter that it's a function of time spent with X though. As a counter example: Emacs was my go to editor for 15+ years, last 2 years - because reasons - I was switching between Neovim, Helix, Emacs, Kakoune. 6 months ago I settled with Kakoune.

Even with many years in Emacs, I still tweaked and tuned it. There was always something to do, change, understand. I actively thought about Emacs.

With Kakoune after initial "set me up" phase, it's just as transparent as Jujutsu. Sure, I made complex plugins (for searching, highlighting unbalanced parenthesis and even a GUI wrapper called Kakvide). But the difference is that in Emacs the driver was the tool itself and in Kakoune it's always "I wonder if I can do X".

And so I believe that Kakoune is better tool than Emacs as it's more transparent to me even with a big time difference in usage.

Regarding "ChatGPT Work" vs "ChatGPT Codex" - In Work diffs are gone and in new chats there's a popup proposing creating docs or sheets. That's it I believe.

Depending on where you are and how you communicate semantics matter more or less. It's very similar to compiler/transpiler. E.g. TypeScript "Compiler" is called compiler but in fact it's transpiler (it emits other high-level language as a result).

https://tinyurl.com/z9m89k2z

> The grapevine was (...), and all those grapes contained the juice of the same message: Jarred was a stinky manager.

Per exact words these two are different:

    - I think someone is stinky
    - I spoke with people who said someone is stinky 

From "product" perspective there's no difference, but in program-compiler perspective (and e.g. raising bugs about compiler), Fuzilli isn't fuzzing.

Per Wikipedia > (then...) The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks.

As for myself, I wouldn't use term fuzzing for integration testing such the one used by Fuzilla. I always caught it dynamic testing, scenario testing and in bigger cases property based tests. Fuzzing in my mind is reserved to a low-abstraction calls.

Might just be me, though.

The problem however is non-covered success cases. A visualisation of the problem: let's say universe of interaction for DB consists of 10.000 SQL queries. Over 10 years various regressions were found and 2.000 SQL queries are guarded by tests. In reference implementation remaining 8.000 never surfaced over this time and it's unclear if they will work.

And, thinking of how many various SQL queries PostgreSQL users around the world are using vs the test cases covered it's obvious that feature space isn't covered in 1% of the success ratio cases.

Now the new, test-based implementation, has to prove it can handle remaining 99%.

There's some YOLO approach to it, but now Codex has self-approving as well as Claude Code (auto mode). I implemented the same feature by my own on Pi with models through OpenRouter and found results very stable thus I have (as always) limited confidence it can fly.

So (disclaimer: I'm Jujutsu advocate :)) I do "jj new", tell it what to do and then let it run, and check in back later.

If there are things I'm not comfortable (like creating PRs or pushing to repo) I ask it to create Ruby scripts instead named like "__pr.rb" (double underscore files are in my global gitignore). So I can leave it working and then inspect back and edit manually before I run "ruby __pr.rb".

The only thing that's not yet there is tying multiple tmux Claude/Codex session together, but I'm thinking about creating a small Rust app that communicates with Tmux for a preview (or a Ruby script that communicates with my LogSeq directly and manages nodes there :))

It isn't even about legality (because laws usually don't regulate how one can interact with entity they have no legal ties to) but only about litigation risk.

There are no legal or moral obligations requiring valid license. Only interested organizations are brainwashing people into thinking otherwise.

But I don't think licenses are the problem. It's quite obvious. You have 100 works of art (music, graphics, code and text). You want to make money. If you sell it - you lose all the rights. You can give it out but then there's no profit.

The only way to not transfer ownership and give away for free is exact middle ground called the license.

License is not an ownership - It's limited right to use something. Any action anyone does that isn't covered by license (in software) is called "piracy".

Games were never sold. Mediums were sold with attached licenses. And most of the licenses as early as 2000 contained something like:

    "This license is personal to you and may not be assigned, sublicensed, or transferred."

The only difference today is that licenses are enforced better. They can be held on license-server and new user can be denied usage after transfering was detected.

But it doesn't matter if it's downloaded, on disc, or embedded on a spoon.

Don't make people believe they ever owned a game. They didn't. You don't own games as well. Never owned them. You rented them.

The only way to get out of it with winning hand is to side with reputable vendor that didn't cheat people out of licenses. Reason why I side with Steam is because I have my licenses intact even though they have 25 years, I know big corps that just make licenses go poof and pretended in never happened.