What interactions with internal tools? If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.
Retrieving messages from Slack over MCP allows a shared read-only bot account accessible from the web browser and CLI. Setup is automated so users can just ask Claude to read them and do something.
Sharing Slack with Claude:
- Using the "normal" way, it shares too much, including privates messages.
- Using your own token, it doesn't work with Claude.AI or Cowork and requires you to go to slack.com to generate an application, tokens and more.
- Using a shared token, now you need context to tell Claude to retrieve it. It still doesn't work for non-Claude Code workflows. Rotation may break currently running workflows.
Yeah. Like I had Claude code write an upload Slab script, and a few linear integration scripts, now it just runs these to interact with those systems. I had it write a redshift proxy that doesn’t take login creds and is just a logging read only account but it can just write sql to research to its hearts content (some columns hashed on replies) and I don’t need much trust but I get a lot of good analysis and verification done.
> If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.
The MCP is the deterministic program.
You need to take a step back and look at the problem you're discussing. What's exactly this MCP thing? It's a protocol to allow agents and coding assistants to access tools, services, and data sources, through a standardized interface.
It's the interface for your deterministic program. That's it.
It's easier if you started a while back shunning all human labor (including your own) in favor of fully deterministic systems. Reality is deterministic so your company or project logically can be run off a single compiled binary with formal verification of correctness for every possible scenario.
I've been doing this myself but it's been extremely hard to get buy-in from the rest of the org. They keep churning MCPs for deterministic interactions while I have tons of little tools written by clankers, not only for clanker-use but also for my own use when needed.
I don't know if it's even OK for a cop to just randomly watch a random street corner without a specific reason to do so. If a cop was following a given person around all day every day without probable cause would this not be considered harassment? If we view the Flock Camera network as a single system is this not harassment?
Just to add context and not to comment on rightness, that was one of the early core purposes of policing--to ensure that a people in a particular public space (where either the people or the space are particularly vulnerable) are free from unwanted disturbance. Here is that exact concept shown in a painting from 172 years ago: https://en.wikipedia.org/wiki/The_Gleaners_(Jules_Breton).
This is what I've been mulling over for months. Surely there's a better, more rigorous specification format than Markdown prose that already exists in the industry and is useful to the agents. Formal Use Cases perhaps? Probably not Gherkin but maybe some other spec DSL.
I agree with this but what I've been trying to answer the last few months is if there was an optimal language for the spec. As with you, I don't think it's English Markdown, but I don't think it's Java either. I also don't think it's Gherkin, Lisp perhaps? I'm still searching.
Well.. I think this is a big open problem in philosophy.
On one hand, you have things like Lean (calculus of inductive constructions), these are relatively simple formal logics (just in more practical notation) that let you define any conceivable type, which is akin to specification.
On the other hand, there is a rich set of modal and fuzzy logics that can help with aspects of reasoning in natural language. I think these can be defined in the former, but nobody has really made a good agreement as to how.
So the main difficulty is for any such language to gain traction, people who speak it.
Instead, we trained LLMs and they came up with something (evolved to reason). I think the future philosophical research will need to answer what exactly do LLMs bring to the table in terms of formalization of natural language.
I realized recently the LLMs are calling bullshit on the moniker of engineer or programmer that I've bestowed on myself over the course of my career. The current LLMs are making it quite easy to seperate software design from implementation. I used to be firmly in the camp that one really needed to roll up their sleves, sit down with an editor and start banging away until the software evolved and coalesced around a solution.
I convinced myself that functional specs and detailed design documents were not needed because they wouldn't be kept in sync with the code. But the LLMs are essentially turning the synthesis of the code from those documents to a compilation step of sorts.
Now I must ponder the question, what portions of the acts of coding, designing and delivering a working product were the portions that bring me joy. I've been attempting to answer this question by making a concerted effort to delegate the coding to the LLMs and reviewing if the code conforms to the designs I've written down. This process is much closer to the historical engineering disciplines but I have to say, its not been easy.
My advice to the the more junior reading this. Experiment with different functional and design spec formats that best serve the LLMs and develop the skill of writing these and then managing the LLMs.
TLDR, the LLMs are giving the term Software Engineering actual meaning.
>The current LLMs are making it quite easy to seperate software design from implementation.
I don't really agree. This kind of division of labor has always been possible, with architects doing the design and engineers/programmers doing the implementation. Architects who design systems with lofty requirements with no regard for the cost of their decisions are kind of a meme in the industry. I don't believe it's really possible to separate design from implementation, unless the person specifying the design is really knowledgeable about the problem space.
The Architects you're describing aren't reviewing the code and making suggestions for changes so your comparing apples and oranges. What I'm describing is more of a team lead to team members relationship.
I understand that. That review process is a bridge that imposes a maximum separation between design and implementation (that is to say, they can be separated so far, and no further). The two can't be fully decoupled.
reply