lawrjone

I enjoyed this being your final post before you left. Quite the swan song.

Posting this on behalf of my colleague (sadly ex as of yesterday, this was his swan song) Rory and team who did a bunch of really interesting digging into why Postgres was struggling with our queues.

I'd dealt with multixact about a decade ago when I had to dig into the Postgres source to figure out how they worked, they're quite a hidden/undocumented (or at least were back then) part of the system.

Glad he spent the time writing this up.

I don’t understand how you’ve reasoned your way here.

How could Jev have possibly built something out of reach of a frontier lab providing the same or 5x as much resourcing to one of their teams to achieve? Which they can do because Jev has only received $40M of funding recently, so a round that is approximately what OpenAI is spending per math problem they try cracking.

In addition to that, these frontier labs have got extremely good at generating synthetic data and running generalised training pipelines. I can only imagine how easy it would be for them to build this internally vs Jev building it from scratch.

And then the final thing: one of the best places you might apply Jev is within a harness, behind layers that customers increasingly have abstracted from them. Frontier labs have huge incentives to do this as it could make their offering much better and cheaper. And whoever gets this first wins another big attraction for users.

My take on this is Jev is either acquired almost immediately for the benefit of the next 1-3 months head start for whichever lab acquires them or we get a similar model offered from all labs in 3-6 months or sooner.

Author here! Wrote this for engineers who are using these tools but want a deeper understanding of how they work.

It’s a write up of what I’ve learned from building support for skills and MCPs into our agent harness, so comes from very practical experience.

Generally just very useful to have it clickable or copyable from the commit is the thing?

Along with models being much better and more direct to follow something if it’s there. An agent will always read commits to look at a change, force it to look at commits and check another index just in case it exists is slower and pays more tokens, now you can just grab it.

But also mostly because who would actually care about this. It’s a sentence on the end of a git commit, in what way does this annoy people other than their prior feelings about AI tech.

It’s not meant for saying “this change was done by Claude” it’s meant to connect commits back to the session. Makes it way easier to jump back into a follow up change between sessions as the agent can reload parts of the context.

Anyone thinking this is about tagging AI generated changes and not just making the experience in Claude better is missing the point of the feature.

It’s really useful for helping agents navigate history and maintain continuity between sessions. So wouldn’t assume it’s for marketing, it has a lot of utility.

As a Claude user this is just a benefit to me. Means I can grab the session and resume if I ever see a commit I want to jump back into, and Claude can read these sessions itself whenever I reference the commit, which helps a bunch.

It might come with advertising benefits for them but expect it’s mostly just because it helps their tools work and that benefits everyone.

Am I misunderstanding this change? This makes it sound like Claude is attaching the entire session content when I thought it was only a link that is exclusively readable by the author, unless deliberately shared?

Fwiw to acquire a banking license and get the relevant approvals I believe you need to prove a redundancy plan that goes beyond just scaling.

I used to work in fintech where we’d face the same requirements and know a bunch of folks from Monzo. You can fight the status quo only for so long until it becomes much easier to just do what you’re being asked and produce a totally separate service that solidly answers any audit you may face.

You’d use it because until recently Cursor had the best setup for cloud agents and visual verification and a bunch of other features outside of the harness.

They are deciding on the merits of the model right? They’re picking the model that’s supported in most tools.

I think maybe you’re suggesting private companies should be forced to support all models which is a position that isn’t technically feasible or one that most would agree is even a sensible ideal.

I work with Johanna (author) on the incident team. It’s been pretty cool watching this roll out, been particularly great that I’ve barely had to think about the replicas when working with the code.

The wiring to route to either replica or primary is very transparent. Seen this done several times before and it’s never been quite as easy to have your code just do the Right Thing.

We have found similar when plugging GLM 5.2 into actual benchmarks in our product. The open-source models are really dialled into the public benchmarks, until you try them in context you won't have a solid idea of how they perform (Sonnet is a higher quality model than 5.2, both in prose, reasoning, and alignment).

Most companies have legal agreements called "Zero Data Retention" with these providers that bans them from storing any data that you send them (we are one of those companies).

The difference here is that for the first time Anthropic have said that's not available for 'Mythos class' models.

I'm on the team who built this, I don't understand how you think these would be used. We need to use a b-tree index to give us ordered results that we then filter by the bloom column, how would an index on the bloom filter column help if we need the ordering?

Context is we didn't think these would work, and did look quite closely. We may have missed something though.

We use CC to power some of our code features and override this setting so we can provide our own attribution. So there are several legit reasons to permit this.

Ah that's fun, glad we could help them out here!

