[1] https://github.com/spacedock-dev/mermaidtext

[2] https://github.com/spacedock-dev/subspace-beta

Comments URL: https://news.ycombinator.com/item?id=48728882

Points: 1

# Comments: 1

related: I made https://github.com/clkao/agentlore can aggregate logs across team, and sharable with permalink. the logs are processed by agentsview, which supports multiple coding agents.

I built this because I wanted to understand my own agent usage patterns. I mostly use Claude Code, and agentsview was already doing the hard work of collecting sessions locally.

Then I wanted to sync sessions across my machines so everything was searchable in one place. When I found interesting new approaches with coding agents (superpowers, gsd, higher-order prompting) that I wanted to share with friends and teammates. I ended up creating gists, which is a terrible way to share conversations.

These clicked together into agentlore. A daemon watches agentsview's local database, masks secrets, and syncs conversations to ClickHouse. A web UI lets you browse, search, and filter across all your sessions.

The part I'm most excited about is git linking. Agentlore parses tool calls for git commit and gh pr create invocations, extracting commit SHAs and PR URLs. So you can go from a commit to the full conversation that produced it. Every conversation gets a shareable permalink, so you can drop it in a PR comment or Slack and people can see exactly what happened.

What I'm hoping to see play out:

- Review agents should get more accurate when they have the conversation context, what was intended and what was manually tested, not just the diff. - People can learn from each other. Someone figures out a better way to prompt for refactoring, the whole team can see how they did it. - Context stops disappearing. When you pick up code someone else wrote with an agent, the conversation is right there instead of lost on their machine.

This is early and likely broken in places. Would love feedback.

Demo: https://demo.agentlore.io/sessions/589b7dd5-93ad-4dc0-8e6f-d... (the conversation the built this project. you can see all subagent sessions, but not all commits are captured yet)

[0] https://github.com/wesm/agentsview

Comments URL: https://news.ycombinator.com/item?id=47275986

Points: 2

# Comments: 1

Verifying schema changes pre-production is only part of the issues, figuring out the actual data changes caused by code logic changes is trickier.

Comments URL: https://news.ycombinator.com/item?id=41470437

Points: 2

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=41348425

Points: 2

# Comments: 0

[1] https://github.com/uwdata/mosaic

Comments URL: https://news.ycombinator.com/item?id=39925257

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=39423617

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=39257431

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=39183590

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=39008266

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=37454070

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=37405130

Points: 2

# Comments: 0

Why? In a previous life I worked on distributed version control systems[1] prior to git, weird data systems like in-postgres REST server with plv8, and building civic tech communities with open data. It always startled me when some new characteristics of data were uncovered, and we had to change some data schema & modeling and then recheck all downstream uses of the data (if we even could).

Fast forward to the modern era of data systems, the data engineering stack is certainly becoming more like the software engineering stack, with dbt as of one of the main game changers. But the engineering practices and tooling~~s~~ aren’t quite there, yet.

We are building the missing pieces of the “data-pipeline-as-code” puzzle, by making pull-requests on data systems more informative and bringing confidence to reviewing and testing the impact of code-change. Here’s an example PR of the campaign finance project[2]. The goal is to augment the CI process to help teams move faster when making data and pipeline logic changes, by being aware of intentional and unintentional downstream models and metrics impact.

As a version control nerd, I personally love semantic-aware diffs that can help inform stakeholders, such as diff formatted law amendment proposals in congressional bills. So, what can we do for complex data systems that are now pull-request-able? One thing is the "lineage diff" - A way to visualize the data models you are adding or making changes to, and help you to make sense of the impact.

Here's another example based on a pull request in the Danish Parliament data[3] dbt project[4] (Note the lineage diff is part of advanced impact analysis which is not open source)

You can try out Lineage Diff in this online viewer[5], by uploading two manifests from your dbt project to see the impact on lineage from your code-changes.

I’d love your feedback!

[0] https://piperider.io/

[1] https://news.ycombinator.com/item?id=32668334

[2] https://github.com/g0v/tw_campaign_finance/pull/2

[3] https://github.com/bgarcevic/danish-democracy-data/pull/8

[4] https://cloud.piperider.io/clkao/default/runs/33a74e0bef5f48...

[5] https://cloud.piperider.io/online-viewer

(Edit: link formatting)

Comments URL: https://news.ycombinator.com/item?id=37403960

Points: 25

# Comments: 3