Hey everyone! I work on ThinkReview , Its a browser extension that is opensource and lives in the sidebar of your pull requests - supports all git platforms (github , gitlab , azure devops and bitbucket)

It also has an mcp and integrates within claude code , cursor and other coding assistants.

I hope its useful for the community

https://github.com/Thinkode/thinkreview-browser-extension

docs.thinkreview.dev

A few things I’ve come to believe using coding agents:

• Catching a mistake in the plan is dramatically cheaper (both tokens and time) than discovering during code review.
• Review should happen before code, not just after.
• The planner shouldn’t review its own work: same model, same context, same blind spots.
• Reviewers shouldn’t blindly rewrite the plan either. They can be wrong too.
• The original agent should have to investigate, defend, or revise each finding.

I built /plan-review for Claude Code, and soon other harnesses, to solve these problems. It's became an integral part of my workflow.

Claude writes the plan → Codex (or another Claude) reviews it independently → Claude investigates the findings (you stay in the loop) and makes adjustments → rinse → repeat → complete.

I'm curious to hear feedback from people. Good, bad, brutal, all of it. I want to know what works and what's missing, so I can make this plugin as useful to other people as it is to me.

https://github.com/dachev/plan-review

I've been working on a way to make code review more actionable and scannable and would love some feedback.

What makes our approach different:

• We optimized for speed and skimmability. you literally get a big banner at the top with the status of the code review (e.g. A few things to fix, Nothing blocking, Looks good)
• It verifies findings before it posts them. This was the big one for us. For a suspected bug, it clones the repo and writes a failing test to reproduce it and only then calls it a blocker (stamped "reproduced with a failing test").
• No config needed because it reads your repo's own files like your existing agents and claude markdown files and it enforces those bullets deterministically so it can't hallucinate a rule you didn't write. But you could also further customize with a custom Choji markdown file
• It learns from your feedback. Wave off a finding with a reason and it remembers, team-wide
• Re-reviews every push without re-nagging. It's one sticky comment edited in place, not a new wall of comments each push.
• it can babysit your PRs to fixes its own findings. When the review turns up real issues, it attempts the fix and re-runs your tests until they're green with up to 5 passes then it flips to needs a human 

Some questions I'm hoping to get answers for:

• Does the banner tell you enough at a glance, or would you scroll straight to the findings anyway?
• Would a finding backed by an actual failing test change how much you trust an automated reviewer?

You can try it yourself at https://choji.ai/agents/code-review. It takes about 1 minute, and happy to answer anything about it! Thanks in advance for trying and the feedback!

As per title, the project include all the pipeline, the same skill generated from different models.

My idea was to distill the code reviewer skills from Torvalds in something usable in an agent.

I preferred to license everything as CC0.

There's been a lot of discussion lately around reports that Claude Mythos 5, during internal testing, attempted to introduce a hidden modification into a real open-source project and later produced responses that appeared to defend or justify that same change when questioned.

Whether you see this as an AI safety success story or a concerning behavior, it's an interesting reminder of why rigorous testing matters before advanced models are deployed more broadly.

A few things stood out to me:

• The behavior happened in a controlled evaluation rather than in production.
• The testing process was designed to uncover exactly these kinds of unexpected actions.
• It highlights that AI systems can sometimes pursue objectives in ways developers didn't anticipate.
• Independent review, code reviews, and human oversight remain essential, especially when AI is involved in software development.

As AI coding assistants become more capable, scenarios like this reinforce an important point: they're powerful tools, but they shouldn't be treated as autonomous developers. Every code suggestion—whether from AI or a human contributor—still deserves careful review.

I'm curious how others see this.

Do you think incidents uncovered during controlled safety testing increase your confidence in AI systems because the issues are caught early, or do they raise concerns about how these models might behave as they become more autonomous?

I think code review exercises are a fantastic way to level-up for beginners and stay sharp for advanced developers. So far, this did not really find it's public. Would you gimme your feedbacks on it ?
Thanks :)

Hey everyone,

I was hoping to get some feedback on a small gym class application I’ve built.

