tobi

Measured a work-in-progress version of Kino (yaroslav/kino) with websockets vs. Falcon on @tobi's campfire-once-ruby-ractor (tobi/campfire-once-ruby-ractor) benchmark. Coming soon! t.co

@wesbos git clone tobi/walgit

I think that if I were to build this I might skip the LLM and just setup a nice interface to the source files using qmd style search. [0] That way the tiny model isn't acting as a potentially incorrect interpreter but you still get semantic search to help you find the right documents quickly. I suppose there is something to be said for a good summarization, I just worry that these tiny models aren't really GOOD summarizers. [0] tobi/qmd

Testing Shared Memory for Claude Code, Codex and Copilot I wanted a solution checked in one project to remain useful when I moved to another project with a different agent. The useful part was the reasoning: what failed, what was checked, and which conditions could change the answer. In the first article, I described how Research Brain turns research and checked project findings into a local wiki. This time I wanted to test the next step: could another agent recover that knowledge and use it in real work without inheriting the earlier conversation? Key takeaways - Fresh Claude Code, Codex and Copilot sessions read the same saved notes through MCP. They did not need the earlier conversation. - In a separate comparison of four tasks, neither direct reading nor MCP added a distinct decision or check to the adopted fixes. Direct reading supplied reminders; MCP returned no candidates. - Before building more retrieval machinery, check whether reading a relevant note changes the work at all. A shared library and a useful consultation are different results. Jump to: [Shared setup](#shared-records-separate-conversations) · [CI case](#what-the-ci-lesson-helped-us-check) · [Four-task comparison](#comparing-consultation-with-ordinary-project-work) · [Next test](#whats-next) Shared records, separate conversations A project still needs its own instructions and architecture decisions. Research Brain keeps reusable notes with the problem, response, sources, checks, conditions and open questions. The notes are Markdown files in a local Obsidian vault. An optional adapter exposes two read-only tools through the Model Context Protocol, or MCP. search_knowledge returns candidate notes; get_concept opens a selected record. Each client starts its own local adapter process against the same files. Conversation histories remain separate. The adapter guide explains the connection and its limits. !Claude Code, Codex and Copilot each use their own read-only MCP process to query the same local Research Brain Markdown vault. The vault retains sources, conditions, verification and open questions. Each agent checks applicability in its current project; saving uses a separate approved proposal. The diagram shows access to shared records. Whether a record changes the next task is a separate question. Saving uses a separate owner-approved workflow. For the first trial, three fresh command-line sessions received the same continuous integration (CI) and deployment-review task in separate copies of one project's starting state. Each was asked to consult Research Brain, without note identifiers, prepared queries or earlier answers. They used the same nine-note private test vault, including five records from earlier GitHub Actions and Vercel work elsewhere. The tool logs confirmed that all three read notes before editing. They kept their normal instructions and used different models and permissions. Claude reached its turn limit after preparing a patch and report; Copilot needed a reporting continuation after its time limit; Codex completed, with sandbox-related test failures checked separately. This established three working client paths through one task, not a ranking of the clients. What the CI lesson helped us check One CI case shows the gap between reading a lesson and using it correctly: 1. The saved lesson. A job had been cancelled near its configured time limit. That duration did not show when it would have finished. Choosing another cap required checking completed runs, interrupted work and signs of progress in the current environment. 2. The new proposal. After reading the note, two agents still proposed a 15-minute cap based on local test durations plus headroom. 3. The review. The current project had no hosted timing observations to justify that cap, so review rejected the proposals. The earlier reasoning was available; it still needed to be applied to the current evidence. A separate CI decision concerned cancelling older validation runs. It needed its own policy check. The selected patch grouped runs by workflow, event type and ref, allowing a newer run in the same group to cancel an older one. GitHub documents the interaction between grouping and cancellation in its concurrency guide. This policy suits a workflow where superseded validation may stop; it would need reconsideration if every run must finish. Existing triggers and validation steps were preserved. Local tests, health checks and lint passed after integration. No hosted Actions run was started during the trial, so neither actual cancellation behavior nor CI-minute savings was measured. The deployment review needed the same care. A Vercel CLI-upload remedy did not justify upload-setting changes for a project documented to use GitHub import. Copilot also dismissed retention on that basis, but Vercel's retention documentation includes Git branch deployments. Retention settings were left alone because no current retention problem had been established. The records made earlier sources and checking questions available in another client's work. Review still had to correct their interpretation. This trial had no equivalent run without memory, so it could not show which decisions the agent would have reached anyway. {% card %} Why a note may not help Reading a note gives the model more information. It does not mean that the model will use it correctly. Sometimes the note adds nothing to what the agent can find in the project. Sometimes it answers only part of the question. I now separate these cases from a search that returns no useful notes. Before adding another component, I want to understand which problem we actually have. Related research: Sufficient Context. {% endcard %} Comparing consultation with ordinary project work To examine that gap, I compared four real unfinished tasks across two projects. For each task, fresh agent contexts produced plans under three conditions: current-project evidence alone, direct access to the same approved notes, or access through the existing MCP tools. The agents did not see one another's answers. Their plans were frozen before each fix was implemented and checked once. The available bank contained 21 concept notes. Here is what each condition produced across the four tasks: | Access to knowledge | Observed result | | --- | --- | | Current project evidence only | The plans already identified the core repairs. | | Project evidence plus direct note access | Nine note reads supplied reminders about boundaries and checks. | | Project evidence plus MCP | Five searches returned no candidates. No notes were read. | The core repair plans were compatible across all three conditions. Review found no additional decision or check from either way of consulting memory in the adopted fixes. One task made the result concrete. A check on timestamp-bearing entries lived inside a sort comparator. With a single entry, the comparator might not run, so an invalid value could escape the check. The plan based on project evidence alone already identified input validation before the sort. The notes reinforced that reasoning without adding a step to the fix. These four tasks came from already localized defects, and their briefs often pointed toward the mechanism. The contribution review was not blind. How consultation would perform on less localized or history-dependent work remains open. What consultation cost in this comparison Four tasks under three conditions produced 12 fresh plans, with no plan retries. The recorded effort was: | Mode | Median plan time | Total input / output tokens | | --- | ---: | ---: | | Project evidence only | 68 s | 643,557 / 6,999 | | Direct note access | 92 s | 954,030 / 8,814 | | MCP | 74 s | 659,785 / 7,461 | {% card %} How to read these numbers Time covers the first attempt to prepare a plan, including agent and tool work. The table shows the median time for each group and total tokens for its four attempts. Input counts include repeated context and cached tokens. They do not show the size of the notes or the billed cost. {% endcard %} The MCP condition returned no candidates, so its shorter planning time than direct reading does not show efficient use of knowledge. These small-sample timings do not establish a speed advantage. Implementation, full review effort and historical capture and maintenance costs were not measured by condition; no end-to-end savings can be inferred. A pause to check the direction We kept working on search, but one question kept coming back: > Were we drifting from useful work into infrastructure again? By then, the conversation included semantic search, summaries, knowledge graphs and increasingly detailed rules for transferring a method. These were relevant engineering questions. I kept returning to the original purpose: recover something useful when another project needs it. I had also asked for an approach that could work on new tasks and be useful to other people. A better answer to a familiar test query could help diagnose a search defect. It could not, on its own, establish the value of the memory. The ordinary-work comparison gave us a way to ask what a note actually changed. Four questions I now keep separate A stored record can be missed. A retrieved record can be inapplicable, or repeat something the agent already knows. Those are different outcomes, even when the task is eventually solved. I now check the path in four stages: | Question | What would count as evidence? | | --- | --- | | Does the library contain something useful? | A passage supplies a method, a concrete partial procedure or a relevant limit. A related topic alone is insufficient. | | Did the agent find and read it? | Actual tool requests and returned content, including misses. Knowing the note's path afterward does not count as discovery. | | Does it apply here? | Part of the task matches the source procedure and its conditions. Work that the note does not cover stays explicit. | | Did it change the work? | The fix uses a fact, decision or check from the note that the initial plan did not contain. | A partial procedure can be useful without solving the whole task. A restriction can prevent an unsupported claim without providing an implementation. I keep those contributions separate from a complete method, and from general reminders. These trials used different small knowledge banks and different protocols. Their counts cannot be combined into a general accuracy rate. Why keep developing this workflow? Shared notes through MCP are already an established idea. Basic Memory offers a Markdown knowledge store for different clients. QMD offers local document search through both a command line and MCP. They are relevant alternatives to compare; these trials do not establish that my implementation is better. Research Brain grew from a research wiki I was already developing. I wanted a project finding to retain its source, checked result, conditions and open questions, then become available elsewhere through an approved save. Building that path let me inspect capture, retrieval and later use together. For someone starting with the same need, I would include existing tools in the comparison before building a custom reader. Conclusion The shared library worked across three clients. The four-task comparison also gave me a reason to keep consultation optional: the agents could already diagnose those localized defects from the projects themselves. I would carry three lessons into another attempt: - Save what is hard to reconstruct. A rejected remedy, the reason for an exception, or a checked project constraint may carry more distinctive information than generic coding advice. That is the next hypothesis to test. - Keep a plain-reading comparison. If reading the relevant note changes nothing, reconsider the knowledge or the task before tuning search. If it does help, check whether normal lookup can recover it. - Keep the evidence available. The receiving agent still needs to check conditions in its own project. Retain the source, the actual passages it used and what needed another check. Some of the search work answered engineering questions without answering the larger question of usefulness. I do not want to turn every retrieval miss into a reason to add another component. The practical outcome so far is a working access path and a clearer decision about where to look for value, rather than a reason to require memory for every defect. What's next The useful test now is narrower: can a fresh agent recover a past project decision that the current code does not explain, and use its limits correctly? That would test the part I wanted to preserve from the beginning. Choose the real task before consulting the notes, and keep the agent's initial plan. Let a fresh session search without the desired note identifier. Record which decisions and checks change, what needs local verification, and the effort of consultation and maintenance. If ordinary project inspection already supplies the answer, keep that outcome too. The public Research Brain repository includes the adapter, a record template and the approved saving workflow. It does not reproduce the private trials described here. New project findings remain outside retrieval until their exact proposed package is approved. Choose which clients and projects may access a vault: retrieved text can reach a hosted model, and source content remains untrusted input.

@tobi @yordisprieto @nats_io lol! welp, if you want, I can continue to maintain it? (been using it for my software factory) and already shipped quite a few PRs 16-ish and fixes from first release github.com/tobi/walgit/pulls

Once an AI novice, now maybe a little less of one ✨ Hi! 👋🏻 It's me again. If you read my last post, you'll know I've just come back to this blog after six years away. A lot has changed in that time, for me and for the landscape of iOS. One of the biggest changes for me has been AI and how I work with it. So this one is a bit more personal. It's about where I started with AI, the mistakes I made and what I've learned so far. If you're someone who takes pride in knowing your stuff, and AI feels a bit scary, this one's for you. 🧠 Knowledge was my superpower Before I joined Depop (my current role), my AI usage was pretty much asking ChatGPT a few basic questions when the Apple Documentation, developer forums, Stack Overflow or asking colleagues couldn't help me solve a problem. For me, knowledge was always my superpower. I wanted to know the syntax for things off by heart, I wanted to know the nuances of different APIs, when to build certain things and when not to. I wanted to be the person who people would look to ask when they needed help or the person that the product manager reached out to when they had an urgent issue. Before the world of AI this was the way I saw to try and push myself forward and this took a lot of outside learning and time. So when AI first started coming into the iOS landscape, I was like most people: very sceptical. Not only of how good it could be. If I'm honest, I kind of wanted it to not be that good. I took a lot of satisfaction in being the person who knew a lot of the little details about lots of different topics and it just so happened that AI would probably be a little bit better than me at that. It could probably answer all the questions people asked with more detail in less time. This concerned me. It left me asking myself: if AI can do this better than me, what can I do better than AI? 🐣 Getting started About 14 months ago I joined Depop, and joined a team with a very different mindset than the one I was in before. This team embraced change, it embraced AI and was set out to utilise it as much as possible. Unlike my prior role, I suddenly had access to all the latest and greatest tools and I was surrounded by people who also had much more experience with them than me. I, on the other hand, was still writing all of my work by hand. I'd never used any of these tools before, and I didn't really know what they could do. To be fair, 14 months ago I don't think many of us knew either. In my previous role I was a Senior iOS Engineer in a team with lots of varying skill levels. Without AI, it was my job to help, mentor and be the person who solved the tough tasks when they needed solving. I'd completed huge migrations, worked on vast technical challenges and written tons and tons of documentation, and I'd never relied on AI or even thought I wonder how this would have gone if AI did it. The thought of letting go of this and taking a step back to begin using AI was a little daunting to me. But the team I was joining was much more open minded and this really opened my eyes. My first step was just installing Claude and giving it a go. It felt like a similar experience to the first time I ever used Xcode, I didn't really know what to expect but the results honestly blew me away. I had no real setup, I didn't even know what a context window was, or a skill or anything for that matter but I was still producing work in a more efficient way than I was before. This was honestly quite exciting. ⚡ So, where did I go from there? Well like everyone probably did, I might have gotten a bit carried away. Even before AI I was always probably known for moving quickly. Even at school my parents would be told by teachers that I just did things very quickly and maybe I needed to slow down. I remember in my first iOS role as a Junior I was told to not bring more than 3 pieces of work onto the board at once as I couldn't manage them all at the same time. So you can probably imagine what I attempted to do when I had AI to basically duplicate myself... I just tried to do too much. I think I found out quickly that you can do it, but it doesn't mean you should. My work was good but it wasn't as high quality as my work before and arguably I hadn't learned as much from the work as I could have. > 💡 Tip: I think a key thing someone told me early on is that if AI can do something you would have done before in 60% of the time, at least spend another 10% of the original time reviewing and analysing what you have done, you'll still have saved 30% and it will at least be something good. !Bar chart: before AI, doing the work takes 100% of the time. With AI, the AI-assisted work takes 60%, reviewing and understanding it takes another 10%, and 30% is saved 🌊 Information overload Once I had got accustomed to the basics of using Claude I wanted to try and progress a little more. Lucky for me I had people around me who were much further along in their AI journey than I was. We regularly had sessions in which people would share the skills they had been working on, the different use cases for AI they had found and basically everything else weird and wonderful about the AI landscape that maybe we would find interesting. Things like cookbooks, recipes, hooks all sorts. This was amazing, it was my first real look into what was possible but it was just.... a lot of information? I think the expectation was just that everyone would be on the ball with everything but the landscape changed so much that it almost felt hard to digest, at least for me. So my plan changed to just: can I make one small change at a time? 🪜 One small step at a time So I took small steps. As with anything, I just needed to at least start. !Four rising steps: 1. Use other people's skills, 2. Write your own skills, 3. Add hooks, 4. Build a knowledge base 1. Using other people's skills. I started by trying the skills others had built and presented, seeing how they worked and how I could best make use of them. 2. Writing my own. Once I was comfortable with that, I tried creating my own skills. Even to this day it's become a great way to share knowledge within the team and the organisation. Personally I've contributed by writing a few skills such as: 1. A skill to review your Claude usage to give you tips to improve (kind of like what this one small step at a time approach did for me). 2. A skill to help you with end of year reviews, utilising Claude to pull feedback for people you work with. 3. A skill to help write better documentation for a specific architecture we use. 3. Hooks. One problem I realised after having such a large amount of skills to use was just... how do I know when to use them? We know Claude is supposed to invoke them but that doesn't always happen. For me I had to set up hooks to let Claude tell me when I might want to use a certain skill. This has been really valuable for me and it's something I've shared with others within my team who had similar concerns. 4. A knowledge base. Most recently, I set up a knowledge base. My notes live in Obsidian, and qmd indexes them so Claude Code can search them for context before asking me. This post actually started life there as a page of raw notes. For me this was probably a mistake I made for the longest time, I didn't realise how little useful context Claude actually had about me in its memory and making a change to actually formalise the storage has had a huge impact. > 💡 Tip: A skill is a set of instructions that Claude loads when a task needs it. If you find yourself explaining the same thing to Claude more than once, that's a good sign it should be a skill. I recently gave a small talk at our iOS guild, and my main suggestion was simply this: make one small improvement to your workflow at a time. With AI it can feel like you should be doing everything at once, but as I've found over the last 14 months, that doesn't really work and my approach has always just been to make one small step at a time. 📱 Putting it into practice: Second Skin In my last post I mentioned Second Skin, my side project for keeping track of your tattoos. It's where I've been putting all of this into practice outside of work. I made one rule early on: I write the code. Claude explains things, reviews my work and only writes parts when I ask it to, which is usually the repetitive stuff I don't learn much from. Before I start a ticket, Claude writes up a list of requirements (Kind of like a product manager might do). Before I raise a pull request, it reviews my changes. At the end of each session, a handoff skill I wrote saves where I got to inside Obsidian, so the next session can pick straight back up. I've also used it as a sounding board for design, exploring different directions for the app and going through round after round of app icon ideas. I'll be writing more about building it soon. 👀 ✨ Where I am now 14 months on, I feel a lot more confident when it comes to AI and speaking about my experiences (which is what inspired this post). AI has become a core part of how I work, it can act as a sounding board for ideas, work as a partner when thinking about large technical problems or solutions, it can work as a planner helping me split things up and articulate them in ways to share with different stakeholders and much much more. Over time I've learned more and more use cases and honestly there's probably way more I haven't even realised yet. I'd say I'm still getting used to adapting my thinking about where I sit in the landscape now. I've definitely shifted from being focused on every piece of syntax and nuance and now I'm more focused on engineering solutions and following good software principles. I've found this is the best way to work with AI to get the best solutions but overall I've realised that AI isn't this scary thing, even for those of us who saw the knowledge we had before AI as our superpower. So, what can I do better than AI? I can be the guide: the person enforcing good architecture and software principles, and steering AI towards the best solutions. We should use AI to our advantage, and let it take the things that would take us the most time for the least benefit. That creates the space for the things AI can't do on its own, like thinking about the larger scale problems we have and how we can transform the areas we work in. 💡 If you're where I was - Make one small improvement at a time. You don't need to adopt everything at once. - Start with what other people have built. Try your team's skills and tools before writing your own. - Learn the tools before speeding up. Spend some time learning how they actually work before trying to do more, faster. - Give the tools you have a go. Whether they're personal tools or tools at work, AI gives us so many amazing ones. It's on us to try them and see what works for us. 🌱 Still a bit of a novice? I'm still maybe considered a novice, and I'm still getting used to this world of AI, but I'm proud of where I'm at now with it compared to last year. It definitely feels like I'm getting somewhere, and I want to keep exploring. If you're on the same journey, I'd love to hear how you're finding it, or the one small improvement that made the biggest difference for you, in the comments.

🔥 Топ-3 находки на GitHub ⭐️Используй их, чтобы обогнать 90% людей! 💼Подписывайся на наш телеграм-канал — прямая ссылка в профиле, там ещё больше подобных подборок и не только! 📆Ежедневный контент на тему AI/IT/LLM и многое другое! Freika/dawarich tobi/qmd eythaann/Seelen-UI #github #opensource #нейросети #программирование #IT #it #smartphone #нейросетьзахватитмир [en-US] 🔥 Top 3 GitHub Finds ⭐️Use them to outsmart 90% of people! 💼Subscribe to our Telegram channel — direct link in the profile — for even more collections like this and more! 📆Daily content on AI/IT/LLM and much more! Freika/dawarich tobi/qmd eythaann/Seelen-UI #github #opensource #neuralnetworks #programming #IT #it #smartphone #neuralnetwilltakeovertheworld

无论是常年被 node_modules、Rust target、Docker 和 ~/.cache 塞满硬盘的程序员，还是想学习怎么用 Rust + GPUI 写现代原生 GUI 的朋友，这个仓库都非常值得一读。 GitHub 仓库：tobi/disktree

いくつか先行事例を見た範囲だと、このプロジェクトが良さそう。アメリカのサーキットはOSMのトレース以上の精度がある。 tobi/track-atlas

not sure if this is exactly what you're looking for, but a certain company is looking at this tobi/walgit