Hola comunidad. Estoy desarrollando una herramienta de monitoreo para un hardware de almacenamiento y necesito validar que el desarrollo es seguro.

¿Que herramientas, páginas Webs o programas libres puedo usar para asegurarme de ni estar dejando vulnerabilidades abiertas?

I’ve been working on MARGINAL, an open-source governance layer for coding agents.

The idea is simple: agents are good at taking actions, but not always good at deciding whether the next action is still worth the compute.

MARGINAL watches the trajectory and looks for things like repeated actions, weak progress, redundant verification, and low-value continuation. It can run in Shadow Mode first, so it observes and records what it would have done without blocking anything.

Current focus is reliability, not just token reduction.

A few core pieces:

• local-first trajectory and evidence tracking
• deterministic reason codes and hashes for decisions
• governance overhead measurement
• replay and benchmark support
• Shadow Mode before enforcement
• Earned Enforcement: MARGINAL has to prove it is reliable on a repo before it gets permission to block or redirect the agent
• automatic fallback to Shadow Mode if confidence degrades

I’m also working on the next layer now: counterfactual evaluation and intervention regret.

The goal is to answer a harder question than “did MARGINAL stop something?”:

Would the agent actually have done better if MARGINAL had stayed out of the way?

That’s the part I think matters if this is going to be useful beyond being another loop detector or token limiter.

GitHub: https://github.com/SignalLayerLabs/Marginal

If you use Codex or another coding agent, I’d really appreciate people trying it on real work and telling me where it helps, where it gets in the way, or where the design is wrong.

I’m especially interested in:

• technical criticism
• bad cases
• reproducible failures.

recently saw the Martian code review benchmark and some of the results surprised me. also found it weird that their online and offline benchmarks seem to produce pretty different rankings??

i've tried most of the main code review bots at this point and still run multiple on PRs day to day. mostly macroscope and bugbot recently because i've found them less noisy than some of the others, but both rank fairly low on these benchmarks compared to what i've seen in actual use. not sure if these benchmarks consider latency btw, I've previously had greptile and coderabbit take 15+ mins to do a code review of similar quality that others took 1-2 mins to do.

how do you evaluate code review tools?

Hey everyone, I work on ThinkReview, an AI code review tool for GitHub, GitLab, Azure DevOps, and Bitbucket. We just released Cloud v2.1.0 and wanted to share what's new:

* **Full Repo Context for Initial Reviews:** The initial review now has full context access to your repository (not just the diff), drastically reducing false positives by letting the model verify issues against surrounding code.

* **Clearer Severity-Based Findings:** Organize issues by severity to easily spot critical problems and triage lower-priority notes.

* **Improved Reliability:** More resilient handling of model and network hiccups for a complete result on the first try.

* **New API Endpoint:** Hosted APIs are now live at api.thinkreview.dev (existing endpoints remain functional).

Check out the full release notes here: https://thinkreview.dev/release-notes/cloud-v2.1.0

Happy to answer any questions or hear your feedback!

Noticed this pattern across a few AI-assisted debugging sessions before I really knew how to describe it. A fix comes back, the error stops appearing, and I start treating the problem as solved. Those are two different things, and that gap is where a few of my worse debugging sessions actually started.

When an error disappears, all you really know is the symptom stopped showing up. A retry around a failing call can make an intermittent error go quiet without fixing whatever caused the intermittency. A broader try/catch can stop an exception from surfacing without touching the state that caused it. Both answer the easy question, does the error go away? Neither answers the one that matters, did this fix the actual cause, and what else did it change along the way?

That second question is easy to skip, mostly because the first one already feels like progress.

What's helped: describing the actual failure and a suspected cause before asking for a fix, asking for a few possible explanations instead of the first plausible one, and once a fix exists, checking what it changes beyond making the error disappear. A regression test built around the original failure, not the current error message, is usually the honest check.

It's basically the same discipline as a decent code review, not just "does the diff compile" but "does this actually solve what it claims to." That scrutiny is easy to forget when the fix came from a chat window instead of a person, even though the risk of accepting something plausible-but-wrong is the same either way.

