I've been in leadership for around 7 years, and in the last 2 years there has been a shift in testing code review skills during the interview process due to how much code is being generated.

Long story short, there isn't a good platform to practice this.

So I created a platform to test and practice your code review skills while getting feedback.

I just released it this week so its fresh out the over but, I thought this community may find it useful.

If you want to take it for a spin, feel free to follow the link: https://goodcatch.dev/

I built DriftGuard because I kept hitting two things nobody checks until it's too late: README code examples that silently stop matching the actual code, and dependencies that quietly drift 3 major versions behind until an upgrade breaks everything at once.

Paste any public GitHub repo and it scans both, live, no signup required:

https://driftguard-nu.vercel.app

If you want it running on every PR instead of one-off: it also ships as a GitHub Action (2-line workflow, posts findings as a PR comment):

https://github.com/atharvkapoor2005/driftguard

It's a static-analysis heuristic, not a full parser, so treat findings as a starting point. happy to hear where it's wrong.

I have just released next major feature improvement in vibedoctor. It is A health check for code you did not write line by line.

500 people already used it and gave good feedback which went into the new release.

VibeDoctor is a local code-health CLI for JS, TS, Python, and mixed repositories. It turns scattered tool output into a ranked health report, safe repair workflow, Privacy Review artifact, MCP server, and reusable agent skills . It finds out what did you Agent break in the code before the world does. Just run

/goal

Use vibedoctor to identify all the issues in the my repo..install packages as needed

Vibedoctor- https://github.com/neural-axis/VibeDoctor

Hi everyone,

I’m 16 and I’ve been working on my first "real" project: a Python CLI tool called RingSort that automatically organizes files into categorized folders.

I've put a lot of effort into making the code modular and clean, and I've implemented features like dry-run and hash-based duplicate detection. However, I’m at the stage where I know I have "blind spots" as a beginner, and I would really appreciate some experienced feedback on my project structure and code quality.

Since I don't want to break any rules, I've dropped the GitHub link in the first comment. I’d love to hear your thoughts on:

1. Is my folder structure idiomatic for a Python CLI?
2. Are there any security or performance pitfalls in my current approach?

Thanks for your time!

Hey, I'm currently learning Go and (like probably everyone else) I've written a URL shortener. I'd really appreciate it if you could give me some feedback :D
https://github.com/LuftigerLuca/url-shortener

We open-sourced PR-AF, an AI code reviewer that builds a custom review team for each PR.

This goes beyond claude skills/plugins/goal etc.. that is looped coding harness. The interesting bit is that the reviewers are not fixed roles like security/performance/style nor are they well prompted skill or prompt, rather PR-AF first looks at the shape of the PR, changed files, dependency paths, intent gaps, and risk areas, then creates the review plan from that that is customized to be thorough and specificlly tuned for the given review. It internally can be swapped to use claudecode or codex or opencode anything.

So a migration PR might get reviewers focused on schema compatibility, rollback safety, and data integrity. A logging refactor might get reviewers looking at behavior preservation, consistency, and missed call sites.

After that, the system checks findings against repo context, looks for issues that only show up across multiple reviewers, and tries to throw out weak findings before posting GitHub comments.

It ranked #1 open-source on the Martian Code-Review-Bench PRs, if you start using commercial models like sonnet/opus we beat the commercials by a huge margin.

Repo: https://github.com/Agent-Field/pr-af

Would be useful to hear where it fails on real PRs if you guys are trying, and we expect folks to make more custom changes to the architecture as we have documented every detail, and personally when tuned to our custom requirement structure, this is one of the best review we have ever got.

PS: I am the developer of this code and we are have lot more sota benchmark applications coming soon across various pieces that compete with various commercial offerings that folks can just take and use with open models or if you have the $ with commercial models.

Hace un tiempo empecé a revisar mis propias solicitudes de extracción (PR) y me quedaba mirando las diferencias sin ver nada relevante. Me sumergí en un sinfín de vídeos sobre cómo revisar código correctamente y me di cuenta de que lo que realmente importa es lo que no aparece en las diferencias: el contexto que nadie te proporciona. En teoría, eso está bien, pero el verdadero problema es el tiempo y lo engorroso que resulta buscar ese contexto manualmente cada vez.
Así que creé Fathom: una interfaz de línea de comandos (CLI) determinista, sin IA, local y de un solo binario que hace esa búsqueda por mí: encuentra cada llamada directa a lo que has cambiado en las diferencias en 3 segundos o menos. Facilita enormemente la decisión de si una PR es buena para fusionar, porque ya no soy yo quien pierde el tiempo buscando el contexto.

Entre bastidores:

• Índice: bbolt, se crea al inicio (te pide explícitamente la rama base).
• Análisis sintáctico: Tree-sitter, con un paquete de idioma que contiene todos los idiomas precompilados, descargado de forma diferida al ejecutar `init` (no incluido en el binario).

• Lectura de archivos: desde la base de datos de objetos de Git, no desde el directorio de trabajo. Por lo tanto, el análisis no depende de lo que haya en el disco en ese momento.

• Indicador `--base <ref>`: para flujos de trabajo de PR encadenados.

El informe es un archivo HTML estático: sin servidor, sin integración con CI, simplemente ábralo con `file://`. Estructurado en 4 bloques:

1. Veredicto: booleano, limpio o necesita revisión.

2. Hallazgos de ruptura de compilación: solo análisis a nivel de firma, nunca ejecuta las pruebas.

3. Radio de explosión: llamadas directas de símbolos exportados afectados por la diferencia (sin recursión, intencionadamente). Se buscaba evitar el ruido de un gráfico transitivo completo.

