There is no fundamental blocker to agents doing all those things. Mostly a matter of constructing the right tools and grounding, which can be fair amount of up-front work. Arming LLMs with the right tools and documentation got us this far. There’s no reason to believe that path is exhausted.
Look at this 18 years old Django ticket: https://code.djangoproject.com/ticket/4140
It was impossible to fix, but it required some experiments and deep research about very specific behaviors.
Or this ticket: https://code.djangoproject.com/ticket/35289
Author proposed one-line solution, but the following discussion includes analysis of RFC, potential negative outcomes, different ways to fix it.
And without deep understanding of the project - it's not clear how to fix it properly, without damage to backward compatibility and neighbor functionality.
Also such a fix must be properly tested manually, because even well designed autotests are not 100% match the actual flow.
You can explore other open and closed issues and corresponding discussions. And this is the complexity level of real software, not pet projects or simple apps.
I guess that existing attention mechanism is the fundamental blocker, because it barely able to process all the context required for a fix.
And feature requests a much, much more complex.
Have you tried building agents? They will go from PhD level smart to making mistakes a middle schooler would find obvious, even on models like gemini-2.5 and o1-pro. It's almost like building a sandcastle where once you get a prompt working you become afraid to make any changes because something else will break.
> Have you tried building agents?
I think the issue right now is so many people want to believe in the moonshot and are investing heavily in it, when the reality is we should be focusing on the home runs. LLMs are a game changer, but there is still A LOT of tooling that can be created to make it easier to integrate humans in the loop.
you can just even tell cursor to use any cli tools you use normally in your development, like git, gh, railway, vercel, node debugging, etc etc
Tools is not the problem. Knowledge is.
> Tools is[sic] not the problem. Knowledge is.
This is the most difficult concept to convey, expressed in a succinct manner rarely found.
Correct! Over at https://ghuntley.com/mcp I propose that each company develops their own tools for their particular codebase that shapes LLM actions on how to work with their codebase.