This is interesting. It would be even better if ones coding agent also got better at its coding abilities every night. Otherwise, agents might re-introduce the same class of bugs that your nightly improvements keep reacting to.
This would require logging agent actions during the day, analyzing it at night, identifying things the coding agent could do better, and update its AGENTS.md memory (relatively easy) or fine-tune the agent (if local LLM, and the fine-tuning cost was acceptable).
It would be nice that when a person corrects an agent's mistake this was captured and fed back into a nightly agent improving process.
nope, not at present. The houses act as your "health" (once they're all gone, it's game over), so I'm minded to keep them as a finite resource. Always open to suggestions to improve the game dynamics though.
nice UI, analysis took a while, but results looked very good.
feedback: different users have very different goals, risk tolerance, knowledge, experience. I would wrap this with very focused UIs for different audiences. Many people want growth, some are risk-adverse, some are income oriented (for example)
The analysis output could be customized for the user based on a brief interview about where they are in their investment journey and what their goals are. Without this, the analysis is very general (which if fine for experienced users).
Appreciate the feedback! we're looking to add more customization with portfolio integration in the future but as far as the analysis being general, have you tried asking for the different perspectives? It might be just answering from the data, so the output looks more generic than one might want.
Ah yeah that would do it. Individual tickers are where you could get the most insight since you can compare them to peers and there's more context for the AI to connect to price fluctuations. and, as you said, a business to valuate.
This is a good approach. I am also am trying to integrate ML and AI into a language as first class concepts, but currently more focused on the ML side, but also using inference. https://sw-ml-study.github.io/sw-mlpl/
Nola asks: "What if calling an LLM were a language primitive?"
sw-MLPL asks: "What if the mathematical operations used to build and understand ML were language primitives?"
Your approach shows some added some value that I might try to incorporate into my ML array language.
Nola puts the LLM into the language.
sw-MLPL puts the math of ML into the language.
Claude Code, Codex, opencode (Z.ai GLM-5.x), sometimes Gemini -- most of my work is at Mac iTerm2 CLI or Arch Linux terminal. I sometimes use emacs as the coding agent, but rarely JetBrains IDE or vscode (more for reading/debugging code).
I supplement this with my own vibe-coded tools that help agents plan, perform sagas/steps, stay on track, tools that check the code produced, tools that check the produced documentation, tools/process to limit AI coding agent write access to files outside their assigned project, and tools that allow coding agents to collaborate (shared wiki, mailboxes, gh cli issues, etc.). I have written test frameworks that my AI agents use to detect functional regressions.
On top of this I used web-based or Desktop: Claude, ChatGPT, and/or Gemini to do research, architecture, requirements, planning, design, and later review; to suggest improvements, answer questions, etc.
And I am trying to switch to opencode using local LLMs, served by llama.cpp, Freetoken, or vLLM, on 12G, 16G, and 24G VRAM GPUs. So far the cloud LLMs are faster/better, but recent qwen3.x MoE models look very promising.
I am curious about what Rust-based extensions I can add next to my custom machine learning programming language.
> https://github.com/sw-ml-study/demo-extensions
shows my first attempt at an extension, desktop graphics. README shows a Conway's Life "Glider" on an interactive view of a 3D torus (and other desktop examples).
The underlying language is implemented in Rust, and supports running in a browser via WASM, but the language itself is an array programming language I created to help me visualize my study of ML. (This is my non-Python response to Jupyter notebooks and Google Colab)
Then I wanted to visualize ML-related Math concepts so I added some demo repos.
And then I added language features to make it a more general purpose application development language, with libraries as a way to share code. So I added I/O, functional programming features, etc. and related demos. Dogfooding!
And more recently the dynamic Rust extension mechanism to add things that cannot be written easily in the array language itself (or for features that would clutter the language).
Maybe I can add a networking extension or an infinite precision math library.
So my curiosity is around what belongs in the base language and what belongs in optional dynamic extensions.
I am a single person LLC so my "production" is just me using AI to build things.
I use MCP for some things, like Playwright; for web UI development, but I also use CLIs, especially custom CLIs I create that have built-in help for the AI coding agent to use. I just to run my command (in the path) with --help and it figures out how to use. This seems more straightforward and efficient than MCP.
I have written MCP servers for all sorts of things, like monitoring remote systems, operating a PvP game as PvAI, others but lately I just create a new CLI with help. I use this with Claude, Codex, Gemini, and opencode (z.ai GLM) instead of dealing with how each agent registers MCPs.
I am trying to make it easier to use LLMs on older, cheaper, smaller GPUs. I'm taking a similar approach (move MoE expert weights to disk, avoid wasting VRAM on these). My goal is also to run models that do not fit. My work also suffers from AI documentation issues. Where my approach differs is that instead of running an LLM that doesn't fit slowly, run many agents in parallel sharing the streams of MoE experts weights, to increase throughput. I envision a team of AI agents sharing a pretty-good-at-coding LLM that does not fit to collaborate on a set of related features, being developed in parallel.
I am doing this work initially on a 6-Xeon-cores Linux workstation with an RTX5060-16G to run MoE models larger than that. Then I will be moving this to a server with a lot more cores (Dual 32-cores) and a mix of SAS HD and SSD drives, using older GPUs.
Ultimately, I hope to build some FPGA/MCU "accelerators" that process the expert weights on systems with not enough CPU cores to offload the experts. If I can enable large capable models to run on older hardware, keeping the limited GPU VRAM for context and things that must be in VRAM, I can get useful work out of my old refurbished systems without paying today's RAM and VRAM/GPU prices.
This would require logging agent actions during the day, analyzing it at night, identifying things the coding agent could do better, and update its AGENTS.md memory (relatively easy) or fine-tune the agent (if local LLM, and the fine-tuning cost was acceptable).
It would be nice that when a person corrects an agent's mistake this was captured and fed back into a nightly agent improving process.
reply