Live data from Hacker News

GitHub Copilot Coding Agent

github.blog

141–150 of 372 posts

Re: GitHub Copilot Coding Agent

#141

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.

This is something I've noticed as well with different AIs. They seem to disproportionately trust data read from the web. For example, I asked to check if some obvious phishing pages were scams and multiple times I got just a summary of the content as if it was authoritative. Several times I've gotten some random chinese repo with 2 stars presented as if it was the industry standard solution, since that's what it said…

> ... sent me to...

Oh wow, that was great - particularly if I then look at my own body parts (like my palm) that I know are not moving, it's particularly disturbing. That's a really well done effect, I've seen something similar but nothing quite like that.

Re: GitHub Copilot Coding Agent

#142
"Drowning in technical debt?"

Stop fighting and sink!

But rest assured that with Github Copilot Coding Agent, your codebase will develop larger and larger volumes of new, exciting, underexplored technical debt that you can't be blamed for, and your colleagues will follow you into the murky depths soon.

Re: GitHub Copilot Coding Agent

#143
post #13

> Copilot excels at low-to-medium complexity tasks in well-tested codebases, from adding features and fixing bugs to extending tests, refactoring, and improving documentation. Bounds bounds bounds bounds. The important part for humans seems to be maintaining boundaries for AI. If your well-tested codebase has the tests built thru AI, its probably not going to work. I think its somewhat telling that they can't share n…

> Microsoft, the company famous for dog-fooding

This was true up around 15 years ago. Hasn't been the case since.

Re: GitHub Copilot Coding Agent

#144

Earlier quoted context omitted.

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…

I don't think it was unreasonable to be very skeptical at the time. We generally believed that automation would get rid of repetitive work that didn't require a lot of thought. And in many ways programming was seen almost at the top of the heap. Intellectually demanding and requiring high levels of precision and rigor. Who would've thought (except you) that this would be one of the things that AI would be especially…

> I don't think it was unreasonable to be very skeptical at the time.

Well, that's back rationalization. I saw the advances like conducting meta sentiment analysis on medical papers in the 00's. Deep learning was clearly just the beginning. [0]

> Who would've thought (except you)

You're othering me, which is rude, and you're speaking as though you speak for an entire group of people. Seems kind of arrogant.

0. (2014) https://www.ted.com/talks/jeremy_howard_the_wonderful_and_te...

Re: GitHub Copilot Coding Agent

#145
post #105

Earlier quoted context omitted.

textbook survivorship bias https://en.wikipedia.org/wiki/Survivorship_bias every bullet hole in that plane is the 1k PRs contributed by copilot. The missing dots, and whole missing planes, are unaccounted for. Ie, "ai ruined my morning"

It's not survivorship bias. Survivorship bias would be if you made any conclusions from the 1000 merged PRs (eg. "90% of all merged PRs did not get reverted"). But simply stating the number of PRs is not that.

As with all good marketing, the conclusions omitted and implied, no?

Re: GitHub Copilot Coding Agent

#146

