Conversation

Jarkko Sakkinen

Edited 1 month ago
"ReadSeek’s anchored reads and edits made targeted changes fast and reduced stale-edit risk."
-OpenCode / GTP-5.6-Terra

opencode-readseek is now live :-)

To get most out of it: turn LSP off.

#opencode #coding #agent
2
0
1

@jarkko curious how the anchoring actually works under the hood. is it hashing the surrounding lines so an edit fails loud if the file moved under it, instead of quietly landing in the wrong spot? that's usually where stale edit bugs hide, not in the diff itself but in what the model assumed was still true.

1
0
0
@eduzsh it hashes the line itself with xxhash32. readseek does also scan the whole source tree and build structural understanding (powered by tree-sitter).

As can be seen for this screenshot OpenCode almost completely disregards its stock edit commands.
1
0
0
@eduzsh What I've also noticed that when the model has a better aim and it can trust better that its edits will hit, it tends to do less that "extra stuff" and more like focused and accurate edits. With line numbers the agent is always in a sort of "slippery slope" as every edit shifts the other lines. Think that editing yourself in a text editor and always being in the wrong line number.
0
0
0

@jarkko Right — line numbers make every edit a moving target, so the model spends half its confidence just relocating itself instead of on the actual change. Anchoring to content (a hash of the line, a unique nearby token) takes that whole class of drift off the table: the edit either finds its anchor or fails loud, it can't quietly land three lines off. Funny how much of the "extra stuff" was really just the model compensating for not trusting its own coordinates.

1
0
1
@eduzsh I think lot of problems around AI should be ripped away from AI researchers, we should put them deep into the cellar and let them work only on training at most ;-)

E.g., inference as an algorithm optimization exercise is more like comparable to a driver design than anything to do with machine learning. For me writing couple of inference engines from scratch has been mostly fun and I'm quickly becoming good at it despite I know almost nothing about training and machine learning. However, I think about e.g. CPU cache hierarchy almost every day (very first time was at high school while writing texture mappers for Pentium with its dual-integer pipeline plus additional simultaneous FPU 1/w op at best).

AI researcher can be considred like hardware designer or compiler writer they just have now overemphasized weight. Often e.g., a C++ compiler and successful programs written in C++ come from different carbon based entities :-)
1
0
0

Jarkko Sakkinen

Edited 25 days ago
@eduzsh I'm going to keep in phase of doing at min two inferences engines annually from scratch but still polish each to as high quality I can. What I want to understand is this:

1. Let's assume we have a SoC.
2. Let's imagine it is capable of doing inference and has special features.
3. The micro-architecture design can make any feasible sacrifices on anything related training post-training (does not have to but I don't give it any weight).

What would be best architecture provide lift up for let's say up 500B parameter models. It's also definitely an area were Nvidia dose not have any tech leadership. Blackwell hardware design is sloppy and dysoptimal if thinking from this "you had one job" angle.

Next model I'm still going to do on Ryze 5 Pro (common laptop CPU from decade ago, Zen 2 architecture) I need to make it scale to GPT-OSS-120B. That's my end goal for this CPU. I'm planning to reach it with 2bit quantization. I have full MoE implementation for 20B version. The magical "model streaming" part was weird. This was discussed either in the context Dwarf Star 4 or Colibii. I mean one always mmaps huge files instead of copying anything and page fault handler brings up the "experts". Still don't get what model streaming is but I'd guess it is just a silly term for the most common activity (never checked this from their implementation).
0
0
0