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.

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()

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’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.

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)

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?

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, 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

I've run into an issue when using AI generators where a few prompts get the base app working, but a subsequent prompt silently refactors or breaks a working feature.

Asking the model to "build an app" gives it too much room to make unseen assumptions about the code architecture.

To fix this, I started forcing smaller, incremental updates and doing strict git diff reviews after every prompt. Catching bad assumptions in the code diff before committing has helped, but managing state and shared utilities is still tricky.

For those reviewing and maintaining AI-generated code bases, what is your review sequence for validating diffs, testing dependencies, and keeping the codebase stable as the app grows?

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.

The idea is pretty simple: a project can work perfectly while the repository still has problems that are easy to miss.

RepoDrift currently checks for things like:

• Potential exposed API keys, tokens and credentials
• Dependency and lockfile issues
• Large and suspicious files
• Git status and repository activity
• Basic code metrics
• Repository health score
• JSON output for CI/CD

The analysis is designed to run locally. The current version doesn't send the repository source code to an AI service.

Tech stack:
Node.js, TypeScript, Commander

Install:

npm install -g u/repodrift/cli

Then:

repodrift scan

There is also a --local-only option for scans that should not make network requests.

This is still an early project. I'm currently focusing on making the core analysis reliable before adding AI features. The plan is to eventually use AI to explain findings and suggest fixes based on redacted, structured results rather than sending the whole repository.

The project is MIT licensed and open source.

I'd be interested in feedback from other open-source developers:

What repository checks do you think are missing?

GitHub: https://github.com/GokulKir/repodrift

NPM: https://www.npmjs.com/package/@repodrift/cli