I find the contextless, reflexive labeling of every article on HN as “AI slop” far sloppier and lazier than the articles being criticized. I am no fan of these trends, nor the companies driving them, but this sort of lazy critique has become counterproductive, IMO.
But it is AI slop. It's obvious that the text is all AI-generated, there's half a dozen different tells that punch you in the face from the first paragraph and never stop. Humans just don't write like this. (And fwiw, Pangram flags it as 100% AI-generated).
This particular blog also has the benefit of having some pre-LLM history. You can see that the older writing style is totally different.
So the "author" is already being lazy and dishonest in presenting this as their own work. Why would we believe any part of the story? Why are you trying to give the benefit of the doubt to something so egregiously bad?
So so much AI slop in these posts that usually would be very interesting. I don't like Claude's voice in most situations. The LLMisms stand out like nails on a chalkboard.
A big part of the cost explosion is using the frontier model for tasks that don't need to be done. I tried using the gpt-4o and much cheaper models, and the cheaper ones were more accurate in my three — paying for the reasoning depth that I don't use. The other half is asking the model to do what deterministic rules should be. Calls that don't are the cheapest. Starting with profiling what calls the larger model really needs.
Really folks. That idea of people without experience and knowledge of software engineering vibe coding production code is a little bit not realistic, no matter how much Claude wants to convince investors of the contrary.
Coding agents are fantastic tools, but they are not Jesus: they don't do miracles.
Very interesting. I am guessing the company didn't offer refunds if the receiving computer wasn't able to process the results, unless the issue was on the service...
> A deterministic failure doesn’t get better when you retry it
Among all the other nonsense here, this one is solid advice. Most software with retries just blindly retries N times - in reality, you need a retry/backoff policy based on the specific type of error encountered (I've been rooting these out of our own software stack lately)
This operation should not have been retried even once. The overall operation failed due to an unsatisfied precondition that a second attempt could not have rectified (the non-existent target resource). The status of the job should have transitioned to permanent failure, awaiting manual intervention.