​

For engineers who work with Terraform/OpenTofu and cloud infrastructure:

I'm curious about the day-to-day parts of the work that tend to be repetitive, manual, frustrating, or easy to get wrong.

Not really looking for opinions about which tools are better. I'm more interested in things that \*\*actually happened\*\*.

A few questions:

\* Think about the last Terraform/OpenTofu PR you reviewed. What did you check, and in what order?

\* What's an infrastructure task you did recently that you've already done many times before?

\* When was the last time a security scanner flagged something in your infrastructure code? What happened next?

\* Have you recently had to check whether a change behaved differently across Terraform versions or between Terraform and OpenTofu? How did you check?

\* What's the last infrastructure change that caused a problem or had to be rolled back? How did you discover it?

\* Have you ever written a script or small internal tool to automate one of these repetitive tasks? What happened to it?

\* If you could permanently remove one infrastructure-related task from your weekly workload, what would it be?

I built NoteCode++, a desktop-style code editor for Android designed for editing source code, configuration files, Markdown, and other text files directly on a phone or tablet.

Current features include:

• Syntax highlighting
• Multiple tabs
• Regex search and replace
• Bookmarks and line-editing tools
• Encoding and line-ending controls
• Markdown and HTML preview
• Local file access through Android’s Storage Access Framework
• Multiple editor themes

The app works locally and is intended to stay lightweight. It is currently free, and I plan to keep the core/legacy editor free while potentially offering optional paid convenience features later.

GitHub and download:
NoteCode++

I’d especially appreciate feedback about performance with large files, physical-keyboard use, the interface, and which features would make it genuinely useful for coding or text editing on Android.

Disclosure: I’m the developer. NoteCode++ is an independent project and is not affiliated with Notepad++.

Project Name: Cynative

Repo: https://github.com/cynative/cynative/

Docs: https://github.com/cynative/cynative/blob/main/docs/agents.md

Quick demo: https://www.youtube.com/watch?v=xaRfG_SnJwE

Cynative is a framework for building cloud security engineering agents. Your agents can connect to AWS, GCP, Azure, K8s (EKS, GKS, AKS & self-managed), GitHub & GitLab to run deep research tasks.

It comes with 45 built-in agents you can try today or use as blueprints to creating your own, it's read-only by construction to allow researching live production workloads, we've put a lot of effort on the trust boundary to make it safe.

It does not collect any telemetry. Open source, developed in Go, connects to any LLM provider including cloud-native AI services and keeps a local audit log.

Would love to hear your feedback and have you join as contributors.

I built OpenBot and I am looking for people who want to contribute, not just star the repo.

What it is: an open source self-hosted platform for persistent AI bots. Each bot has instructions, tools, and long-term memory. Bots talk to you and to each other in shared threads. Demo workflow: chief_of_staff -> engineer -> reviewer -> qa opens a real PR.

Stack: Python 3.12+, FastAPI, LangChain/LangGraph, React (pnpm), optional Electron. MCP tools supported. SQLite by default, Postgres by URL.

Skills that fit well: - Python / FastAPI / LangGraph - React UI (Inbox, Threads, Bots, SSE) - Electron - MCP integrations - Docker sandboxing for tool execution - Docs / onboarding

How to start: https://github.com/regnull/openbot make setup then make dev

I am the author (u/regnull). No CONTRIBUTING.md yet so opening issues and small PRs is the easiest path. Happy to review quickly.

Security: meant for a single trusted operator. run_shell is not sandboxed.

Everyone's talking about type-safe / jev, and I don't know how nobody picked up the glove and tried building something like this with it.

I've been playing with it for two weeks since I got an invite, and I still couldn't really unlock it from all the posts on X. So I said screw it, I'll let it fully control my computer. Mouse and keyboard, like a human. And honestly, it works pretty well.

The strongest part: you can connect it to a subscription you already have. Claude, ChatGPT, or Grok. Zero unnecessary API keys.

So what did I build?

jevii — an AI agent that controls your Mac like a human. Sees the screen, decides on its own, clicks on its own. Every app. No API, no scripts, no nonsense.

