softwarewright

I think AI is more of a radial arm saw. Very flexible, adaptable, capable, but very dangerous in untrained hands.

I tried nono to limit commands an agent can run but that proved to be cumbersome.

I ended up creating multiple logins on a Linux system. I used my developer account to clone git repos and then create local bare repos in a read only dir. The new linux user accounts can clone from these bare repos but not push. This way, each coding agent (installed per linux account) can only work within the file system for that user on the repo assigned to that user.

Each of these user has no github permissions (cannot clone from github, cannot create pull requests, etc.). They can run tools (that I have installed) but cannot generally install software or push changes (no sudo access, no github credentials). So I can ask each coding agent to make local changes, and when they are done they create a pull request branch and wait for it to be accepted.

Then my single authorized user can take that pull request branch and merge it and push it (or create a pull request). This prevents any agent from working on a repo other than the one it has access to.

Doing this allows me to run several agents at once, one per repo, and not interfere with each other. Before I did this the agents would overreach and start modifying other repos while the correct agent was also making changes. Now, each agent creates a document requesting changes from other agents in their respective repo.

So these low privilege users have no credentials (other than to use a coding agent). This setup works for me.

This looks extremely helpful, thanks!

Have you considered providing APIs (possibly MCP) to a Wiki for agents. I've done this, and after solving some timing issues with concurrent page updates, I was able to get agents to cooperate on tasks and share info (and I could view/edit the pages via a browser too).

I ended up providing more of a mailboxes and message channels tools for agents,

I've also just set up shared folders for AI coding agents to communicate blocking issues (I have a graph of github repos with an agent per repo (r/w access) and r/o access to the upstream and downstream repos. This way when an agent needs a new feature or fix upstream, it can communicate what it needs. When an agent adds a feature or a fix, it can communicate it downstream.

I found that my time would end up being poking agents to read each others requests or responses. So I ended up using PTYs to detect when an agent was blocked and use another agent to poke other agent(s) for me. Still kind of experimental but does run some demos that require agents to cooperate.

The reason I asked about the Engram paper is that a colleague implemented it in Python (adding a quick look up mechanism to optimize-out recomputing known results). I also implemented this in Rust (or so I thought). It turns out I trained the LLM to simulate this mechanism. Then I started over and combined the Python work with my Rust work to actually increment this. Anyway, engram seems to be an overloaded term.

Understood, and I like a challenge. I've also solved some tough engineering problems in the past (before AI). With AI it seems (and I emphasize seems) that I can tackle much harder problems. That's why I am proceeding to measurable experiments and not just taking AI chats as accurate.

I have a homelab, electronics lab, and software dev experience (electronics is a hobby, and an early career before I pivoted to O/S development). Before the recent RAM/GPU price jumps I had invested in a lot of used ECC RAM and many older GPUs (and some new GPUs) on many older servers that I refurbished and upgraded. It is hard to justify the prices of new GPUs/RAM going forward. It is cheaper to upgrade my CPUs (and I have) to have more cores.

Yes, my older hardware is slow by today's standards, but it is at least affordable. Yes, old hardware is power inefficient, but I justify that by using solar panels. I cannot do anything about the current supply/demand problems, but I can perhaps help with reuse and upcycling. Maybe my work will help students and junior programmers learn on old/used hardware.

The value proposition I am pursuing is not faster speed, but increased throughput (and possibly reduced kWh).

I'm trying to understand the benefits of streaming expert weights through hardware that offloads the math and avoids storing all of the weights in RAM at once.

But that's not the only thing that can be streamed and offloaded. '

Finally, I'm trying to come up with approaches to reuse old hardware, old GPUs, old RAM instead of paying today's prices for GPU VRAM or unified memory. Even if I do not end up showing any particular FPGA benefit, I might be able to better run very large models on systems without GPUs or without unified RAM.

In my fork, I've added ./experiments where I hacked together a shell wrapper for a no_std Rust app to implement head -<n>.

help > help.txt <script path>/head -2 help.txt

works. This shows how I can cross-compile code to run in the MesaOS shell. This is a workaround until I have better libraries/APIs for argc/argv handling, file I/O, etc. Fun!

Sorry, this was supposed to be a Show HN: post. Too late for me to edit the title. Maybe I will resubmit correctly in the future.

Can you suggest what circuits? examples?

But I can afford my already purchased drawer full of cheap FPGAs for experiments.

I guess I am too risk adverse to bet $10,000 on an ASIC run (having no experience doing that and no desire to go that route).

If I can demonstrate a proof-of-concept in a reproducible research way, others can then advance to the ASIC level.

This is just a hobbyist experiment looking for other hobbyists who can afford a cheap FPGA and have some free time and interest.

