Hacker News Reader

Comment by scifibestfi | Hacker News Reader

What would be your estimate for how much time it saves?

One example of Copilot saving time - the other day I was trying to remember how to access a value from a map in Go. This doesn't take much time - alt tab to browser, ctrl + t for a new tab, type in "golang get value from map", click on a stackoverflow result, scroll down, glance at the result, alt tab back to IDE, and do it. With Copilot, Copilot knew what I was trying to do and suggested the right code to me and I accepted the suggestion by pressing tab.

But! I think the savings are even bigger because there is no context switch. If I have my browser open I might find myself going to hackernews, checking my email, looking at my stackoverflow notifications, browsing twitter - whatever. Copilot is not only faster, it keeps my focus on the code without giving me a chance to get distracted. In some sense, for this example, Copilot saved me 5-10 seconds by not needing to Google something. In another sense, it might have saved me an hour because I didn't decide to just check something on twitter while I had my browser open.

I don’t think the average brain works like this. If you know you have a piece of code to deliver or are in flow, I don’t think you’d willingly start browsing HN just because you went to SO to c&p some boilerplate code.

I find that if my brain is willing to be distracted, it’s made some sort of calculation saying that the cost of being distracted isn’t going to have a significant bearing on deliverables…and I’m pretty sure I’m no better or worse at estimations than anyone else.

I get the desire to ask that question, but it also feels like the main thing Copilot saves me is energy, which can’t be quantified in a very useful way. You’ll just have to take our words for it.

Like, writing a really boring unit test might only take 60 seconds, but if Copilot can do it for me (even if I have to quickly scan it for correctness) that saves me… well something other than 60 seconds. It sure feels like a big deal.

Why write that boring unit test at all? If it is not only boring, but also automatically generated, then what value does it add to the code? I would argue it actually _decreases_ the value, because you now have that much more code to maintain and understand. 90% of unit tests people write are garbage according to my experience.

This take is too reductionist. Every website ever has a boring unit test called “Is it up?” where you check if the site is still working after a deployment.

Boring and repetitive but of infinite value if you can detect early that your deployment broke something.

If a boring/boilerplate unit test like this can deliver value, other b/b unit tests are probably going to similar impacts and hence, saying they all “decrease” value is reductionist.

> Every website ever has a boring unit test called “Is it up?”

Yeah, and it should come almost automatically from the tooling. If you are writting this, you have a tooling problem.

Why can't we come at it from both sides?

Goal of library/language/framework designers: limit boilerplate and unnecessary code

Goal of tool/IDE designers: make it easy to not spend time on boilerplate and unnecessary code.

Both sides have built in limitations that will keep them from completely solving the problem. Terse, highly DRY code tends to also be highly abstracted and hard to read, with a lot of implicit behavior. On the other side, large amounts of generated code lead to tool lockin and cruft accumulation.

No product starts with an elaborate ci/cd pipeline and automated test suite. Many evolve into needing such tooling after having had an incident or two when a deployment broke the site…and the response invariably is that “we should have written a suite of really basic tests which goes to the home page and checks if the hero image is visible.”

If co-pilot’s autogenerated test cases can help prevent this head smacking, it will have proved that basic/boilerplate code was valuable.

The site checker included in the tooling is just a more mature version of the boilerplate unit test co-pilot gives us.

Btw, I have no skin in the game -never used co-pilot…just surprised that HN commenters can be so dismissive of wanting to get the basics right - like having some test coverage.

My own experience with it is rather limited. My workplace doesn't allow the use of it (due to confidentiality), so i've only used it for school work.

It wasn't much help in designing/implementing classes in Java or .NET, but when it came to implementing unit tests it practically wrote everything after i named the class and designated it as a test. It was able to extract all the different methods from the classes being implemented, and create appropriate unit tests based on that.

Now, it was school homework, so not representative of a complex business application, but if i can just handle the basics/boilerplate, it would be worth it.

Assuming a (European) work week of 37.5 hours per week, $10 comes down to $0.06 per working hour, and if it can just save me 5 minutes of work every day it will be worth it.

For me; I would happily pay 50$ a month. It probably saves me at least 10$ worth of time every day.

in some tasks, like refactoring, I would easily say that 75% of my time is saved by copilot.

For example, I just had to convert some OCaml code to Rust. I wrote the first few conversions, and then I would just paste the OCaml code in a comment, and it would auto-complete the equivalent code in Rust. I just had to check that it was correct, which it was most of the time, rinse and repeat and wow. One would have to be blind to not find copilot impressive, really, it's the future.

Reply on news.ycombinator.com