Agreed. This sentiment you are replying to is a common one and is just people self-aggrandizing. No, almost nobody is working on code novel enough to be difficult for an LLM. All code projects build on things LLM's understand very well.

Even if your architectural idea is completely unique... a never before seen magnum opus, the building blocks are still legos.

I think there is a sweet spot for the training(?) on these LLMs where there is basically only "professional" level documentation and chatter, without the layman stuff being picked up from reddit and github/etc.

I was looking at trying to remember/figure out some obscure hardware communication protocol to figure out enumeration of a hardware bus on some servers. Feeding codex a few RFC URLs and other such information, plus telling it to search the internet resulted in extremely rapid progress vs. having to wade through 500 pages of technical jargon and specification documents.

I'm sure if I was extending the spec to a 3.0 version in hardware or something it would not be useful, but for someone who just needs to understand the basics to get some quick tooling stood up it was close to magic.

The standard for obscurity is different for LLMs, something can be very widespread and public without the average person knowing about it. DICOM is used at practically every hospital in the world, there's whole websites dedicated to browsing the documentation, companies employ people solely for DICOM work, there's popular maintained libraries for several different languages, etc, so the LLM has an enormous amount of it in its training data.

The question relevant for LLMs would be "how many high quality results would I get if I googled something related to this", and for DICOM the answer is "many". As long the that is the case LLMs will not have trouble answering questions about it either.

> llms are generally useful to understand more specialized / obscure topics

A very simple kind of query that in my experiences causes problems to many current LLMs is:

"Write {something obscure} in the Wolfram programming language."

They can tell if you let it use whatever CSS it wants (Claude will nearly always make a purple or blue website with gross rainbow gradients). They can also tell if you let it write your marketing copy.

If you decide on your own brand colors and wording, there’s very little left about the code that can’t be done instantly by an LLM (at least on a marketing website).

Some subscriptions offer "unlimited tokens" for certain models. i.e. GitHub co-pilot can be unlimited for GPT-4o and GPT-4.1 (and, actually, GPT-5 mini!). So: I spent some time with those models to see what level of scaffolding and breaking things down (hand holding) was required to get them to complete a task.

Why would I do that? Well, I wanted to understand more deeply how differences in my prompting might impact the outcomes of the model. I also wanted to get generally better at writing prompts. And of course, improving at controlling context and seeing how models can go off the rails. Just by being better at understanding these patterns, I feel more confident in general at when and how to use LLMs in my daily work.

I think, in general, understanding not only that earlier models are weaker, but also _how_ they are weaker, is useful in its own right. It gives you an extra tool to use.

I will say, the biggest findings for "weaknesses" I've found are in training data. If you're keeping your libraries up-to-date, and you're using newer methods or functionality from those libraries, AI will constantly fail to identify with those new things. For example, Zod v4 came out recently and the older models absolutely fail to understand that it uses some different syntax and methods under the hood. Jest now supports `using` syntax for its spyOn method, and models just can't figure it out. Even with system prompts and telling them directly, the existing training data is just too overpowering.

I would say they are not changing but evolving and you evolve with them.

For example: gemini became a lot better in a lot more tasks. How do I know? because i also have very basic benchmarks or lets say "things which haven't worked" are my benchmark.

If you had to hold on for dear life during the ~2014-2017 JavaScript framework chaos, then 3-6 months is peanuts.

This is an industry that requires continuous learning.

This is not an argument for its revolutionary utility. Balancing rocks on the beach is very tiring and difficult for some people, and you can be significantly better at it. Not really bringing anything to the immediate conversation with that insight.

You don’t need 100x productivity to be disruptive. In business 10% gain can be quite enormous. My senior engineers are estimating 25-50% gains. That is a far cry from your 100,000% gain, but very real and meaningful.

> LLMs have the exact same transformative impact on humanity.

But this is begging the question.

Yes, we can see that the internet was radically transformative.

But you are arguing that this somehow proves that LLMs are too, when there's wildly insufficient evidence—either on where LLMs are going in themselves, or in the comparison—to credibly make that claim.

I mean the first decline happened well before ChatGPT so it can't just be that.

So where is all the new tech years into ai? Turns out that wasn’t the limiting factor. The limiting factor is still what it was 10,000 years ago in business: accumulating capital to start and finding a fit in the market to last.

Google raised only a single large round of institutional funding before going public, with the investors contributing $12.5 million

I can be much more specific about “everyone” if you’d like.

You're right, you are using it wrong. An LLM can read code faster than you can, write code faster than you can, and knows more things than you do. By "you" I mean you, me, and anyone with a biological brain.

Where LLMs are behind humans is depth of insight. Doing anything non-trivial requires insight.

The key to effectively using LLMs is to provide the insight yourself, then let the LLM do the grunt work. Kind of like paint by numbers. In your case, I would recommend some combination of defining the API of the library you want yourself manually, thinking through how you would implement it and writing down the broad strokes of the process for the LLM, and collecting reference materials like a format spec, any docs, the code that's creating these packets, and so on.

Well, if you ask it to write a library at the start, it's likely it will not do that well. Start small, spoon feed some examples.