I certainly feel like certain AI coding practices I have leave me with nothing learned in a frustrating way. Sometimes the most effective way to getting what I want is just describing a goal really clearly, and then bashing the AI until it gets there. That bashing process can take a lot of energy and yet I don’t gain useful skills or a “better way” that I would if I was still coding. I generate more training data for BigAI corp, but that’s a slow return cycle.
Not sure if this is the right solution, but I would like to learn/understand/grow more as I pursue reckless efficiency.
Reason #1 to keep writing code by hand is that you don't ever lose that connection between you and the code.
There was an excellent post here on HN that unfortunately went unnoticed. I highly recommend reading it as it exactly points out this problem: understanding.
The post generated a mass of low quality comments (show dead). Plus after about a few paragraphs the site posted degenerates into just calling all AI companies liars with no (in-blog) justification.
I thought the flagging was appropriate after I read it.
Learning is the bottleneck for shipping code. Building the model in your head, feeling out the edge cases and system interactions, and understanding the intricacies. Typing out the code is a small part of the process.
So, if you want to speed things up with LLMs, the bulk of the speed comes from reducing learning.
Imo if you’re reprompting you’re losing. If the agent oneshots the task its good but if it doesn’t manage it on the first try you will get there faster by doing it yourself.
Wait maybe I’m missing something, but are you saying the temporary confusion while people realize they have different versions would be the primary downside? I feel like that’s an acceptable loss. It seems likely that the data in both commits, while one healthy and the other corrupt, will still have to be very different in order to produce the same hash. It’s not like you can reasonably find same-hash commits that just change line19 execute_hack from true to false.
The XZ incident was using binary files checked into git. When you successfully collide this file, one with the trigger, one without the trigger, they get the same git blob-object hash (assuming the chosen-prefix includes the git blob-object header). Because of this, any git tree-object referring to this file is valid for either variant (no further collision needed). This tree-object can itself be part of another tree-object, which can be referred to by a commit-object. Signing this commit with ed25519+sha256 doesn't fix the fact that the tree-object underneath is ambiguous.
People assume sha1 git is cryptographically sound, and a git commit is a secure identifier to reason about source code, whether you and me like it or not.
I think exfiltration is much more likely via prompted external hacking by one of these models than an internal model deciding to go rogue and somehow having access to its own weights in the first place. People do try to exfiltrate model weights indirectly ofc, its called distillation
For anyone that missed it, I believe they’re referring to exfiltrating models by encoding the weights as bits as voltage fluctuations from the relevant data centers. I’m sure they’d take your money but I don’t think that’s what it’s referring to.
Not sure if this is the right solution, but I would like to learn/understand/grow more as I pursue reckless efficiency.
reply