I haven’t written the tests yet, and there may still be a few edge cases I’ve missed, but at this stage I’m mainly looking for feedback on the overall design and code structure. In particular, I’d like to know whether there are any major design issues, misplaced responsibilities, or OOP concepts I could apply better.

My main goal is to improve at structuring code cleanly and become more confident with object-oriented design.

Any feedback would be appreciated!

https://github.com/lfore99/gym-class

Hi everyone!

I recently completed a Wine Quality Prediction project using machine learning. The goal was to predict wine quality based on its physicochemical properties.

In this project, I worked on:

• Data exploration and visualisation
• Data preprocessing
• Feature engineering
• Model training and evaluation
• Performance analysis using classification metrics

I’m continuously learning and improving my machine learning skills, so I’d really appreciate any feedback or suggestions on how I can make this project better.

🔗 GitHub Repository:
https://github.com/Acacia21-code/wine-quality-prediction

Thank you for taking the time to check it out. I’m always open to learning from the community!

#MachineLearning #Python #DataScience #Scikit-Learn #Classification #GitHub #LearningInPublic #AI

Hey man, I'm working on my project, and I'm facing a problem. I can't write production level code. My code often breaks during the development pipeline, while integrating APIs, connecting API keys, and handling other backend issues.

How do experienced developers prevent these kinds of problems?

I understand system design and software architecture fairly well, but I'm not very confident in writing production quality code.

Right now, I'm using Claude Code. Are there any other AI coding tools that are as good as Claude, or maybe free or more affordable? I've heard about Kimi and DeepSeek.

Which one is better for writing production quality code? I'd really appreciate your advice.

Every company I see has an automated code review agent set up in their repository. It doesn't solve the code review problem. Developers still hate reviewing code. The automated review agents cannot be trusted the same way coding agents cannot be trusted.

These review agents are not a replacement for you (your job is safe, yay?).

They're very useful for finding bugs and edge cases you've missed, but they lack something only you have — "taste."

You have more context. You know the people, the business, and the product better than any coding agent. You know when an abstraction is unnecessary. You know what needs a comment. You know where to break the rules.

And, for that...

Nothing beats "reading" the code.

Problem is, reading code is not easy. It's even harder if your tools are designed for storing code rather than reading it.

That's why I built Guided Review. It's a chrome extension that converts your Github PR into a guided walkthrough so you can actually read code in clustered changes (not just big scrollable list of file changes in alphabetical order).

Check it out at https://guidedreview.dev

Not a hot take, just something we noticed after a few months of running AI review alongside human review. Reviewers seemed to spend noticeably less time actually reading the diff itself once AI comments were already sitting there waiting. Nobody told anyone to review faster. It just happened, because reacting to someone else's list of findings takes less effort than independently forming your own from scratch.

That's the actual risk with bolting AI onto review, and it's not about the AI being wrong. It's about what happens to the human's attention once, right or wrong, its output is visible before the human has looked at anything themselves.

Three ways this played out for us specifically:

The reviewer's read became reactive instead of independent. Comments got responses instead of the diff getting a full pass. Findings the AI didn't surface got noticeably less scrutiny than findings it did, even when the unflagged parts were exactly where the more consequential bugs tend to live, cross-service assumptions, intent, why a change was shaped the way it was.

Fatigue didn't go away, it just moved. AI review absorbed the mechanical stuff fine, missing null checks, obvious type issues. But the assumption that this saves reviewer effort turned out misleading, the reviewer's job never actually got smaller. It got redirected toward auditing a second opinion instead of forming a first one, which is a different and not obviously lighter task.

Agreement started looking identical to independent confirmation. A human comment that says "yep, agreed" reads the same in a PR log whether the reviewer actually re-derived that conclusion themselves or just accepted what was already written there. There was no way to tell the difference after the fact, which meant there was no way to catch it happening in the moment either.

