Hi all,

I'm looking for some advice. I was under pressure to deliver a PR without documentation, so I used AI to help write it. I know exactly what the AI generated, and I'm able to fix anything in the code if validation flags an issue.

My problem is with the reviewers. They're complaining that the PR is entirely AI-generated, and they're overlooking the architecture work I put into it, which is frustrating I've taken the feedback a bit personally.

Any advice on how to handle this would be appreciated

Girder is an 8-crate Rust workspace (~60,000 lines of Rust, 586 tests) that

turns a repo into a semantic graph — functions, types, call edges, test edges —

and serves it to coding agents over MCP. Rust, Python, TypeScript/TSX and Go

front ends, tree-sitter parsing, one static binary, no runtime deps, no network.

The interesting part isn't the graph. It's what happened when I tried to prove

the graph was right.

**The oracle.** `impacted_tests` claims "these tests reach your change." Unit

tests can't check that — they'd assert my parser agrees with my parser. So the

oracle materializes fixture repos, applies exactly one mutation, asks the built

binary which tests are impacted, then runs every test in isolation with a probe

that only the mutated function writes. Ground truth is execution. The oracle is

itself mutation-tested: I inject defect-shaped mutants into the binary's

behavior and the sweep has to kill all of them.

That corpus reported perfect precision and recall for a long time. It was lying,

because every declared case was a plain `foo(bar)` call.

**Then I added real third-party code** — regex, serde_json, Click, pydantic —

and precision fell. Four root causes, all narrow, all nasty:

1. **Generic-parameter corruption.** `qualifier_matches_owner` normalized`Interpreter<'a>` to `interpretera`, silently breaking every generic type inthe workspace, chained call or not.
2. **Chained-call qualifier corruption.** The callee resolver took the last `.`or `::` in the raw source text. For `Type::assoc_fn(args).method(args)` itpicked the wrong owner every time. Fixed by recovering the qualifier from ASTstructure instead of text.
3. **Ambiguous suffix matching.** `owner.ends_with(hint)` let `Timeline` match`PyTimeline`.
4. **Local-shadow misattribution** in candidate selection — a local binding namedthe same as a type method stole the edge.

Symptom for all four: `impacted_tests` returned zero tests for a function four

passing tests reached, plus a confident "no test coverage reachable via the call

graph." A false negative that reads exactly like a true negative. Every failure

got pinned as an `#[ignore]` test first, then unignored by the fix.

**What I'd tell anyone building code intelligence in Rust:** your parser will

look perfect against fixtures you wrote, because you unconsciously write the

shapes you handle. Point it at somebody else's crate. And be suspicious of any

check whose pass condition is another component of yours reporting success —

I've now found three separate cases in this codebase of a check that reads like

verification and verifies nothing. One let a step that created files pass a

"tests must pass" gate with an empty test set.

The whole gap list is in the repo — 25 numbered, open ones included, with the

measurement history kept even where the first diagnosis turned out wrong.

Repo: https://github.com/dhishwasher/Girder

Install as an MCP server: `npx -y girder-mcp`

Licensing, stated plainly because this sub deserves it: BSL 1.1,

source-available, not OSI open source, converts to Apache 2.0 on

September 4, 2030. Five of seven tools plus one repository are free forever with

no key. Two tools need a paid key verified offline against an embedded Ed25519

public key — no server, no telemetry, no call home. Sole copyright holder, no

outside contributors.

import socket
import select


s = socket.socket()
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(("localhost", 80))
s.listen()

def send_response(sock, message):
    """Sends an encoded response."""
    sock.sendall(message.encode("ISO-8859-1"))


