I doubt it. There’s more to code than a set of completions, regardless of how powerful they are: 1. There’s the large scale nature of most software. The many

I doubt it. There’s more to code than a set of completions, regardless of how powerful they are: 1. There’s the large scale nature of most software. The many components that must interact well. The database, the interface to users and the outside world. Security, hardware, performance, threading, and more.. the bigger decisions of systems to use and how they work together. 2. There’s the domain knowledge to the problem you’re solving. Not sure how this goes away. 3. There’s the many false positives we’re likely to get. Like when Siri doesn’t understand what you’re saying one in twenty times, you often just give up on voice because it’s so much trouble to correct it. Except the risk here is potentially much higher. Maybe on your first serious copilot issues you’ll be _really_ suspect of it and decide to turn it off. 4. There’s the innovative, interesting work that’s down the long tail of what Copilot knows about. How generic is what you’re doing? How likely is copilot to have encountered similar problems to what you’re doing? 5. There’s debugging. How much time do we spend composing code vs figuring out why code isn’t working well? TBH copilot seems to scratch an itch where I have to weave together a few stackoverflow examples to do some thing that seems a bit silly and time consuming. The task I wonder “why hasn’t anyone solved this yet?” Good software balances a dozen or more different constraints that typically are very specific to the problem at hand. I’m not sure how copilot replaces this.