[TacticalCoder]

> I still don’t understand how people are getting value out of AI coders. I’ve tried really hard and the commits produced are just a step up from garbage.

These aren't mutually exclusive. I pay for ChatGPT. It sucks fat balls at coding but it's okay to do things like "Bash: ensure exactly two params are passed, 1st one is a dir, 2nd is a file". This is slightly faster than writing it myself so it's worth $20 a month but that's about it.

"from now on no explanation, code only" also helps.

Does is still stuck? Definitely. But it's one more tool. I can understand why one wouldn't even bother though.

[Lerc]

>"from now on no explanation, code only" also helps.

Does it? Without using a model with a internal monologue interface, the explanation is the only way for the model to do any long form thinking. I would have thought that requesting an explanation of the code it is about to write would be better. An explanation after it has written the code would be counterproductive, because it would be flavouring the explanation to what it actually wrote instead of what it was wanting to achieve.

[godelski]

At that point, why not learn bash?

I often hear how great GPT is at bash but imo it is terrible. Granted, most bash code is terrible, though I'm not sure why. It's like people don't even know how to use functions. It's petty quick to get to an okay level too! (I suspect few people sit down to learn it and instead learn it a line at a time over a very sparse timeframe)

The other part is compounding returns. This is extra obvious with bash. Getting good at shell scripting also helps you be really good at using the shell and vise versa. The returns aren't always obvious though, but you'll quickly find yourself piping into sed or xargs or writing little for loops or feeling like find actually makes sense. Pretty soon you'll be living in the terminal and questioning why others don't.

Bash scripting is an insanely underrated skill.

In general this is something I find problematic with AI code generation. The struggle is part of the learning process. Training wheels are great and at face value AI should help you learn. But it's like having a solution manual to your math homework. We both know 9/10 people go for the answer and not use it to get unstuck. It's also a bit hard with LLMs because they aren't great doing one line at a time and not spoiling the next steps. But I'm sure you can prompt engineer this to a decent degree of success.

[jitl]

I am fine with bash as a programming language but find Cursor cmd-k very nice:

For boilerplate like the grandparent comment poster - pop 2 args off $@ and check each matches some condition in an if, write error to stderr, return 2, check $@ has no args left: i can write all this code, but it's much faster to type "cmd-k, Bash: ensure exactly two params are passed, 1st one is a dir, 2nd is a file, enter" than to type the code directly. Here AI takes this task from "30 seconds" to "1 second".

For awk | sed | cut style transform pipelines, I can provide an example input text and describe my desired output, and AI does a great job writing the pipeline. Again, I can write this code (although usually requires multiple rounds of trail and error) but using AI takes it from "few minutes" to "few seconds" of time.

[godelski]

  > Bash: ensure exactly two params are passed, 1st one is a dir, 2nd is a file, enter" than to type the code directly

This seems much simpler than you made it out to be. Why not use ${#FOO[@]} for the number of args.

If you have strict ordering, your program is just as fast to type as it is to ask cursor (imo)

  [[ $# == 2 && -d "$1" && -a "$2" ]] || exit 2

  alternatively conditionally assigning

  [[ $# == 2 && -d "$1" && -a "$2" ]] && PREFIX="$1" && FILE="$2" || exit 2

I'll give you that it is probably faster if you are wanting to write it more correct and be order invariant (not what you asked), but with boiler plate I often just use macros.

I'm curious, what is Cursor's solution? Here's a pretty quick way that leaves some room for expandablity

  #!/usr/bin/env bash
  
  declare -ri MAXARGS=2
  declare -rA ECODES=(
      [GENERAL]=1
      [BADARGS]=2
  )

  FILE=
  PREFIX=

  fail_with_log() {
      echo "$1"
      exit ${ECODES[$2]}
  }

  check_args() {
      [[ $# == $MAXARGS ]] \
          || fail_with_log "Wrong number of arguments, expected ${MAXARGS} got $#" "BADARGS"
  
      # We might want to use -f instead of -a 
      # Check if PREFIX + FILE or FILE + PREFIX
      if [[ -d "$1" && -a "$2" ]];
      then
          PREFIX="$1"
          FILE="$2"
      elif [[ -a "$1" && -d "$2" ]];
      then
          FILE="$1"
          PREFIX="$2"
      else
          fail_with_log "Must provide both a file and a directory" "BADARGS"
      fi 
  } 

  main() {
      check_args "$@"
      ...
  }

  main "$@" || exit ${ECODES["GENERAL"]}

I mean a bunch of stuff above are superfluous but it doesn't take long to write (can be macro'd) and that little bit adds some flexibility if we want to extend down the line. There's of course, many ways to write this too. We could use a loop to provide more extensibility or even more conditional assignments. But this feels clearer, even if not very flexible.

[jitl]

As I said, I know bash, I've been writing bash for 20 years. I often ask Cursor to write code because it's literally faster to type "cmd-k, ensure exactly two params are passed, 1st one is a dir, 2nd is a file, enter" then it is to type the code myself. It's like I'm programming with natural language rather than whatever programming language. Like a high level programming language, I decide what the program should do, and AI figures out how to do it. It's analogous to writing bash instead of c. I could write my scripts in c for MAXIMUM PERFORMANCE, but I don't because it's less convenient. I could write this snippet of bash myself, but I don't for same reason.

Re: macros: Cursor works this way as a shortcut for all manner of boring code in any programming language and for this kind of thing is very trustworthy. Using it leaves me more mental energy to spend on other things. Macros (I think I call this "snippets"?) are only worth it for frequently repeated tasks.

This is what that prompt produces. Besides putting the count check first, it's what I would have written myself:

    if [[ $# -ne 2 ]]; then
     echo "Error: Exactly 2 arguments required" >&2
     return 1
    fi

    if [[ ! -d "$1" ]]; then
     echo "Error: First argument must be a directory" >&2
     return 1
    fi

    if [[ ! -f "$2" ]]; then
     echo "Error: Second argument must be a file" >&2
     return 1
    fi

[godelski]

Sure, I mean it depends. If it doesn't matter I'd go with my one line. If it does matter then I find cursors solution insufficient.

I'm not trying to argue that it can't solve the issue, I'm just trying to say there's not a big difference between the number of characters in the solution to the number of characters in the question.

I believe you that you've been writing scripts for 20 years but at the same time with that experience you're probably aware of people with that much experience that still don't know how to write functions. I constantly see people do things right out of bash pitfalls ¯\_(ツ)_/¯