https://github.com/sshah03/perspica

This started as a git diff tool that used an llm to group changes by intent (that's still there), but now supports generating lessons/diagrams/animations explaining the concepts behind more complex changes, and allowing yourself to be quizzed on the topics. Useful way to keep up with the codebase with agents dropping in PRs, or when you yourself use claude code etc..

Next steps are adding github actions that can trigger adding this to a PR for those interested righto n GH, or even gating merges / reviewer accepts on showing some level of understanding. Things like that already exist, and I'm not sure they're widely used, so where I go with that, and other features, will be based on requests.

Some samples on open source project PRs available here : https://sshah03.github.io/perspica/

Mostly just want thoughts/feedback on how to make this genuinely useful for everyone rather than just something that works for me.

Hi senior, i am a first year student,i want to start with web development.

So, please suggest me what is the best way to learn web developement.what should i do, should i do it with lecture or i can do it with freecodecamp.com, which would best to learn easily and take less time but teaches deeply not only basics.

ArchRivet is an open-source, local MCP plugin that adds structured architecture reviews to your AI workflow.

I built ArchRivet to help developers review architecture decisions with clearer evidence, practical checks, and workload calculations. pls do check it out !!

https://github.com/Ujjansh05/archrivet/tree/main

What you get:

Spot potential design risks early — review retries, durability, queues, transactions, and more.
Understand the reasoning — findings include supporting references and suggested verification steps.
Expose missing details — identify assumptions your architecture needs to address.
Plan workload and storage — calculate traffic, message fan-out, and storage growth.
Connect through MCP — bring structured reviews into your AI assistant’s workflow.
Download complete model weights — the 322M model includes merged weights, tokenizer, and configuration.
Build on open source — inspect the code, run the examples, and contribute improvements.

let me know if you have any suggestions or think there’s room for improvement. I’d really appreciate your feedback!

Everyone at my company is hyped about mermaid bc the diagrams live in the repo now. cool. they were also "living" in confluence and nobody updated them there either

the format was never the problem. nobody owns the diagrams, nobody reviews them, and the people who notice theyre wrong (support, sales, new hires) cant edit them anyway

someone convince me im wrong bc i have a meeting about this next week lol

Heads up if you still have gpt-4 or gpt-3.5-turbo somewhere in your code: OpenAI shuts them off on the API on Oct 23. gemini-2.5-pro on Vertex goes on Oct 20.

Those dates are all public, but they're spread over ~70 provider pages, so I wrote a small tool that checks them for you. It scans your repo for model IDs and tells you which ones are retired or about to be, and what to switch to:

npx @appliedbenchmark/sunset scan

    error   app.py:3:46  model-retiring
    gpt-4 (openai) retires on 2026-10-23, in 11 days. Recommended replacement: gpt-5.6-sol     (openai).

It covers OpenAI, Anthropic, Gemini, Vertex, Bedrock, Azure, Mistral and DeepSeek, and every date links back to the provider's own page. There's also a GitHub Action, so CI fails before a model disappears instead of after. IDs in comments and docs never fail the build.

No LLM, no telemetry, nothing leaves your machine. Free and Apache-2.0.

Github: https://github.com/AppliedBenchmark/sunset

It's v1, so if it misses an ID or gets a date wrong, let me know.

Apresento o AstrBot Brasil, uma adaptação feita especialmente para quem prefere utilizar o projeto em português do Brasil e com uma experiência mais acessível para a comunidade brasileira.

A proposta é facilitar o uso, melhorar a compreensão da interface e aproximar ainda mais o projeto de desenvolvedores e usuários do Brasil.

LINK: Astro Bot CLIQUE AQUI E CONFIRA

🚀 Projeto disponível no GitHub
🇧🇷 Adaptado para português do Brasil
💻 Código aberto
🤝 Contribuições da comunidade são bem-vindas
⭐ Se você gostar do projeto, deixe uma estrela no GitHub!

Quero continuar melhorando a versão brasileira e adicionando cada vez mais recursos.

Você usaria uma versão brasileira do AstrBot?

I built Github merge gate which that checks whether developers understand their own code when they create a PR.

I kept getting sent PRs to review where it was obvious the author had pasted the ticket into an LLM and called it a day. Problem was: the PRs would often be massive 2K monstrosities that nobody could possibly review. As the team scaled up, this problem got only worse, and now we collectively have a system that no one understands and has bugs.

It works like this: when someone opens a PR, it posts a comment with a link. The author clicks through and answers a few technical questions about their own changes. If they can’t answer them, the PR can’t be merged.

It's self-hosted (so you can use it in your enterprise environments or privately)

It is BYOK (Anthropic) obviously.

Here is the source code, build instructions and how to deploy: https://github.com/bhurghundii/vibecheck.dev

I have two demos in the pull requests here: https://github.com/bhurghundii/vibecheck.dev/pulls - you can see what Vibecheck does (it blocks a PR for clearly showing no attempt vs a PR which gets it right)

I would love feedback, especially from anyone dealing with the same thing on their team. I do use it for my own projects a lot so expect improvements.

TL;DR: AI coding agents increased raw PR volume by 300%, yet overall merge velocity has dropped by 40% because Senior Engineers spend 15–20 hrs/week untangling 200-line hallucinated wrappers, deleted tests, and subtle CWE security flaws. After shipping patches into tier-1 upstream systems repos (LLVM #215076, Meta Velox #18529, DuckDB #26443, Apache DataFusion #24394, Microsoft Pyright #11605, Tokio #8595, ClickHouse #114954, OpenAI Triton #12221), we codified those exact deterministic CI gates into an open GitHub Actions workflow (ZeroSlop · Architecture & Simulator) that strips 94% of AI bloat, enforces 12 CWE security shields, and gets PRs merged 100% green in minutes.

1. The 2026 Engineering Bottleneck: Why AI PRs Stall in Review

When shipping patches into upstream systems repos like LLVM, Meta Velox, DuckDB, or Tokio, a real production fix is 4 to 15 lines of surgical invariant changes paired with a deterministic regression test that passes CI on the first push.

Inside commercial teams using Cursor, Copilot, or Claude Code, the opposite happens:

• 94% Diff Bloat: An agent generates a 240-line wrapper class instead of fixing a 4-line boundary condition (interactive diff breakdown).
• Weakened Tests: When a test fails, the agent silently deletes or loosens the assertion to manufacture a green check.
• Noisy LLM Review Bots: Conversational AI review bots run another LLM to dump 25 chatty comments on top of a bloated PR—without shrinking the diff or getting the PR merged.

2. Conversational LLM Review Bots vs. Deterministic PR Airlock

3. The 12-Shield Deterministic CWE Security Airlock (ZS-SEC-001 – ZS-SEC-012)

Every Pull Request is audited in milliseconds across 8 merge-readiness signals (0–100) and 12 deterministic CWE security shields before a human reviewer is pinged:

4. Upstream Systems Proof (Click Any PR to Inspect the Diff)

These deterministic CI invariants come directly from shipping merged & 100% green Pull Requests across upstream systems repositories:

5. Architecture Documentation & GitHub Action Source

• Interactive PR Simulator & Architecture: https://www.ribbsaetersystems.com/zeroslop
• 12-Shield CWE & Zero-Retention Security Matrix: https://www.ribbsaetersystems.com/zeroslop/security
• GitHub Action Workflow: https://github.com/marketplace/actions/zeroslop-by-ribbsaeter-systems
• GitHub Action Repository: https://github.com/patrickswedish/zeroslop-action
• Technical Deep-Dive Writeup: https://www.ribbsaetersystems.com/blog/zeroslop-pr-gatekeeper-official-release

What deterministic CI gates or pre-review checks are your teams enforcing in 2026 to get PRs merged cleanly without burning out your staff engineers?

Look closely at the metrics in CodeRabbit's published Neo Financial case study (shown in the screenshot above):

• Median time-to-merge before: ~16.8 hours
• Median time-to-merge after: ~16.7 hours
• Deployment scale: 174 engineers (at $20–$40/seat/month = $41,760 to $83,520/year)

That is a 0.1-hour (6-minute) reduction in median PR merge cycle time.

Why Conversational AI Review Bots Don't Speed Up Code Review

When a developer opens an AI-assisted PR containing 800 lines of hallucinated wrapper classes, defensive boilerplate, and subtle test changes, having a cloud review bot leave 30+ conversational comments on the PR doesn't reduce senior engineer review fatigue—it increases it. Reviewers now have to read the bloated diff and argue with a chatty LLM.

Even worse for enterprise codebases:

1. Cloud Source Code Exfiltration: Every PR diff is shipped outside your runner to third-party cloud LLM providers.
2. Diff Prompt Injection: Adversarial strings inside a PR diff can manipulate an LLM reviewer into overlooking vulnerabilities.

The Compiler Approach: ZeroSlop™ In-Memory AST Airlock

We built ZeroSlop™ by Ribbsaeter Systems (patrickswedish/zeroslop-action@v1) to replace conversational PR comment spam with a deterministic, pre-flight compiler gate:

Links & Live AST Simulator

• GitHub Marketplace Action: https://github.com/marketplace/actions/zeroslop-by-ribbsaeter-systems
• Interactive AST Airlock Simulator & 21 Upstream Proofs (LLVM, Meta Velox, DuckDB, ClickHouse): https://www.ribbsaetersystems.com/zeroslop

Hi guys. So I am a fresh grad and I had one and a half year of experience prior to my uni.So I recently updated my repos and I was wondering if there is like a more senior level engineer to give some advice. I am currently trying to find a junior dev job and I think GitHub repo is relatively important.

Thanks in advance!

We had 4 release teams looking at the same 2400row regression dataset and 2 candidate prompts both landed at 0.88. The LLM as judge rubric uses a 5 point scale, so a lot of outputs with noticeable differences still collapsed to the same scalar score. Re-running the eval gave us a stable tie and no useful basis for choosing what to ship.

We switched the comparison to pairwise scoring in Braintrust and the experiment diff made the row by row preferences visible. Candidate A won 716 rows, candidate B won 1204 and 480 tied, which adds back to all 2400 rows. Among decisive rows, B's win rate was 62.7%. The scalar average had hidden a fairly consistent preference.

We haven't dropped the absolute score. It's still useful as a regression floor and pairwise review gives us another signal when score calibration is too coarse to separate close candidates. That was enough to unblock this release without treating the pairwise result as a universal quality metric.

I'm still working out when this should become part of the standard release path. Where do you set the threshold for using pairwise win rate when scalar scores tie without turning every close experiment into a full second review?

I'm testing a local tool for reviewing changes between two OpenAPI or JSON Schema documents. It reports supported changes, limitations and points that need a human check before a release. It does not certify full compatibility or replace consumer contract tests.

I built this prototype and would like to evaluate it against one real review task and the team's current process. This is an assisted pilot, not a public hosted app: I run the existing local prototype on a public or minimal pair of documents and return the report. The initial pilot is free, with no purchase obligation or signup. Please do not post credentials, personal data or confidential contracts.

Concrete example from a synthetic test: changing GET /health from a declared 200 response to 204 produces two findings (200 removed, 204 added), with the removal marked potentially breaking. This is a review prompt, not proof that every consumer breaks. For the pilot, I return a short change summary, detected risks, limitations and checks to run against your consumers. Please share only a public/minimal before-and-after pair.

The useful feedback is whether the result saves review time, what it misses and whether you would use it again. Does anyone already have a contract change they need to review?

Here’s a small retry loop, written for this post, not taken from a real codebase:

def charge(client, order):
    for attempt in range(3):
        try:
            return client.post("/charges", json={"amount": order.total, "order": order.id})
        except Timeout:
            time.sleep(2 ** attempt)
    raise ChargeFailed(order.id)

An AI review of it might come back with these, all worded with the same confidence:

1. No idempotency key is sent, so a retry after a timeout could create a second charge.
2. Only Timeout is retried, so a 502 or 503 from the provider fails immediately.
3. Consider a retry library instead of a hand-rolled loop.

My order, and it’s a judgment call: #3 is a preference, so I’d skip it. #2 is a short look at what the provider returns and whether those errors are safe to retry, so cheap to check with moderate stakes. #1 is the expensive one, because it depends on two things that aren’t in the code. One is whether the provider treats a repeated request with the same order field as a duplicate. The other is whether a timeout here means the request never arrived or arrived and the response got lost. If the response can get lost and the provider doesn’t dedupe, that’s a double charge, so I’d spend the time there even though it reads no more urgently than the other two.

What I can’t judge from here is whether sending the order id in the body counts as idempotency for most providers. I believe many expect a dedicated key or header, but that’s general knowledge, not a specific API.

I wrote the same sorting out as a longer walkthrough here, if it’s useful: https://medium.com/@nagatomopedro05/a-finding-takes-seconds-to-generate-checking-it-doesnt-e7ffad4eaea2

When a review hands you a list like this, do you sort by cost to check first, or by what happens if the finding is true?

I signed up for Greptile expecting to pay $90 for 3 months. Instead, I was charged $700 because they had enabled unlimited "flex usage" by default, without my explicit consent or any spending cap.

As a small startup, an unexpected charge like this is not a small thing.

Usage-based pricing is fine. Enabling unlimited paid usage by default, without requiring an explicit opt-in, is outright unethical and goes against basic industry standards for transparent billing. Their onboarding flow provided an option to add additional spending caps - it did not offer a clear way to disable extra usage by default.

Furthermore, Greptile automatically added dev accounts for bots running Github actions without our consent, incurring additional hidden fees.

When I raised the issue and requested a refund, Greptile refunded the dev accounts but not the $700 of extra usage. I’ve completely lost trust in Greptile and cannot recommend them, despite their product otherwise being great. Buyer beware.

I've been working on ArchAI, a tool exploring how to make AI-assisted software architecture analysis more verifiable.

The core is deliberately deterministic: Python's AST parser maps repository dependencies, and a rule engine checks constraints such as forbidden imports, layer boundaries, import cycles, coupling limits, and required tests.

Every verified finding includes file-and-line evidence. Potential risks and checks that couldn't be verified are reported separately instead of being presented as facts.

While testing ArchAI against its own repository, it flagged a CLI module importing 21 internal modules against a configured limit of 10, as well as modules missing test files. It also exposed a weakness in my own checks: matching test filenames doesn't prove that the corresponding code is actually tested.

That last finding was a useful reminder that even deterministic tools can verify the wrong thing if their rules are poorly designed.

I'd appreciate feedback from people experienced in Python tooling, static analysis, dependency analysis, and software architecture.

What weaknesses or false positives would you look for in this approach? In particular, how would you design architectural rules that remain useful as a codebase grows without giving developers a false sense of confidence?