I tried doing some vibe coding on a greenfield project (using gemini 2.5 pro + cline). On one hand - super impressive, a major productivity booster (even compared to using a non-integrated LLM chat interface). 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 (putting things where they do…

I loathe using AI in a greenfield project. There are simply too many possible paths, so it seems to randomly switch between approaches. In a brownfield code base, I can often provide it reference files to pattern match against. So much easier to get great results when it can anchor itself in the rest of your code base.

The trick for greenfield projects is to use it to help you design detailed specs and a tentative implementation plan. Just bounce some ideas off of it, as with a somewhat smarter rubber duck, and hone the design until you arrive at something you're happy with. Then feed the detailed implementation plan step by step to another model or session.

This is a popular workflow I first read about here[1].

This has been the most useful use case for LLMs for me. Actually getting them to implement the spec correctly is the hard part, and you'll have to take the reigns and course correct often.

[1]: https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/

Re: GitHub Copilot Coding Agent

#147
Major scam alert, they are training on your code in private repos if you use this

You can tell because they advertise “Pro” and “Pro+” but then the FAQ reads,

> Does GitHub use Copilot Business or Enterprise data to train GitHub’s model? > No. GitHub does not use either Copilot Business or Enterprise data to train its models.

Aka, even paid individuals plans are getting brain raped

Re: GitHub Copilot Coding Agent

#148

Earlier quoted context omitted.

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…

I don't think it was unreasonable to be very skeptical at the time. We generally believed that automation would get rid of repetitive work that didn't require a lot of thought. And in many ways programming was seen almost at the top of the heap. Intellectually demanding and requiring high levels of precision and rigor. Who would've thought (except you) that this would be one of the things that AI would be especially…

Its interesting that even people initially skeptical are now thinking they are on the "chopping block" so to speak. I'm seeing it all over the internet and the slow realization that what supposed to be the "top of the heap" is actually at the bottom - not because of difficulty of coding but because the AI labs themselves are domain experts in software and therefore have the knowledge and data to tackle it as a problem first. I also think to a degree they "smell blood" and fear, more so than greed, is the best marketing tool. Many invested a good chunk of time on this career, and it will result in a lot of negative outcomes. Its a warning to other intellectual careers that's for sure - and you will start seeing resistance to domain knowledge sharing from more "professionalized" careers for sure.

My view is in between yours: A bit of column A and B in the sense both outcomes to an extent will play out. There will be less engineers but not by the factor of productivity (Jevon's paradox will play out but eventually tap out), there will be even more software especially of the low end, and the ones that are there will be expected to be smarter and work harder for the same or less pay grateful they got a job at all. There will be more "precision and rigor", more keeping up required by workers, but less reward for the workers that perform it. In a capitalist economy it won't be seen as a profession to aspire to anymore by most people.

Given most people don't live to work, and use their career to also finance and pursue other life meanings it won't be viable for most people long term especially when other careers give "more bang for buck" w.r.t effort put into them. The uncertainty in the SWE career that most I know are feeling right now means to newcomers I recommend on the balance of risk/reward its better to go another career path especially for juniors who have a longer runway. To be transparent I want to be wrong, but the risk of this is getting higher now everyday.

i.e. AI is a dream for the capital class, and IMO potentially disastrous for social mobility long term.

Re: GitHub Copilot Coding Agent

#149
post #68

Earlier quoted context omitted.

> Light edits are about 10 cents Some well-paid developers will excuse this with, "Well if it saved me 5 minutes, it's worth an order of magnitude than 10 cents". Which is true, however there's a big caveat: Time saved isn't time gained. You can "Save" 1,000 hours every night, but you don't actuall get those 1,000 hours back.

> You can "Save" 1,000 hours every night, but you don't actuall get those 1,000 hours back. What do you mean? If I have some task that requires 1000 hours, and I'm able to shave it down to one hour, then I did just "save" 999 hours -- just in the same way that if something costs $5 and I pay $4, I saved $

My point is that saving 1,000 hours each day doesn't actually give you 1,000 hours a day to do things with.

You still get your 24 hours, no matter how much time you save.

What actually matters is the value of what is delivered, not how much time it actually saves you. Justifying costs by "time saved" is a good way to eat up your money on time-saving devices.

Re: GitHub Copilot Coding Agent

#150
post #29

I tried doing some vibe coding on a greenfield project (using gemini 2.5 pro + cline). On one hand - super impressive, a major productivity booster (even compared to using a non-integrated LLM chat interface). 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 (putting things where they do…

> 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 being helpful for humans, too.

Nowadays when I'm editing with aider, I'll include the project README (which contains a project overview + pointers to other README's), and whatever README is most relevant to the scope of my session. It's super productive.

I'm yet to find a model that beats the cost-effectiveness of Sonnet 3.7. I've tried the latest deepseek models, and while I love the price (nearly 50x cheaper?), it's just far too error-prone compared to Sonnet 3.7. It generates solid plans / architecture discussions, but, unlike Sonnet, the code it generates often confidently off-the-mark.

Post reply on HN