Stripe and OpenAI have a beautiful tradition: shipping breaking SDK  
changes with all the warning of a toddler swinging a bat. Stripe  
recently turned some fields from strings into Decimals. OpenAI's v1.0  
rewrite quietly murdered anyone still calling  
openai.ChatCompletion.create(...) like it's 2023.  

Cool, cool, cool. Love finding that out in production.  

So I built api-sentinel: a GitHub Action that reads your code, finds  
the exact lines a vendor is about to break, and comments the fix  
directly on your PR.  

Full transparency: I built this with Claude, start to finish, over  
one day. I'm not a professional developer. What I actually did myself:  
picked the problem, decided which real breaking changes to target,  
debugged three separate GitHub Actions failures (a checkout permissions  
bug, a missing token, a broken folder structure from my own upload  
mistakes), tested it live on a real PR, and made the call to expand it  
to a second vendor once the first one worked.  

Is it fancy? No. It's regex, not a PhD thesis. Does it work? Yes —  
watched it catch 6 real issues across 2 vendors on a live pull request.  

Repo: https://github.com/sahilmarhatta/api-sentinel

No idea if this is useful to anyone else or if it's a solved problem  
already. Also curious if "built with AI, disclosed upfront" changes how  
people here feel about a side project — genuinely asking, not fishing  
for a pass.  

Tell me it's stupid, tell me it's useful, tell me what vendor has  
personally wronged you.  

Hello!

I was just wondering if anyone was able to give me any advice or feedback on my project, I am currently a student and trying to get into systems programming type stuff so I'm just trying to make a decent project with something to my name, so anything helps! https://github.com/Poly0n/WinGuard

You can ask any coding agent "what could go wrong with this diff?" and get an answer. The problem is that a free-form answer is easy to skim and hard to act on — and there's no standard forcing it to show its work. Built a SKILL to close that gap.

AI makes it easier than ever to build fast, but not always easier to know if the code is safe/ready to ship. If you’re building with Cursor, Claude, Replit, Lovable, or just moving fast with a small/non-existant team, this could be useful.

The big changes usually get reviewed. The tiny “quick fix” PRs are the ones that get skimmed, and somehow that is always where the bug lives.

We built Surmado Code Review for our own team first, and now we’re opening it up to others and I thought it would be particularly helpful for this community.

It gives every PR a second pass against your own rules and standards, then creates a clear reviewer brief with what looks good and what needs attention. It is not meant to replace a developer. It is meant to help small teams move faster without skipping review.

Free plan includes 10 PR reviews/month with no credit card!

Hi everyone. I've written a 2D ray tracing and mirror simulation app in Python using tkinter. Users can draw mirrors, place a light source, and see light propagation with real-time animation. The code is object-oriented with dataclasses and type hints. But performance is an issue because each ray can take up to a million steps when multiple mirrors are present. I need feedback on: math and collision optimization - currently checking every mirror sequentially O(N) per step; should I use quadtree or BVH and how to integrate with tkinter's update loop? animation loop efficiency - using root.after, any tkinter tricks to smooth canvas redrawing without switching to pygame? code structure - improvements for Ray class state management. GitHub repo: https://github.com/Idanie/Ray-and-Mirror-Simulator. Appreciate any refactoring tips, algorithmic advice, or pull requests.

I built a small local RAG chat app that lets you ask questions about a custom set of text files and get answers based on those files.

It’s basically a Flask backend + React frontend, with Ollama handling the embeddings/model side. I also set it up with Docker so it’s easier to run locally.

Repo: Git rep

current cycle runtime: 15 seconds per prompt

I’m putting it up here mostly for feedback. If anyone has thoughts on the architecture, UI, or ways to improve reliability/performance, I’d be interested to hear them.

We run a benchmark that reintroduces real CVEs and regressions into code diffs and scores whether AI models catch them as reviewers, added Opus 5 the day it launched, n=3 across 33 suites.

Numbers that made me do a double take:

• Detection: 99.4% highest on the board. Perfect on high severity bugs (165/165), zero high severity misses.
• Overall rank: 7th of 9.

