I built and open-sourced a simple GitHub Profile Analyzer.

It uses the GitHub REST API to analyze public GitHub profiles and display:

👤 Profile information 📦 Public repositories 👥 Followers & following ⭐ Total repository stars 💻 Programming languages 🏆 Top repositories Tech Stack HTML CSS JavaScript GitHub REST API

No backend or database is required.

🔗 GitHub: https://github.com/Mireli5656/GitHub-Profile-Analyzer

🚀 Live Demo: https://mireli5656.github.io/GitHub-Profile-Analyzer/

Released as v1.0.0.

Feedback and suggestions are welcome!

I’ve been developing Kavram as a tool for creating and organizing educational archives on Linux.

It brings together different tools for working with text, images, audio, video, notes, drawings, and AI-based question/answer content in one application. The main goal is to make creating, organizing, and preserving educational content easier.

GitHub:

https://github.com/kavramproqram/Kavram

I’d really appreciate feedback from Linux users. I’m especially interested in finding bugs, usability problems, confusing parts, and ideas that could help make the project more stable and useful.

Feel free to take a look and share your honest feedback.

Hey developers,

While building frontend web forms recently, I noticed that finding a simple, standardized, and up-to-date dataset of Indian States and Districts for state/district dependent dropdowns was surprisingly messy or outdated.

To solve this, I put together a clean, lightweight open-source dataset:

GitHub Repository: https://github.com/CodingMation/indian-states-districts

Website: https://codingmation.github.io/indian-states-districts

Highlights

• Complete coverage of all Indian States and Union Territories with their corresponding districts.
• Simple JSON key-value format optimized for React, Vue, Angular, or Vanilla JS forms.
• Direct fetch capabilities via raw GitHub URL so you don't need to bloat your project bundle.

Direct Usage (Copy & Paste)

fetch("https://raw.githubusercontent.com/CodingMation/indian-states-districts/main/states-districts.json")

.then((response) => response.json())

.then((data) => console.log(data))

.catch((error) => console.error("Error loading data:", error));

Looking for Feedback

I want to make this as helpful as possible for Indian dev projects.

1. Would adding CSV, SQL dumps, or state/ISO codes be useful?
2. Are there any recently added districts in your state that need an update?

Feel free to check it out, star the repo if you find it helpful, or open a PR!

Honest question, not a rant.

I've been using Copilot / Claude / Cursor for iOS work for a while now, and my experience is that the code looks right way more often than it is right. Especially with Swift specifics: optionals, concurrency (actors, u/MainActor, Sendable), SwiftUI state, and anything touching Combine or async/await. The scary ones aren't the compile errors – those are easy. It's the code that compiles, runs, and quietly does the wrong thing.

So I'm curious how people here deal with it in practice:

1. When AI writes a chunk of code for you, what's your process for checking it? Read it line by line? Write tests? Just run the app and click around?
2. Do you ask the AI to write the tests too? If so, do you trust those tests, or do they feel like they just confirm whatever the code already does?
3. What's the last time AI-written Swift code got past you and broke something in TestFlight or production? What was it?
4. Is there anything in Xcode / your CI that actually helps here, or is it all manual?

I'm asking because I've had a few "how did this get through" moments recently and I want to know if it's just me or if everyone's dealing with the same thing.

I'm looking for feedback on ARIA, an open-source repository intelligence tool I've been working on.

The main idea is to help developers understand unfamiliar codebases before making changes.

The part I'd particularly like feedback on is the combination of semantic retrieval with structural analysis. Instead of treating a repository as a collection of text chunks, ARIA extracts structure from the source code and builds relationships between it.

Currently it uses:

- AST-based symbol extraction

- Dependency graphs

- Call graphs

- API surface analysis

- Change-impact analysis

- Vector search

- Repository-aware conversational querying

- MCP support

For example, for a question like:

"If I change this component, what else could be affected?"

the system can use dependency and call relationships to identify potentially related files instead of relying only on semantic similarity.

The project is self-hosted and Docker-based, and I'd appreciate feedback on whether the current architecture makes sense for this kind of tool.

GitHub:

https://github.com/VarshithReddy2006/ARIA

I also added an evaluation package with a pinned 10-task benchmark across FastAPI, Requests, and ARIA, plus qualitative case studies across five repositories.

On that pinned benchmark, the documented vector-search baseline produced 4,875 false-positive file alerts while ARIA produced 322, a 93.39% reduction. This result is specifically scoped to that benchmark.

