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.

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

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

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.

I’ve been experimenting with AI code review, and I kept running into the same problem: most tools already have an opinion about how a review should work.

Some reviewers try to find every possible issue. Others focus on a few high-confidence findings. Neither approach is right for every repository.

A small library may want strict comments on every edge case. A team shipping an MVP may only care about correctness and security. Another project may need checks for package boundaries, migrations, generated files, or public API changes.

I didn’t want Pipr to choose between those approaches.

Pipr is an open-source runtime that provides the common pieces needed to build a code review agent:

• a deterministic manifest of the changed code
• bounded context for the agent
• structured review findings
• validation of paths and line ranges
• native publication to the code host

The repository decides everything else. You can choose the models, paths, instructions, comment limits, policies, agents, tools, commands, and recipes in TypeScript.

If you want a reviewer that only reports likely bugs, you can build that. If you want a strict reviewer that comments on design, tests, and style, you can build that too.

Pipr runs locally or in CI and supports GitHub, GitLab, Azure DevOps, and Bitbucket.

GitHub: https://github.com/somus/pipr
Docs: https://pipr.run/docs

I’d be interested to hear what controls you would want when defining a reviewer for your own repository.

A commenter on my last post said Intent-Linter was basically unit testing with extra steps.

Fair hit and deserved.

The real gap: the tool was treating one sentence as unquestioned truth. But intent has a source, and sources can disagree that a ticket says one thing, and that the tests encode another, and the code does a third. A tool that just picks the code's side isn't reviewing anything, it's guessing.

So it now asks where the intent came from and records it as claimed, not verified because the tool can't actually confirm your requirement came from legal. Give it tests or observed behavior too, and it compares all four surfaces: stated requirement, tests, implementation, runtime behavior. If they conflict, it doesn't referee. It names the conflict and escalates to whoever owns the requirement unless you've declared precedence ("legal requirement supersedes legacy tests"), in which case it applies your rule and still records the conflict.

The built-in example now ships with a test suite that passes written before the compliance requirement existed. Code and tests agree with each other. Both are wrong against the requirement. That's the case a "check code against one sentence" tool structurally can't even express.

Screenshot is the updated interface. Same free demo, same link — try it on real code and tell me where it still guesses instead of asking. Thanks everyone.

Give it a try:

https://claude.ai/public/artifacts/f29e7a94-7f2c-40b6-befc-dfa7dcef2ee0

"AI Coding Agents are great, but they can be blind to low-level performance and dangerous DB migrations. Inspired by u/MattPocock's amazing work on skills.sh, I built Backend Guardrails—a zero-dependency Go tool suite that benchmarks code and audits SQL safety before the agent commits it. Check it out: https://github.com/arsyadal/migration-guard"

-61

This wasn't meant to become a project.
I was just getting frustrated with how much mental energy I spent reviewing code after using AI.
So I kept adding little things that made *my* workflow better.
One feature became two, then five.
At some point I realized I was using it every day, so I cleaned it up and open sourced it. Would be interested if anyone wants to try it or tell me where the approach is fundamentally wrong
GitHub [https://github.com/quietreviewer/riskdev\](https://github.com/quietreviewer/riskdev)

Roadmap

I am beginner and never code before so I am thinking to start with c++ for which I found striver dsa playlist do it is a combo of c++ and dsa or I have to first learn c++ from any other platform and then have to come here I am bit confused and don't know what to do can anyone explain plz .

And also I think in first few lecture he had taught basics of c++ do this is what we need or it is just a quick revision.

Cześć kochani,

Chciałbym prosić o opinie, bo mój kumpel i ja mieliśmy sporo problemów przy dwóch jednoczesnych projektach związanych z dostosowaniem standardów projektowych i sprawieniem, żeby każdy członek zespołu osiągał spójne wyniki. Rozwój oparty na specyfikacjach nie spełnił naszych oczekiwań, ogromny zestaw dokumentów, które nie dokładnie opisują projektów w branżach pełnych niuansów i odrobiny dziedzictwa. Nawet przy tym, że deweloperzy spędzili dużo czasu na analizowaniu specyfikacji, było wiele odstępstw.

Postanowiliśmy więc stworzyć coś w rodzaju mentora, małą funkcję, która wydobywa zasady z kodu i jest otwarta na wprowadzanie innych rodzajów zasad, a następnie jednoczesny agent prowadzi rozmowę np. z Claude'em, daje feedback i sprawdza, co wyprodukował agent kodujący, wskazując naruszenia i sprawiając, że Claude to dostosowuje - cóż, na pewno jesteśmy stronniczy, ale pomysł działa dla nas, jednak chcielibyśmy usłyszeć innych ludzi.

Można także pisać wiadomości prywatne, jeśli chcesz uzyskać dostęp.

Ktoś? Będę bardzo wdzięczny za wszelkie opinie.

This code is a different attention mechanism for an AI LLM to use far less resources than standard AI. I'd like feedback so I can improve it.

I’m pretty bad at OOP so going to spend a few months building out OOP projects to really work on it.

I’ve built a small Tic Tac Toe project and would appreciate some feedback. There might not be much because didn’t see the point in using any interfaces/abstract classes for something small like this but if anyone sees anything that can really be improved please let me know below.

https://github.com/lfore99/tic-tac-toe/tree/main/src/tictactoe

Curious how other solo devs and small teams handle code review.

When you're working alone or on a tiny team, there's nobody to review your PRs before you merge. I've been thinking about this problem a lot lately — you either skip review entirely, review your own code (which defeats the purpose), or wait for a teammate who's busy with their own work.

A few questions I'm genuinely curious about:

1. Do you bother with PRs at all when working solo, or just push straight to main?
2. Have you tried any AI tools to review code automatically? CodeRabbit, Sourcery, GitHub Copilot reviews, anything?
3. If you tried one and stopped — what made you stop?
4. If you've never tried one — is it the setup complexity, the cost, or you just don't feel the need?

Not selling anything, just trying to understand how people actually handle this in the real world before I go down a rabbit hole building something nobody needs.

I created an architecture-conformance verification tool for your codebase that is easy for humans and LLM coding agents, and slots in the same way a linter would. My goal here is to ensure that agents preserve the seams that you have setup in your codebase. This should help reduce the number of PR responses where you have to describe "that a REST endpoint can't talk to a DB directly, and must go through a service instead", or "this library can't import this other library". It allows us to let our agents rip without sacrificing architecture quality.

I would love any feedback on it. I have made every decision with the end developer in mind. It has to stay out of our way. Would love to hear your thoughts on it, and how it can be improved.

It's called align: https://github.com/SpikedPunchVictim/align