Show HN: i built an AI code reviewer for github (used it on itself during dev)

Show HN: i built an AI code reviewer for github (used it on itself during dev)(codii.dev)

6 points by cepstrum9 1 year ago | 6 comments

I’ve spent the last 2.5 months building a product that runs LLM-powered code reviews on my pull requests — and I just launched it.

The tool is built specifically for solo developers. You install it on your repo, trigger a scan by creating a pull request, and it leaves structured review comments using OpenAI under the hood.

Funnily enough, I used the dev version of this app to review its own pull requests while building it. It helped me spot bugs, simplify structure, and keep quality high — all with minimal need for another human in the loop.

Things I want to try out in the next months : - Model integrations beyond OpenAI: Claude, Gemini, DeepSeek, LLaMA

- Bring Your Own Model (BYOM)

- Smarter review agents: repo memory, config-awareness, custom rules

Right now I’m focused on getting feedback from devs and evolving based on what actually helps.

Try it here: [https://codii.dev]

I’d love feedback on:

- Are the reviews actually useful for you or noisy? - What would make this fit into your workflow? - Anything obviously missing, confusing, or broken?

Happy to answer any questions! (feel free to dm me on X https://x.com/cepstrum9)

ramon156 1 year ago |

Concept is interesting. Few things I'd like to say

- 9$/mth for what? To insert my API key? I'm assuming you're not paying for my Claude bill.

- The "Why Consider Codii" section is inconsistent and doesn't really explain why I'd use Codii. Also you cannot claim it's consistent (because LLM's can't be consistent, but that aside) without at least some examples.

- 10 scans a month is not enough when trying out a tool, I'd want one team member to be able to use it for his workflow, and you're not going to make it through the first two weeks with 10 scans. I understand that the target audience is solo devs, but what makes this exclusive to solo devs? Why aim for such a niche market? It says "no more waiting on team members", so it's not only solo devs that you want to target. Lean into who you are targeting.

- This site uses modern tools but still feels clunky (icons not sizing nicely, divider doesn't fill the screen, etc.). Inconsistencies on your landing page is a big no-no, and shows how low the bar has been set for the end product. There are pre-made landing pages (e.g. astro templates) that come over as more professional.

That aside, congrats on the launch. Hope you make something of it!

cepstrum9 1 year ago | |

First of all, thank you for taking the time to write this, I appreciate it!

- you re spot on the pricing - I have no clear plan yet on the tiers and the exact figure per month - there are 2 options for me here as I see it: a) implement token based pricing to cover pricing for workflows that use my service’s OPENAI key b) allow users to just use their own API key, and just charge the extra organisation layer that my app provides - this would probably be in ~3-5 p.m

- why consider codii - thanks for calling out the inconsistency bit, I ll update that to be phrased more correctly, the basic idea is - code reviews on every pull request as an extra QA check.

- your 3rd point is bang on - 10 is pretty low, and ideally I d be able to sustain a free tier with more scans per month(logistics a bit complex to get right). I ve actually updated that to 100 but have not reflected on the landing page, definitely something I need to do. Re target audience, you ve spotted my confusion there as well, this is indeed aimed for solo devs for now, in which case I should not be claiming team-based benefits. So I want to evolve this slowly starting from solo devs and working my way up to small teams. The action I’m taking from this is to focus on realistic target audience not the one I d like to have in 2 years time.

- re clunky landing page, again you’ve got a solid point there, clunkiness can feel repulsive, this is me basically sacrificing UI for functionality in the chase of feedback, the action I’m taking is to polish up th landing page so that it doesn’t scare people away .

Thank you for the encouragement and the solid feedback! This is exactly what Im after in the current stage!

mmarian 1 year ago |

Curious how it compares with GitHub Copilot? https://docs.github.com/en/copilot/using-github-copilot/code...

cepstrum9 1 year ago | |

Hey, so, Codii is much simpler under the hood: it’s core is a smart prompt + LLM model that runs on pull requests. It doesn’t yet have deep static analysis, embeddings, repo-wide understanding or customisable rules — but it focuses on delivering helpful, lightweight code reviews with minimal setup.

GitHub Copilot Reviews is much more integrated into the GitHub platform and can access richer context like the full diff, surrounding files, and maybe repo history. It’s probably more sophisticated behind the scenes.

That said, Codii is:

• Easy to install (just a GitHub app)

• Fast to iterate on (I can tweak the prompts based on feedback)

• Customizable (it’s mine, so I can steer it toward indie dev use cases like onboarding help or documenting design choices)

In terms of requests and pricing, I believe GitHub Copilot free is going to offer 2k completions and 50 chats per month per user starting May 2025, and offers a Pro plan @19$ per user I think where you actually get access to much more than just reviews just to be clear, whereas Codii for now will be free until I gather feedback, but will be limited to 200 scans per month per user. Planning to offer a paid plan soon around the ~10$ mark

TL;DR: Codii is like a minimalistic, customizable code review assistant powered by GPT — not as powerful as Copilot Reviews yet, but very easy to set up and iterate on

kostas_f 1 year ago |

Congrats on the launch!

I’ve tried several AI code reviewers in the past few months and honestly, most of them fall short in the same ways - they lack proper context about the codebase and can’t remember discussions from previous PRs or design decisions.

IMO the tools that will win this space will be the ones that properly understand the codebase context and coding/architecture patterns.

Btw are you also planning to support customizable rules for code reviews?

cepstrum9 1 year ago | |

Hey thanks! You re spot on, understanding the codebase context is key and maintaining history of the repo is perhaps the top problem to solve going forwards.

Also, there is context that’s not just code but documentation/guidelines etc, plenty of experimentation to be done there.

Customisable rules? YES - i ve got a lot of plans currently on this. I see two layers of customisation: - allow the user to customise when and how often reviews happen, and how they re triggered (i.e every commit/every x mins etc, avoid running prs on specific files I.e package.json changes etc) - pass in custom rules to the reviewer that work well for you(or team in the future). This will allow the tool to be more dynamic in nature as opposed to just LLM + your code.

Hope this answers your questions, thank you for the support!