"Hello everyone! 👋
I'm Javier, and my coding knowledge consists of HTML+CSS, and basic JS+PHP. My real thing is storytelling.
I started using Claude Code in VSC with an academic project I was doing by hand: a historical archive manager (backend). For that project, I needed documentation, so I created a new project that crawls sources and indexes them, extracting the facts.
The succession of needs to resolve generated several projects (one per day), all interrelated: distillation of pictorial styles, image generation, video editing (integrated via Python with DaVinci Resolve), audio generation... All of them operational, with a minimum viable feature test.
During the process, Claude encountered execution frictions, many thanks to VSC's LINT extensions (Docker stuff, system paths, nomenclature like python vs. py...) and reasoning issues (overlooking instructions or paths), so I started (well, Claude did) to establish a system that logged these frictions to avoid them in the future.
My approach was to keep everything on track as much as possible with code, which is deterministic: hooks (preferably pre-tool), access doors to edit Claude's memory files, etc. Everything documented both in the repo and in the GitHub commits.
At this point, I needed something to organize the chaos of ideas I had for each project, to monitor the repo ecosystem (health, status), and to log useful info like repos, documentation, etc. So I created the 'Organization' repo, to rule them all, with an update propagation system.
In theory, it was perfect: absolutely everything was logged. The problem is that almost everything went into a drawer to be forgotten. Too much context in Claude's reasoning, poorly mapped.
I discovered Karpathy and Obsidian, and started moving the useful info from 'Organization' to a new version, creating a vault with more segmented info, and keeping Claude on track when consulting it (using Kepano's skills: https://github.com/kepano/obsidian-skills/tree/main). The system improved: the prose of the .md files is now indexed in a .json, but it still has many holes, mostly related to keeping the code on track that is supposed to prevent those problems.
To recap: I've used this system by combining Claude, Cline (a VSC extension that allows using other models, I've done it with the OpenRouter API), and Gemini from Antigravity. For Claude and Gemini, I don't have an API key; I log in with a pro account (usage quotas). The process works through handoffs between models and my own intervention.
Claude is very good at managing and setting up a project and orchestrating other models, it's even useful for improving instructions for Gemini or Cline, but it gets lost if it has to cover too many things.
At this point, I discovered ICM, thanks to Van Neistat. I found it very elegant how the indexing of his archive was resolved.
I've been watching videos and studying the classroom docs for several days now. The conceptual videos in Module 2 are some of the best I've seen on AI. Although the simplicity of ICM is seductive to me, a priori I still find it counterintuitive: the deterministic part is supposed to be the code, not the reasoning induced with .md files. However, that's what I was supposed to be doing, and it hasn't worked for me.
I have downloaded and studied the Vault materials, and I understand ICM better, and how it manages projects across the 4 workflow phases, but there's something I'm missing (I'm still in Foundation for now): how is recursive memory managed? The execution frictions, the useful info about stacks and repos... I think that's something transversal to each domain (writing-room, production)... and it looks quite similar to the second brain idea.
I don't know if this is covered in depth later in the classroom, or if it has already been discussed in an Afternoon Tea. I would appreciate any help with this.
And sorry for the long rant 😅"