I was just reflecting on this blog post after reading it this morning. What do you think on code mode after implementing it? At this point would not be better to just have a sandboxed api environment with customizable api/tools endpoints? basically an RL environment :)
Yeah the main value is definitely the code execution layer. You could easily generate a type-safe client from your REST, GraphQL, TRPC layer, expose it to the Deno layer and list the types as a resource or something. No need to involve MCP at all. You're basically just defining a stdlib for the LLM.
If you run `deno check` before executing the code you'd get the type-safety loop (working on this now)
Later I want to see what'd happen if you give the LLM a repo of sorts to store useful snippets and functions with comments for later use. So the LLM itself would save workflows, be able to import them into the Deno environment and chain those together.
It definitely needs a prompt that tells it to use the MCP server but I can see it being pretty powerful.
I only did simple tests like get Reddit posts, their comments, find the weather on those days, stick them in duckdb, and run some social media metric queries.
I could see that same test being: "find me leads, filter by keywords, run against some parquet file stored somewhere using duckdb, craft an email for my boss."
I'm kind of ranting but I think this a pretty exciting approach.
Edit: GraphQL style codegen layer but for all your APIs seems like a pretty obvious middle layer for this, maybe next weekend.
I came here looking for partial solutions to fill gaps in our own attempts at CodeMode service. However I'll give you some hope ;)
> Later I want to see what'd happen if you give the LLM a repo of sorts to store useful snippets and functions with comments for later use. So the LLM itself would save workflows, be able to import them into the Deno environment and chain those together.
OMG this is the first thing you should do. We have similar now and its freaking amazing. Just discussing yesterday how I can't remember it going off the rails since implementing automem last week even.
Best thing it does, fully recaps all your daily accomplishments, across all platforms (Claude Code, Claude Desktop, ChatGPT, Cursor).
Called Automem by a friend of my (Jack Arturo), currently closed-source, though I'm sure you could reverse engineer it enough.
- its a hosted stack of FalkorDB + QDrant
- has endpoints for creating/retrieving memories
- embeds stuff using ChatGPT models
- Uses Graph nodes for relating memories together
- Has a dream/sleeping phase which degrades long term memory relevant, finds and tracks patterns and more.
- Has an MCP which connects any AI directly to memory
- Automated hooks which record memory queues on commit, deploy, learning moments
- Automated storing of all queued memories on chat end.
- A lot more magic under the hood too.
So in reality you get a near biological memory, useful by any MCP agent. To be fair Jack has about a 2 month head start on the rest of us with this idea haha.
--
The setup were building will be an always running setup, so it also has a scheduling runtime in Node that uses MD files to create automatable workflows, some uses agents, some just run bash. They can call mcps, tools, run commands, log output, use automem etc, all in human readable text.
PS Keep up the great work on your codemode service, got some great ideas from yours to incorporate to ours that should resolve the one or 2 issues we had outstanding. Will share if I get it working, https://github.com/danieliser/code-mode if it gets any where
Oh this sounds so awesome. The memory system sounds very cool. I could imagine decaying memories in the graph, their initial salience being N then as it gets referenced more and more N goes up (more edges?), keep a decay function over time?
Basically instead of mcp servers you write typescript files that are parsed to generate a typed client, these are executed in one deno sandbox, and the LLM code gets that typed client and its scripts are run in a sandbox with only net allowed.
Been having some fun testing it out today.
If you have time to take a look I would be curious to hear what you think.
I read it as this leading towards an alternative to MCP, what many people have been thinking about as well. Just that to not completely pull the rug on the most hyped thing right now, they are like this is a better way to do MCP.
Haha yes, yes it is. I wrote out and implemented that approach in the links below. I've been playing with it for a few hours and I have to say I actually really really like it.
One thing I ran into is that since the RPC calls are independent Deno processes, you can't keep say DuckDB or SQLite open.
But since it's just typescript on Deno. I can just use a regular server process instead of MCP, expose it through the TS RPC files I define, and the LLM will have access to it.