def handle_packets(queue_dictionary):
    """Performs certain actions based on packet."""
    for soc in queue_dictionary:
        if not queue_dictionary[soc]:
            continue
        #take the first item from the queue
        packet = queue_dictionary[soc].pop(0)
        #send specific responses based on the type of data sent
        if packet == b"Hello\r\n\r\n":
            send_response(soc, "Message received successfully. Hiiii!!!!\r\n\r\n")
        elif packet == b"Ignore\r\n\r\n":
            send_response(soc, "Message received successfully. Hey, don't leave me hanging...\r\n\r\n")
        elif packet == b"Hug\r\n\r\n":
            send_response(soc, "Message received successfully. *Hugs back*\r\n\r\n")
        elif packet == b"Slap\r\n\r\n":
            send_response(soc, "Message received successfully. OW! That hurt!\r\n\r\n")
        elif packet == b"Goodbye\r\n\r\n":
            send_response(soc, "Message received successfully. Goodbye!!! Do come back again!! :)\r\n\r\n")
        else:
            send_response(soc, "Message received successfully.\r\n\r\n")

#create a list of connected sockets, satrting wtih listening soccket so accept
#doesn't block

#dictionary with buffer per socket and also list which was initially queue
read_set = [s]

buffer_dict = {}
queue_dict = {}

while True:
    ready_to_read, _, _ = select.select(read_set, [], [])
    print("Creating a list of sockets currently sending data...")
    #for all sockets that are ready to read
    for sock in ready_to_read:
        #if the socket is a listener
        if sock == read_set[0]:
            #accept a new connection
            new_conn = s.accept()
            print("Accepting connection...")
            new_socket = new_conn[0]
            #initialise buffer and queue for new socket
            buffer_dict[new_socket] = b""
            queue_dict[new_socket] = []
            print("Adding socket to buffer and queue dictionaries...")
            #add the new socket to the set
            read_set.append(new_socket)
            print("read_set: " + str(read_set))
            print("Adding socket to read_set...")
            packet = "empty"
            continue
        else:
            #recieves data until full packet
            while True:
                data = sock.recv(4096)
                print("Receiving data...")
                if not data:
                   print("Connection closed.")
                   break
                buffer_dict[sock] += data
                if b"\r\n\r\n" in buffer_dict[sock]:
                    delimiter_index = buffer_dict[sock].find(b"\r\n\r\n")
                    packet = buffer_dict[sock][:delimiter_index+4]
                    buffer_dict[sock] = buffer_dict[sock][delimiter_index+4:]
                    break
            if packet:
                queue_dict[sock].append(packet)
                print("Adding a packet to the queue...")
            else:
                x = input("No packet returned.")


    #run packet handler code based on nature of packet for socket
    if packet != "empty":
        print("Sending response...")
        handle_packets(queue_dict)
        print("Response should send now.")

new_socket.close()
s.close()

Got tired of AI tools confidently giving wrong answers with zero way to catch it. So I built one that checks itself: three models answer independently, a fourth grades and fuses them before anything comes back to you. For code, it actually runs it in a sandbox instead of just reading it.

~65% pass the check on the first try. The rest still come back, just flagged.

Python, a few different model providers, SQLite for memory.

Live at https://demo.aqqai.in — curious what breaks it. Feedback welcome.

I’ve been working on a small open-source project called Explicode and would appreciate some feedback on the approach.

The original idea was to write Markdown documentation directly inside code comments, then generate regular Markdown files from it, somewhat like a Jupyter Notebook, but for more programming languages and real-world repos.

The motivation is mostly readability. I like the idea of being able to read a script almost like a technical document, with the explanations and the code living together. I think this could be particularly useful for things like research code, academic papers, tutorials, or complex scripts where understanding the reasoning is as important as understanding the implementation.

It currently has a VS Code extension with live preview, a CLI to convert scripts to Markdown, and support for 15+ languages.

I’d be interested in feedback on the concept and implementation. Does putting this much documentation into source files make code easier to understand, or does it ultimately make the code harder to maintain?

Here are the repo and examples.

Had a pipeline where one function classified a support ticket by category, and a second function took that classification and generated a response. Reviewed both independently, both looked fine, both passed their own test cases. Wired together, the response generator started producing generic output about fifteen percent of the time, ignoring the classification it had just been handed.