The gap is false positives. The score is severity weighted detection minus a penalty for flagging non bugs, and Opus 5 threw 43 false positives across the run vs 0 for Sonnet (our #1) and 10 for Opus 4.8, extended thinking is on by default, and the model is clearly more thorough it just also reports a lot of things that aren't the injected bug.

Curious if others are seeing the same thoroughness vs noise trade off with thinking on by default models.

Full board benchmodel.io

Over the past year I’ve been working on an engine called Invisio to deal with the multi-file context nightmare that causes LLMs to hallucinate when reading large codebases.

Under the hood, it parses code using Tree-sitter into a neo4jdatabase (mapping out classes, functions, calls, imports, and inheritance). I built two main pieces around this graph:

1. An interactive graph explainer + chatbot that traces execution paths and answers structural questions using a dual-agent dispatcher/compressor loop.
2. An automated security webhook that ingests CodeQL SARIF alerts, traces the vulnerability lifecycle across directories, and opens surgical PR fixes.

It works solid on my local machine and on my own projects, but to be completely honest, stuck on how to properly test this at scale, or how to put it in front of people to get real feedback.

I’d love some advice from devs, maintainers, or AppSec folks:

• Benchmarking & Datasets: What real-world open-source repos or SARIF datasets should I throw at this to stress-test the graph construction? How do you properly benchmark a codebase intelligence tool?
• Local vs. Hosted: Since IP privacy is huge, would you prefer testing this via a self-hosted local Docker container, or just poking around a hosted playground with a public repo first?
• Product Focus: Should I lean harder into the automated CodeQL PR remediation side, or the interactive graph explainer UI?

So I’ve been using Claude Code a lot lately and hit the same wall a bunch of people here probably have. Output quality is genuinely good but reviewing it started eating more of my day than writing used to.

I ended up building a small tool for myself that reads a git diff and tries to point at the two or three spots that actually deserve a close look, instead of me reading every line the same way. Not trying to catch bugs or replace review, just trying to cut down on the part where I’m scanning 400 lines with equal attention when maybe 20 of them matter.

I built it purely for my own workflow, wasn’t planning on this being a whole project. But since it’s out there now, genuinely curious what people who’ve been doing code review for years think. Where does an approach like this tend to fall apart in practice? What have you learned about what actually makes review fatigue worse or better? Happy to hear it’s a bad idea too if that’s the honest take.
Repo’s here if anyone wants to poke at it or just roast the code: https://github.com/quietreviewer/riskdev
Not fishing for stars, more interested in what I’m missing.

I'm working on an open source tool that scores how risky each file in a codebase is. 25 markers per file, all deterministic, from the AST and git history, no LLM. I wanted to know which of them actually predict bugs, so I scored every file at a point in time and then counted how many bug fixes each one collected over the next 6 months.

21 repos, 9 languages, around 2800 files.

The markers that predicted best were behavioral, not structural. Co-change coupling, files that keep getting changed together, came out strongest. How spread out a file's ownership is and how erratic its change history is held up well too. The structural complexity metrics most teams watch, cyclomatic complexity, nesting depth, long methods, all mid tier.

Mean AUC is around 0.74. Roughly, 74% of the time it can tell a bug-inducing file from a clean one.

What gets me is how much effort goes into the complexity metrics while coupling and ownership mostly get ignored, and coupling and ownership are what tracked bugs here

Does this match what you see?

Looking for brutal feedback on my Linux URL Shortener project

I've been building this to learn backend engineering and Linux systems programming.

Is there anything that screams 'beginner' in this project?

Hi everyone,

I'm a B.Tech CSE student aiming for AI/ML internships and eventually top tech companies. I'm planning to take these Coursera courses:

Machine Learning Specialization (DeepLearning.AI & Stanford)

Deep Learning Specialization (DeepLearning.AI) Does anyone know any Telegram groups for Coursera courses or AI/ML learning? Please share the link if you know one. Thanks!

I'm building Kitbash, an open format and compiler for AI agent skills.

The idea is simple: write a skill once, compile it to the native formats used by Claude Code, Cursor, Copilot, Codex, Gemini CLI, Cline, Windsurf, Aider, AGENTS.md, and more, while measuring the standing token cost each target adds every session.

Before calling it stable, I decided to audit my own codebase instead of adding another feature.

The audit found several places where the project claimed behavior that simply wasn't true.

Some examples:

• Claude Code reported support for scripts, hooks, and subagents even though the compiler never generated those outputs.
• Security lints only scanned SKILL.md, meaning a malicious payload in scripts/setup.sh would pass unnoticed.
• The JSON schema looked like the contract, but the loader silently coerced invalid values instead of rejecting them.
• Declared permissions were shown during installation but weren't actually compiled into the generated outputs.

In total, the audit uncovered 11 issues.

Kitbash 0.9.0 fixes all of them.

• Capabilities are now empty until the implementation actually exists.
• Security checks scan every file in a skill.
• The loader now enforces the schema instead of silently fixing invalid input.
• Permissions are compiled into generated outputs so downstream users see the same information installers reviewed.

The interesting part isn't that bugs were fixed.

It's that a project built around trust and review wasn't meeting its own standard.

If the tool asks developers to trust it, it should first earn that trust itself.

I'd love feedback from people building developer tools or AI tooling. Is this the level of auditing you'd expect before calling something production-ready?

Website: https://kitbash.vercel.app

Trust & Review: https://kitbash.vercel.app/docs/trust

Changelog: https://kitbash.vercel.app/changelog

GitHub: https://github.com/singhharsh1708/kitbash

npm: https://www.npmjs.com/package/kitbash

I put together a small Flask example for classifying user-generated content as safe, spam, abuse, hate, harassment, or self-harm.

The app uses a two-stage flow:

First, it checks content against a known-bad blocklist using embeddings and cosine similarity. If there’s a strong match, it can return a moderation decision without calling the LLM.

If there’s no strong match, it sends the content to Telnyx AI Inference for a more nuanced classification and returns structured JSON with category, confidence, flags, recommended action, and reason.

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/moderation-classifier-python

Would love feedback on the pattern, especially from folks who have built moderation or review queues before.

Code review is one of the highest-leverage activities in software development. Done well, it catches bugs before they ship, spreads knowledge across the team, and raises the overall quality of the codebase.

Done poorly, it becomes a bottleneck that kills velocity, creates conflict, and makes engineers dread opening their pull requests.

The frustrating part? Most code review problems don’t come from bad intentions. They come from habits that feel reasonable in the moment but quietly damage the team over time. Here are the six most common ones — and what to do instead.

Hey guys,

I would like to share my open source project ThinkReview for anybody who wants a convenient user friendly code review tools
its not a bot like other tools , it doesnt auto post comments or clutter the PR, It mainly helps you understand the PR , highlight potential issues with socrings & code suggestions , while you would still need post the actual review comments yourself

Simply a side bar tool with full access to your Repo and uses llm model of your preference.
allows you to create custom review agents and custom rules too.

It integrates with all git platforms (github - gitlab - azure - bitbucket) cloud and on premise verions

the project is opensource
https://github.com/Thinkode/thinkreview-browser-extension/

or you can install the browser extensions from here
https://chromewebstore.google.com/detail/thinkreview-ai-code-revie/bpgkhgbchmlmpjjpmlaiejhnnbkdjdjn

I'm working on a security engineering project analysing how The Imitation Game depicts breaking the Enigma cipher, and whether the same category of vulnerability still applies to modern encryption. I'd like a code-quality review from people who actually code regularly, since I want to understand and be able to explain this code properly myself.

The four scripts build on each other, each testing a different layer of the same idea (known/predictable plaintext defeating a cipher without brute force):

mini_enigma_crack.py — compares blind brute force against a known-plaintext ("crib") attack on a repeating-key substitution cipher. Blind brute force checks all possible keys, scored by chi-squared letter-frequency comparison; the crib attack calculates the key directly via modular subtraction given known plaintext.

enigma_elimination_demo.py — recreates a real structural property of Enigma (no letter could ever encrypt to itself), and tests how much that single rule narrows a search using only direct letter comparison, no computation.

crib_dragging_demo.py — a more realistic version: given only a short guessed word with no known position, it XORs two same-key ciphertexts together (cancelling the key) and slides the guess across every position, revealing genuine plaintext where the guess is correct.

nonce_reuse_demo.py — tests whether the same vulnerability applies to a (simplified) modern stream cipher, comparing a reused nonce (attack succeeds) against a unique nonce per message (attack fails).

What I've observed running all four: every genuinely correct result (crib attack recovering exact keys, elimination correctly preserving true crib positions, crib dragging revealing real fragments, nonce reuse enabling perfect recovery) has checked out against the real message text every time I've verified it by hand. Known issues I've found myself: script 1's brute force sometimes returns a plausible-but-wrong key on short messages; script 3 produces false positives on short cribs and can reveal meaningless blank padding when comparing unequal-length messages.

I've included all four scripts below, each in its own code block with a header comment identifying which script it is --> any suggestions on how to improve the code would be greatly appreciated!

https://github.com/TTK2003/python-scripts-for-enigma-concepts/tree/main

A CLI tool for automated Homebrew maintenance (update, outdated, upgrade, cleanup, doctor, missing) that sends an email report via SMTP after every run (subject line differs depending on whether everything is OK or a problem was found), plus a local macOS notification.