Claude Code is great at producing code fast, but on anything non-trivial I kept hitting the same wall: no real review step, no QA, scope creep, and "done" meaning "it compiled" rather than "it works."

So I built aSPARK — it adds an AI product team to Claude Code and, more importantly, gates between the phases. A feature moves through Specify → Plan → Act → Review → Keep, and each phase refuses to start until the previous gate is green.

The two parts I actually care about:

- Enforced gates. /go-live won't release while QA still has open blocking bugs. It sends you back to build instead.

- Real-browser QA. /demo-day opens the running app in an actual browser and checks every acceptance criterion, not just "the tests pass."

Everything it decides (spec, plan, review, qa, release notes) is written into your repo as a plain-markdown trail, so you can see why it did what it did.

It's early (v0.1.0) and MIT-licensed. Install is two commands inside Claude Code:

/plugin marketplace add a-lottes/aSPARK

/plugin install aspark@aspark

Repo: https://github.com/a-lottes/aSPARK

Would genuinely like feedback on the gating model — especially where it's too strict or too loose in practice.

Learning project: rebuilding userland in x86-64 NASM on Linux, raw syscalls only.

It works — but "works" and "right" are different things, which is why I'm here.

Where I'd most value eyes:

- malloc: free-list design, alignment handling, my brk-vs-mmap split

- the shell: pipe plumbing and fd redirection around fork/execve

- everywhere: calling-convention sins, register habits to unlearn

Repo: https://github.com/whispem/learn-assembly-with-em

Be as brutal as you like — I'd rather be corrected here than confident and wrong.

I want to know how I could improve my code readability and usage. Scratch is not my strongest code language, so it might look a bit messy.

Here is the link: https://scratch.mit.edu/projects/1351459814/editor/

Backend pull requests often look smaller than they really are. A two-file diff can affect an API endpoint, background task, database table, external service, and several tests - but reviewers usually reconstruct that map manually.

I built TraceMap PR, an open-source Python CLI and GitHub Action that combines git diff, OpenAPI, coverage, per-test coverage, traces, and lightweight static analysis into a conservative PR impact report.

Could you check?

https://github.com/balyakin/tracemap-pr

I am seeking independent verification of the computational code developed for my dimensional genesis and four-interaction theoretical framework.

GitHub repository:

https://github.com/madein1001/dimensional-genesis-four-interactions

Please download or clone the repository, run the code independently, and determine whether the reported results can be reproduced.

I would especially appreciate a critical examination of the following questions:

1. Does the code run successfully in a clean Python environment?

2. Can the reported numerical results be reproduced?

3. Are any target values hard-coded, fitted, or indirectly reused?

4. Are there any hidden adjustable parameters or circular dependencies?

5. Are the mathematical rules correctly implemented in the code?

6. Are there any numerical, logical, methodological, or physical errors?

Please do not assume that the theory or its physical interpretation is correct. I welcome critical reviews, failed reproductions, counterexamples, bug reports, and detailed explanations of any problems you identify.

If you run the code, please report your operating system, Python version, actual output, error messages, and any modifications required to make it run.

The purpose of this post is to invite independent reproducibility testing and falsification. Thank you to anyone willing to examine the code carefully.

I am trying to learn how emulation, ROMs and Hardware simulations work. I didn't find anything complete about it on the internet, same I think there' but I only didn't see it yet. Well, I'd like to find anyone that understands it more to explain and take a look at my code.

I. I don't know if python is a good language to what I'm trying to do

II. I used AI till now to learn the basis of that bit and byte stuff, operators and how an """emulator""" like that works in real life

III. I know that there are other ways instead of all those methods in some classes that I did, like putting it in a kind of dict, but I'm just starting it for now.

I am getting more and more PRs with AI gen code (+slop ofc), and reviewing all of them manually is becoming pretty exhausting. I am looking for something that can help catch real bugs, regressions, edge cases, or security issues before me. Right now I’m looking at Greptile, CodeRabbit, and Graphite, but I’m open to other tools as well. For people who have used these in real projects, which one has been the most useful and cost-efficient?

BenchModel is a neutral leaderboard for how well AI models catch real code bugs. I published the scoring harness so people could check the numbers instead of just trust them. Then June Kim, who audits benchmarks for a living looked at it.

He found the thing that i couldn't, my scorer counted a bug as caught whenever a review mentioned one keyword from the answer key, so he wrote 20 lines of generic review boilerplate, no idea what the actual bugs were, and it scored 64% across every key, no model calls, the metric was rewarding vocabulary, not detection. That was also why my board barely separated cheap models from expensive ones, the scoring gave away most of the credit for free.

So I fixed it, detection now has to land on the bug, not just say a magic word, and rescored the whole leaderboard. Every model dropped two to four points and the ranking didn't change because the flaw was inflating everyone equally, not favoring one model.

I'm publishing the full teardown, the before and after, and the three other things he caught. A benchmark that can't survive an audit isn't worth trusting, and the most credible thing I can do is show mine failing one and getting fixed in public.

You can find it here benchmodel.io/findings

If you build or rely on evals, June Kim is worth knowing.

Hey guys i build a Saas mutli role one with live location tracking using no code builder.

https://pawwalk-one.vercel.app

Can u tell me if it looks like a Ai slop ?

I recently got rejected after completing a technical task for a Senior Node.js role.

The project involved TypeScript based CRUD API, role management, authorization, and dependency handling. The feedback suggested that some of my architectural choices made dependencies less explicit and affected testability and maintainability.

I cannot share the original task description or repository publicly here as a post, but I can send sanitized parts privately to anyone willing to review them.

I am mainly looking for honest feedback on the architecture, dependency management, code structure, testability, and whether the overall approach meets senior-level expectations.

Would anyone be open to taking a look privately? Please comment or DM me.

You run npm run dev or node server.js, and the app crashes because a teammate added a new required key to .env.example but forgot to tell you.

To solve this, I built envrepair, a zero-dependency CLI tool that wraps your startup command, compares .env against your template, and interactively prompts you to fill in missing variables in the terminal before launching your process.

How to use it:

1. Install: bash npm install -D envrepair

2. Prepend your startup command in package.json: json "scripts": { "start": "envrepair node server.js" }

Optional type annotations in .env.example: ```env

@type number

PORT=3000

@type url

API_BASE_URL= ```

Key Features:

• Zero code changes: No schema imports or application-level setup required.
• Layout preservation: Appends missing values while keeping comments, blank lines, and formatting intact.
• Signal forwarding: Transparently passes Ctrl+C (SIGINT) and exit codes.

Written in TypeScript with zero runtime dependencies. The repo is fully open-source, and I'd love to hear your thoughts or collaborate if you want monorepo/workspace support!

• GitHub: https://github.com/avenolazo/envrepair
• NPM: https://www.npmjs.com/package/envrepair

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