Live data from Hacker News

GitHub Copilot Coding Agent

github.blog

231–240 of 372 posts

Re: GitHub Copilot Coding Agent

#231

I played around with it quite a bit. it is both impressive and scary. most importantly, it tends to indiscriminately use dependencies from random tiny repos, and often enough not the correct ones, for major projects. buyer beware.

So like the typical junior developer, then.

No, lol. Even the enthusiastic junior developer would go around pestering people asking if the dependency is OK.

Re: GitHub Copilot Coding Agent

#232
post #99

Earlier quoted context omitted.

From talking to colleagues at Microsoft it's a very management-driven push, not developer-driven. Friend on an Azure team had a team member who was nearly put on a PIP because they refused to install the internal AI coding assistant. Every manager has "number of developers using AI" as an OKR, but anecdotally most devs are installing the AI assistant and not using it or using it very occasionally. Allegedly it's pret…

[flagged]

There's a large group of people that claim that AI tools are no good and I can't tell if they're in some niche where they truly aren't, they don't care to put any effort into learning the tools, or they're simply in denial.

Re: GitHub Copilot Coding Agent

#233

Earlier quoted context omitted.

But would you rather get paid to spend your time doing the interesting and enjoying work, or the mundane and boring stuff? ;) My hope is that agents like Copilot can help us burn down the tedious stuff and make more time for the big value adds.

Though I do not doubt your intentions to do what you think will make developers' lives better, can you be certain that your bosses, and their bosses, have our best interests in mind as well? I think it would be pretty naive to believe that your average CEO wouldn't absolutely love not to have to pay developers at all.

The profile indicates he's a product manager, not a developer.

Re: GitHub Copilot Coding Agent

#234

Earlier quoted context omitted.

> I noticed that LLMs need a very heavy hand in guiding the architecture, otherwise they'll add architectural tech debt. One easy example is that I noticed them breaking abstractions That doesn’t matter anymore when you’re vibe coding it. No human is going to look at it anyway. It can all be if/else on one line in one file. If it works and if the LLMs can work at, iterate and implement new business requirements, whil…

Wild take. Let’s just hand over the keys to LLMs I suppose, the fancy next token predictor is the capitan now.

Not that wild TBH.

This is a common view, and I think will be the norm on the near-to-mid term, especially for basic CRUD apps and websites. Context windows are still too small for anything even slightly complex (I think we need to be at about 20m before we start match human levels), but we'll be there before you know it.

Engineers will essentially become people who just guide the AIs and verify tests.

Re: GitHub Copilot Coding Agent

#235
post #150
post #29

Earlier quoted context omitted.

> I also ended up blowing through $15 of LLM tokens in a single evening. Consider using Aider, and aggressively managing the context (via /add, /drop and /clear). https://aider.chat/

I, too, recommend aider whenever these discussions crop up; it converted me from the "AI tools suck" side of this discussion to the "you're using the wrong tool" side. I'd also recommend creating little `README`'s in your codebase that are mainly written with aider as the intended audience. In it, I'll explain architecture, what code makes (non-)sense to write in this directory, and so on. Has the side-effect of bein…

Why create READMEs and not just comments in the code?

Re: GitHub Copilot Coding Agent

#236

Earlier quoted context omitted.

> allowing developers to spend more of their time working on the work they enjoy, and less of their time working on mundane, boring or annoying tasks. I get paid for the mundane, boring, annoying tasks, and I really like getting paid .

But would you rather get paid to spend your time doing the interesting and enjoying work, or the mundane and boring stuff? ;) My hope is that agents like Copilot can help us burn down the tedious stuff and make more time for the big value adds.

Not everyone gets to do the fun stuff. That's for people higher up in the chain, with more connections, or something else. I like my paycheck, and you're supposing that AI isn't going to take that away, and that we'll get to live in a world where we all work on "fun stuff". That is a real pie-in-the-sky dream you have, and it simply isn't how the world works. Back in the real world, tech jobs are already scarce and there's a lot of people that would be happy to do the boring mundane stuff so they can feed their family.

Re: GitHub Copilot Coding Agent

#237

Earlier quoted context omitted.

Copilot only does work that has been assigned to it by a developer, and all the code that the agent writes has to go through a pull request before it can be merged. In fact, Copilot has no write access to GitHub at all, except to push to its own branch. That ensures that all of Copilot's code goes through our normal review process which requires a review from an independent human.

Tim, are you or any of your coworkers worried this will take your jobs?

What if Tim was the coding agent?

Re: GitHub Copilot Coding Agent

#238
post #37

I wish they optimized things before adding more crap that will slow things down even more. The only thing that's fast with copilot is the autocomplete, it sometimes takes several minutes to make edits on a 100 line file regardless of the model I pick (some are faster than others). If these models had a close to 100% hit rate this would be somewhat fine, but going back and forth with something that takes this long is…

I've had this too, especially it getting stuck at the very end and just.. never finishing. Once the usage-based billing comes into effect I think I'll try cursor again. What local models are you using? The local models I tried for autocomplete were unusable, though based on aiders benchmark I never really tried with larger models for chat. If I could I would love to go local-only instead.

Re: GitHub Copilot Coding Agent

#239

Earlier quoted context omitted.

We've been using Copilot coding agent internally at GitHub, and more widely across Microsoft, for nearly three months. That dogfooding has been hugely valuable, with tonnes of valuable feedback (and bug bashing!) that has helped us get the agent ready to launch today. So far, the agent has been used by about 400 GitHub employees in more than 300 our our repositories, and we've merged almost 1,000 pull requests contri…

When I repeated to other tech people from about 2012 to 2020 that the technological singularity was very close, no one believed me. Coding is just the easiest to automate away into almost oblivion. And, too many non technical people drank the Flavor Aid for the fallacy that it can be "abolished" completely soon. It will gradually come for all sorts of knowledge work specialists including electrical and mechanical eng…

Do you've any textual evidence of this 8-year stretch of your life where you see yourself as being perpetually correct? Do you mean that you were very specifically predicting flexible natural language chatbots, or vaguely alluding to some sort of technological singularity?

We absolutely have not reached anything resembling anyone's definition of a singularity, so you are very much still not proven correct in this. Unless there are weaker definitions of that than I realised?

I think you'll be proven wrong about the economy too, but only time will tell there.

Re: GitHub Copilot Coding Agent

#240
post #150

Earlier quoted context omitted.

I, too, recommend aider whenever these discussions crop up; it converted me from the "AI tools suck" side of this discussion to the "you're using the wrong tool" side. I'd also recommend creating little `README`'s in your codebase that are mainly written with aider as the intended audience. In it, I'll explain architecture, what code makes (non-)sense to write in this directory, and so on. Has the side-effect of bein…

Why create READMEs and not just comments in the code?

I’d generally prefer comments in code. The README’s are relatively sparse and contain information that would be a bit too high-level for module or class-level comments. If commentary is specific to a module or class or method, the documentation belongs there. My rule of thumb is if the commentary helps you navigate and understand rules that apply to entire sets of modules rooted at `foo/`, it generally belongs in `foo/README`.

For example “this module contains logic defining routes for serving an HTTP API. We don’t write any logic that interacts directly with db models in these modules. Rather, these modules make calls to services in `/services`, which make such calls.”

It wouldn’t make sense to duplicate this comment across every router sub-module. And it’s not obvious from looking at any one module that this rule is applied across all modules, without such guidance.

These little bits of scaffolding really help narrow down the scope of the code that LLMs eventually try to write.

Post reply on HN