drob

Sometimes, but I think there are a few problems with this:

1. Some context doesn't have an obvious place to write it in the code. If you're explaining why a tricky function is implemented a certain way, you can leave the explanation above the function or within the function. If you're explaining something more general, there might not be a natural place to put it.

2. Relatedly, some context doesn't have an obvious location to read in the code. E.g. you can comment on a schema that a table is intended to be append-only, but an agent could easily miss this comment if it doesn't gather context all the way down to the raw schema. Any research process has unknown unknowns. There may not be a canonical place to look.

3. Adding comments for every single human intent might be a bit noisy. E.g., if a code reviewer flags something that I know isn't a bug, I want the system to learn from this, and I want that knowledge to take effect outside of just code review, but I might not want every single code review thread to yield a codebase comment.

We should publish some stats. The fix rates on bugs are around 45% baseline, increasing over time as we learn from behavior within a given codebase. The merge rates for the codebase health work we do (e.g. deleting dead code) are very high, at least 90%.

Agreed that domain experts should be making these kinds of decisions, and the right way for an agent mistake to get caught is going to depend a lot on the cost and probability of the mistake. My only point here is that the agent side of the system needs to learn. The software production machine needs to improve over time.

Author here, hello! Happy to expand on how we're thinking about this if any of it is unclear.

We wrote this post as part of a launch, which you can check out here: https://x.com/danlovesproofs/status/2095182189499711759

Should work fine. Ping me dan@detail.dev or @danlovesproofs with your account info so we can look into it?

We've been thinking about this too. We have some ideas. Thanks for the comment, in any case – gave us a lot to chew on.

Other auth providers for sure. We'll be adding shortly.

Using an alternate auth provider won't even prevent you from scanning non-public GitHub code. There's a GitHub OAuth App just for auth (which is what you're seeing here), and a separate GitHub App that you need to install either way to give Detail access to the right repos. We can swap out the former for Google/Okta/pw if you want to avoid this warning. GitHub Apps (the half that manages repo access) have a much finer grained permissions model.

As far as we can tell this is a github-ism, and any OAuth permission is a form of "acting on your behalf": https://dappling.medium.com/a-github-app-would-like-to-act-o...

Hi bflesch, fair point – our About Us page has a lot about what we think and not about... us!

I'm the founder. Previously I was at Heap for nine years. There's a company LinkedIn with the rest of the team: https://www.linkedin.com/company/detail-dev/

We're located in SF. The About Us page lists some of our angel investors at the bottom.

Regarding security in particular, there's a lot more info in our Trust Center: https://trust.detail.dev/

If anything else seems conspicuously missing, please flag. In all likelihood it's omitted without intent.

We've run it on a few firmware repos and gotten good results. A lot of firmware code tends to have really poor type-safety which means lots of low-hanging bugs.

We should be able to handle cross-compilation. Want to try it? Ping me in any direct channel (dan@detail.dev / @danlovesproofs) and we can keep an eye on your repo.

Just github for now, but purely for reasons of plumbing. We'll add gitlab and others.

We support java, c/c++, kotlin, ruby, and swift as well. Did you have something specific in mind?

Github only for now. Out of curiosity, is yours on gitlab? Something else?

We should be able to find something interesting in most codebases, as long as there's some plausible way to build and test the code and the codebase is big enough. (Below ~250 files the results get iffy.) We've just tested it a lot more thoroughly on app backends, because that's what we know best.

Fix is deploying, sorry about that!

Fwiw, the authors never actually claimed this. From their technical report [0]:

> Chai-1 achieves a ligand RMSD success rate of 77%, which is comparable to the 76% achieved by AlphaFold3

[0] https://chaiassets.com/chai-1/paper/technical_report_v1.pdf

On a personal level I can absolutely empathize, but respectfully, I don't see why that should be the state's concern. The goal of IP law should be to promote the creation of good art, not to make sure artists' wishes are respected.

So, for example, theft should be illegal, because a world of unrestricted IP theft might be one in which we would get a lot less art. But allowing Tolkien to block adaptations of his bestseller 14 years after publication was probably not good for art.

Do bad adaptations prevent good adaptations? Lynch's Dune flopped but Villeneuve had a $165m budget.

We can't know the contrapositive but I don't see why giving the author a veto makes good outcomes more likely, especially decades after a book is published.

He owns the IP, but we all lose out from this system.

Art has asymmetric upside – bad art doesn't really harm anyone (usually just gets forgotten) but good art enriches millions of people's lives.

It might have been amazing. It might have been bad-but-interesting. We'll never know!

Zstandard gets us 5.5x compression. The previous ZFS config got us 4.4x compression.

XFS, which we ran on for years before rolling out ZFS, does not compress.

Fixed, thank you for flagging!

Fixed. Thank you again for flagging!

Ah. Yup, it is. Thank you for flagging. Will fix this.

To be clear we're talking about the state of the world around two years ago. I'm not a bottleneck for this anymore. :)

