5 ms·

I think minority do. Imagine, you have been vibe-coding this project for a while and it works kind of fine but you just have to fix a few more bugs and you get

by pllbnk 2mo ago

I think minority do. Imagine, you have been vibe-coding this project for a while and it works kind of fine but you just have to fix a few more bugs and you get something like `node /tmp/claude-1000/-home-user-source-github-user-hn/27b740b1-9a45-47f3-ab99-61e5e3cf779a/scratchpad/hidden-smoke.mjs; echo "exit=$?"`. (I took it from my own agent right now and I don't have any idea what it's doing. Thankfully, it's sandboxed so I don't care _that much_ right now). Is it bad? You can probably go into that mjs file and see what's in there, but so far it's been fine every time, why would it be different this time? Approve! We will see many disastrous bugs and hacks in the coming years with the way most developers are coding right now. If you take time to understand _everything_ that an agent is asking of you, then nearly all those advertised productivity gains would be wiped out.

crooked-v 2mo ago
For me, step 1 of trying to make Claude even vaguely usable is putting in a hook that just tells it 'FUCK YOU, STOP USING PIPES' whenever it tries to chain multiple bash commands.
- lonelyParens 2mo ago
  stealing this
- miki123211 2mo ago
  Keep in mind that this likely destroys context and makes your costs go up considerably. An agent often wants pipes so that it can `show_lots_of_logs | sed ...` and only see the part related to whatever error it's currently trying to debug. Without pipes, it has to take that entire log into the context. An agent without pipes is like a human without the ability to scroll.
  - roywiggins 2mo ago
    I guess ideally you'd want to force it to pipe each step back into the agent/IDE for display (and optionally wait for approval) rather than shoving it into the context. And with some sort of heuristic to skip commands that are piped into sed and similar. or use just use actual files instead of pipes with a permissions dialogue gate on write. That would work already in Claude I think, and with IDE integration it would show each step as it went. Of course buffering every step of a pipeline will have its own side-effects.
  - Fabricio20 2mo ago
    If only the piping wasn't execessively cutting too.. `cat | head -10` -> `cat | head -20` -> `cat | head -40` yeah.. I think at some point we need to start sanitizing our tool outputs so that this just isn't necessary at all, long term fixing the tools (ie: gradle outputs like 500 lines of logs for a ... build succeeded), maybe short term a small model in front would be better than all this cut loop fail. One can wish.
    - StilesCrisis 2mo ago
      My favorite is when Claude runs a slow process piped to tail only the last few lines, and then the result isn't what it expected, so it needs to rerun the whole thing. Agents need a way to discard useless data out of context once it's served its purpose, instead of forcing them to preemptively tail everything.
      - Fabricio20 2mo ago
        This was so bad for me I actually added a tool hook that `time`s the tool calls and adds it as [Execution took: Xm, Ys] at the end of every tool call, it helps a little (claude in particular after two executions tends to switch strategy entirely) but in general the agents still insist on cut/tailing the output rather than just dumping it to a file for example! Now that I think about it, maybe I can have a tool hook that detects those cut/tail exessive piping and just strips them and dumps the full output to a temp file..
      - totetsu 2mo ago
        Could it just set up to do like Command | tee -a activity.log | tail -5 So the context only gets a few lines but everything is still logged?
      - godelski 2mo ago
        My favorite is Claude finding .git/index.lock, asking to remove it, finding out it no longer exists, and then hitting a lock again that it itself created. Poor little robot, stop shooting yourself in the foot.
godelski 2mo ago
> I think minority do Let's be real, the minority of people understand bash. It is a terrible language with tons of footguns[0], albeit a very useful language and still worth learning. The number of ~/.claude/settings.json I've seen with "permissions": { "allow": ["Bash(find *)"]} I've seen is crazy[1]. Hell, most people I talk to think `find` is a tool that is used for searching for files. I mean... it does that... along with arbitrary code execution ¯\_(ツ)_/¯ [0] https://mywiki.wooledge.org/BashPitfalls https://mywiki.wooledge.org/BashPitfalls Edit: [1] Fuck it, here's the lazy search: https://github.com/search?q=%22Bash(find%20*)%22&type=code https://github.com/search?q=%22Bash(find%20*)%22&type=code
- ashwin42 2mo ago
  over 30 years ago bash was magic for us oldies :-D
- doublerabbit 2mo ago
  > It is a terrible language It's not. It only becomes terrible when you misuse for it's original purpose. Microsoft Excel isn't terrible, but the way it gets used makes it terrible.
  - zbentley 2mo ago
    No, it is terrible. The entire reason things like Fish annd PowerShell exist is because bash (and POSIX sh language broadly) are garbage even for their original purpose. Maybe it had to be that way because we didn’t know any better or needed to preserve historical semantics. But that doesn’t make it good. Word splitting. Pipefail. Quoting hell. Scoping. On-error-resume-next by default. Returning values implemented like errno. Perlish cryptic tenseness around basic string manipulation/arrays. Magic global variables that don’t behave like other variables. Argument unpacking and shift. These are bad language features, and people trip over them constantly. Even when they’re only using bash as an interactive shell or a <10 line snippet runner.
    - doublerabbit 2mo ago
      And what would you recommend for a system automation script 20 years ago, when I was 13 and discovered Linux for the first time? Perl comes close and it's one of my favourite languages. Even back then it was archaic. Maybe we can agree on Tcl.
