Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Copilot Coding Agent

github.blog

Post reply on HN
Print view View original

331–340 of 372 posts

Re: GitHub Copilot Coding Agent

#331

Post by internet101010 »

timrogers wrote: post #176
ilaksh wrote: post #60

Earlier quoted context omitted.

What model does it use? gpt-4.1? Or can it use o3 sometimes? Or the new Codex model?

At the moment, we're using Claude 3.7 Sonnet, but we're keeping our options open to change the model down the line, and potentially even to introduce a model picker like we have for Copilot Chat and Agent Mode.

Using different models for different tasks is extremely useful and I couldn't imagine going back to using just one model for everything. Sometimes a model will struggle for one reason or another and swapping it out for another model mid-conversation in LibreChat will get me better results.

Re: GitHub Copilot Coding Agent

#332

Post by _heimdall »

binarymax wrote: post #324
_heimdall wrote: post #296

Earlier quoted context omitted.

I'm honestly surprised that Microsoft (and other similarly sized LLM companies) have convinced or coerced literally hundreds of thousands of employees to build their own replacement. If we're expected to even partially believe the marketing, LLM coding agents are useful today at junior level developer tasks and improving quickly enough that senior tasks will be doable soon too. How do you convince so many junior and…

When the options are "do what we tell you and get paid" vs getting laid off in the current climate, the choice isn't really a choice.

That threat doesn't scale. I do get that many haven't put themselves in a position to stand behind their views or principles, but if they did the threat, or the company, would crumble.

Re: GitHub Copilot Coding Agent

#333

Post by ukuina »

adamsb6 wrote: post #232
shepherdjerred wrote: post #114

Earlier quoted context omitted.

[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.

Likely a Five Worlds scenario.

https://www.joelonsoftware.com/2002/05/06/five-worlds/

Re: GitHub Copilot Coding Agent

#335

Post by jessmartin »

rcarmo wrote: post #253
imiric wrote: post #146

Earlier quoted context omitted.

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 m…

Here’s my workflow, it takes that a few steps further: https://taoofmac.com/space/blog/2025/05/13/2230

This seems like a good flow! I end up adding a "spec" and "todo" file for each feature[1]. This allows me to flesh out some of the architectural/technical decisions in advance and keep the LLM on the rails when the context gets very long.

[1] https://notes.jessmart.in/My+Writings/Pair+Programming+with+...

Re: GitHub Copilot Coding Agent

#336

Post by skydhash »

Cthulhu_ wrote: post #259
literalAardvark wrote: post #98

Earlier quoted context omitted.

"We need to get 1000 PRs merged from Copilot" "But that'll take more time" "Doesn't matter"

I feel the same about automated dependency updates, but if your tests and verifications are good, these become trivial.

Sometimes there are some paradigms shift in the dependency that get past the current tests you have. So it’s always good to read the changelog and plan the update accordingly.

Re: GitHub Copilot Coding Agent

#337

Post by rcarmo »

jessmartin wrote: post #335
rcarmo wrote: post #253

Earlier quoted context omitted.

Here’s my workflow, it takes that a few steps further: https://taoofmac.com/space/blog/2025/05/13/2230

This seems like a good flow! I end up adding a "spec" and "todo" file for each feature[1]. This allows me to flesh out some of the architectural/technical decisions in advance and keep the LLM on the rails when the context gets very long. [1] https://notes.jessmart.in/My+Writings/Pair+Programming+with+...

Yeah, I limit context by regularly trimming the TODOs. I like having 5-6 in one file because it sometimes informs the LLM as to how to complete the first in a way that makes sense for the follow-ups.

READMEs per module also help, but it really depends a lot on the model. Gemini will happily traipse all over your codebase at random, gpt-4.1 will do inline imports inside functions because it seems to lack any sort of situational awareness, Claude so far gets things mostly right.

Re: GitHub Copilot Coding Agent

#339

Post by skydhash »

insin wrote: post #155
bamboozled wrote: post #139

Earlier quoted context omitted.

I like updating documentation and feel that it's fairly important to be doing myself so I actually understand what the code / services do? I use all of these tools, but you also know what "they're doing"... I know our careers are changing dramatically, or going away (I'm working on a replacement for myself), but I just like listening to all the "what we're doing is really helping you ..."

I'd interpret the original statement as "tests which don't matter" and "documentation nobody will ever read", the ones which only exist because someone said they _have_ to, and nobody's ever going to check them as long as they exist (like a README.md in one my main work projects I came back to after temporarily being reassigned to another project - previously it only had setup instructions, now: filled with irreleven…

I’ve never seen a test that doesn’t matter that shouldn’t be slotted for removal (if it gets written at all) or documentation that is never read. If people can read code to understand systems, they will be grateful for good documentation.

Re: GitHub Copilot Coding Agent

#340

Post by sensanaty »

bencyoung wrote: post #294

Some example PRs if people want to look: https://github.com/dotnet/runtime/pull/115733 https://github.com/dotnet/runtime/pull/115732 https://github.com/dotnet/runtime/pull/115762

That first PR (115733) would make me quit after a week if we were to implement this crap at my job and someone forced me to babysit an AI in its PRs in this fashion. The others are also rough.

A wall of noise that tells you nothing of any substance but with an authoritative tone as if what it's doing is objective and truthful - Immediately followed by:

- The 8 actual lines of code (discounting the tests & boilerplate) it wrote to actually fix the issue is being questioned by the person reviewing the code, it seems he's not convinced this is actually fixing what it should be fixing.

- Not running the "comprehensive" regression tests at all

- When they do run, they fail

- When they get "fixed" oh-so confidently, they still fail. Fifty-nine failing checks. Some of these tests take upward of an hour to run.

So the reviewer here has to read all the generated slop in the PR description and try to grok what the PR is about, read through the changes himself anyway (thankfully it's only a ~50 line diff in this situation, but imagine if this was a large refactor of some sort with a dozen files changed), and then drag it by the hand multiple times to try fix issues it itself is causing. All the while you have to tag the AI as if it's another colleague and talk to it as if it's not just going to spit out whatever inane bullshit it thinks you want to hear based on the question asked. Test failed? Well, tests fixed! (no, they weren't)

And we're supposed to be excited about having this crap thrust on us, with clueless managers being sold on this being a replacement for an actual dev? We're being told this is what peak efficiency looks like?

Post reply on HN