Hacker Newsnew | past | comments | ask | show | jobs | submit | misternugget's commentslogin

Engineer working on Amp here.

I'm very surprised that it took them this long to crack down on it. It's been against the terms of service from the start. When I asked them back in March last year whether individuals can use the higher rate limits that come with the Claude Code subscription in other applications, that was also a no.

Question is: what changed? New founding round coming up, end of fiscal year, planning for IPO? Do they have to cut losses?

Because the other surprise here is that apparently most people don't know the true cost of tokens and how much money Anthropic is losing with power users of Claude Code.


Yeah. If my claude code usage was on API directly, it would be in thousands. I know this because I have addon credits on top of the max plan because I run into weekly limits often

You think anthropic is losing money now with the weekly limits? And while hitting the gas on mass market?

I thought inference was relatively cheap - no?

> Question is: what changed? New founding round coming up, end of fiscal year, planning for IPO? Do they have to cut losses?

I'm gonna say IPO considering their recent aggressive stealth marking campaign on X, Reddit, and HN.


Can you share more on this?

Hey! Thorsten Ball here. Thanks for the shout-out. I was quite confused when someone sent me this article: same "Emperor has no clothes", same "it's only x hundred lines", implements the same tools, it even uses the same ASCII colors when printing you/assistant/tool. Then I saw the "January 2025" in the title and got even more confused.

So, thanks for your comment and answering all the questions I had just now about "wait, did I wake up in a parallel universe where I didn't write the post but someone else did?"


Hi! Thanks again for writing that first Emperor Has No Clothes blog post; like I said, it really inspired me and made everything click early on when I was first dipping my toes into the world of agents. Whenever I teach this stuff to other engineers, I often think back to that moment of realizing exactly how the exchange between LLM, tool call requests, tool functions, and agent code works and I try to get that across as the central takeaway. These days I usually add diagrams to get really clear on what happens on which side of the model api.

I do wonder whether the path here was:

1) You wrote the article in April 2025

2) The next generation of LLMs trained on your article

3) The author of TFA had a similar idea, and heavily used LLMs to help write the code and the article, including asking the LLM to think of a catchy title. And guess what title the LLM comes up with?

There are also less charitable interpretations, of course. But I'd rather assume this was honestly, if sloppily, done.


Many thanks for your article, it was one of the true "aha" moments for me in 2025! It is a shame that your work is apparently being appropriated without attribution to sell an online course...

Thank you! There's a long way to go still, but it makes me happy to hear when what we think about this, well, new way to program seems to resonate with others.


Working on it!


That is about the idea of rewriting existing tooling in Rust to get rid of node_modules folders, not about prompting users whether to download a language server or not.


One mini-feature I really like: authors highlighting their own favorite or popular articles.

I think I saw it first on Julia Evans' blog (https://jvns.ca/categories/favorite/). I also added it to mine (https://thorstenball.com/blog/) and found the exercise of going through the posts and tagging them very enjoyable.


I second this. I wrote a post around this idea of non chronological blog archiving https://olano.dev/blog/web-anthologists


That's right, someone linked me to this article: https://www.macobserver.com/analysis/apple-dry-run-apfs-prio...

Pretty impressive.


> I'm shocked by how many developers check in code that passes the tests but they have not actually tested to make sure it works.

That's actually one of the other topics I wanted to write about yesterday. Chose to write the article above instead.

Yes, 100%. I've seen it many times: manually testing reveals more in 1min than hours of previous discussions/reviews/test-writing.


Manual testing runs into the same problems, just like coupled messy code needs to be mocked to high heaven to the point that it's hard to be completely sure you're testing the functionality, messy code is also really hard to manually test.

I worked at a place that had a 100% test coverage requirement and the codebase was highly coupled so there were mocks everywhere and tests were ridiculously brittle. Manual testing was nearly a non-starter because it was a microservice architecture with a lot of moving pieces and non-deterministic docker builds failed with surprising regularity (to the point that people shipped development VMs around much to the chagrin of the project "architect"). Getting the stars to align for docker-compose to result in a working test system, then populating it with whatever specific data was needed for that test case so you could actually walk through the flow was a minor miracle.


Hey, author here. Yeah, I worked at Sourcegraph and I do think we built some high-quality stuff and we did write tests. I also think a lot of them were necessary. But, like I wrote here, I think that maybe we/I sometimes overdid it with tests and I'm not so sure about the use of /some/ of them anymore.


Rust's debug-print {:?} quotes the path here.


Yes, but rust's quoting does not match shell's quoting. Imagine a path like:

    $(rm -rf /*; echo /)
That's a valid Unix path, but rust's quoting does nothing to stop it: https://play.rust-lang.org/?version=stable&mode=debug&editio...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: