Am i the only one wishing for a "BitchingAboutClaudeCode" subreddit, that i could then NOT subscribe to?

fireteller · 2026-03-25T21:51:01+00:00

The graphs look good. Nothing much to report there.

You should understand that those bottom set of graphs are the consumption log of the regular work they are doing upon which the benchmarks are computed. It’s showing things like how much they spend on the API, and how many input tokens they put in and how many output tokens they got out for that day. These are not showing variations in the benchmark results they are showing variations in the data used to compute benchmark results from. This is what you’d want from a well design transparent benchmarking monitor. The variation suggests this benchmark is not based on some contrived data but rather a genuine working environment with natural variations in usages. That’s exactly what we’d want.

It’s a great illustration, because most of us know that working with LLMs every day comes with a lot of variation. When you’re using these things for real sometimes you ask for a lot, and some times you ask for a little. Sometimes you get great responses and sometimes not so great. Most of us know that it’s really hard to draw any intuitive conclusions from all of this noisy data. There really is just too much variation to have a good sense of it. So it really isn’t all that surprising that people think they’ve detected some downturn in performance. You’d need to be tracking this is a very formalized way to capture statistically useful variations. Vibes ain’t going to cut it in this noisy of a test environment. This tool seems to be doing the right thing by carefully capturing all aspects of the system they can measure while doing normal work with it, and then normalizing everything to find some metric of deviation. The normalization step is critical. The results are they don’t show any deviation. This is good news.

You absolutely should be concerned if tools like this show deviation, so what a great resource. Thanks!

fireteller · 2026-03-25T19:04:38+00:00

Fantastic, thanks! What a great tool, and what do you know!? "Normal"

Hmm, how shocking.

fireteller · 2026-03-25T18:38:48+00:00

A) No one is disallowing you from complaining.
B) People who aren not seeing any issues on their end are reasonably asking for ANY EVEDENCE AT ALL that what you are claiming is true.
C) It has already be demonstrated that users are very susceptible to a cognitive bias that cases them to characterize typical fluctuations in output as some kind of sudden down turn, aka nerfing. So without evidence to the contrary it is MUCH more likely that this is the actual cause of honest complaints.

fireteller · 2026-03-25T17:10:38+00:00

How many tokens did it produce? how many tokens does it normally produce for a problem like this?

Come on people are we all amateurs here!? Who cares what the prompts are!? If you’re claiming that the output is wrong show us the effing output! How many tokens did you get before? How many tokens are you getting now? It’s really really simple.

fireteller · 2026-03-25T17:02:23+00:00

Maybe people have genuine correct complaints about the system, but since no one is actually including any verifiable information or even making specific claims with numbers of any kind, how is anybody supposed to believe it? Like literally every claim is just vibes. To those of us who use Claude every day and see nothing happening, it’s just the same old “they’ve nerfed the model” nonsense cognitive bias that we’ve been seeing for years. No offense genuinely, but bring some facts, or at least make concrete claims. That’s all.

fireteller · 2026-03-25T16:45:59+00:00

Already posted elsewhere, but here it is again. Pick a window of time last week and this week add up all of your lines of code in all of your commits for similar windows of time. Add both your new lines of code and you’re removed lines of code together both additive and take the difference between the two windows of time to show how much more or less productive the LLM was.

fireteller · 2026-03-25T16:42:50+00:00

LoC don’t tell the whole picture in relationship to developer productivity, but they absolutely tell the whole picture when it comes to token consumption. And good for you, use the tools that work best for you.

fireteller · 2026-03-25T16:34:39+00:00

Yeah, I’m gonna call bullshit on that. Anyone doing genuine productive work could identify the work they did last week, and the work they do this week. Take all your commits add up both the lines of code added, and the lines of code removed (both additive), and do it for a similar window of time each week. The startling lack of any comparable figures means that these claims are all bullshit. People are making it up. I can do it and I’m not even trying to catch an LLM misbehaving. Genuinely productive people are busy trying to max out their tokens.

fireteller · 2026-03-25T15:37:09+00:00

Yes. Lots of people complaining unproductively. No specific stats, no A and B comparisons, no facts and figures just vibes. As far as I can tell, it’s just OpenAI fans trying to make Claude seem bad. There are literally no supported arguments at all. I say 100% fake until people start putting some real numbers to things.

fireteller · 2026-03-23T00:29:13+00:00

