4 ms·

I keep waiting for someone to break character and admit that this is all an extended trolling campaign. People are actually connecting these autocompletes to AP

by scubbo 1y ago

I keep waiting for someone to break character and admit that this is all an extended trolling campaign. People are actually connecting these autocompletes to APIs and giving credentials to take impactful external actions? Y'all are _insanely_ trusting.

tra3 1y ago
I'm with you, but it makes for extremely impressive demos. And surprisingly useful day to day improvements. It's not like you can't do this manually (or automatically) but MCP makes things like this so much easier: > Check JIRA against my org-mode and identify any tasks that I worked on that haven't been reflected in either system. Undoubtedly there's an incredible amount of hype, but there's a reason for it. I prefer MCP tools that are read only for now.
- Yoric 1y ago
  Sounds useful. However, I'd rather put deterministic code in control of the LLM than the LLM in control of deterministic code. And that's even before prompt injections.
- throwanem 1y ago
  Do you maintain a newsletter or take subscriptions in some other fashion? This is a refreshingly low-BS take and those are hard to come by, and I would be interested especially in Emacs integrations.
  - karthink 1y ago
    > I would be interested especially in Emacs integrations. gptel can use MCP server tools in Emacs by integrating with the mcp.el package, here's a demo: https://i.imgur.com/WTuhPuk.mp4 https://i.imgur.com/WTuhPuk.mp4. mcp.el: https://github.com/lizqwerscott/mcp.el https://github.com/lizqwerscott/mcp.el Relevant gptel README section (you'll have to unfold the details block): https://github.com/karthink/gptel?tab=readme-ov-file#model-context-protocol-mcp-integration https://github.com/karthink/gptel?tab=readme-ov-file#model-c...
notepad0x90 1y ago
you don't trust or untrust algorithms. like you said, they're just autocompletes. you quantify the risk and see if you have an appetite for it. any sane engineer won't just let an LLM loose, they'll build guardrails around it. If the solution involved untrusted external/human input the risk is much higher, but for a private system, there is only so much paranoia you can throw around before it turns into anthropomorphizing algorithms.
- scubbo 1y ago
  Leaving aside the fact that anthropomorphization is a perfectly valid discursive shorthand - yes, exactly. LLMs have an insanely-high risk profile to be granted access to anything without a human-in-the-loop. > any sane engineer won't just let an LLM loose, they'll build guardrails around it Sure seem to be plenty of insane engineers around these days. And, worse - plenty of them with good marketing teams that can convinced non-engineers that their systems are "safe" and "reliable".

by scubbo 1y ago

tra3 1y ago

I'm with you, but it makes for extremely impressive demos. And surprisingly useful day to day improvements. It's not like you can't do this manually (or automatically) but MCP makes things like this so much easier: > Check JIRA against my org-mode and identify any tasks that I worked on that haven't been reflected in either system. Undoubtedly there's an incredible amount of hype, but there's a reason for it. I prefer MCP tools that are read only for now.

Yoric 1y ago
Sounds useful. However, I'd rather put deterministic code in control of the LLM than the LLM in control of deterministic code. And that's even before prompt injections.
throwanem 1y ago
Do you maintain a newsletter or take subscriptions in some other fashion? This is a refreshingly low-BS take and those are hard to come by, and I would be interested especially in Emacs integrations.
- karthink 1y ago
  > I would be interested especially in Emacs integrations. gptel can use MCP server tools in Emacs by integrating with the mcp.el package, here's a demo: https://i.imgur.com/WTuhPuk.mp4 https://i.imgur.com/WTuhPuk.mp4. mcp.el: https://github.com/lizqwerscott/mcp.el https://github.com/lizqwerscott/mcp.el Relevant gptel README section (you'll have to unfold the details block): https://github.com/karthink/gptel?tab=readme-ov-file#model-context-protocol-mcp-integration https://github.com/karthink/gptel?tab=readme-ov-file#model-c...

notepad0x90 1y ago

you don't trust or untrust algorithms. like you said, they're just autocompletes. you quantify the risk and see if you have an appetite for it. any sane engineer won't just let an LLM loose, they'll build guardrails around it. If the solution involved untrusted external/human input the risk is much higher, but for a private system, there is only so much paranoia you can throw around before it turns into anthropomorphizing algorithms.

scubbo 1y ago
Leaving aside the fact that anthropomorphization is a perfectly valid discursive shorthand - yes, exactly. LLMs have an insanely-high risk profile to be granted access to anything without a human-in-the-loop. > any sane engineer won't just let an LLM loose, they'll build guardrails around it Sure seem to be plenty of insane engineers around these days. And, worse - plenty of them with good marketing teams that can convinced non-engineers that their systems are "safe" and "reliable".