> And if for some ungodly reason you had to do it in Python

I literally invoke sglang and vllm in Python. You are supposed to (if not using them over-the-network) use the two fastest inference engines there is via Python.

Python being a very bad language for LLM stuff is a hot take I haven’t heard before. Your arguments sound mostly like personal preferences that apply to any problem, not just agentic / LLM.

If we’re going to throw experience around, after 30+ years of coding experience, I really don’t care too much anymore as long as it gets the job done and it doesn’t get in the way.

LangChain is ok, LangGraph et al I try to avoid like the plague as it’s too “framework”-ish and doesn’t compose well with other things.

Ok I agree with that, I think they had some weird idea of managing templates in LangSmith and then being able to load them dynamically from LangChain.

LangSmith’s prompt engineering workflow is okay-ish but a lot of work and gets quite expensive quite fast, and only works for a specific set of prompts (ie one-turn prompts, multi-turn never works).

PydanticAI seems more lightweight and gets out of the way.

Have you seen hamilton/burr python packages for building the state machines for llm work?

yes, in an industry that has rapidly changing features and 7000 of these products that splinter and lose user base so quickly you should write your own orchestration for this stuff. It’s not hard and gives you a very easy path to implementing new features or optimizations.

Oh gosh, not that legacy "hand rolled code"

For what LangChain does, yes, handrolled code. There won't be much of it because it doesn't actually do all that much.

As for "import openai", that's actually somewhat orthogonal, but if what you want is a common API for different providers then there are many options around that do just that. But then again at that point you probably also want something like OpenRouter, which has its own generic API.

Have you heard of `def`?

IME you could get reliable JSON or other easily-parsable output formats out of OpenAI's going back at least to GPT3.5 or 4 in early 2023. I think that was a bit after LangChain's release but I don't recall hitting problems that I needed to add a layer around in order to do "agent"-y things ("dispatch this to this specialized other prompt-plus-chatgpt-api-call, get back structured data, dispatch it to a different specialized prompt-plus-chatgpt-api-call") before it was a buzzword.

To this day many good models don't support structured outputs (say Opus 4.5) so it's not a panacea you can count on in production.

The bigger problem is that LangChain/Python is the least set up to take advantage of strong schemas even when you do have it.

Agree about pillaging for prompts though.

LangChain does not solve any actual problem, so there is no need to replace it with anything. Just build without it.

There's a great talk called Pydantic is all you need that i highly recommend

pydantic/pydanticAI in builder mode or llamaindex in solution architect mode.

> I prefer reading the LLM output for accessibility reasons.

And that's completely fine! If you prefer to read CVEs that way, nobody is going to stop you from piping all CVE descriptions you're interested in through a LLM.

However, having it processed by a LLM is essentially a one-way operation. If some people prefer the original and some others prefer the LLM output, the obvious move is to share the original with the world and have LLM-preferring readers do the processing on their end. That way everyone is happy with the format they get to read. Sounds like a win-win, no?

Unfortunately, the sheer amount of ChatGPT-processed texts being linked has for me become a reason not to want to read them, which is quite depressing.

> You wouldn't complain as much if it were merely poorly written by a human.

Obviously.

> It gets the information across.

If it is poorly written by a human? Sure!

> The novelty of complaining about a new style of bad writing

But it's not a "new style of bad writing", is it?

The problem is that LLM-generated content is more often than not wrong. It is only worth reading if a human has invested time into post-processing it. However, LLMs make badly-written low-quality content look the same as badly-written high-quality content or decently-written high-quality content. It is impossible for the reader to quickly distinguish properly post-processed LLM output from time-wasting slop.

On the other hand, if its written by a human it is often quite easy to distinguish badly-written low-quality content from badly-written high-quality content. And the writing was never the important part: it has always been about the content. There are plenty of non-native English tech enthusiasts writing absolute gems in the most broken English you can imagine! Nobody has ever had trouble distinguishing those from low-quality garbage.

But the vast majority of LLM-generated content I come across on the internet is slop and a waste of my time. My eyeballs are being DDoSed. The only logical action upon noticing that something is LLM-generated content is to abort reading it and assume it is slop as well. Like it or not, LLMs have become a sign of poor quality.

By extension, the issue with using LLMs for important content is that you are making it look indistinguishable from slop. You are loudly signaling to the reader that it isn't worth their time. So yes, if you want people to read it, stick to bad human writing!

Kind of, LLMs still use randomness when selecting tokens, so the same input can lead to multiple different outputs.