WillNickols

All the dimensions are in mm by default, so 39 mm radius on a mug is about right. For all their flaws, the LLMs do usually provide reasonable dimensions.

The conversation itself is sent to the LLM in regular text, and in addition it sees the feature tree (also text) and often a screenshot of whatever the current model looks like. This is usually enough for the model to know what's going on.

Yes - we're likely looking into other 3D systems in the future.

Every time you put in a query, LAD takes a snapshot of the current model and stores it, so you can revert whatever changes the LLM makes if it messes up.

I think that would make a lot of sense for non-CAD images, but the particular task you described there is do-able in just a few clicks in most CAD systems already. I think the AI would almost always take a longer time to do those kinds of actions than if you did it yourself.

Would you use something like this if it worked well in Fusion 360? We chose to start with SolidWorks because when talking with people in mechanical engineering, almost everyone was using SolidWorks and no one even mentioned Fusion (despite online surveys saying it's like 45/45).

Thanks for the input! Haven't done much with Altium but it seems like you get at least somewhat of a boost for it being slightly more about the logic and less about the spatial reasoning.

2 things related to what you said I hadn't put in the original post:

1. In our experience, the LLMs were awful at taking actions directly with any of the SolidWorks API scripting formats (C#, VBA, etc.). Probably 75% of what they wrote just failed to run, and even when they had access to browse the documentation it wasn't much better. If you're getting Opus or anything else to interact with SolidWorks from the CLI, can you say more about how you're getting it to interface effectively?

2. The LLMs are indeed surprisingly bad at spatial reasoning unless prompted specifically and individually. The most notable case of this is when they need to choose the right plane to sketch on. When creating revolve features, they'll often choose the face that would've only worked if they were going to extrude rather than revolve, and when creating sweeps they'll often try to put the sketch that's going to be swept on the same plane as the path that's being swept. If you go back and ask them why they did that and point out that it's wrong, they can fix it pretty fast, but when left to their own devices they often get quite stuck on this.

Curious what you think is the best interface for it? We thought about this ourselves and talked to some folks but it didn't seem there was a clear alternative to chat.

Honestly, the out-of-the-box models aren't great at CAD. We were mostly trying to figure out (1) how well it could do with the best harness we could give it and (2) whether people would want and use this if it worked well.

Not yet - we need to change the header configuration for that to work (versus connecting to local models), but we'll have it available soon.

Nothing R specific. In my experience, Claude is pretty good about using tidyverse for everything. What was is flopping on for you? Our thought on not fine tuning models is that whatever comes out in 6 months is just going to be better than whatever we fine tuned.

FWIW there's a bunch of stuff Erdos has that Positron doesn't (including having solved Positron's top 5 open GitHub issues):

1. Remote development via SSH or containers

2. AI that can connect to ChatGPT, local models, or our backend

3. In-line code execution for Qmd/Rmd files

4. Julia as a first class citizen

5. Multi-agent chats: as many AI sessions as you want and they’ll all run in parallel

6. Windows ARM64 builds

7. Open source AGPLv3 license

8. A bunch of other misc items including read-write data explorer for CSVs and TSVs, plots history sorted by file and time, searchable help, a command history tab, etc

Maybe the biggest difference going forward is that Positron was a ~2 year dev project, whereas Erdos reached feature parity (plus or minus some features) in about ~2 months and is now adding substantial brand new functionality every week.

A bunch of specific things below, but the main point is that it integrates a bunch of features that data scientists use that don't come with Cursor.

Specifics (mostly reproduced from above):

1. R/Python/Julia consoles accessible by the user and AI

2. Optimized jupytext system for editing notebooks efficiently

3. Plots pane for viewing and tracking plots

4. Databases pane for managing SQL/FTP connections

5. Environment pane for managing Python/R/Julia packages and environments

6. Help pane for documentation

7. An AI that interacts with all of that.

8. Open source AGPLv3

For me, the biggest difference in the AI usage is that the AI doesn't need to write one-off python scripts for everything and run them from the terminal because it can just use the console directly.