zlacker

I don't see a divergence, from what I can tell a lot of people have only just started using agents in the past 3-4 months when they got good enough that it was hard to say otherwise. Then there's stuff like MCP, which never seemed good and was entirely driven by people who talked more about it than used it. There also used to be stuff like langchain or vector databases that nobody talks about anymore, maybe they're still used but they're not trendy anymore.

It seems way too soon to really narrow down any kind of trends after a few months. Most people aren't breathlessly following the next twitter trend, give it at least a year. Nobody is really going to be left behind if they pick up agents now instead of 3 months ago.

>>s-lamb+(OP)
Not sure how much falling behind there is even going to be, I'm an old school linux type with D- programming skills, yet getting going building things has been ridiculously easy. The swarms thing makes is so fast. I've churned 2 small but tested apps out in 2 weekends just chatting with claude code, the only thing I had to do was configure the servers.

>>s-lamb+(OP)
The only people I see talking about MCP are managers who don't do anything but read linked in posts and haven't touched a text editor in years if ever.

>>s-lamb+(OP)
What‘s used instead of MCP in reality? Just REST or other existing API things?

>>s-lamb+(OP)
While I agree that the MCP craze was a bit off-putting, I think that came mostly from people thinking they can sell stuff in that space. If you view it as a protocol and not much else, things change.

I've seen great improvements with just two MCP servers: context7 and playwright. The first is great on planning sessions and leads to better usage of new-ish libraries, and the second is giving the model a feedback loop. The advantage is that they work with pretty much any coding agent harness you use. So whatever worked with cursor will work with cc or opencode or whatever else.

>>_1tan+up
Yeah, I suspect the people railing against MCP don’t actually use agents much at all. MCP is super useful for giving your agent access to tools. The main alternative is CLI tools, if they exist, but they don’t always, or it’s just more awkward than a well-designed MCP. I let my agent use the GitHub CLI, but I also have MCPs for remote database access and bugsnag access, so they can debug issues on prod more easily.

>>Nitpic+Gw
My main issue with Playwright (and chrome-devtools) is that they pollute the context with a massive amount of stuff.

What I want is a Skill that leverages a normal CLI executable that gives the LLM the same capabilities of browser use.

>>_1tan+up
Yes and no, it's like if a text document was your OpenAPI specification.

The LLM agent can make sense of the text document, figure out the actual tool calls and use them.

And you, the MCP server operator, can change the "API" at any time and the client (LLM agent) will just automatically adjust.