> it's almost impossible to get Gemini to not do "helpful" drive-by-refactors
Just asking "Explain what this service does?" turns into
[No response for three minutes...]
+729 -522
Just asking "Explain what this service does?" turns into
[No response for three minutes...]
+729 -522
"NEVER REMOVE LOGGING OR DEBUGGING INFO. If unsure, bias towards introducing sensible logging."
Or just
"NEVER REMOVE LOGGING OR DEBUGGING INFO."
Because your coworkers definitely are, and we're stack ranked, so it's a race (literally) to the bottom. Just send it...
(All this actually seems to do is push the burden on to their coworkers as reviewers, for what it's worth)
Just because you don't want to gate every change in #1, doesn't mean you're just throwing shit via #2, I'm still reviewing my code as much as before, if not more now, before I consider it ready to be reviewed by others.
But I'm seemingly also one of the few developers who seem to take responsibility of the code I produce, even if AI happens to have coded it.
Right but in practice from what I've seen at work, it does.
You're right: it shouldn't inherently, but that's what I've been seeing.
> But I'm seemingly also one of the few developers who seem to take responsibility of the code I produce, even if AI happens to have coded it.
Pretty much what I'm getting at, yeah
Edit: obviously inside something so it doesn't have access to the rest of my system, but enough access to be useful.
What I don't have time to do is debug obvious slop.
Built-in approval thing sounds like a good idea, but in practice it's unusable. Typical session for me was like:
About to run "sed -n '1,100p' example.cpp", approve?
About to run "sed -n '100,200p' example.cpp", approve?
About to run "sed -n '200,300p' example.cpp", approve?
You want something like codex -a read-only -s on-failure (from memory: look up the exact flags)
People that don't put out slop, mostly.