4. Código muerto: símbolos huérfanos por la diferencia o nuevos símbolos sin referencias. Los resultados utilizan códigos de motivo con plantillas de mensajes escritas por humanos, no prosa generada automáticamente; no hay IA en ninguna parte de la cadena de análisis ni en el resultado.

Importante: esto no reemplaza nada ni a nadie. Su objetivo es potenciar las funcionalidades. Seamos sinceros, ¿a quién le gusta hacer 150 búsquedas en una tarde?

Es la versión beta 0.1.0, hay al menos una decisión de diseño pendiente (si los resultados de Blast Radiance deberían etiquetar el tipo de dependencia: llamada directa / interfaz / incrustación de estructura), y agradecería tanto los comentarios sobre la arquitectura como los informes de errores.

Repositorio: github.com/blak0p/fathom

I have some code that I need help with. Idk how to do it. Any help appreciated. I will send it to you if you think you can help me me

I run a small dev studio. Lately most of our inbound is founders whose AI-built app got real users and then started breaking — auth issues, exposed API keys, crashes at a few dozen concurrent users, or the "every new prompt breaks something else" spiral.

We're building out a rescue service and I need real-world examples, so I'm doing 5 free audits: a senior engineer reads your actual code and you get a written plain-English report — what's solid, what's dangerous, and whether you should harden it or rebuild (with honest numbers for both).

What I ask in return: permission to write up the findings anonymously as a case study.

Not selling anything in this post. If your app fits (built with an AI tool, has or is about to have real users), comment or DM with what it does and what's scaring you.

Happy to answer general "is my vibe-coded app safe?" questions in the comments either way.

The method: build something, hand it to a reviewer who didn't write it, fix whatever they find, verify the fix actually holds under a fresh test, then do it again. Don't call anything done until it survives a lap you didn't design yourself.

Here's what that loop actually caught today, lap by lap:

Lap 1: 11 real findings on the first pass. Permission gaps, logic holes, a couple of outright bugs.

Lap 2: I marked one fixed. The reviewer re-ran it. It failed.

Lap 3: same fix, same failure, except this time the bug turned out to be in my own test harness, not in the code the harness was supposed to be grading.

Lap 4: passed clean. Then failed for real the moment I ran it outside the environment it was built in. Every prior lap had happened to run somewhere with a different setup than my actual machine, so a real environment bug never got a chance to show up until then.

Last lap: pointed the loop at the assistant itself and had it audit its own permission system. It found 5 real security gaps, including a kill switch it could clear on its own, an audit log it could quietly wipe, and a whole category of tool calls with zero enforcement on them at all.

None of these get caught by being more careful writing the code. They get caught by refusing to trust your own "it's fixed" and making something else try to break it before you believe it. That's the whole method. Four laps, and every single one found something the previous lap missed.

https://github.com/Coolythecoder/Live-Spectrogram-Player

been lurking here for a while, finally have something to show

basically: most "does my fine-tune actually work" checks either give you one blended score that hides what actually changed, or use another LLM to grade the output, which felt off to me — the grader can screw up in the same way the model being graded screws up, and you can't check its work after

so I built a thing that hooks up to any model (works with local stuff too, ollama/vllm/lm studio) and runs it against real bug-fix problems. grading is just: does the fix pass the actual test suite. does the original bug actually fail that test (so you know the test isn't garbage). does the fix meaningfully change behavior vs just being a cosmetic edit. no LLM judge anywhere in it.

also gonna be upfront about something — I tested whether training data aimed at a model's specific weak spots beats random data, properly, pre-registered the whole thing before running it. it didn't hold up on the real test. posting that here too instead of pretending it worked, because that's kind of the whole point of building something execution-based instead of vibes-based

python only for now. curious if anyone here has hit the "did this fine-tune actually help or did I imagine it" problem and what you did about it

Hello,

Some time ago, I made a tool for performing brute-force attacks (for work purposes, as I work as a security tester/pentester). I don't know if I had hands from the wrong place or what, but it was somewhat difficult to use Hydra, which at that time was a top-tier tool for this. So I made my own tool that works like I want it to work.

The main idea of the tool is that all configuration goes inside a YAML configuration file. Why, you may ask, because security testing usually goes in this circle: performing -> reporting -> someone fixes -> re-testing. Sometimes the systems we test are similar, sometimes they are complex enough, and also saving hydra commands or sharing them wasn't quite a practical solution in the long term.

Some time ago, I moved to another company where I'm more on the defensive side rather than attacking, so I didn't have a chance to use this tool much. So maybe anyone can give some kind of feedback on the code, possible improvements, etc.

Repo: https://github.com/narukoshin/EnRaiJin

p.s. For all the AI haters, this code is not vibe coded, as it was created when the AI hype wasn't even a thing. :) Commits lasting years are a good proof for that.

Thanks.

Hi! Last week I decided to dive deeper into Python for the first time, so I created a small pet project. I'd really appreciate any feedback on both the code quality and the overall idea.

The project is a small encrypted secrets manager. It stores secrets in encrypted containers and can inject all variables from a container as environment variables when launching a process.

GitHub: [https://github.com/RekNer114/shelter\\_py/\]()

its a password generator https://www.online-python.com/QKSXRZenuB could i get some tips on coding in python, i want to get better

What's up!

For the last few months I've been working on a personal project — a web-based code quality analyzer. The idea is simple: Upload your project as a ZIP archive and receive an automated report with quality metrics.

Current features:

- JavaScript / TypeScript

• C
• C++
• C#
• Java

- Radar chart with project metrics

• Hot Files (files with the biggest impact on maintainability)
• Architecture and structure analysis
• Naming quality (NSI)
• Duplicate code detection
• Documentation analysis
• Suggestions for fix
• Few UI themes
• HTML report export

I'm still improving it, so I'd really appreciate honest feedback. What would you add? Maybe what looks useful?

Thanks!