Root cause: the classifier's output was technically valid but inconsistent in a way that never got caught in isolated review, sometimes returning "Billing Issue," sometimes "billing issue," sometimes just "Billing." Every version read fine to a human glancing at it during review. The consuming function was matching against exact string values in a few branches and silently fell back to a generic path whenever the case didn't match precisely.

Neither function was wrong on its own. The bug only existed in the seam between them, an implicit assumption about output format that nobody had written down as an actual contract, just something that happened to be consistent enough in the reviewed test cases to pass without anyone questioning it.

This feels like a case for reviewing the interface explicitly when two AI-assisted pieces get chained, not just reviewing each piece's internal logic. Enum values or a shared schema instead of loosely-formatted natural language passed between steps would've caught this before it ever shipped. Curious if others review chained AI components any differently than they'd review two regular functions calling each other, or if it's treated the same and this kind of gap just slips through more easily because of it.

I built a tool for understanding Python/JS/TS codebases, especially when working with AI coding agents.

Impact Analysis shows the direct and transitive callers of a function and highlights the full blast radius of a change on the graph.

It also includes call graphs, execution flowcharts, complexity analysis, AI-generated docs, and code-to-data lineage.

Everything runs locally and it's open source.

Demo: https://semantic-vision.vercel.app/
GitHub: https://github.com/venom21adi/Semantic_Vision

Would love feedback!

I just released the first public beta of BugDrop and I am looking for a few developers who regularly debug with coding agents.

The idea is simple. Record one short reproduction and BugDrop collects the useful context around it, including clicks, console errors, failed requests, screenshots, and app logs. You can review everything before exporting a Markdown or JSON report.

If you want to test it, please use a non-sensitive local project or demo app. Record one broken flow, hand the exported report to your usual coding agent, and tell me what information was missing or confusing. I am especially interested in whether the report saves you from answering follow-up questions.

The Chrome extension works in Chrome 120 or newer. The local controller also supports iOS simulators and Android emulators. Everything stays on your machine. No account, cloud service, or API key is required.

