Lokale codegraph voor agents, terwijl GNOME het AI-meldingenconflict scherp zet

Repopedia biedt een lokale codegraph voor agents zonder vector-database of cloud, terwijl een nieuwe agentdiscussie documentatie als controleerbaar alternatief voor ‘memory’ positioneert. Aan de andere kant van de stack laten een webessay en TensorSharp zien dat zowel platformkennis als runtimekeuze eerst op de eigen taak moeten worden getoetst.

Repopedia bouwt lokaal een callgraph die een agent via MCP kan bevragen

Repopedia is een nieuw MIT-gelicentieerd hulpmiddel voor Python- en TypeScript-repositories. Het parseert code met Tree-sitter, schrijft de graph naar een lokaal SQLite-bestand en kan daarmee onder meer directe en transitieve callers — de ‘blast radius’ van een wijziging — opvragen. Via de meegeleverde MCP-server kan een coding agent die relatie rechtstreeks bevragen in plaats van herhaaldelijk tekstueel te greppen.

Dat is een nuttig, afgebakend alternatief voor retrieval op embeddings: bij vragen als ‘wie roept deze functie aan?’ is een statische graph in principe controleerbaarder dan semantisch zoeken. De auteur benadrukt dat niets naar een server gaat en dat er geen Docker-stack of API-sleutel nodig is. De tool kan ook wiki-achtige documentatie genereren.

De beperkingen zijn even concreet: dit is versie 0.2.1, met alleen Python en TypeScript, en methode-aanroepen via self. worden op naam gematcht. Bij grote class-hiërarchieën kan dat dus onjuist uitpakken. Gebruik de uitkomst als navigatie- en reviewhulp, niet als volledig bewijs van runtimegedrag; controleer dynamische dispatch, imports en tests nog steeds zelf. Projectpost met opzet en grenzen

Agentgeheugen als versieerbare documentatie, niet als verzameling transcript-snippets

Een nieuw essay stelt dat agents doorgaans niet gebaat zijn bij een grote, verborgen verzameling semantisch opgehaalde gespreksfragmenten, maar bij een leesbare werkruimte met specificaties, beslissingen, onderzoek en indexen. Het voorgestelde ritme is: vóór werk relevante Markdown lezen, na werk verouderde documentatie bijwerken. De auteur heeft dat idee uitgewerkt als de open-sourceplugin Operator Memory.

De interessante vraag voor een team is niet of dit ‘echt geheugen’ is, maar wie de kennis kan beoordelen en corrigeren. Markdown in de repository is te diffen, te reviewen, te delen en desgewenst te koppelen aan een besluit of wijziging. Daarmee wordt contextbeheer een expliciet onderhoudsproces in plaats van een onzichtbare selectie uit oude chats.

Dat is geen bewijs dat RAG-geheugen altijd slechter werkt. De auteur argumenteert vanuit eigen gebruik; HN-reacties noemen terecht twee tegenkrachten: documenten kosten ook tokens om te lezen en bij te werken, en kennis kan alsnog verouderen zodra de code verandert. Een bruikbare proef is daarom klein beginnen: houd besluiten, constraints en projectkaarten compact, leg eigenaarschap vast en test na een paar iteraties of een nieuwe agent werkelijk sneller tot een correcte wijziging komt. Essay en Operator Memory · HN-discussie

Voor agentgegenereerde webcode blijft ‘eerst de browser’ een testbare regel

Webontwikkelaar Nolan Lawson onderzoekt waarom ontwikkelaars vaak een library of frameworkcomponent kiezen waar browser-API’s, HTML of CSS al een route bieden. Zijn kernpunt: historische browsergaten, bekende framework-idiomen en betere package-documentatie verklaren die reflex, maar kunnen resulteren in onderhoud van een eigen, inferieure variant van bestaande functionaliteit — hij noemt onder meer dialogs en zelfs opslag in ClickHouse.

Dat wordt relevanter nu agents snel veel userland-code kunnen produceren. Vraag een agent bij UI-werk dus niet alleen om een werkende component, maar expliciet om native mogelijkheden en hun browser- of toegankelijkheidsgrenzen te vergelijken. Dat maakt een beslissing voor een library beter verdedigbaar dan een gegenereerde eerste versie simpelweg accepteren.

‘Gebruik het platform’ is geen absoluut gebod. In de HN-discussie worden bijvoorbeeld toegankelijke searchable comboboxes en tekortkomingen rond native dialog genoemd; dat zijn concrete redenen om soms buiten de standaardprimitieven te bouwen. De les is daarom: toets native opties eerst, maar beoordeel focusbeheer, screenreaders, touch en producteisen op de daadwerkelijke doelgroep. Essay · HN-discussie met tegenvoorbeelden

TensorSharp combineert lokale GGUF-serving en .NET-agentlaag, maar de winst is niet uniform

TensorSharp positioneert zich als .NET-10-engine voor lokale GGUF-modellen op Windows, macOS en Linux, met CPU-, CUDA-, Metal- en Vulkan-backends. De repository noemt een CLI, browserchat en Ollama- en OpenAI-compatibele API’s, plus paged/prefix-gedeelde KV-cache, continuous batching, speculative decoding en een agentlaag met begrensde subagents en standaard read-only workspaces.

Voor .NET-teams is vooral die combinatie interessant: een lokale modelserver en toollaag hoeven dan niet per se via Python of een afzonderlijke containerstack te lopen. Maar zet de server niet blind open: de documentatie zegt expliciet dat hij op 0.0.0.0:5000 zonder ingebouwde authenticatie of TLS luistert. Beperk hem dus tot localhost of zet er een geauthenticeerde reverse proxy en firewall voor.

De eigen RTX-3080-Laptop-vergelijking met identieke GGUFs laat geen universele versneller zien. Zo meldt het project voor Qwen 3.6 35B-A3B op CUDA iets tragere decode maar snellere prefill dan llama.cpp, terwijl de Vulkan-cijfers anders uitvallen. Model-, backend- en workloadkeuze bepalen dus de uitkomst. De broncode noemt bovendien zelf wisselende validatiedekking per architectuur; test tokenpariteit, lange context, toolcalls en foutgedrag voordat je een bestaande endpoint vervangt. Repository, backends en benchmarkmatrix · Reddit-discussie met de 16GB-laptopmeting

Verder nog

• GNOME-debat over AI-meldingen draait zichtbaar om: na het eerdere pleidooi voor een LLM-verbod in GNOME betoogt GNOME-ontwikkelaar Michael Catanzaro nu dat AI-gegenereerde kwetsbaarheidsmeldingen niet op basis van herkomst moeten worden geweerd. Hij wijst op meer CVE’s en op een beëindigd bugbountyprogramma dat volgens hem door de meldingenstroom onhoudbaar werd. Dit is geen GNOME-besluit en de cijfers zijn zijn eigen security-tracking; de praktische spanning blijft dus: valide meldingen toelaten zonder vrijwilligers met ruis, duplicates en reviewwerk te overspoelen. Pleidooi, cijfers en voorgestelde koers · Lobsters-discussie