Local CLI that reads your git diff (or a GitHub PR URL), sends it to Gemini, flags files worth a second look before you push — with a required exact quote from the diff as evidence for every flag.

Tested it against a small batch of real merged Godot PRs. Caught a real concurrency bug, correctly stayed quiet on clean PRs — and also produced one confident, well-evidenced, completely wrong flag (claimed a deadlock, but the mutex type was actually recursive so it wasn't one). Added a second pass that now catches exactly that kind of error by asking the model to name its own unverified assumptions.

If you don't want to bother with the Gemini API key setup — paste a link to one of your own merged/open PRs here and I'll run it and post the output. Genuinely curious how it holds up outside my own testing.

I've run into an issue when using AI generators where a few prompts get the base app working, but a subsequent prompt silently refactors or breaks a working feature.

Asking the model to "build an app" gives it too much room to make unseen assumptions about the code architecture.

To fix this, I started forcing smaller, incremental updates and doing strict git diff reviews after every prompt. Catching bad assumptions in the code diff before committing has helped, but managing state and shared utilities is still tricky.

For those reviewing and maintaining AI-generated code bases, what is your review sequence for validating diffs, testing dependencies, and keeping the codebase stable as the app grows?

The idea is pretty simple: a project can work perfectly while the repository still has problems that are easy to miss.

RepoDrift currently checks for things like:

• Potential exposed API keys, tokens and credentials
• Dependency and lockfile issues
• Large and suspicious files
• Git status and repository activity
• Basic code metrics
• Repository health score
• JSON output for CI/CD

The analysis is designed to run locally. The current version doesn't send the repository source code to an AI service.

Tech stack:
Node.js, TypeScript, Commander

Install:

npm install -g u/repodrift/cli

Then:

repodrift scan

There is also a --local-only option for scans that should not make network requests.

This is still an early project. I'm currently focusing on making the core analysis reliable before adding AI features. The plan is to eventually use AI to explain findings and suggest fixes based on redacted, structured results rather than sending the whole repository.

The project is MIT licensed and open source.

I'd be interested in feedback from other open-source developers:

What repository checks do you think are missing?

GitHub: https://github.com/GokulKir/repodrift

NPM: https://www.npmjs.com/package/@repodrift/cli

​

Is it switching between GitHub, Slack, Discord, Jira, and other tools — and losing the actual code context every time?

Hi, Good day everyone.

Would appreciate a review of the code.

It's a simple beginner level python project

I've been building CodifyLive as a resume/portfolio/learning project to get much deeper into backend engineering with FastAPI.

It's a real-time collaboration platform where users can chat, call, and eventually collaborate on code in the browser.

The backend is built with FastAPI + PostgreSQL + SQLAlchemy. So far I've implemented the authentication system, including Google OAuth, JWT access tokens, refresh-token rotation/reuse detection, password authentication, and CI/CD.

I'm looking for honest feedback from people experienced with FastAPI.

Specifically:

• How does my project structure look?
• Am I using FastAPI/SQLAlchemy in a way that will scale?
• Are there architectural decisions you'd change?
• Anything I'm overengineering or underengineering?
• How would you improve the authentication/session architecture?
• What would you change before considering this production-ready?

Project: https://github.com/fulanii/codify-live-backend

like I was working on a project somehow it turns out to be a better suitable tool for the code review , I am thinking if its even a need right now, Its not like code rabbit that gives you a pr comment by AI, This one give you a mathematical and absolute analysis of the pull request , it still required a human maintainers to look at but yeah it does help maintainers.

whats your thought is this even the need??

CoAudit helps give engineering leads a single dashboard and view across repos and contributors. It serves as an audit trail for what your coding agents may actually have been doing and the goal is to allow tech leads to spot possible AI-generated changes within 30 seconds of opening the dashboard, along with context on why. Currently, it really only works with Claude Code on heuristics, but with git-ai, it works with most agents. We're both pretty new to software engineering, and we would really like your help and feedback. Thank you so much!

https://github.com/atbui2007-bit/flagger

https://flagger-red.vercel.app/

I’ve been building something called EwwCode and wanted feedback from people who actually spend time reviewing code.
The idea is basically social media for code — post a snippet, other developers can rate it from 0–10 EWW, comment, give actual feedback, or roast the questionable decisions 😭
I’m trying to make code review feel more social and fun instead of everything being tied to pull requests or formal technical questions.
Would you use something like this? What would make you keep coming back?

I'm 13 years in, most of it on the same Java codebase, and I've spent a lot of this year worried that the code my team ships got worse the moment everyone started leaning on AI. Not broken, just worse. Swallowed exceptions because only the happy path got tested, Optional showing up as a field type, a JPA mapping that read fine and turned into an N+1 under real load. I tried the obvious things, more review guidelines, a conventions doc nobody opened, longer PR templates. None of it moved the needle.

What actually helped was changing the order. I run PRs through AI review tools first now, let them catch the mechanical stuff, and do my own pass on top of that for architecture and whether the change fits how this codebase already does things. I still read everything. But it gave me back maybe 35% of the time I was spending, and that time goes to the parts a tool cannot judge.

What actually bothers me isn't the tooling though. We scoped a migration off an old payments module in June, said two quarters, and got asked why it isn't two weeks now that the team has AI. Not in a hostile way either, it was a fair question from someone who has watched us close tickets faster all year. I didn't have a clean answer beyond the work being different, which sounded like an excuse even to me.

The team I work with is good. The system has been in production for over a decade, it moves money, and someone will be maintaining it long after all of us have left. Going faster on tickets and going faster on that are not the same thing, and I'm apparently bad at explaining why.

So I want the honest read from people on old Java systems. Are these tools actually helping you hold quality, or are we just processing more code slightly faster and calling it review? And has anyone found a way to answer the two weeks question without sounding like they're protecting their own job?

I recently wrote a blog post on how we can improve our static analysis using linting, custom rules, and hooks, all using oxlint.

It's quite a big article btw.

https://saybackend.com/blog/lint-ai-generated-code/

While my current post is more focused towards Typescript/React but more mature languages with better linters can do even more. The lint rules you didn't wanted to handled when coding manually doesn't mean your agent should avoid them as well.

**Body:**

Hi everyone,

I recently built **Job-Copilot**, an open-source tool designed to help streamline resume analysis and job matching workflows.

🔗 **GitHub:** https://github.com/allenbersho/job-copilot

The core functionality is working, but I’m looking to take the code quality, performance, and architecture to the next level. I’d love to get feedback from the community to help identify bottlenecks, edge-case bugs, or areas ripe for refactoring.

### 💻 Stack

* **Language:** Python

* **Libraries/Tools:** [e.g., FastAPI, Streamlit, Pandas, NLP / LLM integrations]

### 🎯 What I’m Looking For:

1. **Code Review & Best Practices:** Project structure, readability, error handling, and cleaner design patterns.

2. **Performance Optimization:** Reducing latency in data processing/parsing and optimizing resource usage.

3. **Bug Hunting / Edge Cases:** Breaking the parser or matching logic with unusual input formats/files.

4. **Feature & Architecture Suggestions:** High-impact additions or refactoring recommendations for scalability.

### 🚀 How to Run Locally

```bash

git clone [https://github.com/allenbersho/job-copilot.git\](https://github.com/allenbersho/job-copilot.git)

cd job-copilot

pip install -r requirements.txt

[your run command, e.g., python main.py or streamlit run app.py]

Hey guys, wanted to tell you guys about a tool I built called Scanity. Scanity scans codebases to find security vulnerabilities in code. Nowadays, with AI coding so fast, there are so many internal bugs and vulnerabilities that get missed.

Here are the main features we have:

1. Seamless integration with GitHub Actions, checking each PR before it merges, and automatically providing suggested fixes.
2. Drop into any repository, run a full scan, and fix everything you find

Now you may ask, why can't we run this within Claude or Codex? We stand out because we build containerized test units for each finding to verify the issue. So there is no chance of AI hallucination. This is very early stage, and we have plans to grow even further, with many more features and integrations. I'm eager to hear from you and get your feedback.

Check it out here: https://scanity.dev/

Used to treat a clear, detailed PR description as a decent signal the author understood what they changed. That correlation is breaking down. AI tools are good at generating a clean, structured description from a diff regardless of whether the diff actually does what the description claims, and the description reads exactly the same either way. Clear writing and correct code used to travel together often enough that one was a reasonable proxy for the other. They don't anymore.

Caught this on a PR last month where the description said "adds retry logic with exponential backoff for the payment call." Diff had a retry loop. No backoff, fixed interval, three attempts, no jitter. Nobody would've caught that from reading the description, it was accurate-sounding and well-organized. Only showed up because someone happened to open the actual diff instead of trusting the summary.

Not blaming the tooling here, this isn't really new, humans have always been capable of writing an aspirational PR description that doesn't quite match what shipped. What's changed is the volume of well-written descriptions has gone up while the correlation between "well-written" and "accurate" has gone down, because generating a plausible description no longer requires the same understanding writing one from scratch used to require.

Starting to read PR descriptions as a claim to verify against the diff rather than a summary to trust, especially anything specific enough to be checkable, a claimed algorithm, a stated edge case handled, a security consideration addressed. If the description makes a specific claim, it's worth confirming the diff actually backs it up before approving on the strength of the writing alone.

For teams using AI-assisted code review tools, what has your real-world experience been over the past 120 days? Have these tools helped you catch meaningful issues before deployment or have any accepted recommendations unintentionally contributed to production bugs? Have they missed issues that a human reviewer might reasonably have caught?

I am also curious whether your team has become more confident or more cautious over time, and whether you track any metrics to evaluate their accuracy. This isn’t about criticizing or comparing vendors. I am simply interested in understanding how engineering teams evaluate these tools beyond productivity and adoption claims.

I proposed and helped fund an app called retro-crypto, which is being developed by a programmer called bowler-bear: https://github.com/bowler-bear/retro-crypto

It's designed to become the most secure way to message friends or store a Bitcoin stack, but it can't be recommended for more than testing yet. I think at the current stage, the next thing it needs is to have others look at the code and try to find vulnerabilities. I'm not a programmer myself.

"Given enough eyeballs, all bugs are shallow" -Linus's Law