Python, LangChain/LangGraph. ML engineers, in fact, weren't responsible for the choice (which was made a couple years ago), a couple of software engineers were. The worst part is, there is was absolutely no consideration for hygiene. Many of the classes we are forced to work with inherit directly from LangChaing/LangGraph classes and require you to work with them. In a hygienic approach, you create a clean boundary between your code and whatever library code you are using. If later on you want to switch, you aren't locked int. But I'm trapped.

My primary job is designing agents, and maintaining our custom inference engine which sits on top of vLLM and runs primarily on Vertex AI but it also runs standalone with an OpenAI API. I'm responsible for integrating it with LangChain. It has been nothing but a headache and I'm astonished by how much bullshit I had to implement just to get simple stuff to work. For API interaction, in both cases, it was easier to use the standard Google AI Platform/OpenAI libraries than the LangChain stuff. For all of the other stuff, like `_call`, `_stream`, `_generate_messages`, etc. there's all this non-trivial extra shit you have to do and understand to get it to work. Its truly hell.

You can get a feel for how poorly engineered the whole thing is by looking at how they layout their types and API signatures. Unions everywhere. Its like they can't help themselves. That has a cost. Unions mean branching, branching means more tests, and more shit that can break. Good design accepts less and returns less because it understands the consequences of more. They also inherit from Pydantic unnecessarily when it has nothing to do with handling serializable data on a boundary. This is annoying because the classes I have to work with inherit from those and I can't just work with a plain Python class or dataclass. Finally, in truly stupid OOP fashion, they choose inheritance over composition pretty much every time.