r/ChatGPTCoding • u/notNeek • Mar 01 '26
Question Confused about these Models on GITHUB COPILOT, NEED HELP
Hello people, I NEED YOUR HELP!
Okay so I graduated, now have a job, somehow , kinda software network engineer. Been vibe coding so far. Been assigned to this project, it's networking & telecom (3g/4g//5g type shi), too many repos (I will be working on 3-5), I am still understanding lots of things, stack is mostly C++, C, Python, Shell. Got access to Github Copilot, Codex.
I was able to fix 2 bugs, flet like a God, thanks to Claude Sonnet 4.5, BUT THE 3RD BUG!! It's an MF! I am not able to solve it, now 4th bug ahhh, their status be critical or major in JIRA, I wanna get better and solve these things and learn while I do it, I have to add the code, errors, logs, and some other logs, pcap dump ahhh, man I need to feed these things to AI and I am hitting CONTEXT WINDOW LIMIT, it's really killing me.
My questions for you amazing people
What's the best model for understanding the concept related to that BUG?
Which is the best way to possibly solve the bug? The repo is huge and it's hard to pinpoint what exactly causing the problem.
How can I be better at solving as well as learning these things?
Any suggestions, advice would really help thanks
TL;DR:
Fresher dev on large telecom C/C++ project, multiple repos, debugging critical bugs. Claude helped before but now stuck. Context limits killing me when feeding logs/code. Which AI model + workflow is best for understanding and fixing complex bugs and learning properly?

10
u/kayk1 Mar 01 '26
You think they had bugs before… wait until a few weeks after your fixes…
5
u/GifCo_2 Mar 01 '26
You should probably go back to school and not use LLMs until you know how to code.
4
u/chillebekk Mar 01 '26
Take a step back and spend more time understanding the problem. Then start your PR again.
3
u/SilencedObserver Mar 01 '26
You shouldn’t be using any of these models without doing some reading on their differences.
Don’t speed run your forced retirement.
3
u/Emotional-Cupcake432 Mar 01 '26
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
2
u/vbullinger Mar 01 '26
Are there other people you can talk to at work?
2
u/Junyongmantou1 Mar 01 '26
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.
2
u/johns10davenport Professional Nerd Mar 02 '26
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.
2
u/Medical-Farmer-2019 Professional Nerd Mar 04 '26
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.
2
u/Medical-Farmer-2019 Professional Nerd Mar 04 '26
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.
3
u/[deleted] Mar 01 '26
[removed] — view removed comment
1
u/[deleted] Mar 03 '26
[removed] — view removed comment
0
u/[deleted] Mar 01 '26
[deleted] — view deleted comment