News for hackers. Stuff that matters.

keks0r

Show HN: Chkit – Schema, migrations and backfills for ClickHouse (like Drizzle)

https://github.com/obsessiondb/chkit

Hey HN, im Marc, co-founder of ObsessionDB. We are open sourcing ChKit, our tooling to manage schemas, migrations and backfills for clickhouse.I am a big fan of the type safety drizzle provides for the database. Manage the schema in typescript and generate migrations from it is a powerful workflow. I always wished something like it would exist for clickhouse, so we could manage our analytical...

( Read More... | no comments | 6 points | on HN )
The bundling is pretty interesting, does this also work on repo level? e.g. I have added some sales skills into our company brain, but for sessions that others would do, if they are not doing sales related tasks, they would not require any of it. But I still want to be able to directly invoke one of my sales related skills directly.
One of the things that was most challenging and still rough around the edges are backfills. Doing a BC breaking schema change in a chain of materialized view and repopulating can take a week or more for a big dataset. So having stable tooling to help guide that change was super helpful for some of our past migrations.
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?

Show HN: Rudel – Claude Code / Codex sessions reveals 9 types of AI coder

https://app.rudel.ai/wrapped

Claude Code / Codex session metadata can actually tell a story about how you work with AI coding agents.50 days ago we posted about analyzing 1.6k Claude Code sessions from our own team. Skills were used in 4% of sessions, 26% were abandoned early, and we had no real benchmark for what good looked like.Now across 20k+ sessions, we started looking at behavior patterns from derived session...

( Read More... | no comments | 4 points | on HN )
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.

Show HN: We analyzed 1,573 Claude Code sessions to see how AI agents work

https://github.com/obsessiondb/rudel

We built rudel.ai after realizing we had no visibility into our own Claude Code sessions. We were using it daily but had no idea which sessions were efficient, why some got abandoned, or whether we were actually improving over time.So we built an analytics layer for it. After connecting our own sessions, we ended up with a dataset of 1,573 real Claude Code sessions, 15M+ tokens, 270K+...

( Read More... | 91 comments | 88 points | on HN )

Older »