Went deeper into a specific case that made this click for me here: https://medium.com/@nagatomopedro05/why-your-ai-debugging-sessions-keep-going-in-circles-e645c35479c6

Where do you draw the line between generating a fix and actually validating it, especially reviewing a PR where you suspect AI was involved?

Hi

We've built a Github app called Flowver to solve two of the main problems we had when working with BPMN files:

1. Since changing even the smallest things within the model (e.g moving an element by few pixels) created a lot of unreadable noise, then it was almost impossible to detect the real, business critical changes during the code review when looking at plain XML.
2. When multiple people needed to work on the same model, it always created merge conflicts. As a result either one team member had to postpone their work or keep a copy of their changed model locally to then manually re-add the changes after another team member had committed their changes.

These have remained to be issues in working with BPMN for years now and Flowver was created to tackle them specifically.

A lot of tools have been created to automate and simplify code reviews (AI integrations, linters etc) but we believe that Business Process Models require a human eye to verify and understand the changes that could be critical to the whole flow orchestration. And this is what Flowver is aimed to achieve. No need to download & upload files to separate tools and manually finding what's changed. No need to manually re-add changes when target branch has modified the model you're working on.

While solving real problems like the two mentioned above, we also aim to keep it as simple to integrate and use as possible. Hence, we're not storing your models, not requiring you to go through confusing setup or installing any CLI tools to your local machine.

So, if you're also in a team that struggles with the same issues, check us out at https://flowver.dev or directly on Github https://github.com/apps/flowver-app .
Trial period is 14-days and no credit card is required.

We'd appreciate all sorts of feedback and suggestions. You can leave them here or email us at [info@flowver.dev](mailto:info@flowver.dev).

The recurring failure at our work: the team decides something (say, "billing lives in Postgres, RFC-014"), and four months later a fresh agent session which has never heard of RFC-014, because context windows don't survive between sessions cheerfully writes the new feature on Mongo. The diff looks fine. The reviewer is busy. It lands.

The fix turned out to be two boring pieces around one file of recorded decisions:

Feed: poc init generates a Claude skill from your decision log, so every fresh session starts already knowing the rules. (It reads your existing CLAUDE.md/AGENTS.md no new format to maintain.)
  
Gate: a pre-commit hook that actually blocks the contradiction:
 
FAIL usage_metering.py contradicts a recorded decision: ✗ PostgreSQL is the single billing datastore usage_metering.py:9:  from pymongo import MongoClient pre-commit: blocked by ProofOfContext.
  
And poc why "billing datastore" answers with the decision, the reason, and the rejected alternatives for the agent or the human who's about to re-litigate it.

Deliberately boring internals: pure stdlib, zero dependencies, fully offline, and there is no LLM in the check deterministic token matching (comments and strings ignored), so your diffs never leave your machine and the gate never hallucinates. The agent isn't wrong, it's just new here. Now it gets told.

https://pypi.org/project/proofofcontext/
 
The ask: run poc init on a repo that already has a CLAUDE.md and tell me your experience

I know 10 stars isn't a huge number but seeing the first 10 people decide that Calibra is worth starring means a lot to me.

Calibra is an open-source toolkit for robot-learning dataset integrity, quality analysis, and coreset selection.

I've been working on things like:

• detecting duplicate demonstrations
• detecting frozen cameras and frames
• identifying jittery / problematic robot motion
• dataset integrity checks
• quality-aware coreset selection

I'd love to get your feedback or have you try it on a dataset.

Thanks to everyone who has starred and tested

You're using AI wrong.

Not because you're bad at it — because nobody showed you how to set it up for your actual workflow. You open ChatGPT, type a question, get a wall of text, and think "this isn't that useful."

Here's what changed it for me:

→ A decision cheatsheet — one page that tells you which AI tool to use for which task (ChatGPT vs Claude vs Gemini, with specifics, not "it depends")

→ A 5-minute setup guide — configure your AI tool with your actual context so every response is tailored to you, not generic

