I just cancelled my Pro subscription. Turns out that Ollama Cloud with GLM-5 and qwen-coder-next are very close in quality to Opus, I never hit their rate limits even with two sessions running the whole day and there zero advantage for me to use Claude Code compared to OpenCode.
> But the entire reason it's subsidized is that Anthropic can use the data to improve their product.
This is grade A, absolute crap. It's subsidized because everyone else is subsidizing it, and everyone is doing it because they are trying to lock their consumer share.
The solution is quite simple. Just get the FTC to forbid tie-in sales so that we don't get the huge corporations using their infinite resources to outlive the competition. Anthropic/Amazon/Google/OpenAI/Facebook can offer any type of service they want, but if the access to the API costs $X when offered standalone, then that is the baseline price for anything that depends on the API to work.
I'm fine with this as well. I just dislike everyone here presenting it like this is Anthropic being unreasonable. Given the product that is offered and why it's being offered, this is completely reasonable to do.
> If they can provide a relatively cheap subscription against the direct API use
Except they can't. Their costs are not magically lower when you use claude code vs when you use a third-party client.
> For me, this is fair.
This is, plain and simple, a tie-in sale of claude code. I am particularly amused by people accepting it as "fair" because in Brazil this is an illegal practice.
> This is, plain and simple, a tie-in sale of claude code. I am particularly amused by people accepting it as "fair" because in Brazil this is an illegal practice
I am very curious what is particularly illegal about this. On the sales page nowhere do they actually talk about the API https://claude.com/pricing
Now we all know obviously the API is being used because that is how things work, but you are not actually paying a subscription for the API. You are paying for access to Claude Code.
Is it also illegal that if you pay for Playstation Plus that you can't play those games on an Xbox?
Is it illegal that you can't use third party netflix apps?
I really don't want to defend and AI company here but this is perfectly normal. In no other situation would we expect access to the API, the only reason this is considered different is because they also have a different service that gives access to the API. But that is irrelevant.
It's basically the difference between pro-market capitalism and pro-business capitalism. The value to the society comes from competition in the market and from the businesses' ability to choose freely how they do business. When those two goals are in conflict, which one should be prioritized?
Anthropic provides an API third-party clients can use. The pro-market position is that the API must be available at every pricing tier, as the benefits from increased competition outweigh the imposed restrictions to business practices. The pro-business position is that Anthropic must be allowed to choose which tiers can use the API, as the benefits from increased freedom outweigh the reduced competition in the market.
So if Claude code didn’t communicate with Anthropic’s server using a well defined public api but some obscure undocumented binary format it would be fine?
Or should every app/service be required to expose documented APIs?
The immediate pro-market position is that if third-party clients are allowed / possible, Anthropic should be allowed to favor its own clients with lower prices.
But the position can go further if the service in question can be considered infrastructure. For example, a company that owns a mobile network may be required to let virtual operators use their infrastructure for a reasonable price. And a company owning a power grid may be required to become a neutral infrastructure provider that is not allowed to generate/sell power.
Anthropic is neither a monopoly nor has a dominant market position. Generally standards applied to companies like that are very different due to good reason.
Like I mentioned somewhere else I can see why some people think they are entitled to do this and I also fully understand wanting to do it from a cost standpoint.
While I do personally disagree with thinking that you should be able to do this when it was never sold in that way, at the end of the day as a customer you can choose if you want to use the product in the way that they are saying or use something else if you don’t want to support that model.
However the person I was responding too brought up legality which is a very different discussion.
Imagine if video service came with a free TV that watched you, and was really opinionated about what you watch, and you could only watch your videos on the creeper TV.
Then I would not use it because it does not work the way I want it to work...
But if that is the service they are making and they are clear about what it is when you sign up... That does not make it illegal.
I can see why people think they should be entitled to do this, but it does not align with how they are selling the service or how many other companies sell services. In most situations you don't get unlimited access to the individual components of how a service works (the API), you are expected to use the service (in this case Claude Code) directly.
"Both parties are okay with the terms" is far from being sufficient to make something "legal".
Tie-in sales between software and services is not different from price dumping. If any of the Big Tech corporations were from any country that is not the US, the FTC would be doing anything in their power to stop them.
> Tie-in sales between software and services is not different from price dumping.
I disagree, in many cases what you are specifically paying for is the combination of the software and the service that are designed to work together. And in many cases do not work independent of eachother.
There are countless cases of this, that what you are paying for is a thing that is made up of a piece of software and a serverside component. MMO's (and gaming in general) being a major example of this, but so are many of the apps I pay for subscriptions for on my phone.
The actual technical implementation of how it works is irrelevant when it is clear what it is you are paying for.
> "Both parties are okay with the terms" is far from being sufficient to make something "legal".
True but the opposite is also true, just because you don't like the terms it does not make it illegal.
> in many cases what you are specifically paying for is the combination of the software and the service that are designed to work together
And in many cases like Claude Code and the Anthropic models, they can and do work perfectly independently.
> True but the opposite is also true, just because you don't like the terms it does not make it illegal.
This is not me "not liking it". Like I said somewhere else in this thread: these types of tie-in are illegal in Brazil. This practice is clearly not done to favor the consumer. You can bet that if the US was anything closer to a functional democracy and the laws were not written by lobbyists, this would be illegal in the US as well.
Are MMO’s illegal in Brazil? Is PlayStation Plus illegal in Brazil? Is Spotify, Apple Music, etc etc etc also illegal in Brazil?
It would be ridiculous to argue that I could pay for a subscription to World of Warcraft and make my own third party client to play the game with. (Obviously you are free to argue it all you want but I would be very surprised if this was actually illegal).
> And in many cases like Claude Code and the Anthropic models, they can and do work perfectly independently.
Unless I am mistaken Claude Code does not have a local model built into it, so it requires a server side component to work?
As far as the Anthropic models, yes like many other services they ALSO have a public API that is separate from the subscription that you are paying for.
The critical difference here being that in the subscription it is very clear that you are paying for “Claude Code” which is a combination of an application and a server side component. It makes no claims about API usage as part of your subscription, again the technical implementation of the service you are actually paying for “Claude Code” is irrelevant.
When it comes to “Claude Code” for all that we should care about, again given that “Claude Code” is what you are paying for, they could be sending the information to Gemini or or a human looks at it. Because it’s irrelevant to the end user when it comes to the technical implementation since you are not being granted access to any other parts of the system directly.
"Tie-in sale": the business practice where a seller conditions the sale of one product (the tying good) on the buyer’s agreement to purchase a different product (the tied good).
The examples you are giving are not "tie-in" sales because the service from Playstation Plus, Spotify, Apple Music, etc is the distribution of digital goods.
> Unless I am mistaken Claude Code does not have a local model built into it, so it requires a server side component to work?
Which part are you not understanding?
I don't care about Claude Code. I do not want it and do not need it. All I care about is the access to the models through the client that I was already using!
> When it comes to “Claude Code” for all that we should care about, again given that “Claude Code” is what you are paying for.
No, it is not! I paid for Claude Pro. Claude != Claude Code.
> "Tie-in sale": the business practice where a seller conditions the sale of one product (the tying good) on the buyer’s agreement to purchase a different product (the tied good)
I will keep my response to this part in particular limited because I have limited understanding of this law. However based on doing a little bit of searching around the law is not as cut and dry as you are presenting it to be. It is possible that Claude code would fall under being fine under that law or no one has gone after them. I honestly don’t know and I don’t feel like having an argument that it is highly likely both of us don’t fully understand the law.
That being said I do question how exactly “Claude code” differs from those services as a digital good.
> I don't care about Claude Code. I do not want it and do not need it. All I care about is the access to the models through the client that I was already using!
OK! That is not what you’re paying for as part of Claude Pro, end of story. You are not paying for the API. It is no different that the people that have a free plan and can only chat through the web and the app also don’t get access to the API even though it is obviously using an API to access those endpoints as well.
Or are you also going to argue that free users should have access to the API because they are already using them in the browser.
> No, it is not! I paid for Claude Pro. Claude != Claude Code.
Claude Code is one of the features you are paying for as part of Claude Pro so yes in a way you are paying for it. And again not on that list is the API.
Claude Pro = claude.ai, and they made no changes to that arrangement. Both claude.ai and Claude Pro are products built on top of the Claude API. You are free to buy access to the Claude API itself, with or without the other two, but the pricing is different because the price of claude.ai and Claude Code includes the API charges they incur.
> but the pricing is different because the price of claude.ai and Claude Code includes the API charges they incur.
If that was true, then getting equivalent usage of the API without claude.ai and Claude Code should cost less, not more.
You can try to find all sorts of explanations for it, at the end of the day is quite simple: they are subsidizing one product in order to grow the market share, and they are doing it at a loss now, because they believe they will make up for it later. I understand the reasoning from a business point of view, but this doesn't mean they are entitled to their profits. I do not understand people that think we simply accept their premise and assume they can screw us over just because they asked and put it on a piece of paper.
We don't know if, on average, paying API prices for Claude Code is cheaper or not, so we don't know if they're operating it at a "loss". That math doesn't make sense in any case since it would be a "loss" based on their own external prices. The entire company is operating at a loss, regardless.
In any case, the point is it's not tying; you're free to choose any combination of products.
> n any case, the point is it's not tying; you're free to choose any combination of products.
These products can function independently, and the acquisition at a heavy discouont for one of them is conditional on the acquisition of the other. It definitely is a tie-in sale.
- It was possible to do it.
- OpenCode did not break any security protocol in order to integrate with them.
- OAuth is *precisely* a system to let third-party applications use their resources.
It's not what they wanted, but it's not my problem. The fact that I was a customer does not mean that I need to protective of their profits.
> (from their business perspective)
So what?!
Basically, they set up an strategy they thought it was going to work in their favor (offer a subsidized service to try to lock in customers), someone else found a way to turn things around and you believe that we should be okay with this?!
Honestly, I do not understand why so many people here think it is fine to let these huge corporations run the same exploitation playbook over and over again. Basically they set up a mouse trap full of cheese and now that the mice found a way to enjoy the cheese without getting their necks broken, they are crying about it?
You'd have to point me to an authoritative source on that (explicitly saying users are allowed to use their models via private APIs in apps of the user's choosing). If something isn't explicitly provided in the contract, then it can be changed at any point in any way without notice.
Honestly, I'm not big on capitalism in general, but I don't understand why people should expect companies to provide things exactly the way they want at exactly the prices they would like to be charged (if at all). That's just not how the world/system works, or should, especially given there are so many alternatives available. If one doesn't like what's happening with some service, then let the wallet do the talking and move to another. Emigration is a far more effective message than complaining.
> I don't understand why people should expect companies to provide things exactly the way they want at exactly the prices they would like to be charged
This is a gross misrepresentation of my argument.
I wouldn't be complaining at all if they went up and said "sorry, we are not going to subsidize anyone anymore, so the prices are going up", and I wouldn't be complaining if they came up and said "sorry, using a third party client incurs an extra cost of on our side, so if you want to use that you'd have to pay extra".
What I am against is the anti-competitive practice of price discrimination and the tie-in sale of a service. If they are going to play this game, then they better be ready for the case the strategy backfires. Otherwise it's just a game of "heads I win, tails you lose" where they always get to make up the rules.
> Emigration is a far more effective message than complaining.
Why not both? I cancelled my Pro subscription today. I will stick with just Ollama cloud.
It's not tie-in. They give users 2 choices: a) use their service via their public API, with the client(s) of their choice, at the regular price point; b) use the apps they provide, which use a private API, at a discounted price point. The apps are technically negative value for them from a purely upfront cost perspective as their use trigger these discounts and they're free by themselves.
Good on you re that cancel. May you find greener grass elsewhere.
> They give users 2 choices: a) use their service via their public API, with the client(s) of their choice, at the regular price point; b) use the apps they provide, which use a private API, at a discounted price point.
There was a third choice, which was better than both of the ones presented: use any other client that can talk with our API, at whatever usage rate they deemed acceptable. If the "private API" was accessible via OAuth, then it's hardly "private".
We can argue all day, when I signed up there was nothing saying that access was exclusive via the tools they provided. They changed the rules not because it was costing them more (or even if does, they are losing money on Pro customers anyway so arguing about that is silly) but because they opened themselves for some valid and fair competition.
There was no third choice if they didn't explicitly state that there was.
> If the "private API" was accessible via OAuth, then it's hardly "private".
If you invite people on your porch for a party, and someone finds that you left the house key under the mat and went off to restock, then it's hardly "private". It's perfectly fine for whomever feels like to take the party indoors without your permission. Pretty much what you're saying, reframed, but I seriously doubt you'd agree to random people entering parts of yours premises to which you didn't explicitly invite them.
Try not making it sound like the company is doing me a favor by letting me access the thing I was paying for. I wasn't "invited to a party", I was sold on an agreement that by paying a guaranteed monthly fee I could have access to the model at a rate that was lower than the pay-as-you-go rate from the API.
The primary offering is access to the models. That's what the subscription is about. They can try as hard as they want to market it as Claude being the product and access to the model being an ancillary service, but to me this is just marketing bs. No one is signing-up for Claude because their website is nicer, or because of Claude Code.
> I was sold on an agreement that by paying a guaranteed monthly fee I could have access to the model at a rate that was lower than the pay-as-you-go rate from the API
Yes, that agreement is there, with the condition that their app is used. That's option B. And I'd think it fairly obvious that if one has to go to extraordinary lengths to gain access, like finding a key under a mat, or needing to login with an official client to gain access to a token for an unofficial client, then - implicitly - it's highly unlikely that that method of access is part of the agreement. And Anthropic has now made it explicitly clear that no, that access method is not part of the agreement.
Nope, there's no tie-in sale[0] as you do not pay for the apps. And particularly, there's no real competition angle[1] as the market is loaded with LLM service providers, not to mention downloadable options.
There's a reason in this particular case why the particular APIs aren't documented: they aren't intended for public use. And they've made it crystal clear, so all you have to do now is take your wallet somewhere that offers the access you desire. You have no case here.
> as the market is loaded with LLM service providers
The LLMs are not commodities. The program that interfaces with them are.
> they aren't intended for public use.
It was available at first, it made possible for people to use the LLM model without having to use their specific CLI tool. It's a bait-and-switch.
> You have no case here.
I don't need to have a legal case here to keep thinking it's a morally dsgusting practice. What I don't understand is: why do you keep defending it? Is there something in it for you, or are you just trying to rationalize your way into acceptance of their terms?
Could you clarify exactly what you think is an illegal tie-in? Because it seems like what you are upset about is literally the opposite -- Anthropic unbundling their offerings so you aren't required to buy the ability to offer third party access when you purchase the ability to use Claude code and their other models. Unless I really misunderstand you, your complaint is literally thaf
The laws prohibiting tie-ins don't make it illegal to sell two products that work well together. That's literally what the laws are designed to make you do -- seperate products into seperate pieces. The problem tie-in laws were designed to combat was situations like Microsoft making a popular OS then making a mediocre spreadsheet program and pushing the cost of that spreadsheet program into the cost of buying the OS. That way consumers would go "well it's expensive but I get excel with it so it's ok" and even if someone else made a slightly better spreadsheet they didn't have the chance to convince users because they had to buy it all as one package.
Anthropic would be doing something much closer to that if they did what you wanted. They'd be saying: hey we have this neat Claude code thing you all want to use but you can't buy that without also purchasing third party access. Now some company offering a cheaper/better third party usage product doesn't get the chance to convince you because anthropic forced you to buy that just to get claude code.
Ultimately this change unbundled products the opposite of a tie-in. What is upsetting about it is that it no longer feels to you like you are getting a good deal because you now have to fork over a bunch more cash to keep getting what you want. But that's not illegal, that's just not offering good value for money.
Look at it this way: the service that you're accessing is really a (primarily desired) side-effect of the software. So re subscriptions, what they're actually providing are the apps (web, desktop, etc), and the apps use their service to aid the fulfillment of their functionality. Those wanting direct access to the internal service can get an API key for that purpose. That's just how their product offering is structured.
I've heard they actually cache the full Claude Code system prompt on their servers and this saves them a lot of money. Maybe they cache the MCP tools you use and other things. If another harness like Opencode changes that prompt or adds significantly to it, that could increase costs for them.
What I don't understand is why start this game of cat and mouse? Just look at Youtube and YT-DLP. YT-DLP, and the dozens of apps that use it, basically use Youtube's unofficial web API and it still works even after Youtube constantly patches their end. Though now, YT-DLP has to use a makeshift JS interpreter and maybe even spawn Chromium down the line.
Some people drop out of the game as it gets harder. I've basically stopped looking at youtube videos unless I want it enough to download it (and wait if the current workarounds broke) with how much they've clamped down on no-account usage. Most I suspect just give in to the company's terms.
> Their costs are not magically lower when you use claude code vs when you use a third-party client.
If subsidizing that offering is a good hook to get higher paying API users on board, then some of that cost is a customer aquisition cost, whereas the cost to them of providing the API doesn't have the same proportion that they can justify as a customer acquisition cost.
I absolutely have zero concerns about their cost to acquire new customers. As a (former) customer, all I am concerned is the freedom to consume the service I am paying for however I see fit.
Unless it's illegal in more places, I think they won't care. In my experience, the percentage of free riders in Brazil is higher (due to circumstances, better said).
> Except they can't. Their costs are not magically lower when you use claude code vs when you use a third-party client.
I don't have a dog in this fight but is this actually true? If you're using Claude Code they can know that whatever client-side model selection they put into it is active. So if they can get away with routing 80% of the requests to Haiku and only route to Opus for the requests that really need it, that does give them a cost model where they can rely on lower costs than if a third-party client just routes to Opus for everything. Even if they aren't doing that sort of thing now, it would be understandable if they wanted to.
It (CC) does have a /models command, you can still decide to route everything to Opus if you just want to burn tokens
I guess it's not default so most wouldn't, but still, people willing to go to a third party client are more likely that kind of power user anyway
They still have the total consumption under their control (*bar prompt caching and other specific optimizations) where in the past they even had different quotas per model, it shouldn't cost them more money, just be a worse/different service I guess
As things are currently, better models mean bigger models that take more storage+RAM+CPU, or just spend more time processing a request. All this translates to higher costs, and may be mitigated by particular configs triggered by knowledge that a given client, providing particular guarantees, is on the other side.
That’s kind of the point. Even if users can choose which model to use (and apparently the default is the largest one), they could still say (For roughly the same cost): your Opus quota is X, your Haiku quota is Y, go ham. We’ll throttle you when you hit the limit.
But they don't want the subscription to be quota'd like that. The API automatically does that though, as different models use different amounts of tokens when generating responses, and the billing is per token. And quite literally is having the user account for the actual costs of usage, which is the thing said users are trying to avoid, on their own terms, and getting upset about when they aren't.
> It (CC) does have a /models command, you can still decide to route everything to Opus if you just want to burn tokens I guess it's not default so most wouldn't
Opus is claude code's default model as of sometime recently (around Opus 4.6?)
A) People are so used to infinite growth that it’s hard to imagine a market where that doesn’t exist. The industry can have enough developers and there’s a good chance we’re going to crash right the fuck into that pretty quickly. America’s industrial labor pool seemed like it provided an ever-expanding supply of jobs right up until it didn’t. Then, in the 80s, it started going backwards preeeetttty dramatically.
B) No amount of money will make people buy something that doesn’t add value to or enrich their lives. You still need ideas, for things in markets that have room for those ideas. This is where product design comes in. Despite what many developers think, there are many kinds of designers in this industry and most of them are not the software equivalent of interior decorators. Designing good products is hard, and image generators don’t make that easier.
Its really wild how much good UI stands out to me now that the internet is been flooded with generically produced slop. I created a bookmarks folder for beautiful sites that clearly weren't created by LLMs and required a ton of sweat to design the UI/UX.
I think we will transition to a world where handmade software/design will come at a huge premium (especially as the average person gets more distanced from the actual work required to do so, and the skills become rarer). Just like the wealthy pay for handmade shoes, as opposed to something off the shelf from footlocker, I think companies will revert back to hand crafted UX. These identical center column layout's with a 3x3 feature card grid at the bottom of your landing page are going to get really old fast in a sea of identical design patterns.
To be fair component libraries were already contributing to this degradation in design quality, but LLM s are making it much worse.
Yeah. For a few years, I’ve been predicting that human-made and designed digital goods will be desirable luxury items in the same exact way the Arts and Crafts movement, in the late 19th/early 20th century, made artisan furniture, buildings, etc. to push back against the megatons of chintzy shit produced during the Industrial Revolution.
Component libraries can be used to great effect if they are used thoughtfully in the design process, rather than in lieu of a design process.
Paying a premium for "luxury" makes sense for people looking status signaling or an unique experience. Software is (most of the time) an utility. People would be willing to pay for a premium when there is tangible performance improvement. No one is going to pay more for a run-of-the-mill SaaS offering because the website was handcrafted.
> People would be willing to pay for a premium when there is tangible performance improvement.
Developers like to assume this because it’s something they value in their own software usage, and something they know how to address. That’s not something you can generalize to non-developers. Look, feel, and features are the main difference users see between FOSS and most commercial software— not performance. In fact, FOSS performance is obviously better in many/most cases. That’s why almost the only FOSS software projects with a significant number of non-dev users are run by organizations that employ designers — Mozilla, Blender, Signal, Android, etc.
Unless you’re making a tool for developers or gamers, or the competition is intolerably bad, people rarely pay for increased performance.
I wasn't using "Performance" in the sense of "how fast does it go?", but it the sense of "how well does it do what I need to do?"
> Mozilla, Blender, Signal, Android, etc.
First, this is selection bias. I'm sure we can find plenty of cases of software that failed even when designers were around, and I can certainly point to software/services that have horrendous "UI" but were still incredibly useful/valuable: Craigslist and Bloomberg Terminal come to mind.
Second, you are confusing cause and effect. The examples you gave only employ designers now because they were valuable even without designers working on it.
Anyway, you did not address the core point of my argument: no one is going to pay more for a run-of-the-mill SaaS offering because the website was handcrafted.
You do know we're hemorrhaging and lot of finite resources to play these games badly, right? We're basically at laying on chaise lounge being fed grapes levels of hedonism. Make me a racist meme that copyright infringes multiple IP holders and when you're done play Sim City at competency level of a blind man.
You say this any time someone drives an ICE for fun? Eats a beef burger? Buys clothes they don't need? Or the worst of all, takes their 2nd vacation by airplane of the year?
Let me lower the bar - have you asked any of the above to random people you don't know well for a combined total of more than twice in your life?
If so, hats off to you, respect. That takes some courage.
If not, which seems to be the case in 99.99% of cases where people pretend to care about the environmental impact of AI, man up and stop making a mockery of those who do care about the environment and have made personal sacrifices for it.
> meme that copyright infringes multiple IP holders
The "subset of the population" is not small, and there is no easy way to protect the most vulnerable.
> it's a wildly popular form of entertainment with millions of creators sharing their lives
I don't think we should be rewarding those who make a living by creating "content" that serves for nothing but a dopamine rush, and you can bet that those who who put it in the effort to create valuable content would prefer to have one less channel where they are forced to put out content just to satisfy the algorithm overlords.
It's not about the content, but the format and the economic pressure that corporations exert over everyone.
If you want to distribute short videos on a website that let's you choose what you want after search and deliberately clicking on a button to play it, by all means feel free to do it. But the current Tik-Tok mechanism removes all agency and are an extreme version of mind pollution.
I'm going in the opposite direction: with each new model, the more I try to optimize my existing workflows by breaking the tasks down so that I can delegate tasks to the less powerful models and only rely on the newer ones if the results are not acceptable.
Excel spreadsheets have little to no validation logic that you're actually getting a good result, unless you have a secondary check (most spreadsheets are structured as "single entry" accounting, so lack the checks)
A prime example of this was the Reinhart/Rogoff paper advocating austerity that was widely quoted, and then it was discovered that the spreadsheet used had errors that invalidated the conclusions:
The point is not that people will be using specifically Excel, but that most business only pay for software because it is the tool that gives them the most power to automate their processes. They don't need high availablility, they don't need standards compliance, they don't extensive automated tests, they won't need cloud engineeers and SRE... all you need is some tool that can get the results your are looking for right now.
Academia already works like this. Software wrtiten for academic purposes is notoriously "bad" because it is not engineerd, but that doesn't matter because it is good enough to deliver the results that researchers need. Corporate IT will also start looking like this even at mid-sized companies.
I don't disagree with anything you say here - using a tool that lacks guardrails is fine for a lot of tasks, but if that's the only tool and used where those guardrails go from "nice to haves" to something more critical is where the problem is.
I've been in ops for a long time and have encountered far too many "our IP addressing plan is just a spreadsheet with manual reconciliation".
I truly wonder if Excel and all it's predecessors and direct clones (Google Sheets, etc.) are holding back industry from making something truly better and more reliable.
> holding back industry from making something truly better and more reliable.
What "industry"?
If you are talking about the software industry, then I'd say you are creating a circular reasoning. If you are talking about all the other things that we actually need to do and which only incidentally have become too reliant on software to do it, then see back my original point: people don't need "better and more reliable" software to keep running their businesses.
If running your business to '90s standards is acceptable, sure, you can use AI to automate your manual processes with the same error rate and keep doing the same thing indefinitely.
But if the competitors have real software engineers and have used them to actually improve reliability, you'll be left behind.
What software engineers are being hired to work on:
- A facilities management company
- A bar/restaurant with a staff of 8
- An Architecture office
- A Law Firm with 10 associates
- A day care
- A car repair shop
- A cement factory
- A family-owned hotel
- A conference/event organizer
- A video production crew
- A roofing company
Ok, but if your competitors are getting/using software from a supplier who has real software engineers, and using that to operate at a higher level of reliability, then the same argument goes through.
If you want to go down the value chain, then by definition the less valuable the software is and the easier to be commoditized. The automation is not going to help just the manager-turned-vibecoder, it's also going to help professionals to create FOSS alternatives that can be robust enough.
It's not going to happen overnight, but the trend is there.
> If you want to go down the value chain, then by definition the less valuable the software is and the easier to be commoditized.
I'm not sure that holds for what we're talking about - high-value software can afford to be somewhat flaky because it delivers enough value when it works to make up for it, software that's only marginally worthwhile needs to be reliable because if it isn't then it's not worth the bother. Commoditized fields are more competitive.
> The automation is not going to help just the manager-turned-vibecoder, it's also going to help professionals to create FOSS alternatives that can be robust enough.
Not convinced. In my experience these tools don't really help with creating high-quality software. Maybe they'll get there eventually (at which point we're all out of a job), but right now they can't "hit the high notes".
Doesn't that also lead to the conclusion that "software engineers" are going to lose their ability to command high salaries, if the real value is in the domain expertise and not in the ability of optimizing some part of the business process?
> Doesn't that also lead to the conclusion that "software engineers" are going to lose their ability to command high salaries, if the real value is in the domain expertise and not in the ability of optimizing some part of the business process?
I mean the job has always required both - just being good at leetcode isn't enough to get paid well (except perhaps where there is a dysfunctional interview process), the key skill is being able to translate back and forth between the world of software and the world of business. Regular folk seemingly still find it difficult to think rigorously, in the way that fully correct automation requires, and AI hasn't actually helped with that any, so I think people with that skill will still command a premium. Work that doesn't benefit from rigour - being able to slap together a quick marketing site on wordpress or what have you - will pay badly if at all, but that was already the low end of the industry I think.
An academic paper needs to deliver its output once, for the research. Maybe someone will try to replicate it later but that's someone elses problem (and fairly often proves the output of the former to be wrong)
Some stuff in companies might be similar, but there's a lot of things that people use every day, in a lot of different ways, and the software needs to work correctly regardless. You can't just drop it like a hot potato once you've built processes around it.
As always, the first 80% takes 20% of the time/effort, the last 20% takes the other 80%.
That's a software engineer that is limited to an mostly untyped macro language, with worse version control and poor tooling. It's not that software can't be written as an Excel spreadsheet, it is that it is just inefficient and failure prune.
I guess that's technically true, because "most businesses" are sole proprietorships without any employees... but they could get by just fine with a checkbook and a note pad.
But the reasons the business software sector grew far beyond Excel of the 1990s is because of the inherent limitations in scaling solutions built by business analysts inside of Excel. There's a vague cutoff somewhere in the middle of the SMB market where software architecture starts to matter and the consequences for fuckup are higher than the cost of paying for professionally made software with, importantly, a vendor on the hook for making sure it doesn't fuck up.
Uh, no. The main reason the software sector grew in the 90s was a particularly potent combination of FOMO, kickbacks, and strategically deployed cocaine.
reply