rbehrends

True, but coding is where something like 80%-90% of their revenue comes from; few other use cases are as token-hungry, and none of those are nearly as widespread. Many users will of course use the models just as chatbots, but they don't generate much in terms of revenue. And that is ultimately what determines where labs focus their resources.

The primary attraction of treaps (aside from fast intersection/union/diff) is that they are probably one of the easiest types of balanced trees that can be implemented manually if you need a dependency-free balanced tree. There are only two types of rotations, they are straightforward, and they are mirror images of each other.

These days, where an agent can just write you an AVL tree, red-black tree, or B-tree library in under a minute, it probably matters less.

You said above that "Opus 5.5 still makes a lot of mistakes". This seems to contradict what you are saying here?

Yeah, but that's also a large part of why they remain interchangeable, I would say. I feel like we may be talking past each other?

I have been using Opus 5.5 (as well as pretty much all frontier models). I am not sure why you think I haven't.

If I'm not "demanding enough" from models, it's precisely because they are imperfect. Having them do long, complex tasks autonomously usually comes with more cleanup work afterwards IME.

My usual workflow (not counting throwaway code) is to use agents as virtual pair programmers, which gives me a good balance of quality and velocity.

Each interaction with the agent remains individually comprehensible and makes progress towards one of the following goals:

- Understanding the problem/solution space.

- Implementing a solution.

- Understanding the solution, especially any agent-written parts and interaction with existing code.

- Evaluating the solution (tests, code analysis, what-if scenarios, consider edge cases).

This does not just involve the model generating code, but also explaining or analyzing it as needed.

This process allows me to retain a mental model in lockstep with developing the written code and have some assurance both of its functionality and non-functional requirements. It also fits in nicely with most existing team-level workflows.

But it's also something that I can do with pretty much any of the modern models.

A couple of points.

First, it does not really reflect my experience. I find modern models to be largely interchangeable when it comes to common software engineering tasks, including some of the more recent open weight ones. The strongest models become interesting for Ph.D. level of work for me, which is not something I deal with regularly anymore.

None of them are perfect; they all have their strengths and shortcomings, but I can reasonably work with all of them and it honestly doesn't matter much anymore. I do sometimes wonder what exactly people are doing to see such a difference; at a minimum, their workflows must be very different from mine.

Second, you're arguing based on subscription pricing. But Anthropic makes the bulk of its revenue (and has its biggest margins) from enterprise/API pricing, where they are the most expensive provider by far. Anthropic isn't going to make a lot of money off your $20 subscription. With a subscription, you currently get more usage per dollar out of Anthropic's than OpenAI's plans, which approximately offsets the difference in API pricing.

Junie is integrated in the AI Assistant. It's just one of several agents you can use with it (alongside Codex and various ACP plugins). One option on a dropdown menu.