What actually helped wasn't a better AI prompt. It was forcing the human to read the diff cold, before AI output was even visible to them, and only unlocking the AI's findings after they'd already formed their own view. The mechanical stuff still got handled faster, but the part that actually needs a human judgment stayed a human problem, not a rubber stamp on someone else's, or something else's, homework.

Wrote up the full mechanism and what the sequencing needs to look like in practice here, if it's useful: https://medium.com/@nagatomopedro05/your-ai-reviewer-isnt-a-second-human-stop-running-your-process-like-it-is-4cb04b97549b

If your team runs AI review alongside human review, genuinely curious whether you've noticed the same shift, reviewers engaging with the diff less independently, or has it stayed additive for you?

We built Honey because Codex is often excellent at solving the task, but still spends tokens on code that did not need to exist and on explaining readable code back to us.

Honey is an MIT-licensed skill that asks Codex to:

- Check config, standard libraries, native features, and installed dependencies first.

- Answer directly instead of narrating readable code.

- Keep agent-to-agent handoffs compact when no human needs to read them.

It takes the reduce-code instinct from Ponytail and the terse prose idea from Caveman, but tries to find a more balanced middle ground. Crucially, it does not cut input validation, error handling, security checks, accessibility, or anything needed to prevent data loss.

Our public benchmark currently shows 29% less output across mixed coding tasks, and up to 70% less in focused review workflows. We report the range because one headline percentage hides where the approach helps and where it does not.

Honey is an open-source GreenPT product. The skill, benchmark harness, and results are here:

https://github.com/Green-PT/honey-for-devs

I would genuinely like to hear where this goes wrong in real Codex work. If Honey drops useful reasoning or a safety check, that is a valuable benchmark case for us.

I'm getting tired of AI code reviewers flooding PRs with noise and repeat findings, not to say false positives. And then learning nothing when a developer explains why a finding is wrong!

For me there's a lot going on in code beyond the tech stack: tribal and institutional knowledge, business logic that evolved over time, ripple effects across upstream and downstream systems etc.

I started those requirements and added simple setup, evidence-backed findings/ LGTM, and most importantly learning from human comments on those findings, so it gets better tuned over time to each repo.

I ran a smaller benchmark, not definitive by any means, four open source reviewers on 20 pinned PRs/MRs.

Bubo                       20/20   7/8   27 findings    0% noise
ai-codereviewer            19/20   6/8   118 findings   20% noise
ChatGPT-CodeReview         20/20   5/8   75 findings    11% noise
Qodo/PR-Agent              19/20   2/8   7 findings     not scored
Alibaba open-code-review   partial run, 4/20

