cool to see more AI tools address this
idk, everyone else seems to want to take the 40 year old IDE paradigm we're all used to (really! that's how old Turbo Pascal 3 is!) and graft AI onto it. I think we need a fundamentally different design to truly take advantage of the change from "I'm mostly reading and writing code at human speeds" to "I'm mostly supervising the AI which is better at generating syntax than I am."
of course the downside to going against the crowd is that the crowd is usually right, we'll see how it goes!
The big problem is that we're treating the AI as an all knowing oracle. And probably what we should be doing is treating the AI as a colleague -- allowing it to ask questions about the code base to develop the subtle clues.
Often what happens is that subtlety is lost on the code base, and sometimes, AI will think it's an outright error, when in fact it's completely on purpose.
Comments go a long way towards this end, but in large legacy codebases, comments may not exist, and the coders expected people to understand at first glance the code was correct.
Test driving Junie, I've had it remove a feature it thought was broken code, and then it fixes the unit tests, instead of trying to understand if the unit test was actually broken or the feature was broken.
jbellis•1y ago
I made an intro video with a live demo here: https://www.youtube.com/watch?v=Pw92v-uN5xI
soco•1y ago
lutzleonhardt•1y ago
https://brokk.ai/blog/brokk-under-the-hood
bchapuis•1y ago
Could you share a bit more about how you handle code summarization? Is it mostly about retaining method signatures so the LLM gets a high-level sense of the project? In Java, could this work with dependencies too, like source JARs?
More generally, how’s it been working with Java for this kind of project? Does limited GPU access ever get in the way of summarization or analysis (Jlama)?
jbellis•1y ago
Yes, it's basically just parsing for declarations. (If you doubleclick on any context in the Workspace it will show you exactly what's inside.)
You have to import the dependencies via File -> Decompile Dependency and then it gets parsed like the rest of your source, only read-only.
I have a love-hate relationship with Java, mostly love lately, the OpenJDK team is doing a great job driving the language forward. It's so much faster than Python, it's nice being able to extend a language in itself and get native performance.
Since we're just using Jlama to debounce the LLM requests, we can use a tiny model that runs fine on CPU alone. The latest Jlama supports GPU as well but we're not using that.
neoncontrails•1y ago
What does this flow look like in Brokk? Do models still need to resort to using obsolete terminal-based CLI tools in order to find stuff?
lutzleonhardt•1y ago
1. Quick Context Shows the most relevant files based on a pagerank algorithm (static analysis) and semantic embeddings (JLama inference engine). The input are the instructions and the AI workspace fragments (i.e. files).
2. Deep Scan A richer LLM receives the summaries of the AI workspace files (+instructions) and returns a recommendation of files and tests. It also recommends the type of inclusion (editable, read-only, summary/skeleton).
3. Agentic Search The AI has access to a set of tools for finding the required files. But the tools are not limited to grep/rg. Instead you can: - find symbols (classes, methods, ...) in the project - ask for summaries/skeletons of files - provide class or method implementations - find usages of symbols (where is x used?) - call sites (in/out) ...
You can read more about this in the Brokk.ai blog: https://brokk.ai/blog/brokk-under-the-hood
silverlake•1y ago
corysama•1y ago
jbellis•1y ago
lutzleonhardt•1y ago
saratogacx•1y ago