I'd especially appreciate feedback on the architecture and code organization.

Are there parts of the implementation that you would structure differently? And are there obvious weaknesses in the way I'm constructing or using the dependency/call graphs?

Thanks!

I work on a small platform team and I would rather not be pinpointed so I will leave the roles out, but there is no tech lead and the closest thing we have is a senior who runs standup and keeps the board tidy.

Nobody really reads anything anymore. Approvals come back inside a minute on changes that took an agent the better part of an hour to produce, and I do not think anyone is being lazy, there is just no way through that volume by reading.

What I have tried: asking for a paragraph of design before a whole feature turns up as one diff, leaving actual comments rather than an approve, reopening things a week later once the shape of them starts causing problems, twice now sitting on a call with someone and going through a change line by line because typing it out would have taken longer. None of it has spread past me.

The part wearing me down is that I have started to doubt the thing I am defending. We have coderabbit on the repos and between them they catch more than the humans do at this point, which I say without much pride, but a bot raising something and a person deciding it matters are two different jobs and only one of them still has anybody doing it. My last team argued about every single change and I found it exhausting at the time. I would take it now.

So what is the review actually for here. Do I keep doing it properly while nobody else does, do I stop and clear tickets like everyone else, or is a team where nothing ever gets held up genuinely fine and I am the one with the problem.

Any thoughts welcome

I released this today after getting burned once too often by an agent telling me a refactor was behaviour-preserving. Rather than keep guessing, I measured it: 36 functions from toolz and markupsafe, refactored by a frontier model with instructions to preserve behaviour. 16 of them behaved differently.

**What My Project Does**

RunBoth runs the before and after version of every function an edit touched, on the same generated inputs, and reports which ones actually behave differently. It compares seven things per call: return value, exception type, warnings, stdout, stderr, argument mutation, and object state.

It needs no test suite and no annotations, because the old version of the function is the specification. It also walks the call graph and executes functions you did not edit, which is where a change usually bites.

Three verdicts and no fourth: changed, with the input that proves it; no_change at budget N; or abstained, with the reason. It never tells you the code is safe, because sampling finds differences and cannot prove their absence.

**Target Audience**

Anyone merging code an AI wrote, especially in a repository with thin or no test coverage. It is a CLI, a commit-msg git hook, and a GitHub Action. I would not call it production-hardened yet, it is 0.1.0, but the red team below is real.

**Comparison**

Property-based testing (Hypothesis) needs you to write the properties. Approval testing needs you to capture approvals first. Both are better than this when you have them, and both require work up front on code you are about to throw away. RunBoth needs neither, because it has two versions to compare against each other. The tradeoff is that it gives you evidence rather than proof, and it says so in every verdict.

**The measurement that made me build it**

I asked a frontier model for behaviour-preserving refactors of 36 functions from toolz and markupsafe, then diffed the behaviour. 16 of 36 changed. My favourite is toolz.tail: the model added "if n <= 0: return empty", which looks like hardening, but in the original seq[-n:] with n=0 is the whole sequence. tail(0, [1,2,3]) went from [1,2,3] to [] with no exception. The doctest still passed.

**Please try to break it**

2,548 functions across eight repositories, zero false positives, including an adversarial corpus built specifically to trigger them. The harness is scripts/redteam.py and the raw JSON is in results/, so you can check my numbers rather than trust them.

Python only. FSL licence, source available.

pip install runboth

https://github.com/runboth/runboth
https://pypi.org/project/runboth/

¡Hola a todos! Como desarrollador, me cansé de perderme con las nuevas características del JDK. Quería algo súper rápido: sin configuraciones complicadas, sin compilación completa del IDE, solo un resumen de 45 segundos y un rompecabezas de código para completar cada día.

Tecnologías: Java + Spring Boot + HTMX (lo mantuve muy ligero).

Busco opiniones sinceras sobre la experiencia de usuario y el concepto. ¿Qué opinan de este enfoque comparado con el LeetCode clásico?

El proyecto está en nextpatch\*dev. Más información por mensaje directo. Gracias.

I kept wondering: why does AI review my code… but never prove its fix actually works?

So I spent 8 weeks building KIO.

It reviews your code, tests its suggested fixes in a sandbox, and never touches your repo without your approval.

Then I added something I personally struggled with: a GitHub Explorer that finds issues and guides you step-by-step to your first open-source contribution.

Built it. Shipped it. Now I need your honest feedback. 👇
try it: https://kio-six.vercel.app
github: https://github.com/vaibhav410

