Live data from Hacker News

A few random notes from Claude coding quite a bit last few weeks

twitter.com

861–870 of 870 posts

Re: A few random notes from Claude coding quite a bit last few weeks

#861

Earlier quoted context omitted.

Good for you. Others like myself find the tools incredibly useful. I am able to knock out code at a higher cadence and it’s meeting a standard of quality our team finds acceptable.

Looking forward for those 10x improvements to finally show up somewhere. Any day now! Jokes aside, I never said it's not useful, but most definitely it's not even close to all this hype.

> very flawed non-deterministic tool that requires a lot of effort to get useful code out of it

We are all different but I think most of us with open minds are the flaw in your statement.

Re: A few random notes from Claude coding quite a bit last few weeks

#862
I sometimes wonder about the similarities between this paradigm switch (coding -> vibe coding) and when the industry switched from writing assembler to using high-level languages. I both cases we switched from having to specify every posibble implementation detail to focusing more on higher level concepts and letting the machine work out the rest. Maybe in the future instead of sharing source code, we will share prompts that we used to create a program. Similarly how different compilers produce different assembly now, "compiling" prompts with different agent/model would give different results. Maybe in the future an analog for "optimizing compiler" would emerge for agents, which would turn the (working) slop into something more clean.

Re: A few random notes from Claude coding quite a bit last few weeks

#863
post #355

Earlier quoted context omitted.

Perhaps it's harder to "do Closure wrong" than it is to do JavaScript or Python or whatever other extremely flexible multi-paradigm high-level language

Having spent 3 years of my career working with Clojure, I think it actually gives you even more rope to shoot yourself with than Python/JS. E.g. macros exist in Clojure but not Python/JS, and I've definitely been plenty stumped by seeing them in the codebase. They tend to be used in very "clever" patterns. On the other hand, I'm a bit surprised Claude can tackle a complex Clojure codebase. It's been a while since I a…

This changed a lot over the last year, with an absolute seismic shift with Opus 4.5 (I've been trying regularly).

Re: A few random notes from Claude coding quite a bit last few weeks

#864

Earlier quoted context omitted.

Why not? Seems like you'd just build the same app on each of the models you want to test and judge how they did.

> Why not? Seems like you'd just build the same app on each of the models you want to test and judge how they did. I tried that on a few problems; even on the same model the results have too much variation. When comparing different models, repeating the experiment gives you different results.

Interesting point about model variation. It would be useful to run multiple trials and look at the statistical distribution of results rather than single runs. This could help identify which models are more consistent in their outputs.

Re: A few random notes from Claude coding quite a bit last few weeks

#865

Earlier quoted context omitted.

And yet many the same people who lament the tooling bloat of today will, in a heartbeat, make lame jokes about PHP. Most of them aren't even old enough to have ever done anything serious with it, or seen it in action beyond Wordpress or some spaghetti-code one-pager they had to refactor at their first job. Then they show up on HN with a vibe-coded side project or blog post about how they achieved a 15x performance bo…

Highly relevant username!

I try :)

Re: A few random notes from Claude coding quite a bit last few weeks

#866

Earlier quoted context omitted.

> Why not? Seems like you'd just build the same app on each of the models you want to test and judge how they did. I tried that on a few problems; even on the same model the results have too much variation. When comparing different models, repeating the experiment gives you different results.

Interesting point about model variation. It would be useful to run multiple trials and look at the statistical distribution of results rather than single runs. This could help identify which models are more consistent in their outputs.

> Interesting point about model variation. It would be useful to run multiple trials and look at the statistical distribution of results rather than single runs. This could help identify which models are more consistent in their outputs.

That doesn't help in practical usage - all you'd know is their consistency at the point in time of testing. After all, 5m after your test is done, your request to an API might lead to a different model being used in the background because the limits of the current one were reached.

Re: A few random notes from Claude coding quite a bit last few weeks

#868

At the risk of exposing my... atypical take on contemporary occupational "morality". LLMs, and Claude Code specifically, have given me the ability to work two jobs, and retain my soft-standing as the "guy" that gets stuff done/knows my stuff/can fix anything, while still working less hours than I did when I just had a single job. I firmly believe, at SOME point, ML is going to eat my lunch. And I'd like to be well an…

Honestly man, this is totally understandable. It's a rat race, and if you don't use the tools at your disposal, you'll be left behind.

Re: A few random notes from Claude coding quite a bit last few weeks

#869

Earlier quoted context omitted.

> And you most likely do not pay the actual costs Oh my lord you absolutely do not. The costs to oai per token inference ALONE are at least 7x. AT LEAST and from what I’ve heard, much higher.

We can observe how much generic inference providers like deepinfra or together-ai charge for large SOTA models. Since they are not subsidized and they don’t charge 7x of OpenAI, that means OAI also doesn’t have outrageously high per-token costs.

Actually, that doesn’t mean anything.

OAI is running boundary pushing large models. I don’t think those “second tier” applications can even get the GPUs with the HBM required at any reasonable scale for customer use.

Not to mention training costs of foundation models

Re: A few random notes from Claude coding quite a bit last few weeks

#870
post #608

> I am bracing for 2026 as the year of the slopacolypse across all of github, substack, arxiv, X/instagram, and generally all digital media. 2026 is just when it picks up - it'll get exponentially worse. I think 2026 is the year of Business Analysts who were unable to code. Now CC et all are good enough that they can realize the vision as long as one knows exactly the requirements (software design not that important)…

Agree here, the code barrier (creating software) was hiding the real mountain: creating software business . The two are very different beasts.

Software engineers were never paid to "create software business". That's the job of business ppl, and a thin minority of software engineers.
Post reply on HN