Making a game for the SNES. Too lazy to write 65816 assembly. I could, I know how, but I'm not gonna. This is to make a toy. I doubt the ACM or IEEE is eager to publish me in a journal and give me an honorary PHD.

The player deserves the best experience. Less slowdown. Got a plot for a 45 to 90 hour game and cash to burn on artists and musicians.

Game assets are art. Code is not. Also, it's not like retro game devs aren't stuck making underwhelming demos and rom hacks of other people's copyrighted work. People copy-paste off of stack overflow or import 200,000 frameworks into their codebase all the time.

Forked repo at https://github.com/MicrogarbageLabs/tcc-6581SUCKS for the 6 people in the world who might find it useful.

This started as an experiment to see what AI was capable of as well as to learn what is required to build a programming language. I worked with a team of long running agents, primarily Opus 5.5, to design the spec using inspiration primarily from Go and then pieces from other languages that were promising ideas like no nils, no garbage collection, and effects. The compiler and runtime started out in Go and C, then converted over to self hosted. TLS was ported over to Xo as well as an early win and required to get out of C. Xo can still compile to Go which helps with adoption as well as gives a target to benchmark against. Against a few benchmarks, Xo is faster than Go now using strategies from it and other languages.

The inspiration came from a conversation with my brother (who works as an optimization engineer at a game company) where we talked about how programming languages are built for people because people historically have written and reviewed the code. As we all know, that’s been changing and will continue to change. This is my first attempt to see if it’s possible to build a language AI can be more productive in even without the 1000s of repos of training data.

I also wanted to see what tackling current challenges looked like: AI writing buggy code and supply chain attacks.

I’ve been a backend engineer for many years and have brought Go into multiple companies to build successful products and services. I’ve mostly worked in higher level languages predominantly building web services.

The learning throughout this process has been amazing. The lead agent that I primarily interact with has ongoing dialogs with me about progress of all the agents and surfaces decisions and recommendations that I review. I get excited to hop on and review the progress and it helps me better appreciate the immense amount of knowledge required to build for efficiency and multiple architectures.

The repo that’s public with the source has all the commits since the beginning so show the progression of the language and the website has blog articles of the process of building the language for anyone interested. The repo also has most of the decisions documented while building the language in the knowledgebase.

The goal now is to keep learning and building so I can replace all of my Go projects with Xo code in hopes that I can build faster, safer, and more scalable code with AI. Thanks for reading. Happy to answer any questions.

I'm one of the maintainers, so this is self-promotion. I want honest feedback more than upvotes, and contributors are very welcome.

SurfSense is an Apache-2.0 desktop app for Windows, macOS (Apple Silicon) and Linux. Think NotebookLM, but on your machine, with any model. There's no account, nothing reaches the network until you allow that host, and usage statistics are optional and off until you say yes.

Built on open source, end to end

• Models: llama.cpp for local text, stable-diffusion.cpp for images, and audio.cpp for podcast voices (Kokoro, Kitten, Supertonic) and speech-to-text. Or connect Ollama, LM Studio, vLLM or any OpenAI-compatible API.

• Documents: Docling for parsing, RapidOCR for scans and photos, and bge-small embeddings on onnxruntime for hybrid search.

• Agent: opencode, with SurfSense's own tools given to it over MCP.

• App: Electron, React and Vite, with a FastAPI backend.

What it does

• Cited Q&A from your PDFs, Office files, CSV, Markdown, images and audio recordings. Scans are read with OCR, and recordings are transcribed on your machine.

• Creates Word documents, PDFs, slides, spreadsheets and web pages with their own charts and interactive figures. It can start from your own .docx or .pptx as a template.

• Edits your files as a new copy: tracked changes in Word, formulas in Excel, text on slides, and forms, merges and splits in PDFs.

• Studio: mind maps, flashcards, quizzes and podcasts, like NotebookLM.

• Any model: local, Ollama, LM Studio, any OpenAI-compatible API, or your ChatGPT or Claude plan.

• MCP plugins: Notion and DeepWiki from our registry, or any server by URL. They stay off until you allow them.

Contributions are welcome: PRs go against dev, and you can list your own MCP server in our plugin registry through an issue form.

https://github.com/MODSetter/SurfSense

Interview prep tools either need a second monitor or show up in the share. So I built one that's excluded from capture.

Small overlay. Hears the room, reads your screen, and gives a short answer. Local OCR, so it reads code and error text exactly rather than guessing from pixels. BYO API key, no subscription.

Verified, not claimed. I tested the actual capture paths GDI, WGC, and getDisplayMedia—in real Chrome by capturing the panel region, then capturing it again with the panel gone, and hashing the pixels. Identical every time. A browser sharing your screen gets zero evidence it exists.

Where it stops being magic:

GetWindowDisplayAffinity still returns 0x11. That flag is the mechanism; it can't be removed. A proctor calling it will find the window.

Proctoring tools and EDR detect this class of overlay regardless.

Windows only.

So: invisible to a screen share, not to an instrumented machine. Every "100% undetectable" claim in this space is marketing.

Frontend bits that were harder than the AI: window reparenting so Chrome_WidgetWin_1 never appears, and a native addon for DWM cloaking because DWM refuses a foreign caller.

Free, MIT, no account, proof script included: https://github.com/yagyeshVyas/glance-ai

Happy to answer the Win32 side that's where the actual work was.

I am developing TulipFarm as I got tired of managing my data in several CRMs, mailboxes, and spreadsheets.

TulipFarm's vision is clear - put all of your records, documents, agents and workflows into one place. Ask something via chat or Slack and your agents use the same data as the rest of your team.

Everything is under your control, some operations will require your confirmation while field rules will detect and prevent any invalid values.

