Learning project that became my favourite: a chiptune synth written entirely in x86-64 assembly (Linux, NASM). No libc, no audio library — just computing raw 16-bit samples and writing a WAV header by hand.

The premise is that sound is just a list of numbers (44100/second) describing where a speaker sits. So the whole synth is: generate the numbers, write them out.

It does four oscillators (square/saw/triangle + LFSR noise), polyphony by mixing voices into one buffer, ADSR envelopes, and FM synthesis with a hand-built sine table. Working on effects next (vibrato, delay, reverb).

github.com/whispem/asm.fm

Feedback on the low-level details welcome — especially the fixed-point math in the FM operator.

For details, visit: www.pipelang.com.

Pulled up an AI code review from a few weeks back that had approved a PR touching retry logic near a payment flow. At the time it read as thorough, numbered comments, a couple of suggestions, a clean summary at the end. Went back afterward and checked it against five specific questions instead of just trusting the tone.

Did it establish what was actually at risk? No. Nothing in the review distinguished the retry logic from a comment on variable naming, both got roughly equal attention. The model wasn't told this touched a payment path, so it had no way to weigh it differently.

Did it check a specific failure mode? No. The comment was "should probably check for duplicates," which sounds like a finding but is actually a hedge. Nothing tested whether the retry would double-charge under a duplicate request with the same idempotency key.

Was severity justified? No. The duplicate-check comment sat at the same visual weight as a docstring suggestion. Nothing forced a distinction between "this could cause an incident" and "this is a nitpick."

Did it state its own scope? No. Silent about whether it had visibility into the caller, or the idempotency key generation happening elsewhere. Silence read as "nothing else to worry about," which is a much stronger claim than "I didn't check that part."

Was there a confidence check on its own findings? No second pass existed. A confidently wrong suggestion and a confidently correct one look identical in tone, the only way to actually tell them apart is asking what would prove it wrong and then checking.

Four out of five, on a review that read as completely fine at the time. Re-ran it with risk context supplied up front, a specific failure scenario framed explicitly, severity tags required with justification, and a stated scope, and the duplicate-charge risk became the one clearly flagged blocking issue instead of one line sitting level with a naming suggestion.

The uncomfortable part wasn't that the AI missed something. It answered confidently either way, whether it had actually checked or not, and confidence was the only signal I had to go on until I started asking these five questions deliberately instead of trusting the shape of the output.

Wrote the full breakdown of the five questions with the before/after comparison here: https://medium.com/@nagatomopedro05/five-questions-your-code-review-should-always-answer-66be919bb200

Worth running your own last "looks good" AI review through the same five questions. Curious how many people find theirs holding up better than mine did.

Started with our own review queue. Most of the code in a PR is generated now, so PRs land faster and bigger than anyone reads properly. First thing that goes is context outside the diff. Nobody opens the other repo to see who calls the function you just changed. Skim, approve.

So we automated that part. It resolves the symbols the diff touches, walks the callers through a code graph, and pulls in how your repos connect: routes, queues, shared tables, package deps. Sub-agents for architecture, security, logic, tests. One review comes out.

Weak spots: GitHub only, no benchmark, noise tuning needs work. Free tier is one repo crawl plus your first reviews, no card.

If you try it: what fraction of the findings would you have acted on?

https://contextgoblin.com/

Hello, I'm an aspiring software engineer. I've recently finished developing microservice for managing projects and tasks using Spring Boot. I'd appreciate if you could review codebase of my project and provide feedback on it.

GitHub: https://github.com/Simpav-chill/tasktracker

Hi everyone, I didn't know much about OOP. So I made a project surrounding classes to help me out. I'm self taught so please be honest with your judgment of it. Its a little unfinished testing wise, but it feels bigger than it needs to be. And if anyone has anything I can read or project I can contribute to to learn best practice, I'm all ears! Thank you!

https://github.com/Eidos-bot/ClassBasedModulesPublic

Hey everyone! I’m building an open-source production readiness checklist with extensive testing and quality coverage.

I would appreciate feedback on test strategy, integration testing, acceptance testing, regression, test environments, test data, exploratory testing and nonfunctional testing.

If anything is missing, unclear or unrealistic, please let me know. Corrections and pull requests are very welcome.

Thanks!

https://github.com/MarinJursic/production-readiness-checklist

I've been building Pinaka on the side for the past few months — an AI agent that automatically writes root cause analyses when a bug ticket is filed.

The problem it solves: every time a production bug hits, a senior engineer spends 2-3 hours investigating before writing a single line of fix. The actual fix takes 20 minutes. The investigation takes the rest of the day.