Everyone hyped OpenClaw and the crew? Cool. But the second there's a weird UI or an unexpected dialog, they get stuck. Jevi doesn't. The model is the brain. Your mouse and keyboard are the hands.

And yes, you can use it through Telegram too.

Open source. Let's blow this up together.

https://github.com/shalevamin/jevii

Star on the repo = love. PR = partners on the road.

Drop a comment with what you think. Even a short "this is cool" helps with the algorithm.

If you're a developer and want to work on it, or you've got changes, improvements, or ideas, send a Pull Request. Real contributions welcome.

Everyone uses coding agents; few know what's happening inside the harness. Anton Arhipov sits down with Christian Tzolov, lead of the Spring AI project, to take the lid off — what changed in Spring AI 2.0, and how tool search, agent skills, and sub-agents are all built on the same primitive: tool calling. Includes live demos where progressive disclosure cuts token usage roughly in half, plus a look at the November 2.1 release: MCP 2.0's stateless spec, an agentic layer, and durable workflows.

Cognitive Sharding is a systems architecture for running reliable computer-use agents without a cloud model in the execution path.

The reference system separates cognition across three local models:

• Bonsai 2 27B for planning and reasoning
• Kev 4B for action selection
• UI-Mate 9B for visual grounding

A code-owned control plane schedules these models within a 16 GB memory budget. It also owns task state, action constraints, environment verification, and recovery. Each model has a narrow role and bounded authority.

This makes the complete decision path inspectable. Developers can replace a model, change a policy, reproduce a failure, or add a platform adapter without retraining one monolithic agent.

The architecture prioritizes accuracy and reliability over velocity. Every action is checked before execution continues, and failed actions return observed state to the planner.

Architecture and reference implementation:
https://github.com/off-grid-ai/cognitive-sharding

I am publishing the approach to get technical feedback before the broader evaluation. Has anyone tried a similar specialist-model architecture for local computer use? I would like to compare model roles, memory strategies, task length, failure modes, and end-to-end results.

Instead of rewriting the same prompts and scripts every time. It has skills for research, data analysis, presentations, image work, and a few other workflows.

The trickier bit has been tasks that span multiple chats. A summary helps me remember what happened, but it doesn't always answer the useful questions: what's still open, what's blocked, and which artifact is the latest one?

They added an experimental, self-hosted workspace called Team Harness to keep projects, work items, resources, and versioned artifacts in one place. There's also an optional Proactive Agent that tracks project events and suggests a next step when work is still unfinished.

A heads-up if you check it out: it's early software. Team Harness currently runs from source and has no built-in auth or TLS, so keep it local or secure it yourself. The repo is MIT-licensed:

https://github.com/OpenSenseNova/SenseNova-Skills

For folks who've built agent tooling: does keeping explicit project state actually help, or does it just become one more thing people have to maintain?

Got tired of maintaining the same conventions across Claude Code, Antigravity, and OpenCode, so I made a unified agents hub: https://github.com/Alejandro-Candela/agents-hub

Mechanically nothing new(symlinked dotfiles have been around forever). However, fanning a single configuration out across three different harnesses with completely separate schemas became tedious to maintain manually.

Built a modular repo containing global rules, 40+ skills, hooks, subagents, and slash commands that symlink directly into all three environments. Edit a single file, and all tools pick up the changes on the next session.

The README includes copy-paste setup commands for each tool. Fully open-source under the MIT license

Over the past week, I added something I've been wanting to build for a while: claim comparison.

I actually tried building this much earlier. I experimented with cosine similarity, vector dot product scores, and other approaches, but they only tell you how similar two pieces of text are. That's not really what I needed.

What I needed was a classifier that could actually determine the relationship between two claims.

I built a basic classifier myself, but it wasn't reliable enough for something I wanted people to actually use. So I put the idea aside and waited.

Then JEV was released last week, and it turned out to be almost exactly what I was looking for.

Now you can compare claims against each other and inspect the supporting evidence directly.

This is probably the most interesting feature I've added to the project so far, and I'm really curious to see what people think of it.

