Comment by verdverm
3 hours ago
My read is that GP is eluding to people over estimating how much of a model they need for a task. Perhaps Claude can make more features work in autonomous mode more often, but what are the actual artifacts? What is the quality of the architecture?
Their point may also be (re: wine), that some devs have been conditioned to think a certain token vendor (vineyard) is of superb quality, while if given a blind test (tasting) of the agents on a real world task, they would not notice the difference.
For those of us who use open weights, the difference has narrowed dramatically this year. I've personally been mostly eyes-free developing an NES harness with mostly flash models, bringing in Kimi from time to time, and stepped in a couple times to reframe the approach or architecture. For those of us who (when we) stay in the loop, the difference is near-zero because the tasks we give them are more bite sized.
The difference I have observed is most closely tied to the complexity or context requirements. While I work in a multi-million LoC codebase without any issue for open weights or flash models, my NES project is only 20k lines. The challenging part is the core loop (which needs to blend the emulator FPS with the agent loop) and game state observation (needs to detect byte changes in emulator RAM). The ROM decoding itself has not been so bad, I have actually been quite impressed with the little open weight models on this front. After it extracted the maps, then pulled out even more details, it has written an A* implementation that requires moving between different modes of transportation. (Final Fantasy 1)
> Their point may also be (re: wine), that some devs have been conditioned to think a certain token vendor (vineyard) is of superb quality, while if given a blind test (tasting) of the agents on a real world task, they would not notice the difference.
Yes, this was the core of my point.