[kentonv]

I mean... I don't like it either but this is pretty standard stuff and it's obvious why they're doing it.

Claude, ChatGPT, Gemini, and Grok are all more or less on par with each other, or a couple months behind at most. Chinese open models are also not far behind.

There's nothing inherent to these products to make them "sticky". If your tooling is designed for it, you can trivially switch models at any time. Mid-conversation, even. And it just works.

When you have basically equivalent products with no switching cost, you have perfect competition. They are all commodities. And that means: none of them can make a profit. It's a basic law of economics.

If they can't make a profit, no matter how revolutionary the tech is, their valuation is not justified, and they will be in big trouble when people figure this out.

So they need to make the product sticky somehow. So they:

1. Add a subscription payment model. Once you are paying a subscription fee, then the calculus on switching changes: if you only maintain one subscription, you have a strong reason to stick with it for everything.

2. Force you to use their client app, which only talks to their model, so you can't even try other models without changing your whole workflow, which most people won't bother to do.

These are bog standard tactics across the tech industry and beyond for limiting competitive pressure.

Everyone is mad about #2 but honestly I'm more mad about #1. The best thing for consumers would be if all these model providers strictly provided usage-based API pricing, which makes switching easy. But right now the subscription prices offer an enormous discount over API pricing, which just shows how much they are really desperate to create some sort of stickiness. The subscriptions don't even provide the "peace of mind" benefit that Spotify-like subscription models provide, where you don't have to worry about usage, because they still have enforced usage limits that people regularly hit. It's just purely a discount offered for locking yourself in.

But again I can't really be that mad because of course they are doing this, not doing it would be terrible business strategy.

[cmrdporcupine]

I'm not "mad", I'm "sad" -- because I was very much on "Team Anthropic" a few months ago ... but the tool has failed to keep up in terms of quality.

If they're going to close the sub off to other tools, they need to make very strong improvements to the tool. And I don't really see that. It's "fine" but I actually think these tools are letting developers down.

They take over too much. They fail to give good insights into what's happening. They have poor stop/interrupt/correct dynamics. They don't properly incorporate a basic review cycle which is something we demand of junior developers and interns on our teams, but somehow not our AIs?

They're producing mountains of sometimes-good but often unreviewable code and it isn't the "AI"'s fault, it's the heuristics in the tools.

So I want to see innovation here. And I was hoping to see it from Anthropic. But I just saw the opposite.

[kentonv]

There is so much low-hanging fruit in the tooling side right now. There's no way Anthropic alone can stay ahead of it all -- we need lots of different teams trying different things.

I myself have been building a special-purpose vibe-coding environment and it's just astounding how easy it is to get great results by trying totally random ideas that are just trivial to implement.

Lots of companies are hoping to win here by creating the tool that everyone uses, but I think that's folly. The more likely outcome is that there are a million niche tools and everyone is using something different. That means nobody ends up with a giant valuation, and open source tools can compete easily. Bad for business, great for users.

[cmrdporcupine]

Yep. And in a way this has always been the story. It's why there's just so few companies making $$ in the pure devtooling space.

I have no idea what JetBrain's financials are like, but I doubt they're raking in huge $$ despite having very good tools & unfortunately their attempts to keep abreast of the AI wave have been middling.

