|
|
|
|
|
by YZF
36 days ago
|
|
What tools have you tried? Are we talking Codex GPT 5.5 and Opus 4.7? Would you say the project is well architected? Clear boundaries? Or ball of mud? How large is large? Are there AGENT.md files giving good information that helps LLMs get context when looking at a certain area of the code? Is it all in one repo? multiple repos? Are there good tests? I feel like these are some of the many variables that can make a difference. I work on a pretty large project/code base, written mostly in Go, and I have pretty positive experience with LLMs. I take on fairly small chunks, I review and understand the changes. I also use LLMs to explore options and prototype quickly. They're also very good at fixing bugs, failing tests etc. |
|
Yes, with generous budgets.
> They're also very good at fixing bugs,
Seeing opposite here too, they are like eager juniors 'oh the issue is here and here's a 5 page report why', and it's wrong... then you add more info and it goes to a different spot... repeat until you get tired and solve it yourseld, it is useful as a rubber ducky i guess.
> I work on a pretty large project/code base, written mostly in Go, and I have pretty positive experience with LLMs. I take on fairly small chunks, I review and understand the changes.
Great that it's working for you, I'm just pointing out there's a massive disconnect.
I would assume your work can be done by a junior engineer without any prior knowledge (except LLM md files) with same quality but less speed?
If yes, then great, perhaps that's where the disconnect is, complexity.
Also, if yes, which would be cheaper?, junior engineer or LLM?