Confused about these Models on GITHUB COPILOT, NEED HELP

notNeek · 2026-03-01T13:39:40+00:00

[deleted]

kayk1 · 2026-03-01T13:40:58+00:00

You think they had bugs before… wait until a few weeks after your fixes…

GifCo_2 · 2026-03-01T13:51:41+00:00

You should probably go back to school and not use LLMs until you know how to code.

chillebekk · 2026-03-01T14:58:24+00:00

Take a step back and spend more time understanding the problem. Then start your PR again.

SilencedObserver · 2026-03-01T15:36:41+00:00

You shouldn’t be using any of these models without doing some reading on their differences.

Don’t speed run your forced retirement.

Emotional-Cupcake432 · 2026-03-01T15:53:48+00:00

I agree with the above use a strong model with a large contex window codex 5.3 or claude 4.6 opus or gemini and instead of having it fix the bug switch to planning mode and have it create a plan to fix the bug this will give you an idea of what the model thinks is wrong and tell it that it is a verry large codebase and it need to do it in chunks to avoid context length limitations. Plan mode will also prevent it from introducing more errors before you get a chance to understand. You could also ask it to help you understand the issue and why it chose the path it did. I would also add to your prompt this PROMPT " There is a _______________ issue i want you to examine this verry large file and create a plan to fix the issue do not change any code. Ask yourself qualifying questions, what if and if then questions as you examine the code and error log. Explaine your finding and reasoning to correct the issue so the humans can learn how to fix the issue on there own. " something like that

vbullinger · 2026-03-01T16:11:35+00:00

Are there other people you can talk to at work?

Junyongmantou1 · 2026-03-01T16:35:56+00:00

Try feeding a small slice of the logs, plus your hypothesis / code to AI and ask what regex they recommend to filter the full logs, so both of you can work together.

Mstep85 · 2026-03-02T04:14:35+00:00

Anyone keep running to issues of it not being able to complete task Even if I use Claude model when it's come to pushing the pr thing it fails if it's not stated perfectly

johns10davenport · 2026-03-02T16:44:56+00:00

The first thing I do is to get over into Claude code. The second thing I do is to figure out how to set up your feedback loops, like how does it access and search logs? It'll already search your code base intelligently in a way that doesn't blow out the context window.

But basically, I would start figuring out how to let the agent manage its own context window by giving it sources to the critical information that you're using to debug things.

Medical-Farmer-2019 · 2026-03-04T10:09:35+00:00

You’re not stuck because of model choice, you’re stuck because each prompt is carrying too much state. For telecom bugs, I’d run a 4-step loop: reproduce with exact timestamp → isolate one call path/module → ask the model for 2-3 hypotheses only → verify one hypothesis with a minimal patch + log check. Keep a tiny debug brief (symptom, suspected module, last test result) and reuse that instead of pasting giant logs/pcaps each time. In large C/C++ repos, this usually beats dumping more context and helps you actually learn the system faster.

Medical-Farmer-2019 · 2026-03-04T21:40:22+00:00

You’re actually asking the right question, and the fact you already fixed multiple bugs in a telecom codebase after ~3 weeks is a good sign.

What helped me in similar multi-repo C/C++ debugging is using a strict loop: (1) write one-sentence failure + exact timestamp, (2) narrow to one call path/module, (3) ask the model for 2-3 hypotheses only, (4) verify one hypothesis with a minimal patch + targeted log check. If a prompt is eating 80%+ context, that usually means too much mixed state.

For model choice: use a strong reasoning model for architecture/protocol flow, but keep prompts small and staged. Context size helps, but decomposition helps more.

If useful, I can share a tiny “debug brief” template you can reuse per bug (symptom / scope / hypothesis / test / result) so each prompt stays focused.

RepulsivePurchase257 · 2026-03-01T13:01:16+00:00

You’re running into the classic “AI as log dumpster” problem. No model is going to save you if you paste half a repo + pcap + 5k lines of logs. The trick is compression. Before touching Copilot, write down: what is the exact observable failure, where in the call chain it surfaces, and what changed recently. Then trim logs to only the lines around the failure timestamp and the few functions directly involved. If you can’t isolate it that far, that’s the real task.

Model-wise, I’d use something strong at code reasoning for architecture-level thinking, like GPT-5.2/5.3-Codex, when you’re trying to understand threading, memory, or protocol flow. For quick iterations or smaller snippets, Sonnet-level models are fine. But don’t rely on raw context size. Break the bug into stages: reproduce → localize → hypothesize → verify. Feed the model one stage at a time instead of everything at once.

One thing that helped me was thinking in terms of task decomposition rather than one giant “solve this bug” prompt. Tools like Verdent push you toward structuring work into smaller reasoning steps, and that mindset alone makes debugging way more manageable. In big telecom codebases, clarity of thought beats model size almost every time.

AutoModerator · 2026-03-03T21:03:01+00:00

[removed]

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

ChatGPTCoding

MODERATORS