Also, this is a bit of an uncharitable read. The calculus at the time wasn't about trust per se, and more about the fact that the relationship between quality of blog content and the content's reach is nonlinear. That means it's worth taking the time to get it right, even if the people best suited to make that happen aren't super available, because the difference between getting on the front page of HN vs not is multiple orders of magnitude. (But I think we get the best of both worlds now.)

> what are your thoughts on having dedicated content writers - like technical writers or developer advocates - working on/owning the blog, vs "all engineers are explicitly encouraged to blog"?

I like this, and I think a good developer relations person who is prolific, sufficiently technical, and can get the tone right can be very valuable for building up a company's visibility. It's a good way to take 80% of the work of writing a post off the relevant engineer's plate and also produce great posts, because the person writing them is a professional writer.

We're small enough right now that we can do well enough with some ad hoc stuff, e.g. periodic slack posts to shake the tree. But this is something we discuss every now and then and the timing will be right at some point, as we scale.

It's easier to justify the cost of a full-time employee if your buyers are also primarily engineers. For someone like Stripe or Twilio, an active eng blog doubles as marketing.

:wave: hi Craig!

I'll also note that we asked Craig for eng blog advice way back in Jan 2017, and he was very helpful. :)

> One person at a company with a compelling blog noted that a downside of having only one approver and/or one primary approver is that if that person is busy, it can takes weeks to get posts approved.

Heap CTO here. I'm pretty sure this quote is about me! Or if it's not, it would be equally true about me. This is why we rolled out the "buddy" system described in this post. That way 90% of the iteration can be between the engineer writing the post and someone else who will be a lot more available than I am. This matters a lot if a post requires three or four round trips to really get it right. Plus, in a lot of cases, that other person is better at technical storytelling than I am to begin with.

I'd also note that this post and HN discussion focus a lot on reducing friction, as if having a really good blog is the state of nature. In my experience, this has not been true. A good blog won't just happen if you get out of the way.

Someone senior at the company needs to actively prioritize the engineering blog. You also need eng leadership that respects that writing posts is real work and is willing to have engineers spend time on-the-job working on them. At Heap, we do this down to the level of taking this into account in sprint planning. Also, a lot of the good ideas for posts come from working with engineers to find the kernel of a story in something they're working on. This is an active process, not something spontaneous that you just have to permit to happen.

We also benefit from having a lot of legitimately interesting technical work to talk about. This is more true at some companies than others, and is a big multiplier on how compelling you can make your blog. The success of a blog post is pretty non-linear – either it gets wide readership or not much at all. Having something interesting to talk about is pretty important, and is hard to manufacture.

Under this scheme, the only way to make more money as a law firm would be to increase your costs, so this creates an incentive to prosecute the case as expensively as possible.

The eventual endgame of this system would be that law firms’ costs should rise to eat as much of the settlement as possible, which leaves as little as possible for the actual victims.

A fixed percentage system creates an incentive to maximize the settlement (on behalf of the victims) and leaves the law firm to pay its own costs.

Ooh, check it out and let me know what you find! It would make me really happy if this post helped someone debug something when they had previously hit a dead end.

We're running a single flink cluster. Engineers can run whatever jobs they need, but we aren't writing new flink jobs that often so the load is pretty predictable. We have a single digit number of jobs at the moment.

We are on 1.3.2 at the moment, running on EC2 vms.

Iirc Ivan (post author) spent a few days tracking this down. There were some other debugging dead ends that we omitted in this writeup. One red herring was that the issue appeared to happen during the US morning, so there was some time-of-day component, and we thought it might be a system load issue.

The fix turned out to be fairly involved too – on the order of a week I think.

Ivan works from Bulgaria so sadly he is asleep right now.

Heap CTO here – would love to answer any questions you have.

This was my first exposure to btrace, which a super useful swiss army knife for JVM debugging. That made this a worthwhile adventure for sure.