Basically, I need Claude Code with a proper review phase built in. I need it to slow-the-fuck-down and work with me more closely instead of shooting mountains of text at me and making me jam on the escape key over and over (and shout WTF I didn't ask for that!) at least twice a day.

IHMO these are not professional SWE tools right now. I use them on hobby projects but struggle to integrate them into professional day jobs where I have to be responsible in a code review for the output they produced.

And, again, it's not the LLM that's at fault. It's the steering wheel driving it missing a basic non-yeet process flow.

[porker]

> Basically, I need Claude Code with a proper review phase built in. I need it to slow-the-fuck-down and work with me more closely instead of shooting mountains of text at me and making me jam on the escape key over and over (and shout WTF I didn't ask for that!) at least twice a day.

It sounds like you want Codex (for the second part)

[hakanderyal]

Try plan mode if you haven't already. Stay in plan mode until it is to your satisfaction. With Opus 4.5, when you approve the plan it'll implement the exact spec without getting off track 95% of the time.

[cmrdporcupine]

It's fine, but it's still "make big giant plan then yeet the impl" at the end. It's still not appropriate for the kind of incremental, chunked, piecework that's needed in a shop that has a decent review cycle.

It's irresponsible to your teammates to dump very large giant finished pieces of work on them for review. I try to impress that on my coworkers, and I don't appreciate getting code reviews like that for submission, and feel bad if I did the same.

Even worse if the code review contains blocks of code which the author doesn't even fully understand themselves because it came as one big block from and LLM.

I'll give you an example -- I have a longer term bigger task at work for a new service. I had discussions and initial designs I fed into Claude. "We" came to a concensus and ... it just built it. In one go mainly. It looks fine. That was Friday.

But now I have to go through that and say -- let's now turn this into something reviewable for my teammates. Which means basically learning everything this thing did, and trying to parcel it up into individual commits.

Which is something that the tool should have done for me, and involved me in.

Yes, you can prompt it to do that kind of thing. Plan is part of that, yes. But planning, implement, review in small chunks should be the default way of working, not something I have to force externally on it.

What I'd say is this: these tools right now are are programmer tools, but they're not engineer tools

[teiferer]

> Which means basically learning everything this thing did

I expect that from all my team mates, coworkers and reports. Submitting something for code review that they don't understand is unacceptable.

[8note]

i think the review cycles weve been doing for the past decade or two are going to change to match the output of the LLMs and how the LLMs prefer to make whole big changes.

i immediately see that the most important thing to have understand a change is future LLMs more than people. we still need to understand whats going on, but if my LLM and my coworkers LLM are better aligned, chances are my coworker will have a better time working with the code that i publish than if i got them to understand it well but without their LLM understanding it.

with humans as the architects of LLM systems that build and maintain a code based system, i think the constraints are different, and that we dont ahve a great idea on what the actual requirements are yet.

it certainly mismatches with how we've been doing things in publishing small change requests that only do a part of a whole

[0x457]

Well, if the plan is large, it splits into stages and asks if it needs to continue when it's done with a stage. This is a good time to run `git diff` and review changes. You review this code just like you would review code from your coworker.

[mormegil]

> I have no idea what JetBrain's financials are like

In 2024, ~725 M$ total revenue, ~119 M$ net profit.

[cmrdporcupine]

(Also, Kenton, I'd add that I'm an admirer more broadly of your work, and so if by chance you end up creating some public project commercial or open source in the general vein we're talking about here, I'd love to contribute)

[vrosas]

> And that means: none of them can make a profit

Well, no. It just means no single player can dominate the field in terms of profits. Anthropic is probably still losing money on subscribers, so other companies "reselling" their offering does them no good. Forcing you to use their TUI at least gives them control of how you interact with the models back. I'm guessing but since they've gone full send into the developer tooling space, their pitch to investors likely highlights the # of users on CC, not their subscriber numbers (which again, lose money). The move makes since in that respect.

[bambax]

Well, yes. When competition is "pure and perfect" then profits eventually tend to be zero. That's a law of economics that is always true regardless of the industry.

[bambax]

> The best thing for consumers would be if all these model providers strictly provided usage-based API pricing

Using openrouter myself I find the costs of APIs to be extremely low and affordable? I don't send the whole codebase to every question, I just ask about what I need, and everything is actually ridiculously cheap? $20 lasts about 3 months.

[wiether]

I tried to plug CC on my OpenRouter account, and just asking it what my project was doing (a directory containing three .sh of around 100 LOC each), I saw like 20 API requests to OpenRouter accounting for almost $1 in total.

Meanwhile copy/pasting those shells in OpenRouter's Chat and asking the same question resulted in a single API request costing a tenth of a cent.

I could probably try tuning everything to keep costs down, but idk if it's worth the efforts.

[oooyay]

I don't actually think Claude Code is very good and this is exactly why. It's not really optimized to use its tools efficiently. I think Cursor probably does a better job of that but I imagine all of these coding assistants will come with some form of local tooling support in the way of vector DBs etc one day.

[nake89]

I have not had the same experience. I pay 10 dollars a month for GitHub Copilot, where I get to use Claude Sonnet 4.5.

I tried the same with OpenRouter and I used up 2.5 dollars in a day using Sonnet 4.5. Similar use on copilot has could maybe make me use 10% of my quota (and that's being generous for OpenRouter).

I think GitHub Copilot is way more affordable than OpenRouter.