keks0r

Does this mean, that the full node compatibility purely depends on oxc for transpiling? So oxc compatibility = nub compatibility?

How does this integrate with Git? is the CRDT stack mainly for syncronizing locally? and then "snapshotted" into git? Or how would the team collaboration part of this work?

yes we had to tune the claude.md and the skill trigger quite a bit, to get it much better. But to be honest also 4.6 did improve it quite a bit. Did you run into your issues under 4.5 or 4.6?

Team of 4 engineers, 1 data & business person, 1 design engineer.

I would say roughly equal amount of sessions between them (very roughly)

Also maybe 40% of coding sessions in large brownfield project. 50% greenfield, and remaining 10% non coding tasks.

We dont expect anything, we put it out there, and we might be able to build trust as well, but maybe you dont trust us, thats fair. You can still run it yourself. We are happy about everyone trying it out, either hosted or not. We are hosting it, just to make it easier for people that want to try it, but you dont have to. But you have a good point, we should probably put more about this on the website. Thanks.

1. can only partly be answered, because we can only capture the "edits" that are prompted, vs manual ones. 2. for us actually all of them, since we do everything with ai, and invest heavily and continously, to just reduce the amount of iterations we need on it 3. thats a good one, we dont have anything specific for debugging yet, but it might be an interesting class for a type of session.

the skill usage was one of these "I am wondering about...." things, and we just prompted it into the dashboard to undertand it. We have some of these "hunches" where its easier to analyze having sessions from everyone together to understand similarities as well as differences. And we answered a few of those kinda one off questions this way. Ongoing, we are also using a lot our "learning" tracking, which is not really usable right now, because it integrates with a few of our other things, but we are planning to release it also soon. Also the single session view sometimes helps to debug a sessions, and then better guide a "learning". So its a mix of different things, since we have multiple projects, we can even derive how much we are working on each project, and it kinda maps better than our Linear points :)

We used it across the team, and when you want to bring metrics together across multiple people, its easier on a server, than local.

Cool, whats the link? We have some learnings, especially in the "Skill guiding" part of our example.

Our focus is a little bit more cross team, and in our internal version, we have also some continuous improvement monitoring, which we will probably release as well.

The tool does have a quite detailed view for individual sessions. Which allows you to understand input and output much better, but obviously its still mysterious how the output is generated from that input.

The 4% usage was about our internal team, and we have skills setup. So it is not necessary that they are not built, but rather that they were not used, when we expected them to be used. So we adapted our CLAUDE.md to make claude more eager to use them. Also the 4% usage was on the 4.5 models, 4.6 got much better with invoking skills.

Ohh this is exciting, I kinda overlooked it. I assume there are still a lot of differences, especially for accross teams. But I immediately ran it, when I saw your comment. Actually still running.

It will be only enabled for the repo where you called the `enable` command. Or use the cli `upload` command for specific sessions.

Or you can run your own instance, but we will need to add docs, on how to control the endpoint properly in the CLI.

This is great. How are you "identifying" these stages in the session? Or is it just different slash commands / skills per stage? If its something generic enough, maybe we can build the analysis into it, so it works for your use case. Otherwise feel free to fork the repo, and add your additional analysis. Let me know if you need help.

Ah sorry, the readme is more about how to run the repo. The "product" information is rather on the website: https://rudel.ai

Its our own sessions, from our team, over the last 3 months. We used them to develop the product and learn about our usage. You are right, they will remain closed. But I am happy to share aggregated information, if you have specific questions about the dataset.

The docker-compose contain everything you should need: https://github.com/obsessiondb/rudel/blob/main/docker-compos...

There is also a docker setup in there to run everything locally.

Yes we added codex support, but its not yet extensively tested. Session upload works, but we kinda have to still QA all the analytics extraction.

Hey Hana & Josue, congrats on the launch. I like your approach of how to integrate it into products (via native React libs). I think you could go even a little bit further. One concern I would have is that by using your react library, I also bring in a new state management (mobx). In our case it would be fine, because we are using it already, for others it might be an issue. The most extreme version I found is from feedback.fish, which gives a native react component, but internally imports their scripts still in an iframe.

The other thing would be, that the react package could export not only hooks to interact (useMagicBellEvent), but also provide some hooks or headless components to easier integrate with existing UIs. Something like this is very important to all external services we bring in, because our Product Design should feel like one.

Were also using Courier at laserfocus (https://laserfocus.io) for e-mail and it has been fantastic so far.