I have a lot of projects that kind of go on in parallel. It's not so much that I get bored of them, it's that I often hit a brick wall and struggle to progress, so I shelve them and come back to them later.
Often it's that I need information I don't have, I don't mean to sound arrogant when I say this, a huge blocker for me is often needing a 'rubber duck' to bounce ideas off and a huge hurdle for me is that I do not typically have a 'circle' of people I can approach to discuss these challenges with. I often find that I'm 'first' to the challenge, or that it's proprietary, or those that have the knowledge do not want to share (a typical issue in the tech' field).
One project I approached is reverse engineering a BIOS for a computer. There's not a lot of detail I'll necessarily go into here, but there are embedded systems where they prevent you from being able to 'flash' the BIOS to the chip through software, because it's digitally signed with a cryptographic key. For usability, I want to be able to modify the BIOS and still be able to flash the device through software, yes there are the options with chip programmers to directly dump and restore the BIOS, and frankly that's a fallback for recovery, but ultimately, I may want to share these modifications with others that when proven safe, can be used without a chip programmer.
So therein lies my problem, I have a BIOS binary, that's typically a UEFI bios, meaning it has 'driver' components, dxe, and other reference contents, padding, etc. So the first step is usually to grab UEFIExtract, UEFITools, etc, and pour through the files, maybe throw them into ghidra, decompile them, look through the resulting C code and stretch my programming mental muscles, assembly programming, etc. Maybe be lucky and identify some strings.
Perhaps though I can 'find' my rubber duck, and maybe the rubber duck can quack back.
I was handed a trial subscription of Claude Code, and if you're not familiar with it, it's basically a Command Line Interface (cli) method of interfacing with a "chat" ai, but it is extensible. It can expand to 'skills', to control 'MCP' and even run commands directly on your system.
I fired up a spare debian linux PC and installed claude code, I could have ran it in a VM, but isolating it sufficiently on a PC I didn't care about and would happily wipe is fine for me. Immediately I'm 'chatting' with Claude Code, and uploading the binary files I'm working with into my home directory, running `claude` from the directory sets it up as a project and immediately lets it access the files. I also tell it to use 'git' to version control the files so that it can iterate and revert, and then I look into installing 'ghidra-cli', and 'ghidra' on the debian box, and I do something that I would warn against unless you know what you're doing, getting fed up of having Claude Code ask me every time for permission, I let it have full control of the computer.
It updated everything it needed, resolved issues and even found a bug in ghidra-cli that prevented it from working with ghidra 12, and fixed it. I didn't tell it to push a pull request to the ghidra-cli repo, but I did note in the 'issues' on there, people were having similar issues that were, at the time of writing, unresolved. Claude Code had already overcome hurdles I was having.
Now at this point I was burning through tokens, and I was burning through the 1 million context window, it was starting to 'forget', and I thought to myself "what can I do about this, to reduce the burden, but also to ensure I get the most out of it?".
The first step was to advise Claude Code to keep track of what it was doing, so it started writing to memory.md to tell it to refer to reference files, a 'knowledge_base.md', and 'reference_'.md files. It kept track of it's learnings from ghidra, and the overall project. When this began to get too cumbersome, it created another 'prompt' .md file, a knowledge_compact.md, and then referred to 'knowledge_base.md' when it needed to go deeper.
That helped with cross-context 'memory' issues, but what about running all of those commands and watching the terminal output?
The first step I took was to have Claude Code write up python scripts to do the work, churn over in the background as a process, and produce an output file that it could get the answers from, instead of doing command by command and churning through 'fluff' output it didn't need and then adapting, it would write a python script whose output file gave it the minimal amount it needed, and then it could continue working.
Now it could also 'spawn agents' to do work in parallel, meaning Claude Code agents, but at that point you're burning through tokens even more, and I'm loathed to let it directly charge my card to eat at my money at the same time.
However, I still encountered a problem, this was a lot of work for it overall, I had gained some good answers, it had made discoveries. My intention was to be able to 'extract' a BIOS, and then re-wrap it with an appropriate structure that it was accepted for the software to flash.
It was mostly there, and it had created a reproducible output for me to simply 'push button, receive output' with the scripts, rather than Claude Code directly saying "I've done it for you, here's the binary file". I had something reproducible.
However, I needed a bit more work, and a few more tokens.
Before the great 'rampocalypse' that we're presently suffering, I had decided to build my own gaming PC and not intend on upgrading for a long while, it rocks an i9 13900K, 64gb of RAM, and a GeForce 5090 32gb.
That means I can run my own LLM, kinda, only I run Windows on that computer. So I picked up WSL, windows subsystem on linux, and I did something a bit weird after I installed openclaw, an "ai chat interface" that was a 'claude code' alike, which could directly pull AI models from hugging face (it can also use claude code).
It's not 'amazing' to run LLMs on it, there's a lot of reasoning and data it doesn't have access to like the models on ChatGPT or Claude, or Mistral, but it works.
And it's at this point I setup SSH keys and gave Claude Code access to it. Telling Claude "setup the open claw instance as an MCP server, and delegate investigatory tasks to the sub AI so that you're not investigating or processing, but ensure it's running correctly and guide it to further investigations".
It did.
Now I had an 'orchestrator' in the form of Claude Code, and my local LLM/AI was doing the majority of the grunt work, without eating up my tokens (only perhaps my electricity bill) and it was working in a similar way, generating scripts, processing the output, and determining its own "best next steps".
After about a week of hitting Claude Code limits (which were about every 4 hours, which I'd burn through in 3-4 days and then reset after a week on a sunday) I had the secondary LLM churning through everything outside of that time and feeding back to it. Directly communicating over SSH and then feeding back to me with updated knowledge bases, practical code, and a modified BIOS that could be 'signed' to fool the system that my modifications were in fact, legitimate.
It also discovered, as it searched online, other people attempting to resolve the same 'problem' that I was, and also found vulnerability 'papers' it was able to take advantage of. Like it was my own 'mythos'.
If you take away at least one thing from my experience here, it's that you perhaps should consider 'distributed' local LLM work, if you want to dive into 'agentic' or 'claude' code working, and 'claude code' can manage to do a little bit more than solely programming.
Meanwhile, I think I'll tweak the workflow a bit more, and perhaps I can find a single board computer that can run as a 'focused' learned model, on a particular topic, that responds to MCP controls. Perhaps home automation.
Let me know what you think.
