3 ms·

The "Read" file list sounds a lot like Copilot Edit mode, where you manually specify the list of files that are added to the context. Similarly, Copilot has an

by danjl 1y ago

The "Read" file list sounds a lot like Copilot Edit mode, where you manually specify the list of files that are added to the context. Similarly, Copilot has an Ask (Chat) mode that doesn't change the code. One of the downsides of all these new IDEs is that it is difficult, even for the developers of those tools, to have enough time to test out coding in each of their competitors. Also, the switching cost of changing IDEs is pretty high, even if they are forks of the same code base, which makes it hard for the users to really test out all the options. In the long run, I expect that the "larger" IDE providers will purchase the smaller ones. IOW, if you wait long enough, all the good bits will be in Copilot (or maybe Cursor with their new funding).

jbellis 1y ago
(creator here) 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!
- danjl 1y ago
  I am a huge supporter of completely re-working the IDE UI as well. I'm not arguing for keeping the existing IDE interfaces. I like that folks are experimenting with entirely new interfaces. In fact, I'd go further and suggest that all of the overly complex interfaces used on any sort of content-creation app, like Unity, Unreal, Photoshop, as well as code IDEs, will eventually be completely refactored to remove all the old complexity in favor of either chat-based or other AI-driven interfaces. My point is simply that there are too many new AI-driven IDEs for folks to try out, even the developers of those IDEs. Many of the features in Brokk that were seemingly described in the Brokk 101 blog video as "differentiators" are existing Copilot features. Has the author ever used Copilot? Or just Cursor? Or another AI variant?
- danjl 1y ago
  I'd love to see things like Brokk experiment a bit more with what other information to include in our git repositories, besides the code, that helps improve AI-based code generation. For example, perhaps the repo should include more design information about the look-and-feel, as visual information or Figma files, rather than just, say the CSS and HTML. Or it might help if the repository included more business requirements so that the AI has better information to guide prioritization of changes. Obviously other bits, like coding standards, should be included as well, though perhaps using a larger context might mitigate the need for coding standards if the generated code followed the existing code (which often doesn't happen).
- bb88 1y ago
  I think that's what's going to happen over time. We're going to be writing more and more code, but supervising an AI mostly. 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.

by danjl 1y ago

jbellis 1y ago

(creator here) 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!

danjl 1y ago
I am a huge supporter of completely re-working the IDE UI as well. I'm not arguing for keeping the existing IDE interfaces. I like that folks are experimenting with entirely new interfaces. In fact, I'd go further and suggest that all of the overly complex interfaces used on any sort of content-creation app, like Unity, Unreal, Photoshop, as well as code IDEs, will eventually be completely refactored to remove all the old complexity in favor of either chat-based or other AI-driven interfaces. My point is simply that there are too many new AI-driven IDEs for folks to try out, even the developers of those IDEs. Many of the features in Brokk that were seemingly described in the Brokk 101 blog video as "differentiators" are existing Copilot features. Has the author ever used Copilot? Or just Cursor? Or another AI variant?
danjl 1y ago
I'd love to see things like Brokk experiment a bit more with what other information to include in our git repositories, besides the code, that helps improve AI-based code generation. For example, perhaps the repo should include more design information about the look-and-feel, as visual information or Figma files, rather than just, say the CSS and HTML. Or it might help if the repository included more business requirements so that the AI has better information to guide prioritization of changes. Obviously other bits, like coding standards, should be included as well, though perhaps using a larger context might mitigate the need for coding standards if the generated code followed the existing code (which often doesn't happen).
bb88 1y ago
I think that's what's going to happen over time. We're going to be writing more and more code, but supervising an AI mostly. 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.