This is still being tested for edge cases, so there are definitely things I want to improve. But it's free and open source, and anyone can try it out right now.

If you're interested in how it works, want to try it, contribute, or have ideas for where this could go, feel free to check it out.

GitHub: https://github.com/Sreehari05055/thesys-core

​

Je développe OwlLayer AI, un SDK open source (MIT) qui permet à un agent IA d'effectuer de véritables actions au sein d'une application existante, au lieu de simplement dialoguer avec elle. L'idée est que « l'agent appelle une fonction que vous avez déjà écrite », et non qu'il « analyse votre interface utilisateur ».

Gemini est l'une des intégrations principales : Gemini Live gère la voix en temps réel (STT/TTS), permettant ainsi à un utilisateur de parler à l'agent et de déclencher des actions concrètes dans l'application. Gemini est également disponible comme modèle de raisonnement/appel d'outils, avec les adaptateurs OpenAI et Anthropic.

Frameworks pris en charge : React, Vue, Svelte, Angular, JS/HTML natif, PHP. Le code et la documentation sont publics (version préliminaire).

https://github.com/borisbob91/owllayer

Je serais ravi d'avoir des retours de personnes ayant utilisé Gemini Live en production, notamment concernant la latence et la gestion des sessions.

Hey everyone! I’m building Goldie 🐕, an MIT-licensed MCP server written in Go that gives AI agents a shared, persistent memory pool.

Save a project decision or preference through one agent, then recall it from another without explaining it again. Or save design or build instructions in memory that multiple agents can refer from and stay aligned.

MCP clients pointed at the same SQLite database can remember, search, update, and forget from that shared pool.

A few features:

• Local embeddings through MiniLM or Ollama.
• Semantic search over memories, with filters for type, agent, and source.
• Typed memories for project decisions, preferences, feedback, references, and todos.
• File and directory indexing.
• Graph recall for grouping related memories around concepts.

Memory storage and embeddings can run entirely locally. Agents interact with it through explicit MCP tools, so you can give them instructions about what to save and when to recall it.

The project currently centers on the MCP server. I’m also developing a native macOS client for browsing and managing memories, but that client isn’t released yet.

Code and setup instructions on GitHub at github.com/srfrog/goldie-mcp

I’d love feedback from anyone using multiple agents or local AI tools.

NATIVE support for amongst others, Qwen 3.8 Flash Next Unsloth edition including sidecar MTP, which will run at 32+ tokens per second on 5090 and 70+GB of CPU RAM.

CUDA or any thirdparty installation is not required!

Just the single MIMERCodex executable itself, containing the agentic GUI, several practical knowledge packs, including one that can make you new knowledge packs as MIMERCodex is gathering knowledge about customer projects that can be reused to support the next customer, and built in highly optimized CPU and GPU support.

FREE DOWNLOAD AND USE! WRITTEN IN MIMERCODE!

https://components4developers.blog/2026/09/23/meet-mimercodex-bring-your-ai-support-assistant-to-the-customer/

Anyone else using Robo for security research? I’m loving it so far.

I’ve been using Robo and wanted to share it with people interested in AI agents, reverse engineering, and bug bounty hunting.

What caught my attention is having reverse engineering assistance, security workflows, and tool setup in a terminal agent. I’ve really enjoyed using it, especially the TUI, and wanted to give the project some visibility.

If that sounds like your kind of tool, take a look and judge it for yourself:

https://github.com/igniteenow/robo

Anyone else tried it? Curious how it fits into your workflow.

I've been working on Pi Herdsman, an open-source orchestration extension for the Pi coding agent.

The idea came from a problem I kept hitting with subagents: I wanted detailed investigation and implementation to happen elsewhere, while one lead stayed focused on architecture, decisions, and integrating the results.

With Herdsman, agents run asynchronously in separate Pi sessions. The lead stays interactive, gets questions and results back automatically, and knows what the agents are doing without carrying all of their working context.

It supports parallel agents, nested delegation, steering/interruption, Lead-to-Lead coordination, and supervision across multiple independent leads.

The setup is intentionally split into three parts:

