Mesa is building GitHub for AI Agents. We create new kinds of infrastructure and human interfaces for AI-driven software development. We are currently a team of 7 (all engineers), looking to add a few more highly autonomous SWEs.

Comp: $180k - $275k, 0.2% - 2% equity

Sound like a good fit? Email founders@mesa.dev

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

Points: 2

# Comments: 0

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

Points: 3

# Comments: 1

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

Points: 1

# Comments: 0

We recently open-sourced a small tool we built internally to help answer a question we couldn't find a good solution for: How do you evaluate AI coding agents on a real production codebase?

Like most teams, we had lots of opinions about which agents and models "felt" best, but no hard data. The missing piece wasn’t analysis; it was attribution. We needed to know which lines of code were written by which agent/model, without changing how engineers work.

The key insight was that Git already gives us most of what we need.

By reverse-engineering how tools like Cursor and Claude Code modify files, we attach attribution metadata directly to Git whenever an AI agent edits code. Engineers don’t have to opt in or change their workflows.

Once that data exists, we can run fairly simple queries to answer questions like:

- merged lines per dollar by agent/model

- bug rates correlated with AI-generated code

- how different developers actually use AI in practice

An unexpected side effect was code review: once we surfaced AI attribution in pull requests, reviews got faster because reviewers could focus on AI-generated code in sensitive areas.

We've open-sourced the data capture layer and code review extension so other teams can experiment with this approach. For us, the most valuable part wasn't which agent "won," but finally having a way to measure it at all.

Happy to answer questions or hear critiques.

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

Points: 5

# Comments: 2

- No manual configuration required - Works out-of-the-box on most data types (ex. people, companies, product catalog)

Implementation details:

- Embeds records using an E5 model - Performs similarity search using DuckDB w/ vector similarity extension - Does last-mile comparison and merges duplicates using Claude

Demo video: https://youtu.be/7mZ0kdwXBwM

Github repo (Apache 2.0 licensed): https://github.com/SnowPilotOrg/dedupe_it

Lmk any feedback on how to make this better!

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

Points: 4

# Comments: 2

- No manual configuration required

- Works out-of-the-box on most data types (ex. people, companies, product catalog)

Implementation details:

- Embeds records using an E5-family model

- Performs similarity search using DuckDB w/ vector similarity extension

- Does last-mile comparison and merges duplicates using Claude

Demo video: https://youtu.be/7mZ0kdwXBwM

Github repo (Apache 2.0 licensed): https://github.com/SnowPilotOrg/dedupe_it

Background story: My company has a table for tracking leads, which includes website visitors, demo form submissions, app signups, and manual entries. It’s full of duplicates. And writing formulas to merge those dupes has been a massive PITA.

I figured that an LLM could handle any data shape and give me a way to deal with tricky custom rules like “treat international subsidiaries as distinct from their parent company”.

The challenging thing was avoiding an NxN comparison matrix. The solution I came up with was first narrowing down our search space using vector embeddings + semantic similarity search, and then using a generative LLM only to compare a few nearest neighbors and merge.

Some cool attributes of this approach:

- Can work incrementally (no reprocessing the entire dataset)

- Allows processing all records in parallel

- Composes with deterministic dedupe rules

Lmk any feedback on how to make this better!

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

Points: 5

# Comments: 5

1. Assign, then save. AFAIK, this is effectively transactional if you're saving a single object, since it's a single `UPDATE` statement in sql. If you assigned to a related object, you need to save that separately.

2. Use ActiveRecord functions like `post.update({title: "foo", content: "Lorem ipsum"})`. This assigns to the in-memory object and also kicks off a request to the DB. This is basically syntax sugar over assigning and then calling `save()`, but addresses the issue around devs forgetting to call `save()` after assigning. In Rails, this is used in 90% of cases.

3. I can also choose to wrap mutations in a transaction if I'm mutating multiple proxy objects, and I need them to succeed/fail as a group. This is rarely used, but sometimes necessary. For example, in Rails, I can write something along the lines of this:

```rb

ActiveRecord.transaction do

  post.title = "Foo"

  post.author.name = "John Smith"

  post.save()

  post.author.save()

# Alternatively, using the `update()` syntax

ActiveRecord.transaction do

  post.update({ title: "Foo" })

  post.author.update( { name: "John Smith" })

```

This gives transactional semantics around anything happening inside of the `do` block. I think the syntax would look very similar in javascript, for example:

```js

transaction(() => {

  post.update({ title: "Foo" })

  post.author.update( { name: "John Smith" })

```

Naively, it seems more verbose than necessary.

Also, I like that in Rails, there are ways to mutate just in memory, and then ways to push the change to DB. I can just assign, and then changes are only pushed when I call `save()`. Or if I want to do it all-in-one, I can use something like `.update(..)`.

In the browser context, having this separation feels most useful for input elements. For example, I might have a page where the user can update their username. I want to simply pass in a value for the input element (controlled input)

ex.

```jsx

```

But I only want to push the changes to the db (save) when the user clicks the save button at the bottom of the page.

If any changes go straight to the db, then I have two choices:

1. Use an uncontrolled input element. This is inconvenient if I want to use something like Zod for form validation

2. Create a temporary state for the WIP changes, because in this case I don't want partial, unvalidated/unconfirmed changes written to either my local or remote db.

In ActiveRecord, I can do this:

```rb

post = Post.find_by(author: "John Smith")

post.author.email = "john@example.com"

post.save

```

In React/Vue/Solid, I want to express things like this:

```jsx

function BlogPostDetailComponent(...) {

  // `subscribe` or `useSnapshot` or whatever would be the hook that gives me a reactive post object

  const post = subscribe(Posts.find(props.id));

  function updateAuthorName(newName) {
    // This should handle the join between posts and authors, optimistically update the UI

    post.author.name = newName;

    // This should attempt to persist any pending changes to browser storage, then
    // sync to remote db, rolling back changes if there's a failure, and
    // giving me an easy way to show an error toast if the update failed. 

    post.save();
  } 

  return (
    <>
      ...
    
  )

```

I don't want to think about joining up-front, and I want the ORM to give me an object-graph-like API, not a SQL-like API.

In ActiveRecord, I can fall back to SQL or build my ORM query with the join specified to avoid N+1s, but in most cases I can just act as if my whole object graph is in memory, which is the ideal DX.

I appreciate that you're thinking about relational data and about permissions. I've seen a bunch of sync engine projects that don't have a good story for those things.

imo, the more that you can make the ORM feel like ActiveRecord, the better.