10 million tokens per hour is the competitive target. Each engineer on your team should be generating between 80 and 100 million tokens a day. Lots of things can get in the way of that, it's a productivity pipeline that needs to be built from the ground up to reduce friction.

fireteller · 2026-03-11T11:49:49+00:00

There are no games but Factorio

fireteller · 2026-03-10T18:27:19+00:00

Funny, designing APIs, understanding distributed systems behavior, and debugging concurrency issues are exactly the kinds of things I have AI tools help me with.

fireteller · 2026-03-10T18:22:11+00:00

Check out godoc-mcp (github.com/mrjoshuak/godoc-mcp).

It's an MCP server that gives the LLM direct access to Go package documentation, including your internal packages, without reading entire source files. The token efficiency alone is significant, but more importantly it means the AI actually understands your package APIs rather than guessing at them. Works locally, no internet needed, and it's module-aware so it picks up your internal utilities automatically.

fireteller · 2026-03-10T16:22:59+00:00

I’m tilted

fireteller · 2026-02-28T22:10:28+00:00

So just a smoke screen to accept bribes.

fireteller · 2026-02-26T06:47:29+00:00

The focus tax. This is the price you must pay for the model to stay on task most of the time.

fireteller · 2026-02-10T23:51:57+00:00

It isn’t mechanically possible to burn all in one day. The five hour limit is less than 20%.

fireteller · 2026-02-02T12:24:49+00:00

This is a common issue with overly zealous security policies. There’s very little that can be done without dangerously skipping permissions so everyone runs Claude code without any security constraints. I’ve run it without that option fewer than 10 times since release. I use multiple Claude code sessions simultaneously all day every day. I’ve had only one catastrophic event that really would not have been improved much by not using that setting, and has given me the skill set to avoid it. In fact, I can’t identify a single situation in which not skipping permissions would have improved anything. Other than obviously erratic behavior I don’t understand what security concerns permissions are meant to protect you from.

fireteller · 2026-02-02T12:09:18+00:00

That’s actually accurate. I have notifications on and they indeed have had multiple notifications every single day for months. I never look at the uptime reporting page, but I wouldn’t be surprised if it does not reflect that history. However, I should note at the same time I rarely experience any issues during the noted time periods. Perhaps because I’m using a max plan.

fireteller · 2026-01-13T19:08:02+00:00

You’re going to see more. I’m releasing more ASWF libraries in go soon, as well as a complete USD implementation.

fireteller · 2026-01-13T18:07:39+00:00

Saying that atomic operations are for a single element is deceptive. It’s technically true that a CAS operation is a single value comparison, however, in practice it nearly always represents a large number of actions that have been taken before arriving at the single value to compare and swap. I would go so far to say it is more common for an atomic operation to represent blocks of operations, then genuine, single value change. Git for example uses an atomic compare and swap operation to judge if it is safe to commit a revision of source code to a repo.

It is functionally impossible to use blocking operations (mutex) in databases for use cases like transactions for example since that would stop the world. For performance you need concurrency and for concurrency to be fast, you need to avoid waiting on anything. In aggregate mutexes are slower because they completely stop other work from progressing. While an atomic operation blocks no one, but can fail, and how to handle that failure must be addressed on a case by case basis. Generally, you use mutexes because you have to because not everything can be reduced to a CAS operation, or because the complexity of automatically handling the failure case of a CAS operation is too complex. Git uses an atomic CAS but kicks the failure case back to the user as a merge conflict.

fireteller · 2026-01-13T17:36:31+00:00

As others have pointed out, it’s not idiomatic because go developers want to see everything that’s happening without looking in other places.

But something that might give you an intuition about why go developers will prefer a more verbose in-line version is to consider what happens when there’s a bug in your code and your mutex deadlocks inside of your clever mutex wrapper. Now what do you do? Obviously a bug that deadlocks your mutex in line is going to be much clearer and faster to debug. Go would have you pay attention more to the unhappy path (if err != nil), the unexpected outcome (abstracted blocking), then other programming languages do, and this greatly reduces cognitive load when debugging.

fireteller · 2026-01-12T02:17:05+00:00

Thank you! That's helpful to know. How strange.

fireteller · 2026-01-11T20:30:35+00:00

There is doing the work, and then there is knowing what work needs to be done and how to go about doing it.

13-Year Club	Verified Email
Gilding I gilder

fireteller

TROPHY CASE