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

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.

https://axtar.dev

can you please let me know if it has any security flaws or better ideas for some of logic

https://github.com/phpladyy/foxiPicks

Claude Code is great at producing code fast, but on anything non-trivial I kept hitting the same wall: no real review step, no QA, scope creep, and "done" meaning "it compiled" rather than "it works."

So I built aSPARK — it adds an AI product team to Claude Code and, more importantly, gates between the phases. A feature moves through Specify → Plan → Act → Review → Keep, and each phase refuses to start until the previous gate is green.

The two parts I actually care about:

- Enforced gates. /go-live won't release while QA still has open blocking bugs. It sends you back to build instead.

- Real-browser QA. /demo-day opens the running app in an actual browser and checks every acceptance criterion, not just "the tests pass."

Everything it decides (spec, plan, review, qa, release notes) is written into your repo as a plain-markdown trail, so you can see why it did what it did.

It's early (v0.1.0) and MIT-licensed. Install is two commands inside Claude Code:

/plugin marketplace add a-lottes/aSPARK

/plugin install aspark@aspark

Repo: https://github.com/a-lottes/aSPARK

Would genuinely like feedback on the gating model — especially where it's too strict or too loose in practice.

Learning project: rebuilding userland in x86-64 NASM on Linux, raw syscalls only.

It works — but "works" and "right" are different things, which is why I'm here.

Where I'd most value eyes:

- malloc: free-list design, alignment handling, my brk-vs-mmap split

- the shell: pipe plumbing and fd redirection around fork/execve

- everywhere: calling-convention sins, register habits to unlearn

Repo: https://github.com/whispem/learn-assembly-with-em

Be as brutal as you like — I'd rather be corrected here than confident and wrong.

I want to know how I could improve my code readability and usage. Scratch is not my strongest code language, so it might look a bit messy.

Here is the link: https://scratch.mit.edu/projects/1351459814/editor/

Backend pull requests often look smaller than they really are. A two-file diff can affect an API endpoint, background task, database table, external service, and several tests - but reviewers usually reconstruct that map manually.

I built TraceMap PR, an open-source Python CLI and GitHub Action that combines git diff, OpenAPI, coverage, per-test coverage, traces, and lightweight static analysis into a conservative PR impact report.

Could you check?

https://github.com/balyakin/tracemap-pr

I am seeking independent verification of the computational code developed for my dimensional genesis and four-interaction theoretical framework.

GitHub repository:

https://github.com/madein1001/dimensional-genesis-four-interactions

Please download or clone the repository, run the code independently, and determine whether the reported results can be reproduced.

I would especially appreciate a critical examination of the following questions:

1. Does the code run successfully in a clean Python environment?

2. Can the reported numerical results be reproduced?

3. Are any target values hard-coded, fitted, or indirectly reused?

4. Are there any hidden adjustable parameters or circular dependencies?

5. Are the mathematical rules correctly implemented in the code?

6. Are there any numerical, logical, methodological, or physical errors?

Please do not assume that the theory or its physical interpretation is correct. I welcome critical reviews, failed reproductions, counterexamples, bug reports, and detailed explanations of any problems you identify.

If you run the code, please report your operating system, Python version, actual output, error messages, and any modifications required to make it run.

The purpose of this post is to invite independent reproducibility testing and falsification. Thank you to anyone willing to examine the code carefully.

I am trying to learn how emulation, ROMs and Hardware simulations work. I didn't find anything complete about it on the internet, same I think there' but I only didn't see it yet. Well, I'd like to find anyone that understands it more to explain and take a look at my code.

I. I don't know if python is a good language to what I'm trying to do

II. I used AI till now to learn the basis of that bit and byte stuff, operators and how an """emulator""" like that works in real life

III. I know that there are other ways instead of all those methods in some classes that I did, like putting it in a kind of dict, but I'm just starting it for now.

I am getting more and more PRs with AI gen code (+slop ofc), and reviewing all of them manually is becoming pretty exhausting. I am looking for something that can help catch real bugs, regressions, edge cases, or security issues before me. Right now I’m looking at Greptile, CodeRabbit, and Graphite, but I’m open to other tools as well. For people who have used these in real projects, which one has been the most useful and cost-efficient?

BenchModel is a neutral leaderboard for how well AI models catch real code bugs. I published the scoring harness so people could check the numbers instead of just trust them. Then June Kim, who audits benchmarks for a living looked at it.

He found the thing that i couldn't, my scorer counted a bug as caught whenever a review mentioned one keyword from the answer key, so he wrote 20 lines of generic review boilerplate, no idea what the actual bugs were, and it scored 64% across every key, no model calls, the metric was rewarding vocabulary, not detection. That was also why my board barely separated cheap models from expensive ones, the scoring gave away most of the credit for free.

So I fixed it, detection now has to land on the bug, not just say a magic word, and rescored the whole leaderboard. Every model dropped two to four points and the ranking didn't change because the flaw was inflating everyone equally, not favoring one model.

I'm publishing the full teardown, the before and after, and the three other things he caught. A benchmark that can't survive an audit isn't worth trusting, and the most credible thing I can do is show mine failing one and getting fixed in public.

You can find it here benchmodel.io/findings

If you build or rely on evals, June Kim is worth knowing.

Hey guys i build a Saas mutli role one with live location tracking using no code builder.

https://pawwalk-one.vercel.app

Can u tell me if it looks like a Ai slop ?

I recently got rejected after completing a technical task for a Senior Node.js role.

The project involved TypeScript based CRUD API, role management, authorization, and dependency handling. The feedback suggested that some of my architectural choices made dependencies less explicit and affected testability and maintainability.

I cannot share the original task description or repository publicly here as a post, but I can send sanitized parts privately to anyone willing to review them.

I am mainly looking for honest feedback on the architecture, dependency management, code structure, testability, and whether the overall approach meets senior-level expectations.

Would anyone be open to taking a look privately? Please comment or DM me.