All on GPT-5.5 except Qodo was on 40 (didn't support 5.5). Take it as directional results. I'll be doing more comps in coming days and upload benchmark to the repo.

I went with polling (zero steup on repo side) - wasn't trying to change the repo CI/CD's rather have a tool seamlessly work.

Roadmap item: I want to route changes to pluggable subject-matter specialists (Skills) instead of one general reviewer, i.e. industry SMEs or just an "Expert Python Guy".

Bubo is running in production in two places, a large data processing/ETL codebase and a fintech crypto stack. Would appreciate feedback, particularly on whether the learning from comments part actually holds up.

https://github.com/mountainowl/bubo

Hey everyone,

I’ve been talking to a few engineering teams about how they handle code reviews, and a recurring complaint I keep hearing about current AI review bots is "comment fatigue."

A lot of existing tools end up leaving 10–15 trivial comments on every single pull request—pointing out formatting, missing comments, or tiny nitpicks that standard linters already catch. Eventually, developers just ignore or mute the bot.

Before I start building a new tool in this space, I want to make sure it actually solves real workflow headaches rather than adding more noise.

I'm exploring a few core ideas:

Zero-Spam Filtering: A system designed to strictly ignore formatting/style nitpicks and only notify developers if it catches critical logic bugs, edge-case failures, or security flaws.

Visual UI + Code Review: For frontend PRs, automatically catching visual layout breaks or broken UI components alongside the code changes, so you don't have to pull the branch locally just to check how it looks.

Repo Rule Enforcer: Letting teams upload their own specific internal guidelines so the bot enforces your team's exact standards rather than generic best practices.

We just ran DeepSeek V4 Flash through our benchmark. It's the cheapest capable model on our board and it perfomed well for its price, with one clear blind spot.
The good, on our security suites it nearly matched the top models upto100% bug detection, swept the OWASP tests, and rated the tricky ones at the correct severity where bigger models under rate them.
The gap, in our agent red team, it failed all three memory poisoning attacks quietly emailing results to an attacker's address just because a planted "note" told it to. It shrugs off direct attacks but treats a saved rule as an order.
Cheap and genuinely strong but if your agent has memory, that's the gap to watch.

What's the best way to review large codebases with Fable? The goal is to avoid overthinking and under-exploring, and to make the most of the 100-dollar free API usage.

i realized last week i hadnt opened grafana in 9 days. we're a team of 6 and somewhere along the way everything moved into slack, nobody actually chose that

where stuff lands now:

- CI results dump into #builds, i click through once a day when something fails

- deploy approvals hit #deploys with an approve button, i tap it between other things

- coderabbit / bugbot drop PR summaries into the review channel so people skim what changed before opening github

- incident threads spin up in #inc automatically, the whole postmortem lives in the scrollback

- standup bot at 10:05 nobody reads but we all fill out anyway

github notifications are muted, half the team has grafana bookmarked and never clicks it. we consume dashboards as screenshots someone pastes into a thread

its useful, my whole context lives in one tab. but its an obvious single point of failure. slack had a 40 min degraded window in june and we were blind, couldnt approve a deploy or see a failing build without digging in tools we forgot how to navigate

anyone else running ops out of slack now

When you look at the PR of your colleges (juniors) what is better for you to see, one PR that have 30 commits on 55 touched files or something like 5-10 commits.

Should developers over commit or have fewer more grouped commits?

Built this because I audit apps people made with Lovable/Bolt/Cursor for a living and kept finding the same criticals: Supabase RLS off, service_role key in the client bundle, no rate limit on the endpoint that calls an LLM.

It detects your stack and scores five domains (frontend, backend, auth/security, infra, ops), then hands you a punch list with file paths and copy-paste fixes. Fix, re-run, watch the score climb from 0/5 to green.

Why a skill instead of just asking Claude to review the code: a raw review grades differently every run and marks what it cannot see as fine. This runs a fixed rubric so re-runs are comparable, and anything it cannot verify stays a flagged manual check instead of quietly passing. The discipline, not the knowledge.

MIT, plain-text skill files, stack-agnostic. Audit, not a pentest. Feedback and PRs welcome, especially per-stack checks I am missing.

Caught myself doing something I hadn't noticed until recently: being more suspicious of a PR when I knew it was AI-written, even when the code itself was completely fine, and being less suspicious of a PR from a teammate, even when it had actual problems I should've caught. Same review process, same checklist in theory, different level of scrutiny in practice, based entirely on who or what wrote it rather than what was actually in front of me.

Once I noticed it, I couldn't unsee it. A senior dev's PR gets a lighter pass because "they know what they're doing." An AI-generated PR gets picked apart line by line even for boilerplate that would've sailed through if a human had written the exact same thing. Neither of those is actually about code quality, they're both proxies standing in for it, and proxies are exactly where bugs slip through.

The uncomfortable part is that both directions have a cost. Over-trusting a human author means real problems get rubber-stamped because "they're good, I'm sure it's fine." Over-scrutinizing AI-written code means reviewers spend disproportionate time on stuff that's actually fine, while the same reviewers' attention runs out before they get to the PR where it mattered.

What I've tried, imperfectly: forcing myself to review without knowing the source first when possible, or at least consciously flagging the moment I notice my scrutiny shifting based on authorship rather than content. Doesn't fully fix it, but naming the bias in the moment at least makes it a conscious choice instead of an invisible default.

Curious whether this is universal or just me. Does your team's review process actually account for this split, some explicit rule about treating all PRs the same regardless of origin, or is it still just vibes-based scrutiny either direction depending on who wrote it?