HN user
Mesa | San Francisco - On-site | Software Engineers (Senior+) | https://mesa.dev/
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
OP here.
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.
looks cool. do you have any case studies of people using this for big refactors?
not quite what you're describing, but I open-sourced a fuzzy deduplication tool last week: https://dedupe.it Would be interested in expanding it to deal with data cleaning more broadly
Appreciate the kind words! Linear scaling in terms of speed and cost. We haven't yet optimized the prompts & choice of model to minimize token usage, so I'd recommend emailing us for advice if you want to run this on a large dataset
Thanks! Yeah, we'd do a GSheet extension if there's enough interest. Privacy-wise, we don't store any data. Local-only isn't a priority, but should be easy to self-host if you take a look at the Github README.
Very cool :) I initially tried something like this, but had trouble getting reliable results without tuning my distance functions to the specific schema & domain. Did you find a way around that?
Congrats on the launch! One piece of feedback - I find the tagline confusing. I had no idea what "post-code tasks" meant until I clicked around and saw a few examples.
Congrats guys, this looks great. Definitely would've used Dittofeed for some previous projects.
@stopachka, sorry for late reply. I've mostly provided my ideal API in the posts above. I think my answer to transactions and forgetting save is to offer a few options, as in ActiveRecord. From what I recall, Rails gives a few ways to make persistent changes:
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" })
```
Maybe a dumb question, but why do I have to wrap in `db.transact` and `tx.*`? Why can't I just have a proxy object that handles that stuff under the hood?
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
<input value={user.name} ... />
```
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.
I really want an ActiveRecord-like experience.
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.
This is awesome. I know that a lot of people are looking for something like the Linear sync engine.
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.
This is so epic. One of the fundamental challenges in mainstreaming personal aviation is the difficulty of learning to fly. If you can make it 10x easier, it will be a massive step forward. Good luck and congrats on the progress so far!
fantastic. ill give it a go!
Great concept. Needs a little refinement, but I really miss the ease-of-use of Azure DevOps now that I'm on GH. Excited to test it out
Btw, is it open-source?
Interesting, will try this. I imagine "symmetric" is not the correct term, but what is? I imagine there are constraints on types of random variables for which this will work, but I haven't looked into it deeply.
tl;dr: Gaussians show up when you add together enough small random effects. The notebook has some code and prose that shows why that's the case both for human height and for manufacturing wooden doors.
Typical California. The problem is excessive regulation and zoning laws preventing private developers from building. And California proposes more government... This only works in Singapore because it has the world's most competent and least corrupt civil service.
The US doesn’t block other countries from trading with Cuba. Only the US itself doesn’t trade with Cuba. Embargo, not blockade.
Those anti-competition laws are only applicable when a company is using market dominance to exclude new entrants, distorting the free market. Not true in this case. Lots of small companies are not inherently economically better than big firms. It totally depends on the maturity of the market in question. Large firms gain economies of scale, and can pursue opportunities with large upfront capital requirements.
Artificial Intelligence
The matching engine on the exchange is also automated. The settlement system is electronic. Etc. etc.
Are you familiar with quadratic voting? It takes into account much of what you’re taking about, with the benefit of being less gameable.
Definitely agree. Also, one minor point: PoW/PoS are technically Sybil control mechanisms, not consensus mechanisms. PoW/PoS rate-limit block producers, but actual consensus is achieved by something like Practical Byzantine Fault Tolerance. There are only a few blockchains that actually use a different mechanism for consensus, such as Avalanche.
Sybil control mechanisms like PoW, PoS, and PoH are intended to rate-limit block producers, in order to prevent any one entity from controlling the network. In Bitcoin PoW, a block is produced every 10 mins, and your chance of getting to propose the next block is related to your hash power. All block producers are competing for the same slot in the blockchain.
As I understand PoH, blocks are instead continually proposed, but block producers are rate-limited by having to show completion of an operation similar to a verifiable delay function. Therefore, block producers avoid having to all compete for the same slot in the blockchain and duplicate lots of work. This is actually a novel Sybil control mechanism that is more efficient than standard PoW/PoS. It's somewhat analogous to the difference between a dedicated communication channel (as in landline phones) and a packet-switched communication channel (as in the internet).
The catch is that the PoH operation approximates a verifiable delay function, but is not currently proven to be equivalent to one. So there's the possibility of a black swan event where someone discovers a clever way to speed up the PoH operation, allowing them to cheaply control the network. Another knock against Solana is that although it has innovated in transaction efficiency, its token distribution/crypto-economics may be less "fair" than competitor blockchains. Please correct me if you spot any mistakes.
If there were two, or ten, food safety inspection groups, we could figure out which ones had trustworthy ratings. No need for end consumers to inspect every restaurant (every app) individually. That's what Epic is asking for - to have its own app store on iOS.
Not all crypto assets are crypto currencies. Many DeFi tokens (ex. UNI, SUSHI, AAVE) govern projects with real cash flows and are poised to become more like equities on the blockchain
This idea comes from Modern Monetary Theory (MMT). Most mainstream economists do not agree with it. But the MMT claim is that at base, people only need USD because it’s how taxes are denominated. The notion is that without the driving force of compelled taxation, no one would use USD or other sovereign currencies. MMT also claims, through similar logic, that a monetary sovereign can print an extreme amount of currency without causing inflation. Which MMT’ers use to justify massive government spending programs.