Posted by tomeraberbach 15 hours ago
What you should be paying attention to: Stainless is shutting down, and their team is joining Anthropic to build, who knows, some dumb integration to make Hubspot data available in Claude, or something equally as boring. But, Stainless was successful. Be the next Stainless. The idea is already validated, these AI companies have already done this to a handful of companies and they're going to keep doing it.
Fun fact, I named it "Stainless" after Stainless Steel pipes, likening ourselves to a high-end plumbing supply shop. If you look at the earliest versions of stainlessapi.com on archive.org, you'll see our original motto was "Quality fittings for your REST API".
All that is to say, the incredibly "boring" infrastructural work of making "boring" APIs like Hubspot's more usefully accessible is absolutely the kind of thing I'm excited to do at Anthropic :)
(It also happens to be what got us all excited to work at stainless in the first place, but of course, we understand it's not for everyone!)
edit: they sure do
They might be a big part of the reason why claude code can edit notion docs for you pretty easily
Why aren’t they dogfooding their own products to replace such roles?
And seeing how people use it: good programmers review output and iterate to get better output. But bad programmers simply trust the output is good: they have no ability to review it themselves and often don't try.
With about 5-10h over the weekend using free tier Claude and ChatGPT I managed to put together a scraper for a particular thing on a website I’m interested, grab the item images, do an initial pass with local OCR, if it hit some keywords, run openCV to crop for better OCR and dump the hits for further investigation.
Nothing particularly advanced but it would have taken me a horrendous amount of time without it to be half as good, like it did when I built a similar scraper 10 years ago.
Neither were very good code quality i’m sure.
On average, the output is still better than what a bad programmer would produce.
For example, a recent story about the openclaw creator using $1.3M of tokens/month. And let's assume he's getting paid $5M/yr which is probably a vast under estimate.
Is he providing value that a traditional software development org with normal developers couldn't provide for $20M/yr?
Finally in some ways agentic workflows magnify the power of the individual who is adept at harnessing them, they don’t have to argue (much) with the agents to effect their ideas. I’ve found a lot of very bright engineers spend their days fighting to be heard by managers and peers who can’t / won’t understand them. By unshackling them from trying to debate down idiots, they deliver way way more, and of the right things, than they otherwise could have.
Leibniz, literally parallel.
Was Newton just a smart guy at the right place and the right time. These smart folks require other smart folks to understand and verify what they did. There are many who have amazing pedigrees in history.
Yes, $1.3M in token cost in less than 30 days and some days were even off-peak, if you can call it that with that insane scale that likely hides quite a lot of tokens in the lower bars.
I don't think existing companies will bite that bullet, but I think you'll see AI native companies in five years with like, a baffling small number of people.
Who claimed that?
Their customers will be happy if their product replaces all the junior positions and midwit developers off the payroll. then that's already a huge saving to any company's bottom line.
Even if it doesn't directly replace workers, reducing the bargaining power of those spoiled SW devs and not having to give them huge raises all the time or they leave, is still enough. That's the whole point of layoffs and offshoring anyway.
Possibly not if they are paying the full cost of inference
Dario Amodei
This tests for very different skills than being an exceptional programmer.
The reason why I avoided this term is that in Germany, there exists a quite strict of whatx an engineer (Ingenieur) is, which is defined in the laws of many federal states (Ingenieurgesetz [engineering law]). "Ingenieur" (engineer) is a protected professional title:
> https://de.wikipedia.org/w/index.php?title=Ingenieur&oldid=2... (*)
Falsely claiming that you are an Ingenieur when you aren't (by the definition in the Ingenieurgesetz) is a punishable crime in Germany:
> https://de.wikipedia.org/w/index.php?title=Missbrauch_von_Ti...
There exist some boundary cases under which as a software developer you can call yourself an "Ingenieur", but you have to be insanely careful about whether you actually satisfy the legal criteria (see (*)) - in most cases you don't and you are thus a criminal if you do.
If so, is this ever enforced?
Using the German translation "Softwareingenieur" of "software engineer" on your LinkedIn page might easily get you into trouble.
Typically, as far as I know, law enforcement agencies only get active in the punishable act "Missbrauch von Titeln, Berufsbezeichnungen und Abzeichen" [abuse of titles, occupational titles and emblems] if the culprit gets denounced by someone or if there is a public interest, but everybody knows how easy it is to make enemies in your job or on the internet.
I think you're overestimating the rationality of this game.
Having a successful business requires a lot of factors that don't really have anything to do with software engineering. Things like luck, connections, access to funding, good marketing, etc. And while have good engineers on the payroll undoubtedly helps, the good engineers aren't necessarily the ones getting a big fallout from the acquisition and may not stick around for long after the acquisition, especially if they get put on a project they don't care about.
What's the difference between a software developer and a software engineer?
The honest answer is that in most day-to-day contexts, the distinction is more about company culture and title preference than actual job duties. A "software developer" at one company might do more rigorous engineering work than a "software engineer" at another.
There are plenty of other reasons to acqui-hire, but it is not the only or even the most effective way to hire the strongest engineers
Successful founder is deeply filtering for very uncommon skills. Effectiveness, grit, decision making, independence, technical plus sales ability.
University is a shit filter in comparison.
The current word is "taste" but even that is way too narrow. Intelligence is close, although usually too academic (hence the VC uni dropout theme).
The other big problem with a independent capable people is that they rarely apply for jobs.
Normally I would say those Engineers would leave eventually, because there are not enough technical challenges and/or the pace is slower. But I guess when you pay much above market rate that doesn't really matter.
All that's moot though if your fundamental premise is wrong. Why does Anthropic need "the world's best software engineers" to build on top of the models? Compentent developers can build APIs - sorry - MCP servers and other integration plumbing.
If Anthropic can rummage through your data and workflows to deem you worthy of their grace, then that is seriously wrong.
For better or worse, it's an acquihire.
not anymore lol
I can't even imagine the money wasted on turn-and-burns in the F1000 alone. The US needs a wake up call with respect to consumer / buyer protections. The life of the snake oil salesman is plentiful these days, and you have a lot of AI-psychotic executives who can't seem to get enough.
They mostly have. By mostly refraining from dealing with startups and companies they deem either “too young” or "too small" to be reliable partners. And, when they do, imposing long sales cycles.
And thus the enterprise well is poisoned for most startups.
But buyers try to insert this language into partner/ biz dev contracts all the time.
Much less common for sales.
A place I worked some years ago we even had an escrow foisted on us by our larger partner in the agreement so that they’d be able to continue running the software we were building if we went under.
Honestly, it was a pain in the ass and meant that for them alone we ended up running an older version of the software than we offered to clients because as we developed its capabilities it became ever more integrated into our core platform and we weren’t about to escrow that.
When the agreement came up for renewal at the three year mark we managed to get the escrow clauses removed.
Hadn't heard of Stainless before today. Did it have enterprise customers?
They can also keep the product running behind the scenes for a select few and just shut down the public facing part
I suspect a lot of larger orgs just have site-wide subscriptions with volume discounts that they don’t need.
Either way, it does seem irresponsible and tone deaf for an acquiring/hiring company and an acquired/hired company to send these conflicting signals. If one puts oneself out there as dependable in the face hopes and needs of other, smaller, up-and-coming projects, then a rapid wind-down for $ is incongruent with such a posture.
So much so that, at least for my part, I'd be quite reluctant to hire someone who had engaged in this sort of bob-and-weave pursuit.
> As we focus on Claude Platform capabilities and connecting agents to APIs, we’ll be winding down all hosted Stainless products, including our SDK generator. Starting today, new signups, projects, and SDKs will not be available.
> If you’re a Stainless customer, visit app.stainless.com/transition for help transitioning from Stainless-managed products to other options. As always, you own the SDKs you’ve generated to date, and have full rights to modify and extend them however you wish.
By self-service, do you mean that the SDK generators are now source-available so they can be run by end users locally?
* Manual Maintenance: Returning to the pre-Stainless era.
* Agentic Coding: Works to an extent, but you lose the deterministic, review-free output required to keep an SDK perfectly structured and coherent.
* Open-source Generators: Helpful for basic use cases, but they lack Stainless's full-stack features like multi-language generation and publishing, MCPs, and documentation.
We were an ealy adopter of their Node SDK generator at Mux (and latterly their Typescript and other generators), and the product worked great, and I'm sad to see it be shut down.
At the same time, it's easy to understand why this is a complciated product/market to be in at the moment - it's very tempting and easy to vibe code SDKs from a OpenAPI spec files right now. I would think a lot of teams will just go in that direction (for better or worse), using the same toolchain that the product developers are using today for the product, for effectively no extra cost.
But, no one uses it, because uber and lyft have become kleenex or coca cola: the brand name associated with the basic phenomenon, such that consumers cannot even think about the phenomenon without thinking first of the brand and probably resorting to the brand.
Maybe I’ll try again in a few years.
This is the same startup culture. The only innovation here is finding new way to swindle customers and businesses out of money.
As we focus on Claude Platform capabilities and connecting agents to APIs, we’ll be winding down all hosted Stainless products, including our SDK generator. Starting today, new signups, projects, and SDKs will not be available.
If you’re a Stainless customer, visit app.stainless.com/transition for help transitioning from Stainless-managed products to other options. As always, you own the SDKs you’ve generated to date, and have full rights to modify and extend them however you wish.
If you intend to sell it to the highest bidder eventually then what difference does it make what was your plan?
If a business had real values then they would never sell out (see lichess).
I very much doubt you would apply your expectation of altruism to yourself!
It kind of blows my mind that the majority of Claude users have just accepted that CLAUDE.md is a tracked file that the whole team has to standardize on and share. Coding agents are the ultimate API. They conform to however you prefer to interact. Is anyone really expecting to enforce standard operating procedures with this non-deterministic black box of magic?
The amount of money thrown at it means at some point the words Return on Investment were going to appear.
It’s the classic loss leader applied to trillion dollar (across the market) capital investments.
Allowing users to take advantage of their monthly/weekly/daily token limits with the software of their choosing is a perfectly valid expectation.
Restricting it to their own underperforming, buggy TUI client is textbook walled garden.
Because that's what the API is for.
This isn't hard to understand. The cost you pay for subsidized tokens is lock-in. If you don't want lock-in, there's the API.
This isn't egregious or wrong or anything. It's exactly what you'd expect out of a heavily subsidized product option.
Really walled garden is the only direction that makes sense--models will slowly become commodities
*load-bearing* just started popping up like crazy with opus 4.7.
Although Claude will never hold a candle to Codex’s jargon, at least in my experience.
I get that most of our new customers will use AI to generate client libs. But our existing customer base depends on our Stainless generated client libs. These OpenAPI schema > client lib providers had a bit of lockin since the client libs are all slightly different.
Migration's unfortunately not as easy as just switching to Speakeasy or Openapi generator w/o breaking existing customers.