I am doing the initial work on many core dual CPUs. I already have systems with large system RAM and older GPUs with less VRAM, and large SAS HDs, fast SSDs running large open weight LLMs that do not really fit any GPU I own (they offload and/or run on CPU and system RAM, but slowly).

I have the MCUs and FPGAs (in a drawer) and I am retired, and this is my idea of fun.

I am trying to generalize an approach to use large MoE models (with possibly small quants) to run many agents in parallel without spending more on more or bigger GPUs.

I am also doing some edge ML (bird species recognition near the camera) using NPUs (in design phase, yet untested). I have an electronics lab, and I've emulated soft CPUs and built software that runs on FPGAs and in my emulators.

Instead of assuming my approach won't work or is too expensive, I choose to be optimistic. Also, failures are educational. I'm trying to gain more FPGA experience.

Tang nano FPGAs are around $10, the idea being to couple with a $25 ARM or RISC-V dev board and offload the math from a streaming store. Coupling this with an older 8GB VRAM board can theoretically run a model whose weights do not fit. The weights get repeatedly run through the MCU/FPGA and the VRAM is used for KV Cache and context. If you connected several via USB and streamed a MoE model expert per FPGA, you could achieve parallelism. Won't be fast, but, many requests could be processed in parallel, as each request shares the large static weights.

The reason for this is, model weights do not need to be randomly accessed. So why store them in expensive RAM.

Cerebras and Qrok seem to be using a very different approach than NVIDIA to get orders of magnitudes speed ups. I'm trying to explore other alternative approaches.

nice. I like the metaprogramming and the error handling.

so the built-in nano helps a lot, since the help output scrolled off the screen. I tried to use head, less, and more. I could redirect help output to a file (but until I found nano, could not page that). I also looked for dd.

The VNC UI seems generally stable, I was able to log in as all three users, and issue many commands.

Is there a bundled assembler or compiler. How can I write apps for this? Do you have a way to cross-compile and mount a shared folder or scp binaries in?

My AI wrote scripts to launch and attach. I was able to do a lot login in as root. One bug: when I run the ring3 demo, the shell stops accepting input.

I have forked, cloned, and built (had to pin a specific nightly Rust for it to build). When I run it, it crashed at login; I reran it with VNC, was able to login as root, issue ls and uptime, but then it crashed. My AI is debugging...

yes, works now, thanks

I have also developed a preemtive-multitasking O/S (and some programming languages to build this and apps) targeted for embedded soft cpu (not x86).

I build tools in Rust, too. I joined your discord but cannot comment anywhere yet (lack of permissions).

Do you use AI coding agents?

I've been playing with makerlisp.com's COR24-TB 24-bit RISC soft CPU development board. I developed a Rust emulator for this ISA. The Rust emulator can run inside of a Yew/WASM app in the browser. The TUI is an ncurses-inspired variable tiled window panes. The O/S supports preemptive multitasking. There are cpu-hogs that do not yield that are force preempted. You can run interactive apps and background apps. It has a shell, monitor, debugger, and a few bundled apps.

I plan to add an SPI SD card to load programs. It currently supports up to 16 processes (sharing 1M RAM, no MMU, no internal clock, and I2C clock to be added). Right now, the modified terminal emulator (and WASM demo) send clocks to the O/S which drives the UART ISR to do the cooperative (and when needed, the preemptive) dispatching.

I developed this using a language I built that was inspired by PL/M and IBM's PL/I (PL/AS, PL/X) languages (because I wanted metaprogramming via executable macros).

I've developed many compilers and interpreters that run on COR24 ISA (not yet in this demo; they have their own demos). I plan to port a lot of this work to ARM and RISC dev boards with NPUs to explore edge ML.

How does your Engram compare to the Engram in this paper? https://arxiv.org/abs/2601.07372

The conclusion seems to be that very large models are okay or better at literate programming than medium sized models. My experience is similar. I use ChatGPT, Claude, and Z.ai GLM-5.x and they have been able to produce Emacs org-mode documents for reproducible research. While I haven't tried this to generate Jupyter Notebooks, I have tried this to produce my own literate code in a similar notebook style.

This looks potentially useful.

When I tried this on a Rust project it said to run "codegraph cluster-only <path>". but I had to first uv pip install codegraph, and then codegraph -h did not have any cluster-only (it had -o and --object-only). (codegraph cluster-only <path> fails with an error.) The -o output was hard to understand.

Maybe a web-based version that takes a github repo URL and analyzes that might be a better way to demo this? After trying that a user could install locally and use with an LLM for more in-depth results.

I wanted to try this on a small, simple Rust project before trying it on a large, complex Rust project. My Rust projects tend to be multi-component (each "component" is a multi-crate workspace). How large a project have you tested this on? How did you test this on all the supported languages? How can I add a language that you do not yet support?