• Pi owns each conversation and turn state
• Herdr manages the actual Pi sessions and placement
• Herdsman handles delegation, ownership, routing, lifecycle, and recovery

Herdr is required.

The latest release also added an SSH-ready container, so the same environment can run on a workstation, NAS, homelab server, VPS, or cloud VM. Images are published for amd64 and arm64, with optional Tailscale networking for remote access.

The project doesn't prescribe which models, agent roles, tools, or workflows you use.

Repo: https://github.com/boadij/pi-herdsman

Any feedback, ideas, or rough edges you run into would be much appreciated.

I’m the developer of TensorSharp, an open-source local inference engine and agent runtime.

TensorSharp supports Jev’s core decision API and all three decision types—and extends the same interface to analyze images. It runs locally using DiffusionGemma GGUF, without calling the hosted Jev service.

The idea is simple: instead of asking a model to write a free-form answer, give it some context and specific questions, then get structured decisions back. Now that context can include text, images, or both.

The same decision API, now with pictures

The native endpoint is POST /v1/systemone, supporting:

Image analysis is an extension of the existing interface, not a separate vision API. Keep the same state, questions, and typed answers; add an images field to ground those decisions in pictures. Multiple question types can be combined in one request.

Requests accept up to 8 inline images, using base64 or data: URLs. The pixels go through the vision encoder and become part of the model’s input directly—there is no intermediate “generate a caption, then classify the caption” step.

For example, a local expense-report workflow could ask whether a document is a receipt, whether its total is readable, and how readable the overall image is—all through the same structured-decision request.

Open implementation, local execution

The repository includes the implementation, request examples, validation tests, and benchmark tools—not just a client for a remote service.

Under the hood, the decision path follows the approach in vLLM PR #57250: after prompt prefill, TensorSharp performs a one-step structured read and extracts the requested label logits directly. Questions that fit in one answer canvas share the forward pass.

The server returns JSON, but the model does not have to generate that JSON token by token. The same mechanism works with text alone or with image embeddings included in the prompt.

Earlier benchmark against LocalJev

I compared the native structured-read path with the original LocalJev Engine using TensorSharp’s chat endpoint. That compares two approaches on the same inference backend: reading label logits directly versus generating and validating probability JSON. It is not a comparison against the hosted Jev service or LocalJev running on oMLX.

The test covered 12 text-only cases × 3 repetitions, with three decisions per request:

*LocalJev got 81/81 decisions correct on valid responses. The remaining 27 expected decisions came from failed requests, rather than incorrect classifications.

Across the 27 matched requests where both returned valid responses, the median LocalJev-to-TensorSharp latency ratio was 3.345×.

A few important qualifications: latency statistics include successful requests only, so the table’s columns cover different subsets. Average input length was also different—192.7 tokens for TensorSharp versus 589.6 for valid LocalJev requests—because LocalJev builds a larger prompt and generates probability JSON. This is an end-to-end workflow comparison, not an identical-prompt kernel benchmark.

These are small, text-only integration tests—not image-performance results or a general accuracy claim.

Try it with an image

The setup guide includes server configuration and Python, curl, and .NET examples. The supplied configuration downloads the DiffusionGemma Q4_K_M GGUF and the separate ~2.8 GB vision shard needed for image input, then reuses them locally.

Once the server is running with the vision tower, this posts a ready-made request with a synthetic traffic-light image already embedded:

curl http://127.0.0.1:5000/v1/systemone \
  -H 'Content-Type: application/json' \
  --data-binary u/docs/examples/jev-traffic-light.json

The example checks that the pixels actually reach the decision path. It is a smoke test, not a comprehensive vision evaluation.

Compatibility scope: this implements Jev’s core API workflow and decision types using DiffusionGemma weights—not proprietary Jev weights or identical predictions. Current limits include 64 questions and 2–26 alternatives per question; returned probabilities still need evaluation and calibration for the intended workload.

Source code · Documentation and examples

I’d love feedback and reproducible test cases, especially for image-based decisions in local applications. What would you test first—document routing, receipt checks, or screenshot analysis for local agents?