denn-gubsky
denn-gubsky on Hacker News
Posted by
denn-gubsky on Tuesday October 20, 2026 @09:55AM
from the loomcycle.dev dept.
Posted by
denn-gubsky on Monday October 19, 2026 @10:30AM
from the loomcycle.dev dept.
Posted by
denn-gubsky on Monday October 12, 2026 @09:37AM
from the loomcycle.dev dept.
I'm using cloud models for development, and many local models for internal works. Local models a good for doing the part of work related to personal user information, internal functions, like facts extraction and chats consolidation, web search and market research, internal documents preparation and handling. I also use local decision models (nimble, clef) for classification and other related staff, local embedding and voice recognition models.
I prefer self-hosted and hardware password managers. This does not completely mitigate the risk, but makes the attack surface smaller. Another question is your local network perimeter protection. I don't feel safe even with reverse proxy like tailscale, and thinking about local LLM Agent based network safety monitor.
I've built a robust self-hosted OSS agentic runtime. Look for loomcycle on github.
I think that LLM Agents will communicate with each other using internal embeddings - the natural language LLM thinking on. The final output may be a platform-specific assembly or binary output.
When specifically asked, the LLM Agent may present the architecture and structure in human-redable language or on diagrams.
I do not see the real reason for LLMs to support so many programming languages created by humans and for humans.
I created a couple of agentic workflows to scan tech news, filter and create short digests. 5 top news is enough per day. 5 minutes reading. The rest of the time I can concentrate on things which matter for me the most.
The next step is to automate all the boring stuff like accounting, taxes, funds management etc.
Now I have time for family, sport and new agentic software development. The last one is just for fun, because nobody uses it but me :)
I had not access to my pull requests and CI for few hours. Nice unicorn was presented instead :)
I used Arduino sets to teach kids electronics and minimal programming. We created various simple devices with sensors and motors using resistors, capacitors and transistors to construct interfaces between digital inputs/outputs and analog devices. This way kids understand why we need analog components in digital circuits. The simplest possible example is R + LED to limit the current. You can explain that R is a thin tube which limits amount of electrons flowing to the LED. Then you can demo the R-divider to cut the voltage on the digital input. Then add a capacitor and demo kids the slowly flashing LED driven by digital output. Use oscilloscope to visualize the signal - it's hard to understand how capacitor works. Then use transistors and MOSFETs to drive motors. I also created a 3D printed parts to assemble working models like the radar, barrier and real clock driven by the stepper motor.
Ryzen 7 8700G is an APU, and it has built-in Radeon 780M GPU (12 CUs, ~12.6 TFLOPS, plus an NPU). This is not very strong, but this is floor which runs local models for me and saves a lot of paid tokens. Potentially this setup may be upgraded to AI MAX when AM5 APUs will become available in box packages (now they are OEM-availabe only). The most expensive part of my system is DDR5, and it may be reused in case of upgrade. Actually, this is my self-hosted NAS (TrueNAS Scale) which also runs Ollama and serves as my local inference machine.
I'm running qwen3.6, gpt-oss and embeddinggemma with Ollama on Ryzen 7 8700G + 96 GB DDR5 with 12-14 tokens/sec. Consider this as a floor. On Strix Halo it will run 4-6 times faster depending on memory bandwidth. For my local task 14 tok/s is quite enough for the price I paid.
I'm building the agentic runtime and agents running on this platform. The keystone of agentic work is "allowlists vs denylists" choice. On my platform I use allowlists for everything (tools, MCPs, skills, memories etc.). Agents work in a sandbox and have only allowed resources they need for functioning. Nothing more.
The LLM is a probabilistic by nature, it can try to access or delete the resource without a reason, it may follow the prompt injection, it may leak the secret or private data. So all this should be controlled by the agentic runtime.
In my system I use specialized agents as team players - each agent does it's part of work using available resources. This way you can keep all needed data in the model's context window without compaction and optimize resources control.
Ask more specific question if you need a detailed answer.
I develop 5-10 times more complex projects now without anticipation to never complete them. And I can do it alone with team of agents running 24/7. Maybe these new projects will not be used by anyone, but I feel more confident in previously unknown for me domains like robotics, agentic runtimes or GraphRAG. So my advice: just keep evolving.
Thanks for the useful article. I'm building a hierarchy chunked graph document memory as the project knowledge base in my agentic runtime. After reading your articles I will pay more attention into semantic search and retrieval methods. I also started from linked MD documents, but they are too big and contaminate agent's context, so I moved on to the chunked graph model for more selective retrieval operations.
Recently I upgraded my TrueNAS box with Ryzen 7 8900 APU + 96GB DDR5. This config runs Ollama + loomcycle (my agentic Go runtime) + loomboard (the agentic UI), all self-hosted. I tired several models and Ollama configurations. For me is important to fit the whole model in GPU and run multiple agents+tool in parallel (see the blog for details:
https://loomcycle.dev/blog/local-llms-on-truenas-and-the-fro...). Gemma4 is fast, but hallucinating a lot, especially when using tools. My current favorite is qwen3.6:27b. This is smart and reliable model, which can run tools in agentic configuration, do long researches, generate code, formulas and diagrams. On my hardware the qwen3.6 speed is about 9-13 tok/s, which is not high, but acceptable. The most tricky part is context size balancing for multiple model instances in limited memory. Ollama splits the context memory between model instances and may fail to run if agentic runtime allocates larger context than size than it is available in the context storage.
If you model starves because of small context window (your described symptoms), then I would suggest:
a) Split the job between agents, each with it's own context window;
b) Use advanced model as orchestrator for multiple coding/testing/reviewing agents;
c) Use code indexers like
https://github.com/ory/lumen or/and
https://github.com/defendend/Claude-ast-index-search
d) Use planning and detailed specifications preparation before the coding phase.
I'm doing a lot of QA in my startups. There are several layers:
1. One model (Opus) writes a code, another model (Sonnet, Qwen, Kimi) writes unit tests using requirements and code;
2. Full code review by me. Just to understand what is going on in the codebase;
2. Integration tests are running with PlayWright MCP. Another model validates UI per requirements;
3. Substantive runtime tests prepared by me or human QA team. All features should be included into testing, plus regression testing of existing features, plus edge cases.
QA in AI era becomes more important than coding skills. So keep it in a good shape.
In my experience, AI solves the implementation part well - if you know explicitly what should be implemented. If your engineering understanding is fuzzy, the implementation will be fuzzy too.
Engineering and architectural skills matter more now than before. Previously, you had time for rethinking and rearchitecting while coding. That timeline is collapsing - your ideas become real in hours, the bad ones included.
Verification matters more than implementation. When you ship 20 PRs to verify in a single day, every day, all month, how can you be sure the ideas are right, and the implementation is correct? You need ways to challenge your own system: integration tests, runtime tests, and load tests that make you confident in what you're building.
Three skills become non-negotiable in this AI era (until tomorrow, when the answer probably changes again):
1. System Architecture. Build correct framing for your ideas with room for future extensions. Requirements should be complete, precise, and extensible. Project documentation grows with the code and stays current.
2. Organizing AI agentic teams into verifiable flows. Self-evolving specialized agents that verify each other's output until you're confident the code matches the requirements you actually had.
3. Verification, verification, verification. Integration tests, runtime tests, load tests, experiments. The code an AI produces has to be confirmed correct across every dimension that matters.
Posted by
denn-gubsky on Tuesday June 30, 2026 @12:37PM
from the loomcycle.dev dept.
Thanks for the article. It's super interesting for me, but I have not found a solution for agents running in runtimes without browser. For example on VPS. I'm using WebFetch/WebSearch now, but in some cases I need authorization and cookies. I'm wondering if there is GUI-less browser available, just for agentic usage?
I integrated the gbash and benchmarked it. gbash is not production grade yet. There are issues with tools implementation and compatibility (I added findings as issues) and performance issues (avg ~30% slower than system C utilities, grep is way slower). Here is full report:
https://loomcycle.dev/blog/bashbox-in-process-shell-sandbox
Thank you for good advise. The agentic runtime I'm developing uses system Bash and has to spawn system processes. The pure Go is better match. Checking the repo.
Interesting library. I think I could use for agents running in virtual volumes. I maintain an agentic runtime written on Go. What is the best way to incorporate bashkit.sh?
I'm curious what to do if agent self-improvement goes a wrong way. How do you evaluate the agent quality? Which way do you return to the last good branch? How to automate this process?
Nice and very fast indexing tool. Installed by Claude code, and indexed by 3.5K nodes codebase in less than 2 seconds. Outstanding.
The graph looks good, but navigating with the trackpad is not easy. Would be more convenient if zooming centered on mouse position, not in the center of view. So user can select a node by mouse and zoom directly.
Anyways I installed the MCP and will see if code review will work faster now.
Posted by
denn-gubsky on Tuesday June 16, 2026 @11:26PM
from the show-hn dept.
Thanks a lot. He is 12. I got books and will try to propose for him. But your comic-like website works better :)
Contacted you on LinkedIn.