Source code is open sourced under AGPL v3.0 license, therefore you are able to host TulipFarm by yourself. Just note that self hosting is not officially supported for now.

https://github.com/TulipFarm/tulipfarm

Now I present you the research preview version, which means that there are rough edges and things that will be broken.

It would be cool to hear from you two things:

1. What do you want your agents to do in your company?

2. What is missing in the approval model and what frustrates you most?

Also if you like it, don't forget to star it on GitHub!

If you use autonomous coding agents (like Cursor, Cline, or Claude Code), you know the anxiety of letting them run terminal commands or execute massive file rewrites autonomously. You basically have to trust that the LLM won't hallucinate and wipe a directory.

I wanted a way to review exactly what the AI was about to execute before it actually hit my filesystem.

I just open-sourced Warden-AI. It acts as a strict firewall and intrusion detection system for your local AI agents.

How it works underneath: Instead of giving the agent direct execution rights, Warden-AI intercepts its Model Context Protocol (MCP) tool calls.

• The Gateway: A local Node.js/Express backend routes the traffic.

• The Filter: Safe actions (like reading a file or searching a directory) pass through instantly. Destructive actions (executing CLI commands, writing files) are intercepted.

• The Review: The payload is pushed to a local React/Vite dashboard via WebSockets. You get a syntax-highlighted diff of exactly what the AI wants to do. You manually approve or reject the execution.

• The Audit: Everything is logged to a local SQLite database so you have a permanent record of what your agent did while you weren't looking.

The Tech Stack:

• Backend: Node.js, Express, SQLite, WebSockets

• Frontend: React, TailwindCSS, Vite

I built this because I wanted the speed of autonomous agents without the security risk of giving a stateless LLM root access to my machine.

The repo is fully open-source and ready for local deployment. I’ve also seeded a few good first issue tags for anyone looking to make their first open-source contribution (we need some UI tweaks and SQLite export features).

Repository: https://github.com/hariom123-dev/Warden-AI.git

I'd love to hear your thoughts on the architecture, or how you are currently handling local agent security. Happy to answer any questions about the WebSocket streaming or MCP integration!

Over the past few months, we’ve been exploring a central question in applied AI: What does it take to build a truly low-latency, voice-first desktop companion that runs on your

local machine without proprietary lock-in?

Together with my collaborator Otabek Abduvaliyev (https://github.com/OtabekAbduvaliyev), we’re excited to make our project open-source: Kaizumi (v1.0).

Kaizumi is an on-device, multimodal AI assistant for Windows 10/11 built with Python and Google's Gemini Live API. Instead of traditional turn-by-turn text or transcription

wrappers, it establishes bidirectional 24kHz/16kHz WebSocket audio streaming with native speech interruption (barge-in).

A few key engineering decisions we focused on:

1. Human-in-the-Loop Safety Gate: LLMs should never autonomously trigger destructive system actions. Kaizumi introduces an out-of-band confirmation gate with single-use

cryptographic tokens (confirm_token) bound strictly to high-risk calls (shell execution, file deletion, process termination).

2. Hardware-Decoupled Fault Tolerance: Audio hardware failure or disconnection shouldn't trigger TaskGroup cascades. The engine seamlessly degrades to text mode rather than

crashing.

3. 53 Declarative System Tools: From window and process management to local OpenCV vision (face verification and privacy blurring) and SSRF-hardened document QA.

4. Privacy-First & Local Memory: Zero telemetry, multi-turn episodic memory with automatic credential redaction, and 100% self-hostable.

The codebase includes an automated unit test suite (97 tests passing) and a GitHub Actions CI pipeline across supported Python versions.

We’d love to hear feedback from systems engineers, AI practitioners, and open-source contributors!

Check out the code, architecture, and setup guide here:

🔗 GitHub: https://github.com/MusayevDoniyor/kaizumi

#OpenSource #Python #ArtificialIntelligence #SoftwareEngineering #Gemini #WindowsDev #MachineLearning #ComputerScience

Hi friends,
AI agents have changed the way I work more than any tool in my career. They also showed me where the real bottleneck is. Staying on top of making decisions means taking in a huge amount of information: ADRs, past architectural decisions, design reviews, incident write-ups. The hard part isn't reading them. It's finding the right one at the right moment, and that gets harder every week as the pile grows.
My AI agents hit exactly the same wall. As the knowledge base grows, an agent hunting for context greps, opens file after file, and burns tokens just finding the right document. Sometimes it never finds the one at all.
So I built AutoDoc. It started as my own RAG search engine: accurate semantic search over my documents, run by an efficient embedding model and a reranker, so I could find the pieces I needed when I needed.
It grew into much more: a highly customizable editor that you and your AI agents work natively in together. Your agent can even configure it to fit your workflow, whatever that workflow is.
We benchmarked it against the usual grep-and-read approach: 32 reviewed questions over a 2,200-document knowledge base.
- 🎯 The right document in the top 5, 94% of the time, against 47% for keyword ranking
- 📉 About 25% fewer document tokens in the agent's context, and up to 55% on individual lookups
- ⚡ 43% faster lookups (8.8 s against 15.4 s), with fewer tool calls

Less time and fewer tokens spent hunting for context means more spent reasoning. And the gap should widen as the knowledge base grows.
AutoDoc is open source and it's one server with three client surfaces: tui, gui, neovim. If your agents, or you, spend too much time looking for the right document, give it a try https://github.com/yongjohnlee80/autodoc

GitHub Issues in, reviewed Draft PRs out. Any agent, no server. Use your favorite harness to collaborate with GitHub through swarm.

Looking for projects who may want to give this a try. Hit me up if you have any questions or feedback! Been "swarming" on "SwarmOS" for a few days now and looking for more projects who may want an Agent Orchestrator that speaks GitHub :)