Since I’ve been attempting to keep up with the jones (as they say) in terms of AI, the big kids on the block from what I’ve heard on my list were MCP and Langchain. MCP seemed like the thing a few friends were gleefully praising and Langchain was coming up repeatedly either in conversation or on the job boards. Normally, I don’t buy into the hype because I like to see technologies really prove themselves before investing time into them. That said, because I haven’t been an early adopter, I did miss out on a few key things like MongoDB/NoSQL, GraphQL, Node.js, etc. that might’ve helped me out a bit more later on. However, none of those things were that crucial in my overall career compared to more conceptual learning. Nonetheless, I decided to take a peek to see what the hype was about.
First, MCP, or Model Context Protocol, is self described as the “USB for connecting models to external systems.” That’s just a fancy way of saying this is an overengineered thing that probably is best used by mid to large sized companies who need scale to connect their backend system if they lack an architect. As far as I can tell, all you’re really doing is writing another wrapper function (or functions) to serve data to the AI and allow it to be queryable through the JSON-RPC protocol where you need to stand up one or more MCP servers on top of whatever solutions you’re already hosting. It sounds great on paper especially with the fancy marketing description but here’s what they’re not telling you: you get added complexity and more importantly another network call that you have to secure to make this shit work.
That seems like a lot of phony bologna to me.
Why not just write a wrapper function that you can pass into your AI…oh wait you can do that without the overhead. And it’s fucking easy. You know what this load of crap smelled like to me? EJBs 1.0 from back in the day. Overengineered, overly complex, poorly documented hype that just were marketed to CEOs of companies rather than the developers. Of course, resume boosters loved EJBs just because then they could claim they were on the cutting edge of tech. But when was the last time you heard of anyone using EJBs? How many iterations did it take before people just realized you needed some basic CRUD system that spat out JSON with some caching to hopefully let that system survive?
So for me at least in my limited time playing with this junk, I just thought it’s worthless and mostly for people who want another resume booster. But companies would need to invest resources into this thing to get it working rather than just developer time. Server cost for self-hosted MCP servers, security to ensure there’s authentication, more eyes on another resource to manage when it goes down for one reason or another. All just to make a simple query that you can write with a wrapper function.
What about Langchain? What does this new player on the market have to offer that a wisened, old fart dev like me can’t already provide with the bare bones tools? How about another horribly documented, obfuscated through layers upon layers, spastic, swiss army knife that doesn’t do anything particularly well. I gave myself a day to give this thing a try and it was a hair pulling experience. In the end, the real wall I ran into was getting told to check to ensure that my billing was enabled. WTF.
Worse yet both ChatGPT and Gemini had no clue what the current APIs were since those constantly were changing. And then there’s the models underneath that change. And if something underneath changes, it’s hard to figure out how to get all of it working because you have to deal with layers of abstraction.
So maybe I’m just stupid and cheap. That’s a fair assessment. Cheap I can guarantee. But the stupid part I realized I’m not the only one who shared similar feelings about Langchain. I read a reddit post where people complained about very similar things. The best comment I read generally could be summed up to how it was probably someone’s pet project that got out of control and some jackasses decided to form a company and attempt to make money off of it. Okay, I editorialized that comment but that’s effectively the message. There was another comment about how if you decide to switch this model for that and that graph DB for that, then your homegrown solution is going to be fucked. My reply is that if you’ve invested that much time, money and resources into that solution, you aren’t going to suddenly change everything on whim. Your CEO and CFO would probably want a very long talk with you. So that’s not a realistic situation.
What a realistic situation is is you going crazy when you get your next update and these schizoids decide to change things yet again because they can’t make up their minds and the landscape for all the underlying components change too. So are you going to depend upon a brittle framework with poor, outdated documentation that can’t produce more than the perennial weather app as your solution? Give me my own in house where I code wrappers around these drivers that I can control and debug rather than something that bipolar, neurotic developers are baking in the oven (and I’m sure that’s not the only thing getting baked).
Langchain really seems targeted to places that can afford it, have no decent in house architect and need quick and dirty solutions for people who aren’t great coders. That’s the real take away for me. Maybe I’m being harsh but to me a good tool should be something reliable that is easy to use and solves my headaches. Langchain, at this stage, is akin to having a hammer that strikes you in the head rather than a nail. That’s not a good tool to me.
I think it’s better to understand how agents, genai and infrastructure like GCP play together to perform the real tasks you need. I think in the AI gold rush people are tripping on their feet and not really building anything long lasting. Or they’re trying to build swiss army knives glass houses (imagine that visual). What’s really needed are cost effective, proven small tools that actually function as tools. You then take these tools (or parts) and make the bigger tools for more proven things. That’s the pattern of engineering that we need, not the standard anti-pattern of the silver bullet/god object that engineers end up painting themselves into a corner with (along with overly ambitious and greedy CEOs and the VC crooks that back them).
Leave a Reply
You must be logged in to post a comment.