ratelimitsteve 2mo ago
this. the problem with HitL is that there are so many decisions to make that decision fatigue is inevitable. Beyond a certain number of approvals most people are going to switch to an approval process that goes from "carefully consider the need and risk of each command" to "approve unless there's a blatant sudo rm -rf / because the last several hundred times i approved without reading it was fine"

by pllbnk 2mo ago

crooked-v 2mo ago

For me, step 1 of trying to make Claude even vaguely usable is putting in a hook that just tells it 'FUCK YOU, STOP USING PIPES' whenever it tries to chain multiple bash commands.

lonelyParens 2mo ago
stealing this
miki123211 2mo ago
Keep in mind that this likely destroys context and makes your costs go up considerably. An agent often wants pipes so that it can `show_lots_of_logs | sed ...` and only see the part related to whatever error it's currently trying to debug. Without pipes, it has to take that entire log into the context. An agent without pipes is like a human without the ability to scroll.
- roywiggins 2mo ago
  I guess ideally you'd want to force it to pipe each step back into the agent/IDE for display (and optionally wait for approval) rather than shoving it into the context. And with some sort of heuristic to skip commands that are piped into sed and similar. or use just use actual files instead of pipes with a permissions dialogue gate on write. That would work already in Claude I think, and with IDE integration it would show each step as it went. Of course buffering every step of a pipeline will have its own side-effects.
- Fabricio20 2mo ago
  If only the piping wasn't execessively cutting too.. `cat | head -10` -> `cat | head -20` -> `cat | head -40` yeah.. I think at some point we need to start sanitizing our tool outputs so that this just isn't necessary at all, long term fixing the tools (ie: gradle outputs like 500 lines of logs for a ... build succeeded), maybe short term a small model in front would be better than all this cut loop fail. One can wish.
  - StilesCrisis 2mo ago
    My favorite is when Claude runs a slow process piped to tail only the last few lines, and then the result isn't what it expected, so it needs to rerun the whole thing. Agents need a way to discard useless data out of context once it's served its purpose, instead of forcing them to preemptively tail everything.
    - Fabricio20 2mo ago
      This was so bad for me I actually added a tool hook that `time`s the tool calls and adds it as [Execution took: Xm, Ys] at the end of every tool call, it helps a little (claude in particular after two executions tends to switch strategy entirely) but in general the agents still insist on cut/tailing the output rather than just dumping it to a file for example! Now that I think about it, maybe I can have a tool hook that detects those cut/tail exessive piping and just strips them and dumps the full output to a temp file..
    - totetsu 2mo ago
      Could it just set up to do like Command | tee -a activity.log | tail -5 So the context only gets a few lines but everything is still logged?
    - godelski 2mo ago
      My favorite is Claude finding .git/index.lock, asking to remove it, finding out it no longer exists, and then hitting a lock again that it itself created. Poor little robot, stop shooting yourself in the foot.

godelski 2mo ago

> I think minority do Let's be real, the minority of people understand bash. It is a terrible language with tons of footguns[0], albeit a very useful language and still worth learning. The number of ~/.claude/settings.json I've seen with "permissions": { "allow": ["Bash(find *)"]} I've seen is crazy[1]. Hell, most people I talk to think `find` is a tool that is used for searching for files. I mean... it does that... along with arbitrary code execution ¯\_(ツ)_/¯ [0] https://mywiki.wooledge.org/BashPitfalls https://mywiki.wooledge.org/BashPitfalls Edit: [1] Fuck it, here's the lazy search: https://github.com/search?q=%22Bash(find%20*)%22&type=code https://github.com/search?q=%22Bash(find%20*)%22&type=code

ashwin42 2mo ago
over 30 years ago bash was magic for us oldies :-D
doublerabbit 2mo ago
> It is a terrible language It's not. It only becomes terrible when you misuse for it's original purpose. Microsoft Excel isn't terrible, but the way it gets used makes it terrible.
- zbentley 2mo ago
  No, it is terrible. The entire reason things like Fish annd PowerShell exist is because bash (and POSIX sh language broadly) are garbage even for their original purpose. Maybe it had to be that way because we didn’t know any better or needed to preserve historical semantics. But that doesn’t make it good. Word splitting. Pipefail. Quoting hell. Scoping. On-error-resume-next by default. Returning values implemented like errno. Perlish cryptic tenseness around basic string manipulation/arrays. Magic global variables that don’t behave like other variables. Argument unpacking and shift. These are bad language features, and people trip over them constantly. Even when they’re only using bash as an interactive shell or a <10 line snippet runner.
  - doublerabbit 2mo ago
    And what would you recommend for a system automation script 20 years ago, when I was 13 and discovered Linux for the first time? Perl comes close and it's one of my favourite languages. Even back then it was archaic. Maybe we can agree on Tcl.

ratelimitsteve 2mo ago

this. the problem with HitL is that there are so many decisions to make that decision fatigue is inevitable. Beyond a certain number of approvals most people are going to switch to an approval process that goes from "carefully consider the need and risk of each command" to "approve unless there's a blatant sudo rm -rf / because the last several hundred times i approved without reading it was fine"