I've never been able to see any benefit in this because typing the code takes much less time than deciding what code should be there.

I could get a little bit of benefit out of an autocomplete that only showed legal suggestions, but even with deterministic autocomplete I frequently had to look at too many suggestions and it was faster to throw a query at Google.

I've found it to be useful for things where the auto-complete is both long enough and boring enough that it doesn't actually take longer to look at it

For a practical example, lets say I define protobuf models, I start by writing

```

service X {

   rpc doSomething([cursor]

}

```

It'll generally be smart enough to complete to the same pattern as every other one in the codebase

I can then put my cursor after and get it to generate the models by just tabbing a bunch:

```

service X {

  rpc doSomething(DoSomethingRequest) returns (DoSomethingResponse);

}

[cursor]

```

```

service X {

  rpc doSomething(DoSomethingRequest) returns (DoSomethingResponse);

}

message DoSomethingRequest {}

message DoSomethingResponse {}

```

Then I can go to my actual code file where this is implemented, and having had both the context of the codebase and the context of the protobuf file, it'll generate

```

class DoSomethingImpl extends some.grpc.package.DoSomethingService {

  override def doSomething(request: DoSomethingRequest): Future[DoSomethingResponse] {

     // Some usually bad code I just delete

  }

}

```

Nothing here is super complicated, I know it's right at a glance, it's super easy to write, but I hate having to do the boilerplate. Could I write a simple script that kind autogenerates this for a given API? Maybe. But a bunch of typing and piping things around becomes just a bunch of "tab" presses. And an LLM is more flexible to slight changes in the pattern.

This is multiplied times 10 if I then want to consume this from some other language, and it has both in it's context. I literally just need to create the one definition, and the LLM will complete the required code to product / consume the API on both sides as long as it's all in the same context window (and tools are getting good at doing this)

What I really want now is to just have to say "Add a proto api for `doSomething` and add boilerplate to give a response and then consume it. Put it in X existing grpc service" and just have it do all of this without a series of smaller completion.

I wonder if it depends on the programming style, because I always feel like I have this massive amount of things that I need to "vomit" out, so Copilot is always helpful for me. Like I already know what the whole system should be like, so it's just about laying it out.

It's mostly full stack web applications, with React frontend and APIs with databases, so it's not exactly something groundbreaking.

I think that's a big part of it. I'm writing servers and systems in C++ and Kotlin. C++ is a very dense language, virtually every token is semantic with little redundancy except the archaic header declaration system, so there are not all that many shortcuts that still preserve my intended meaning. Kotlin feels like a response to Java being so low-density, and is much higher density, although not as much as C++.

Every time I play with web or GUI development I get the impression that the languages and systems are misaligned with the way people express their intentions in the space. It makes me want to develop a language (or family of languages) directly for expressing GUI concepts, but I don't understand the space well enough to do a good job.

I build CRUD apps at BigCo and most of the LOC is pretty mindless but needs to be deployed yesterday. Copying over 100 different memberVariable = DATABASE_CONSTANT in different forms becomes much easier when copilot starts guessing the format.

I would say that in many cases there is annoying amount of boilerplate, and I would say it would make sense to DRY & abstract it away, because it's painful to write it, but Copilot has made it bearable, so I'm less caring of that now.

And sometimes if you do abstract it away too much, edge cases handling and everything affecting everything else might not be worth it.

I also think with Copilot in the house, it's completely acceptable to have it write utils fn even if they are not DRY, in the sense that you could import leftPad as a package, but it doesn't matter since you can just write function leftP and copilot will do it for you within few seconds, which is faster and more flexible for the future. And without unnecessary, unknown dependencies with potential vulnerabilities baked in.

I think there's going to also be some sort of enlightening in terms of overusing libraries and idea of everything having to be DRY. Because frequently this will cause more problems than it wins even though you think the code is really, really clean.

A lot of the time it'll guess the type signature I'm using or the entire shape of the mock object I'm trying to build. When it works it's much better than intellisense, but I don't ever go to it, if the ghost text pops up in a way that works for me I'll hit tab, otherwise I'll keep typing until/if it figures out what I'm aiming for.

And all the generated code needs to be maintained.

Typing the code yourself incentivizes you to write code that's concise and easy to read and avoids repetition.