Pinaka eliminates that investigation step. Tag a Jira ticket or mention @pinaka-app on a GitHub Issue — it reads your indexed codebase, captures runtime context via an SDK, and posts a structured RCA as a comment. Root cause, exact file, exact line, fix approach. Automatically.

What I've validated so far

Ran it against real open source bugs:

• BullMQ issue #2487 — code only scored 6.5/10, code + runtime context scored 9.2/10 against the actual merged fix
• Prisma ORM issue #29480 — open bug, no ground truth, diagnosed from behavioral contrast across test files
• Pinaka's own Java SDK — found a real ForkJoinPool exhaustion bug, fix shipped same day

All three write-ups are public, including the limitations.

What I'm looking for

couple of engineering teams (2-150 engineers) using GitHub who want to try this on a real production bug. Free, no commitment. I'll personally onboard you and be available for any questions.

Works with Jira and GitHub Issues. No Jira required. One OAuth click to connect. First 5 RCAs free.

Honest state of the product

No paying customers yet. Building in public. The product works — the benchmarks above are real — but I need real teams on real codebases to validate it beyond my own test cases.

If this sounds useful for your team, drop a comment or DM me. Happy to show you a live demo on your repo.

👉 getpinaka.com

Hey guys, I have been adding new repos and taking my github seriosly after a long time
Most of time i open private repos to maintain my workflow on game/website projects
for last a few month i have been working on portfolio/resume projects to put on my website.
And i just like every time i see my contributions on panel, it is like idk how to explain but seems helping me to maintain consistency. I also realized there is achievement badge i have got.
So to pick it up, I am asking for ways to make my profile look better and be better. What can you recommend? Pins, repo names, maybe even links?

https://github.com/TheIlkinAlizade
this is my github, you can also see my porfolio website(which is old version, i will update it with new projects i have been working on)
thanks btw for spending your time to read this

Most "AI reviews your PR" tools annoy me. They hallucinate nits, the output changes every run, and you can't tell if a flag means anything. So I wanted to know if you can get a useful review signal the boring way. Static metrics plus git history, without any LLM in the loop, so same input gives the same output every time.

The question I actually wanted answered: do deterministic code-health metrics predict which files get bug-fixed later?

How I set it up :

• Score every file at a historical commit (T0).
• Count bug-fixing commits to that file over the next 6 months.
• Correlate the T0 score with the bug-fixes that came after. No file sees its own future.

Metrics are the usual suspects plus churn signals. McCabe complexity, deep nesting, LCOM4 cohesion, god classes, clone detection, function-level churn, code age, ownership spread, change entropy. 25 of them, combined into a 1-10 per file. I ran it across 21 OSS repos, 9 languages.

What came out:

• Mean ROC AUC 0.74 at picking the files that go on to get bug-fixes. Up to 0.90 on some repos, weaker on others.
• It survives controlling for file size (partial Spearman -0.16). So it's not just "big files have more bugs," which was my first worry.
• Out-ranks churn alone by about +0.10 AUC, and prior-defect history by +0.12.
• Held on an external dataset I never touched (PROMISE/jEdit), AUC ~0.77.

I ran it head to head against CodeScene too, same 2,770 files, same commit, same labels, since it's the closest established tool. Discrimination was close (0.73 vs 0.71). The gap showed up on effort-aware ranking. Under a "you only have time to review 20% of the changed lines" budget, the deterministic score surfaced more of the real defects (recall 0.17 vs 0.07, Popt 0.61 vs 0.46). Similar at telling risky from safe, better at ordering what to look at first.

Where it falls down, because 0.74 is not magic:

• It tells you where bugs cluster, not what the bug is.
• Ranks files, doesn't read them so not a review replacement.
• Defect labels come from bug-fix commits, which is a noisy heuristic. Some "fixes" aren't, some bugs never got a clean fix commit. That ceiling is baked in.
• The 6-month window is a choice. Move it and the numbers move.
• The CodeScene edge is specifically ranking under a budget. On raw "is this file risky, yes or no," they're close.

Where I landed: the signal is real and it's reproducible, which is the part I care about for PR gating but it won't catch a logic bug in a 4-line diff.

It's good at "this PR touches a file that's been a problem for a year with one owner, slow down." Different job than line-by-line review, and I think it's the job the deterministic approach is actually good at.

I have also added agent provenance to the same which allows it to determine if an AI PR is worse than human

If anyone wants to take a look at the repo: https://github.com/repowise-dev/repowise

Also, if you have any feedback on the metrics itself or if I can try some new metric, would love to try that