I hadn't come across GPTZero before and wondered if it worked. Just testing on a sample of my blog posts (I do one each year) I got a 100% AI generated mark for a post in... 2022, and 2023. Both before AI tools were around.

Not to say this post isn't AI generated but you might want a better tool (if one exists)

This is my colleague Mike’s write-up about using bloom filters to make our list alerts endpoint much faster for filtering and pagination.

In a past life I’d struggled a lot with a public API that had some really tricky pagination performance problems. It was something we were always fighting, be it awkward edge case data shapes or the Postgres planner having bad statistics, where everything would get difficult past >5TB in the table.

Was really happy to see the team find a solution that feels scalable and can be generically applied to a lot of our endpoints at incident. Quite a great outcome where I think we’ll be safely scalable for the next few years instead of hitting other problems that would crop up had we gone with gin indexes or otherwise.

Am one of the engineers who responded to this incident. Lots of lessons to be learned, was a painful Monday.

Happy to have fixed up a bunch of these issues already though.

I'm one of the engineers at incident.io, so thanks for the mention! But yes, when we first started the majority of our customers bought us for incident management and used PagerDuty as their on-call provider (phones them, receives the alerts, hands-off to us when an incident starts).

We've since built on-call directly into our product and we've had loads of those customers migrate entirely into us, dropping PagerDuty. The biggest customers we're onboarding now tend to buy us as their sole on-call and incident management tool, too.

We have a bunch of case studies of people who've moved if that's useful to anyone. My favourite is probably Intercom who migrated from PagerDuty into our on-call in a few weeks (the Intercom team are great fun to work with!)

https://incident.io/customers/intercom

Always makes me laugh when people pick company names that are domains and spend their life fighting incorrect capitalisation.

I work at incident.io it's a daily struggle.

Author here, thanks for posting!

Would be interested if anyone else sees these dynamics playing out. It seems there’s a really powerful combination of larger players starting later and a rising tide of AI improvements that mean the smaller shops can leap frog ahead, in ways that I haven’t seen before.

Urgh, alongside Opsgenie shutting down that’s a lot of people whose paging solution has just EoL’d.

It’s an alerting/incident response incumbents thing. Ask anyone how much PagerDuty/Opsgenie have improved in the last decade and you’ll have the answer!

There’s a first wave of incident startups that responded to the market having stagnated about 4 years ago (incident.io, FireHydrant, Rootly) then a slew of extremely recent (<1 year) companies leaning into AI incident response.

It’s weird that Opsgenie is just quitting that race but realistically they weren’t really competing in terms of pace of development. Felt more like Opsgenie was bought under the assumption IR was a ‘solved’ problem that Atlassian could just add to their stack and be done with it, while today it’s increasingly apparently that just paging someone is the smallest part.

I work at incident.io and we’ve had to help a number of our customers who were affected by this. While Atlassian frame it like you can migrate, there’s no official migration story and the feature lists don’t match at all.

We’ve got a good migration story (import OG schedules and escalation paths, etc) so most customers just migrate to us, but if you didn’t have that option the Atlassian migration is much more painful.

This really sucks, that is rough. When you’re buying from a company like Atlassian you don’t expect this to happen really.

The writing has been on the wall for a while with Opsgenie though. I work at incident.io and loads of our customers have had deprecation/migration warnings for a year or so now, pushing them away from Opsgenie and into different Atlassian products (with no migration plan, sadly).

It’s been great for us as they tend to move to us (we have good migration support for Opsgenie) but confusing to watch from the outside as Atlassian never stopped selling the product even while actively shutting accounts down.

I mean, AI is just matrix multiplication, amirite?

Pretty reductive argument honestly. AI services mean that a lot of AI operations are 'just HTTP requests' but it doesn't mean there isn't a huge amount of tooling that you need to work effectively with them.

AI tooling in this case being:

- Fine-tuning - Eval test suites - Observability based around AI interactions

Would you call Lovable a basic app that makes API calls? Or is it AI enough to justify the label?

Asking as they made a move from Python to Go just the other day for similar reasons as in this post: https://lovable.dev/blog/from-python-to-go

I'm the author of that MacBook blog post. I wouldn't say it was a waste of time, in that it helped us feel very confident about the ROI for upgrading, and the results have been really meaningful for our team.

I wouldn't agree exactly with the article, in that while it's very easy to start making decisions that are genuinely ROI silly (all companies make them, my current one not excluded) there is a balance between just paying without question and adding friction that encourages good decision making.

But in our case, getting the data wasn't too much effort, and helped inform us for a subsequent batch of hardware purchases. It ended up representing about $50k of spend that we'd like to allocate well, and took me a couple of days to investigate and write-up: my day rate means that was well worth it.