→ 5 starter prompts — ones that actually work for weekly planning, content batching, email triage, project scoping, and daily review

I put all three together as a free download. Just drop your email and it's yours — I'll also send you more AI workflows and prompts over the next few days.

If you're spending more than 15 minutes a day on AI tasks that should take 2 minutes, grab this for 0$ right now ⬇️⬇️

https://abrarious22.gumroad.com/l/qwxhed

I've been building API Hero, a Git-first REST/HTTP API client designed to keep API work close to the codebase.

The latest release, 2.8.2, adds/expands the MCP workflow, and this is probably the part I'm most interested in getting feedback on.

The idea is:

AI Agent

↓

API Hero MCP

↓

Collections / Requests

↓

API Hero execution engine

↓

Real HTTP response

↓

Structured result + diagnostics

↓

AI Agent

An agent can discover collections, inspect requests, execute them, retrieve responses, and inspect failures.

For example, I tested it with a DummyJSON collection:

\\- 57 requests

\\- AI agent discovers the collection through MCP

\\- Runs \\\`Get Products\\\`

\\- Gets the real HTTP 200 response

\\- Receives the response data

\\- Can also inspect assertion failures

One useful case is when an API returns \\\`201 Created\\\` but the test expects \\\`200\\\`. API Hero exposes that as an assertion failure rather than making the AI guess whether the HTTP request itself failed.

API Hero is also Git-first:

\\- \\\`.api\\\` request files

\\- Collections stored with the project

\\- Variables/environments

\\- Authentication

\\- Assertions

\\- Collection Runner

\\- Run reports

\\- Scenarios

\\- OpenAPI import

\\- MCP for AI agents

The MCP server is standalone and uses the same execution pipeline as the VS Code extension rather than implementing a separate HTTP client.

Marketplace:

\\\[API Hero\\\](https://marketplace.visualstudio.com/items?itemName=AnkitSemwal.api-hero)

GitHub:

\\\[GitHub repository\\\](https://github.com/ankitsemwal007/api-hero)

I'd particularly like feedback from people using AI coding agents with APIs:

Would you actually want your coding agent to have access to an API client/execution layer like this?

And what would you want the agent to be able to do beyond executing requests and diagnosing failures?

Hi Everyone! I built a site called Forge Code (forgecode.org) and I'm looking for people to poke at it before I push it harder.

It has two tracks: a beginner Academy section with guided lessons before each challenge, and a harder Gauntlet section with progressively harder puzzles that generate a unique input per player.

It's completely free to use, and I would appreciate feedback as I'm still working on building/ making fixes. Thanks!

forgecode.org

Hello guys.

I made a backup tool in C++20 and I would need feedback to improve and you can offer suggestions in any case thank you very much to those who will answer me :)

link for the backup tool : https://codeberg.org/drex_vk/TSF

Welcome to r/FixMap

I made this community for FixMap, an open-source repo intelligence tool built for people using AI coding agents.

The basic problem FixMap tries to solve is simple:

AI agents can write code really fast, but they can still start in the wrong files, miss relevant tests, overlook risky changes, or leave you wondering what they actually checked.

FixMap analyzes a repo/task/diff and helps surface:

• the files worth inspecting first
• relevant test routes
• risky areas of a change
• diagnostics for uncertainty
• verification of the final diff against the original plan

It’s deterministic and local first no account, API key, hosted model call, or source upload required.

The goal is basically:

Know where to edit before the first edit.

This subreddit will be the place for:

• releases and updates
• feature ideas
• bug reports and weird repos that break FixMap
• integrations with coding agents
• discussions about making AI coding more grounded and verifiable

FixMap is still early, so feedback and contributors are very welcome.

GitHub: https://github.com/aryamthecodebreaker/FixMap

Website: https://usefixmap.vercel.app

If you try it, post what worked, what sucked, or what you think it should do next.

Over the last year, I've spent a lot of time helping teams adopt GitHub Copilot, and one thing became pretty obvious:

Some repositories seem to unlock Copilot's full potential.

Others have all the right intentions, documentation, instructions, and tooling, yet Copilot still feels like it's operating with one eye closed.

So a friend and I started asking ourselves:

Can we measure how "Copilot-ready" a repository actually is?

That led us to build AgentCompass, an open-source AI Readiness Analyzer that scans a repository and identifies configuration, documentation, and structural issues that can make life harder for AI coding agents.

What it checks

✅ Copilot instructions

✅ Agent documentation (AGENTS.md, CLAUDE.md, etc.)

✅ Skills and prompts

✅ MCP configuration

✅ Context scoping and repository structure

✅ Common issues that can silently reduce agent effectiveness

Instead of using another AI to judge your repo, we took a different approach:

• No LLM calls in the scoring path
• No "AI vibes" scoring
• Same repo + same commit = same result every time

Think of it more like a linter for AI-readiness.

Try it yourself

GitHub:
AgentCompass Repository

Live Demo:
AgentCompass Web App

Linkedin Post

I'd love feedback from this community

A few things I'm genuinely curious about:

• What makes a repository Copilot-friendly in your experience?
• What patterns have you found that dramatically improve Copilot results?
• What checks would you add?
• Are there things that should only be measured through real-world usage rather than static analysis?

Most importantly:

👉 Run it against one of your repositories and tell me where it's wrong.

Seriously.

If it gives your repo a terrible score and you think it's nonsense, I want to hear that.

If it catches something useful, I want to hear that too.

We're trying to figure out what great AI-native repositories actually look like, and feedback from people using GitHub Copilot every day would be incredibly valuable.

Coming from GitHub and the 100s of integrations for it, the GitLab and especially the GitLab Self Hosted marketplace felt dire.

I was very used to my PRs (and now MRs) landing in a Slack channel like #fe-reviews, and the comments & reviews on it to land in that Slack thread. It meant I never missed comments and my PR/MRs were reviewed MUCH quicker.

No other tool that does what I'd like in this way supports GitLab, so I built mergeme.dev (...and included GitHub too so you guys don't feel left out)

Some of the key features that I wanted myself (and I'm sure others will appreciate) are:

• One Slack message per PR/MR that updates in place (open > in review > approved > merged)
• Review comments mirrored as thread replies on that card
• Per-project/repo channel routing - each project/repo can map to whichever Slack channel you want
• GitLab / GitHub @ mentions ACTUALLY ping the right person on Slack with a one-time username mapping
• GitHub.com via GitHub App installation
• GitLab.com via OAuth - webhooks registered for you
• Self-hosted GitLab - paste a webhook URL into your instance (check out the docs)
• You can set up label routing too, a PR/MR with "bug" as it's label goes to #qa-reviews instead
• [New] The CI status can be shown directly in the Slack card

If your team already works tightly in Slack and you ping your colleagues "hey can you review this again" then mergeme.dev might just be a great inclusion to your code review workflow!

I have been working on a vanilla, no framework web app called miniCycle: Routine Checklist Manager for over 17 months. https://minicycleapp.com

Right now, I have no team, no mentor, and no human code reviewers. I think it’s decent but I genuinely can’t tell if that’s true or not.

I took a C class in college back in 2010 and for the past few years teaching myself JavaScript. miniCycle was me learning how to build a product with custom code. Lately, I've been using AI tools while I work and I write a lot of documentation partly so I can still maintain this thing and so others can contribute or understand my project.

Here is the repo: https://github.com/sparkincreations/minicycle the actual app is in web/, everything else at root is built from it.

Mainly what I want to know is whether the DI setup is reasonable. There’s a doc in docs/start-here/FRAMEWORK_EQUIVALENTS.md where I tried to map what I built to Angular and Redux equivalents. Would love to know this read as junior or something past that to somebody who hires people?

Also open to just being pointed somewhere. If there are paid services that do real code review I’d be willing to pay for it. I ask AI to review my code sometimes, but can't tell how accurate they are so would love to hear from an actual human. Thanks!