If you really do mean normal Vim (which I don’t think you do) then it’s on my list. NeoVim will probably be solved before I get to it 
I meant the NormalVim distribution of Neovim.
LOL ya I figured I was showing my ignorance there, though apparently Nvim plugin authors are doing everything they can to make any combo of “<english-modifier> Vim” to mean “nvim” so to that I can only throw up my hands 
It is the worst name, totally unsearchable.
I just had an interaction with someone who mentioned “normal Vim” and I figured they meant “Vim” as “Vim” as in, uh, “not-nvim,” so now I don’t know what to think. Though if this is as hard as life gets I suppose it’s not so bad.
1 Like
I got it working with just claude desktop on the side, so no changes to my (n)vim configuration.
Asked it to make a change and it worked nice!
What I wonder is how do you switch projects?
By who? Musk? 
Having said that, there are fully autonomous vehicles around right now, and maybe not where you’d expect. Google tells me:
China has emerged as a leader in fully autonomous vehicle development, particularly in the realm of robotaxis and other commercial applications. Cities like Beijing and Wuhan are actively testing and deploying autonomous vehicles on public roads.
Vid: https://www.youtube.com/watch?v=izLfWY4c0Ko
Me too! I personally wouldn’t trust a self-driving vehicle just yet - and maybe not ever… you’ve seen Upload, right? 
Upload Spoiler
IIRC he works in tech, wants to help save the world (for free) but others who want to make as much money as possible have other ideas, and kill him via a self-driving car! It’s actually a nice show well worth a watch 
On a more serious note and getting back on topic, the AI revolution is, I think, inevitable (unless we annihilate ourselves). A nice idea for a Wikis, Polls & Dev Envs > Polls thread with multiple polls could be:
Edit: Poll posted here: How useful do you think AI tools are/will be? (Poll)
1 Like
3 posts were merged into an existing topic: How useful do you think AI tools are/will be? (Poll)
Congratulation Jose, what a fantastic achievement, and open source. Thank you so much.
Google just announced this today: Announcing the Agent2Agent Protocol (A2A) - Google Developers Blog
4 Likes
Watch TideWave transform Claude Desktop into an agent by running a MCP server in your web app!
I don’t get it. Why is there a need for this when you can use Claude Code and Cursor directly? Why would you want to use Claude Desktop?
Why is there a need for this when you can use Claude Code and Cursor directly? Why would you want to use Claude Desktop?
You can use Tidewave with any AI Assistant that support MCPs. Jose used Claude, but Cursor would work too.
I’m using Tidewave 2-3 times a week, based on my personal experience it boosts the capacities of the AI assistant and brings me back results with less round trips and generally more accurate. Tidewave provides functions that the LLM can use to interact with a running app, that’s just great!
1 Like
I use it with claude code because that way I do not have to leave my terminal.
2 Likes
Allow me to re-ask my question above, because I believe that I failed to formulate it properly.
I am not asking if you can use Tidewave with Cursor/Claude Code/Claude Desktop. That is a given.
I am asking for clarification as to what is the value proposition for Tidewave in the first place? What can it do that Cursor/Claude Code cannot already do? The demonstration of Jose was centered around:
- Ability to have Claude Desktop access the phoenix project files via Tidewave MCP —> Cursor/Claude Code already fulfill this exact need
- Ability to have Claude Desktop read the contents of the Liveview component in the browser —> Browser MCPs already exist to fulfill this need.
So what is the value proposition of Tidewave? Does it have special features that make it much better than other solutions? If so, in what way and why?
4 Likes
Great questions!
That particular example had the MCP tell the precise LiveView active on the page, which is not as straight-forward to get from a browser MCP (doable but then you had to write your own JS traversal scripts). This reveals the two important parts about Tidewave: it runs inside your application, so it has access to everything your application does, and it is fine-tuned for your specific web framework.
For example, one of the tools Tidewave offers is access to the database. Surely you can do this with another MCP, but your app already has access to the database, with all of the credentials and configs you would need, and that saves you work. Plus the tool has the ability to query your database using SQL or using your language’s query builder. And this applies to everything: access to background queue? Check, Access to the APIs you talk to? Check. Most of it is powered by the project_eval tool, where we evaluate code within your running application instance.
Another tool that we offer is to get the package documentation. Many people are asking for llms.txt (which I agree are useful) but, when working on a project, all of the packages and their documentations are already available on your machine, with the exact version your application uses. This also applies to getting the location where packages are installed or the file+line of where modules and functions are defined. Those are all things that could be done separately but, because Tidewave is literally running within your web app, we can ask the language runtime/compiler, which will just do a better/faster job.
14 Likes
Thanks for introducing TideWave, I am using it with a rails application and it definitely provides some nice context to the LLM.
One thing I have noticed when using MCP tooling with my LLM ( I am using Avante in NVIM ) is high token usage. I wonder if this is Avante itself doing something that I don’t know about OR if that is the nature of offloading your AI development to your local machine ( by using MCP ) versus using a cloud based solution (e.g. Devin, Codex).
To be honest, I think MCP locally with an LLM provides some nice benefits in that the LLM can interface with your application. For example, I recently used it to created records in my database that it could debug with, plus these were records that I could also observe and interact with. I think this is nice compared to the cloud based black box experience that Devin and other tools provides.
However, I think the trade off is that with the increase local tooling, you end up with potentiall more input tokens and more expensive AI platform costs. That said, I would expect compute costs to come down in the future, so this may only be temporary (still also might be misconfiguration of my nvim plugins). I would be interested to hear anyone elses experience around this.
So I ended up running a test for this and comparing the costs between a cloud based solution and an LLM connected to MCP tools in my local IDE. Initially I thought there was a large cost discrepancy between running a cloud based solution like Devin and my local equivalent. Quickly got to the bottom of that when I realised I was using the most expensive Claude model, after dropping back from opus to sonnet, the costs incurred are close enough to Devin to not be a concern. I also found the code quality generated with Claude to be better (it wrote tests off the bat) and tools like Devin could potentially incur ongoing costs (as it monitors comments on PRs) unless sessions are put to sleep. No issue now with using MCP tools locally with an LLM, in fact I think they have a slight edge to cloud based equivalents.
2 Likes
TL; DR:
Here, for discussion, are some speculative notions sparked by recent work by José Valim, Chris McCord, et al.
Background
José has been shepherding Elixir’s set theoretic type system for a few years now and things appear to be proceeding quite smoothly (yay!). The current work concentrates on detecting (and warning programmers about) type conflicts found in code.
Unlike Dialyzer, no declarations are required; the facility analyzes the code itself. Although it attempts to handle all legal code, the type system project may issue deprecations as needed to handle corner cases.
More recently, José has announced Tidewave, an Elixir-friendly, open source LLM (etc) agent. Because Tidewave uses Model Context Protocol (MCP), it can interoperate (to varying degrees ;-}) with a variety of LLMs, text editors, etc. And, of course, it has access to the entire Elixir / Erlang toolbox (e.g., BEAM, Ecto, Phoenix, …)
Chris McCord has also been working on similar tooling. However, his approach uses containerization (e.g., on Fly.io), rather than the locally hosted approach taken by José. No matter; it’s all good…
Discussion
My basic notion is that there is an opportunity to integrate these (and other) efforts, collecting configuration and operational data and making it available to programmers in a more useful way.
Tidewave, LLMs, and data
Tidewave leans heavily on LLMs, so let’s begin there. Although an LLM can digest many sorts of data, all data is not created equal (GIGO). Ideally, one would give it clean, correct, well-structured data that contains summary, temporal, and other information.
Data sources
There are various ways that the compilation process and/or the BEAM could supply information for use by the LLM. For example:
- The new type system could provide type information for every data instance of interest.
- Information on libraries could be harvested from HexDocs, Hex, etc.
- Source code and configuration files could be harvested by ElixirLS.
- Compiled code (e.g., Elixir AST, Erlang Abstract Format) could be processed to create a graph of possible call-trees.
- At runtime, the BEAM could track significant events (e.g., message handling, process creation). Similarly, the Phoenix Telemetry facility could supply useful operational data.
- …
Data Storage
For best results, a mechanism will be needed to store the collected data. Graph representations are my preference, because of their extreme flexibility and generality. Graph databases (e.g., ArangoDB and Neo4j) provide both convenience and high performance.
Both the ArangoDB and Neo4j folks are hard at work on integration with LLMs, etc. However, other database approaches (e.g., relational) can generally be coerced into handling graphs (YMMV) and common formats (e.g., JSON) can be used for data exchange. So, graph databases aren’t the only possible options.
Use Cases
Given this combination of static and dynamic information sources, Tidewave could describe a running Elixir system in fairly arbitrary and detailed ways. For example:
- Diagram the active processes, showing ancestry (as in Observer), message traffic (both potential and active), etc.
- Report on processes receiving unmatched message formats.
- Report on data type mismatches in handling received messages.
- …
Here’s hoping that this sort of data collection and integration will start showing up soon. (ducks)
-r
1 Like
speculative notions
Maybe related: yesterday’s release of ElixirLS has an embedded MCP server. see CHANGELOG Not sure how this would fit with Tidewave, types, UsageRules, etc.
1 Like
Good catch! I’ve added this idea to my post.
1 Like
In a recent post, I promoted the use of graph databases as a way to store information on Elixir systems. However, I neglected to mention a very strong argument for their use in systems such as Tidewave. So, here goes…
Although LLMs are certainly capable of extracting useful information from bodies of text, the process isn’t as reliable as we might wish. So, for example, in retrieval-augmented generation (RAG), the LLM is asked to dig through text to find and stitch together relevant snippets. If it fails at this, incorrect facts and relationships (i.e., hallucinations) may be reported.
As a remedy for this, the folks at Microsoft have developed GraphRAG. Because it is based on a knowledge graph, it can typically produce more reliable output with substantially less effort than a vanilla RAG approach would require.
Happily, much of the information needed by systems such as Tidewave is well suited to encoding as a knowledge graph. For example:
- relationships among functions, modules, libraries, etc.
- relationships involving messages, processes, etc.
- …
Since the graph database folks are working hard at supporting GraphRAG and related approaches, it seems only reasonable to take advantage of their work in Tidewave et al.
