[Swizec]

> Are you willing to elaborate about how they can accelerate you?

A few examples from my experience:

    - Here is a SQL query. Translate this back into our janky ORM
    - Write tests that cover cases X, Y, Z
    - Wtf is this code trying to do?
    - I want to do X, write the boilerplate to get me started
    - Reshape this code to follow the new conventions

And it often picks up on me doing a refactor then starts making suggestions so refactoring feels like tab tab tab instead of type type type.

[t-writescode]

To add:

  - "I've never used this language / framework, this is what I'm trying to do, how would I do it?"
  - the documentation for these libraries is ... not useful. How do I do X?
    Followed by: "these parts didn't work due to these restrictions, tell me more".
    (I'm currently using this one to navigate Unity and UdonSharp's APIs. It is far from perfect
     but having *something* that half-works and moves me in the right direction of understanding
     how everything connects together is much much faster than sitting there, confused, unable
     to take a single step forward)

I find that a lot of cases where "just read the documentation" is the best route are situations where there is good (or any) documentation that is organized in a single, usable space and that doesn't require literal days worth of study to sufficiently understand the whole context to do what is, with all that context, a very simple task.

I'm reminded a bit of the days when I was a brand new Java programmer and I would regularly Google / copy-paste:

  public class Foo {
  
    public static void main(String[] args) {
        
    }
  }

Or new Python devs when they constantly have to look up

  if __name__ == '__main__':
    run_me()

because it's just a weird, magical incantation that's blocking their ability to do what they want to do