Comment by rw_panic0_0
4 days ago
how do you trust the code claude wrote? don't you get anxiety "what if there's an error in tui code and it would mess up my git repo"?
4 days ago
how do you trust the code claude wrote? don't you get anxiety "what if there's an error in tui code and it would mess up my git repo"?
I'm not GP, but I have backups, plus I always make sure I've committed and pushed all code I care about to the remote. I do this even when running a prompt in an agent. That goes for running most things actually, not just CC. If claude code runs a git push -f then that could really hurt, but I have enough confidence from working with the agents that they aren't going to do that that it's worth it to me to take the risk in exchange for the convenience of using the agent.
> how do you trust the code claude wrote?
If that's something you're worried about, review the code before running it.
> don't you get anxiety "what if there's an error in tui code and it would mess up my git repo"?
I think you might want to not run untrusted programs in an environment like that, alternatively find a way of start being able to trust the program. Either approaches work, and works best depending on what you're trying to do.
> If that's something you're worried about, review the code before running it.
It takes more, not less, time to thoroughly review code you didn't write.
Depends. If I was the one coming up with the implementation anyways, it's basically just the "coding" part that was replaced with "fingers hitting keyboard" and "agents writing to disk", so reviewing the code certainly is faster, you just have to "check" it, not understand it from scratch.
If we're talking receiving random patches where first you have to understand the context, background and so on, then yeah I agree, it'll take longer time probably than what it took for someone to hammer with their fingers. But again, I'm not sure that's how professionals use LLMs right now, vibe-coding is a small hyped world mostly non-programmers seem to engage in.
4 replies →
>It takes more, not less, time to thoroughly review code you didn't write.
Nope, it takes way less. Else PR reviews would take as long as coding, which they obviously don't.
Writing 1000 lines, figuring out the nuances of the domain, fixing bugs, testing, takes way more time that reading and reviewing the resulting code.
Besides, you can even ask another agent to review it. Different brand of agent even.
It's a git repo. What's sort of mess-ups are you worried about that you can't reflog your way out of (or ask claude code to fix)? It's certainly possible to lose uncommitted work, but once it's been committed, unless claude code goes and deletes .git entirely (which I've had codex do, so you'd better push it somewhere), you can't lose work.
Isn't it this case no matter who wrote the code? How do you ever run anything if you're worried about bugs?
When I write the code myself, I'm not worried that I snuck a `git reset --hard` somewhere.
Do you only run code you wrote yourself?
1 reply →
Different type of creator, different type of bugs. I'd assume a human giving me a way to delete merged branches has probably had the same issue, solved the same problem and understands unspecified context around the problem (e.g protect local data). They probably run it themselves so bugs are most likely to occur in edge cases around none standard use as it works for them.
Ais are giving you what they get from common patterns, parsing documentation etc. Depending what you're asking this might be an entirely novel combination of commands never run before. And depending on the model/prompt it might solve in a way any human would balk at (push main to origin, delete .git, re-clone from origin. Merged local branches are gone!)
It's like the ai art issues - people struggle with relative proportions and tones and making it look real. Ai has no issues with tones, but will add extra fingers or arms etc that humans rarely struggle with. You have to look for different things, and Ai bugs are definitely more dangerous than (most) human bugs.
(Depends a little, it's pretty easy to tell if a human knows what they're talking about. There's for sure humans who could write super destructive code, but other elements usually make you suspicious and worried about the code before that)
> ...a way any human would balk at (push main to origin, delete .git, re-clone from origin. Merged local branches are gone!)
Ahem... But yeah, then I -- or we, I and my team at the time -- (somewhat, at least rudimentarily) learned git.
It makes a difference whether an AI or a human wrote it. AIs make more random, inconsistent errors or omissions that a human wouldn’t make. AIs also don’t dog-feed their code the way human developers of tools usually do, catching more errors or unfit/missing logic that way.
I push my branches daily, so I wouldn't lose that much work. If it breaks then I ask it to fix it.
But I do quickly check the output what it does, and especially the commands it runs. Sometimes it throws all code in a single file, so I ask for 'good architecture with abstractions'.
I see this regularly: "I use GitHub to backup my local repos."
If `gh repo ...` commands get run you can lose everything instantly. You can force push and be left with a single blank commit on both sides. The agent has full control of everything, not just your local data.
Just set up Rclone/restic and get your stuff into a system with some immutability.
Force pushing doesn't actually remove anything from the remote repository, only changes some references for which commits the branches point to. Plus, any forks on github will be completely unaffected. It's not perfect, since Github doesn't seem to offer any history of such reference alterations (a la the reflog), but it's still a valuable offsite backup from a developer's perspective.
1 reply →
I assume that whatever I type can be also flawed and take precautions like backups etc
I don’t even trust myself to not mess up my git repo