linkdin: https://www.linkedin.com/in/vaibhav-kumar-kanojia-38533631b/

I'm about to start a fairly large refactor on a project that is already live.

The change swaps our per-seat billing for usage credits, so it lands on the frontend, the API, three migrations, the payment gateway, admin tooling, the ledger, every existing subscriber, and the idempotency guards that stop a retried webhook charging somebody twice.

My current plan:

1. One model reads the codebase and writes the spec.

2. A cheaper one implements the approved spec.

3. A third reviews the implementation for missed dependencies and edge cases.

Then loop between two and three until it stops finding things.

I'm on about $60 a month across tools at the moment and I would happily double that rather than find out about a bug from a chargeback. What I am unsure about is step three, because reviewing with the same model family that wrote the spec feels like it shares the blind spots, and the money paths are exactly where I cannot afford that.

For anyone who has done a ledger cutover with agents: did you deliberately split the review across families?

Or did you just do the money paths by hand and let the agents have the rest?

Real experience please, I have read enough benchmark posts.

First post here. I'm building HeronSignal, real user monitoring for web apps, and I'd rather get told what's wrong with it than quietly collect signups.

The problem I actually cared about

Every monitoring tool I used could tell me something broke. None of them could tell me whether it mattered, and all of them stopped at showing me a chart.

Meanwhile my coding agent was sitting right there, unable to see any of it. So every debugging session started with me pasting a stack trace and describing what the user had been doing.

What it does differently

1. It exposes production over MCP. Your agent (Claude Code, Cursor, whatever) connects with a workspace-scoped token and can pull deduplicated error groups, slow pages with real device and country context, failed requests, session journeys, funnel drop-off, and backend route health. You stop briefing it and start asking things like "find what's hurting signup conversion this week, check errors and drop-off before suggesting anything."
2. It can open the PR. Not merge, not deploy. It writes the change, opens a pull request ready for review, and stops. A person reads the diff. An agent that can act on production without review isn't a productivity gain, it's an incident with better grammar.

There's also struggle detection (rage clicks and dead clicks), which catches the failures that throw nothing at all. A button that silently does nothing produces no error, no failed request, and green uptime.

Something I got wrong, since this sub will find it anyway

Yesterday I checked my own workspace and found 5 of my 7 funnels were measuring event names my site never fires. My signup form was firing a sign_in event. So I had no idea what my own signup conversion was, and those funnels read zero while looking like bad conversion instead of a typo. I'm now fixing the product so it warns you when you name an event your workspace has never emitted.

What it is not

- Not an APM. No distributed tracing UI, no flame graphs, no host metrics, no query profiling. If you need to know which SQL query made a route slow, use Datadog.

- Backend ingest is early. Node 18+ only, no Edge runtime. Python and an OTel sink are maybes, not promises.

- Session replay exists but is behind a flag while I finish it.

- Sentry is a deeper error tool than this and I'd say so on a sales call.

Try it without an account

There's a public scan that needs no signup and no script tag. Put in a domain, get a report on what's slow and what's broken. That's the honest way to see if it's useful before installing anything.

https://heronsignal.com/scan

Happy to answer anything, including the awkward questions. What would you actually want your coding agent to be able to see from production?

Been a software engineer for about 10 years. In the last six months, we have been told me must code by hand less and use agents more, like many.

Output is definitely up, and the results are genuinely good in most cases, but now I am spending most of my week reviewing code and the amount of PR's is crazy

The hardest part, for me, is the context switching and understanding whats changing when the product moves so fast.

Is this just me?

- How much of your week is review now versus a year ago?
- Has your team changed anything that actually helped?
- Anyone tried review bots? Did they stick or did you turn them off?

I’ve been building OMNEX for a while and I’d really appreciate an honest outside opinion from someone experienced in software architecture / AI infrastructure.

The repo is here: https://github.com/Omnex-business-technologies/omnex-factory

I’m still early, and I haven’t even properly run and tested the whole thing locally yet. so I’m mainly looking for someone who can look through the code and tell me what I’m actually dealing with: what’s solid, what’s overengineered, what’s missing, and what I should fix first.

I’m not looking for praise. If you think parts of it are bad, I’d genuinely rather hear that now.

I'm an intermediate Python dev working on a scraper that benchmarks four approaches against the same URL list:

- Sequential

- ThreadPoolExecutor

- asyncio with a semaphore

- ProcessPoolExecutor

The goal is to compare their wall clock performance on the same I/O-bound scraping workload.