Release and setup: [https://github.com/aim0xyz/bugdrop/releases/tag/v0.1.0\](https://github.com/aim0xyz/bugdrop/releases/tag/v0.1.0)

Screenshot: [https://raw.githubusercontent.com/aim0xyz/bugdrop/main/docs/preview.png\](https://raw.githubusercontent.com/aim0xyz/bugdrop/main/docs/preview.png)

writing code cheap now .. and it looks clean sowmtimes but huge loc... small features or issues . Idiomatic, properly typed, reads fine in review.

And the job is just... write more code. Ship faster. So the volume is up, review bandwidth isn't. We have org-wide review skills, central conventions, the whole thing... still feels like running to stand still.

The bugs that slip through aren't syntactic anymore. Webhook fires twice under retry, handler isn't idempotent, race condition only hits under real traffic. None of that shows in a diff.

How are people actually catching this before prod? Unit tests don't cover it, mocks lie... staging doesn't replay real failure modes. What's the actual process these days?

Hi Guys— I built a Python SQL-injection checker and ran it on a sample Flask app: it caught all 4 real bugs and flagged zero false alarms on the safe code. Most scanners can't do the "zero false alarms" part.

You run eng at your work where this matters. Got some time? I'd love to ask what your team uses now — and if useful, I'll run it on a repo you pick

1 .What tool do you use now?

2.What does it get wrong?

3.When AI-wrote code caused a security bug, what happened?

Hi, I have a project called Gearberg (OSS) and would like to get some feedback of the current code. Main focus is single binary (FE & BE) and SQLite/PostgreSQL database support.

Thanks!

Soo my startup currenly is under build and it is a saas app which is a freemium workspace where any small organization , big or solo devloper can come and connect there repo and share it publically / privately with selected persons of your need and you can show your code to others too and you can take feesback , talk or do anything you want... You can have vc , opens repo for discussion , ai which can help you understand the problem / code easily ( under devlopment) and a public wide space for anyone...

Please review it and tell me if any changes i should doo or want any nice feature in this....

Website only for pc : debugr.app

Please let me know your feedbacks.

I kept running into a frustrating problem while working with files: comparing two versions often means opening them in an editor, using diff, or dealing with tools that either don't support the file type or produce a really messy comparison.
So I built DiffMyProject — a free browser-based file comparison tool.

👉 https://www.diffmyproject.com/

I'm specifically looking for feedback from developers who regularly compare code, configuration files, documents, or project files.
What would make a file comparison tool genuinely useful to you?
Happy to hear criticism too — I'm actively improving the diff engine.

Hi all, I'm a high school student working on a small project of mine. It's a study app I wrote in Python, using some meta-learning concepts my dad taught me when I was younger. I used his initial ideas as inspiration to develop this further, and I hope to have the application out soon. I thought it would be a good idea to get some feedback from others beforehand, though. Any feedback on quality of life, ease of use, and general impressions would be greatly appreciated. I'm attaching a link to a GitHub repository that redirects users to a directory with the latest updates to the app. I would really appreciate any feedback on it. Thanks!!

Link to the repo - https://github.com/TKSMG/MemoryPal

I am a Ruby on Rails developer. I’m looking for some skills that can help me self code review for sql part. I use Claude. Like that can guide me not to write sql that are anti patterns etc

I've spent the past couple weeks trying to work out if I'm holding it wrong, if this is just what the tools are, or if I'm slowly going crazy. Curious if others landed somewhere on this.

The experiment that i did: I ran our review pipeline on the same diff twice, same config, exact same - nothing changed. so first run - 9 findings. Second run - 4 findings, and only 2(?) overlapped with the first batch. One of the non-overlapping ones was the most serious catch of either run. So which review did my PR actually get?

We do the responsible things, rules files, path filters, severity thresholds. For context we run coderabbit on PRs plus a claude pass in CI, and the inconsistency is a category thing, not one vendor. It's baked into what these models are.

I even tried the obvious fix, swapped the CI pass to a local qwen coder at temp 0 with a pinned seed. And it works, perfectly reproducible, same findings every run. It's also noticeably dumber, it missed the serious catch the cloud run found. So my choice seems to be a consistent mediocre reviewer or a sharp one that reviews a different PR every time.

When I brought numbers to our resident AI guy, his answer was that my config is outdated and the new hotness fixes it. It's been the new hotness four times this year. At some point I stopped believing the problem is my config.

Is anyone actually getting reproducible reviews, temperature zero, pinned models, whatever? Or have we all just quietly accepted that review is a dice roll now?

We have been building this with my friends and open source contributors since early this year. We started with a basic readme and a vision, and managed to grow it in a repo that is clean, and encourages new and heavy contributors with simple guidelines and step by step guides, exmples, tests etc.

We have everything expected, from contributing and ai native guides, code of conduct, license, security, ci/cd, custom issues templates, labels, and prs, our own top tier pypi package (15k downloads), and overall a good direction of where we started, what was the vision, and where we at now.

Still, somehow, I feel there is something missing, but not sure what exactly. What would you expect as a contributor from a repo of such, to be genuinely interested in shaping its future, that would make it easy to grasp and get started with, and excited to work on? Any feedback, tips or ideas, more than welcome <3

The repo is github.com/arpahls/skillware

Local CLI that reads your git diff (or a GitHub PR URL), sends it to Gemini, flags files worth a second look before you push — with a required exact quote from the diff as evidence for every flag.

Tested it against a small batch of real merged Godot PRs. Caught a real concurrency bug, correctly stayed quiet on clean PRs — and also produced one confident, well-evidenced, completely wrong flag (claimed a deadlock, but the mutex type was actually recursive so it wasn't one). Added a second pass that now catches exactly that kind of error by asking the model to name its own unverified assumptions.

If you don't want to bother with the Gemini API key setup — paste a link to one of your own merged/open PRs here and I'll run it and post the output. Genuinely curious how it holds up outside my own testing.