Why did this thread suddenly massively down ranked? It was at the very top 15 mins ago, now it's on page 4 and dropping fast despite very high engagement... @dang
I would argue performance optimizations help with local/open models but hurt openai and anthropic - because open and or cheap/alternative models are threat to those companies. There is a fundamental contradiction/conflict between the prevelance of open models and the financial success of openai and anthropic. That is why they are doing everything they can to kill any open/cheap/efficient/chinese models (take a look at this thread - it was top of HN 40 mins ago, with very high engagement... now it is buried in page 5... totally normal and legit).
Yeah, you need a lot of resources in order to waste a lot of resources. Look at codex and Claude code - these trillion dollar companies 'with top talent' cannot build what open code and pi/oh-my-pi have built in the open for free? Both codex and Claude code, are slow, buggy pieces of shit (and I say that as someone who still heavily uses both for work, moved to open code and pi for personal stuff). The reality is these companies mostly focus on marketing and market capture through, non-competitive means - their services and software are unreliable, buggy trash.
I don't think the OP and your comments are mutually exclusive. If Anthropic usage is lower, and the OP considers it basically unlimited for their case, that just means that they would have virtually unlimited usage with other plans.
You're assuming product people don't 'invent' work, which is faaaar from true. The more technical the area, the more nonsense 'product' generates, that engineering then has to either redo, clean up or fight. The 'product' people on 'product-led' teams also generally own the internal comms and marketing (internal) side of things, which often has the effect of silencing engineering (and many other negative side effects). (Not always but often imo)
Engineers should understand their customers and their product (whether internal or external), should understand their metrics, and should be able to make intelligent, informed decisions. Sticking a non-technical 'product' (aka marketing) person into the mix is generally net-negative imo.
I think the problem is one of management and prioritization and decision making - when multiple engineering teams disagree, how do you decide? Management consistently hires people that solve management problems, and mediating disagreements or picking product direction are core management functions that have been completely left behind as managers become purely MBA number people.
I don't think they're making any claims about non-platform teams never having similar work-invention problems.
They're just saying a good platform team engineer cares about their users.
Which is fairly at-odds in spirit with the quoted idea of "there's no market to lose."
The original article does say "talk to your users" but it also de-emphasizes this by having it among an apparent laundry list of other signals: crashes, costs
Focus on cost without talking to your users - aka the people who care about the spend? You might spend a lot of time reducing a number that isn't very important right now. Focus on crashes but don't talk to your users? You might address some things with easy workarounds ("i hit retry") while ignoring much more painful toil. This is captured in the details for those sections, but not in the headlines.
There's also some interesting stuff in there in some of the bullets, like overloaded use-cases and partner-to-prototype, but again, that's just more specifics on how to talk to your users.
I think the article would be a lot more helpful to a lot more people if it was a "Guide to Talking to Your Users" and then framed each of those specifically as: user discovery, and how to talk about the given part.
The readme was very clearly AI-written (or at least heavily AI-assisted)... not saying that's a bad thing, and I agree it's fairly well written... but it is very obviously AI
k, I just looked through it for where the latest is. First of all, the earliest version were fully written by me, and then lightly edited with AI. The current state are as follows: intro sentences written by me, "why lightspeed" section too. Quickstart AI written, Features mostly written by me, but AI keeps interfering there. Design was also written by me several times, it also used to be much longer, but I just noticed AI put one a few paragraph of slop in there, I think that's the most egregious--shame on me for not caching it. So, if I look at the readme right now, I would say it's about 60% me. It can be better, I'll make the effort because it really bothers me if readmes are not (mostly) written by humans.
I really don't have a problem with you using AI, as long as you review and validate/test what it writes, and seems like you did that. Great project btw!
Stripe has already existed for a while, and has gone through ups and downs. There was a period where customer experience was first, and the systems inside were built fast and in rather cavalier ways (See Greg Brockman famously telling everyone in a MongoDB convention about using Mongo's oplog as a queue). There were times where internal tools teams could spend all the time they needed to get about as much shine internally as the external facing websites were. Huge investments in everything. But there's just so much churn, as some staff burns out, and others realize that they have so much vested stock that continuing in such a high intensity environment is pointless, that whatever Stripe might have been during your tenure might be very different from other people's, and you can both be right.
I worked at stripe too. Sail design system at time was exemplary. A ton of effort got invested in little details. They spent an insane effort in making ruby fast with their own jit, formatter and type checker they built.
I think it has more to do with the fact that Stripe has already 'won' in a lot of ways, and the company has now basically transitioned from the innovative tech startup phase to the MBA/marketing/bureaucracy phase. Quality, efficiency as priorities are replaced with marketing and 'strategy'...
I've been working on a general repository linter. The idea is to declaratively define a set of rules/conventions for your repo, (for things that language-specific linters don't cover), covering things from directory structure, required files, file staleness/freshness, file size, rules for binary files, rules around use of invisible Unicode, etc. - which can be checked deterministically. Many/most large repos have a set of hand-authored scripts for doing these kinds of checks, the tool I'm building basically packages these in a fast, reusable and extensible tool, with some niceties added.
It would be great if I could integrate this into our existing (and rather extensive) eslint config as as a plugin of some sort rather than integrate yet another new tool to our dev environment. Any plans for that?
Yeppp, I've been seeing this Jacob Coxon [0] guy popping up all over legacy media for the past couple days nonstop...he claims he quit OpenAI and Anthropic because the models are getting 'too smart' and that's dangerous, etc. The typical AI fears mongering drivel, without seemingly any criticism, at all, of the companies he quit supposedly because of these AI fears... and of course the mainstream media appearances prefix the interviews with this guy with 'this is not a marketing stunt'[1]... which, obviously, it is.
Seems just like another case of collusion - continuing the story of VCs pushing all of their companies to use each other and 'stay within the network'. The good news (kinda) for the rest of us, is that many of these VC marketing/product/'strategy' people aren't actually all that competent - this is literally the best they can come up with.
reply