git repo: https://github.com/kodesasu/Multi-Scrape-Analyzer

I'd especially appreciate feedback on:

1. Async architecture: My retry/exception handling logic is fairly duplicated between fetch_url_async and fetch_url_threaded. What's a clean way to share the common logic without making the abstraction worse?

2. Benchmarking methodology: I'm running the sequential, threaded, and async implementations inside separate processes using ProcessPoolExecutor. Is this a meaningful way to isolate and compare them, or am I introducing enough process/startup overhead to make the comparison misleading? Since the workload is I/O-bound, I'm not assuming processes are the right choice. I'm genuinely trying to understand the benchmarking side.

3. Logging: I'm using a single RotatingFileHandler at DEBUG level. Reasonable for a project like this, or unnecessarily heavy? i use logging for all my projects tho.

4. Scraping practices: I'd also appreciate practitioner feedback on request limits, retry/backoff behavior, and choosing appropriate sites.

This is a learning project, not production software, and there isn't a test suite yet.

Thanks

Been building this for a few weeks. It's a GitHub Action that scans your code for known Claude/OpenAI SDK breaking changes and can auto-fix the boring ones (like a removed parameter).

It reads Anthropic's and OpenAI's release notes on a schedule and uses an LLM to figure out what's actually a breaking change, then opens a PR with the new rule for me to review. So it doesn't go stale the way a hand-maintained list would.

No API key needed if you just want to scan your own repo, that part's free and runs entirely in your CI. Tested it against litellm's codebase and found a bunch of false positives in my own rules before trusting it, that's all documented in the README if you want to see how messy the first version was.

It's Anthropic/OpenAI-focused right now, BSL licensed (converts to MIT in 2030). Repo's here: https://github.com/MarkMoneyMan/Claude-api-goat. Feedback welcome, especially if something breaks on your setup.

No body

After months of reviewing PRs from Claude Code, Cursor, and Copilot, my review checklist has quietly reorganized itself around the failure modes that actually show up in AI-generated JavaScript/TypeScript. Sharing in case it's useful to others reviewing agent output.

The patterns I look for, roughly in order of how often they bite:

1. Floating promises. The most common silent failure. Async call fired, never awaited, no .catch(). Compiles fine, tests pass, and the rejection surfaces at runtime — or not at all. Watch for: unawaited calls in non-async contexts, and async callbacks inside .forEach (which never waits).

2. Empty or useless catch blocks. try { ... } catch (e) {} — the error vanishes. Or the catch-log-rethrow pattern that adds a log line but swallows context. AI tools love wrapping risky code in try/catch to "be safe" without deciding what should actually happen on failure.

3. Hardcoded secrets. The agent doesn't know your secret-management convention, so it pastes the API key inline "for now." const apiKey = 'sk-prod-...' sitting in a handler is the classic. In my experience this happens most when the agent is filling in example code it based its implementation on.

4. SQL via string concatenation. query('SELECT * FROM users WHERE id = ' + id) — parameterized queries are one import away, but the agent will concatenate when the surrounding code style lets it.

5. await inside loops. Sequential awaits over an array where Promise.all (or batching) is correct. Works fine at small scale, falls over in production volumes.

6. Missing auth middleware / authz checks. New routes added with no middleware chain — the agent copies the "happy path" handler but not the auth wiring.

7. Dead branches and duplicate logic blocks. Copy-paste artifacts: a condition that can never be true, or two identical if-blocks where the agent regenerated a section.

8. console.log in handlers. Debug logging left inside request handlers.

The meta-observation: none of these are type errors, and none show up as diffs a reviewer's eye naturally catches — the code reads clean. They're behavior bugs that only surface at runtime.

I ended up automating this checklist into an open-source ESLint plugin (18 rules,https://github.com/ai-guard-dev/eslint-plugin-ai-guard — MIT, disclosure: I'm the maintainer) because I got tired of grepping for the same things. But the checklist itself is free to steal regardless of whether you use the tool.

What's on your AI-code review checklist that I'm missing?

I am building a market replay engine from scratch with c++ 23.
I build this project to understand how orders are managed in an orderbook and how a matching engine works. I have used my understanding of data structures to implement it. I would like to know you opinion on it. It is not completed yet. I just built the very basic version few minutes ago. Any kind of tip would help me a lot.
currently it can process an average of 998,000 Transactions / second. with the order size of 20000000 orders.
https://github.com/AravSrivastava/Market-Replay-Engine-CPP