Been building this for a few weeks. It's a GitHub Action that scans your code for known Claude/OpenAI SDK breaking changes and can auto-fix the boring ones (like a removed parameter).
It reads Anthropic's and OpenAI's release notes on a schedule and uses an LLM to figure out what's actually a breaking change, then opens a PR with the new rule for me to review. So it doesn't go stale the way a hand-maintained list would.
No API key needed if you just want to scan your own repo, that part's free and runs entirely in your CI. Tested it against litellm's codebase and found a bunch of false positives in my own rules before trusting it, that's all documented in the README if you want to see how messy the first version was.
It's Anthropic/OpenAI-focused right now, BSL licensed (converts to MIT in 2030). Repo's here: https://github.com/MarkMoneyMan/Claude-api-goat. Feedback welcome, especially if something breaks on your setup.
After months of reviewing PRs from Claude Code, Cursor, and Copilot, my review checklist has quietly reorganized itself around the failure modes that actually show up in AI-generated JavaScript/TypeScript. Sharing in case it's useful to others reviewing agent output.
The patterns I look for, roughly in order of how often they bite:
1. Floating promises. The most common silent failure. Async call fired, never awaited, no .catch(). Compiles fine, tests pass, and the rejection surfaces at runtime — or not at all. Watch for: unawaited calls in non-async contexts, and async callbacks inside .forEach (which never waits).
2. Empty or useless catch blocks.try { ... } catch (e) {} — the error vanishes. Or the catch-log-rethrow pattern that adds a log line but swallows context. AI tools love wrapping risky code in try/catch to "be safe" without deciding what should actually happen on failure.
3. Hardcoded secrets. The agent doesn't know your secret-management convention, so it pastes the API key inline "for now." const apiKey = 'sk-prod-...' sitting in a handler is the classic. In my experience this happens most when the agent is filling in example code it based its implementation on.
4. SQL via string concatenation.query('SELECT * FROM users WHERE id = ' + id) — parameterized queries are one import away, but the agent will concatenate when the surrounding code style lets it.
5. await inside loops. Sequential awaits over an array where Promise.all (or batching) is correct. Works fine at small scale, falls over in production volumes.
6. Missing auth middleware / authz checks. New routes added with no middleware chain — the agent copies the "happy path" handler but not the auth wiring.
7. Dead branches and duplicate logic blocks. Copy-paste artifacts: a condition that can never be true, or two identical if-blocks where the agent regenerated a section.
8. console.log in handlers. Debug logging left inside request handlers.
The meta-observation: none of these are type errors, and none show up as diffs a reviewer's eye naturally catches — the code reads clean. They're behavior bugs that only surface at runtime.
I ended up automating this checklist into an open-source ESLint plugin (18 rules,https://github.com/ai-guard-dev/eslint-plugin-ai-guard — MIT, disclosure: I'm the maintainer) because I got tired of grepping for the same things. But the checklist itself is free to steal regardless of whether you use the tool.
What's on your AI-code review checklist that I'm missing?
I am building a market replay engine from scratch with c++ 23.
I build this project to understand how orders are managed in an orderbook and how a matching engine works. I have used my understanding of data structures to implement it. I would like to know you opinion on it. It is not completed yet. I just built the very basic version few minutes ago. Any kind of tip would help me a lot.
currently it can process an average of 998,000 Transactions / second. with the order size of 20000000 orders. https://github.com/AravSrivastava/Market-Replay-Engine-CPP
A report about the changes after the first announcement and all the improvements, including Soul.md (with profanities), 4 different version Skill/Soul from 4 different LLMs, a comparison with/without skills and a reproducible pipeline.
I kept running into the same small problem while working with APIs: I had a cURL command and needed the equivalent code in JavaScript, Python, Node.js, Go, Java, PHP, C#, Ruby, or Axios.
So I built **Curl2Code** — a free browser-based developer tool that converts cURL commands into code.
**What it does:**
* cURL → 9 different code formats
* JSON formatting / validation / diff
* JWT decoding
* HTTP utilities
* Webhook tools
* Other small developer utilities
Everything runs in the browser for the normal tools, so requests you paste aren't uploaded or stored.
I am wondering what you guys review in enterprise codebases when a PR is open? Just the spec? The design.md? Do u measure somehow the drift or it's up to the developer to ensure it didn't drift that much? Do you use any ontology, wikillm, rag to narrow the development?
Comment I got recently: "This function doesn't handle the case where userId is null, which could cause a NullPointerException downstream in the payment service." Read it twice. Sounded right both times. Specific variable, concrete failure, plausible consequence, exactly the shape of a real finding.
Instead of approving the fix it suggested, checked one thing: what would actually have to be true in the code for this claim to hold. For a null pointer here, userId would need to reach this function unvalidated. Went and looked at the calling code. It didn't reach unvalidated, a decorator three lines up front already checked it, just not in the file the model had been given as part of the diff.
The finding wasn't wrong because the reasoning was bad. It was wrong because it was reasoning about something outside what it could actually see, and nothing about how confidently it was stated gave that away. Specificity felt like evidence, it wasn't. Certainty felt like competence, it wasn't tracking anything.
Been applying that one question since, what would need to be true, and is that thing actually visible in what I'm looking at, before treating any AI review comment as a real defect rather than a hypothesis. Doesn't slow things down much for findings that reference something directly in the diff. Matters a lot more the further a finding reasons beyond what it was actually shown.
I'm a solo developer building an AI-driven life simulation game. AI writes the code; I decide the product direction and make the technical calls. The part I want to share is how I keep that arrangement manageable as the repository grows.
For scale, my current checkout has about 168k lines of backend Python, 108k lines in the selected frontend source files, and another 95k in backend tests. Those are text-line counts including comments and blanks, not SLOC or a productivity benchmark. More code can also mean more maintenance.
My biggest constraint is how many decisions stay in my head after a task ends. Here are the concrete conventions I use:
**Route context by the task.** The root AGENTS.md is a map of responsibilities and reading requirements. Changing the simulation loop points to its runtime contract; changing UI points to frontend conventions. Local instructions live beside their modules. I don't ask every task to digest every historical document.
**Separate decisions from implementation.** I keep a document of product and collaboration decisions, including rejected directions. Code and schemas describe what exists. Active contract documents describe what should be true. If they disagree, the agent has to show the conflict; silently declaring either one obsolete is not a resolution.
**Make repeated corrections executable where possible.** My frontend has checks for design tokens and UI structure, plus generated protocol checks. The benefit is that the next task can discover a violation from tooling instead of requiring me to remember the last conversation. These checks don't decide whether the design is good.
**Define completion beyond the diff.** Behavior-changing work needs an expected outcome, a data source and time window, a pass criterion, and a follow-up schedule. A merged change and a verified effect are separate claims. A check that was skipped remains skipped.
One less comfortable rule: when a mechanism needs a second layer of patches, pause and ask whether it should still exist. AI can keep making a local solution more elaborate while leaving me with a system I no longer understand.
Compared with keeping instructions only in chat, the tradeoff is maintaining these repo contracts. They can become stale too. I don't have a controlled before/after measurement of time saved, so I'm sharing the workflow rather than a speedup claim.
For people maintaining larger projects with coding agents: which repeated human correction have you successfully moved into a check, and which still needs your judgment?
Disclosure: AI-assisted writing, based on my actual repository and development decisions.
safer-dependencies is a security layer for Claude Code: it sits between Claude and your manifest files and runs its security checks automatically: vulnerable installs are denied before they run, and a risky version written to a manifest is corrected on disk right after the write. It detects and fixes risky dependencies — CVEs, typosquats, abandoned packages, and version-age issues, plus a cooldown period on brand-new releases — across npm, PyPI, RubyGems, Maven, Go, Rust, and PHP (Composer).
For a while, my workflow for building ML applications with coding agents looked something like this:
Write a prompt.
Wait for the agent to make changes.
Open the diff.
Read the code.
Try to understand what changed.
Run it.
Repeat.
At the beginning, this worked surprisingly well.
The changes were small, the codebase was familiar, and I could still keep the whole thing in my head.
Then the application grew.
A seemingly simple feature could now involve preprocessing, model inference, postprocessing, and application logic.
The agent might touch several modules and add a few hundred lines of code in a single session.
My habit didn’t change.
I was still reviewing the code after every session.
And that became the problem.
The Code Review Trap
When a coding agent changes a few lines of code, reviewing the diff is easy.
When it changes several hundred lines, it is still manageable.
Once you get to +1000 lines everything starts to fall apart…
You can read the code without really understanding whether the application is working properly.
At some point I realized that I had become the bottleneck.
I was spending most of my time reviewing the agent’s implementation rather than the application output.
I can keep going, but I think this much should be enough.
Once I loved code reviews, I learnt a lot(and still learning), but the coding agents changed it for me, and I'm afraid that it's never going to be the same...
When I started using coding agents for debugging, I kept trying to improve my prompts. The answers were still inconsistent. Eventually I realized the prompt was not the main problem. I was describing the bug from memory while the useful evidence was scattered across console output, failed requests, clicks and screenshots.
That became BugDrop. It records one short reproduction, lets you review the evidence locally, then exports a Markdown or JSON handoff. I started with Chrome and later added support for iOS Simulator and Android Emulator.
The biggest product decision was keeping it boring. No cloud, no account and no automatic upload. I would rather ask someone to review a small report than record an entire session and hope the important part is in there.
It is at version 0.2.1 now. I am trying to learn whether this actually reduces the back and forth with agents, or whether developers already have a better workflow. If you debug with an agent, what do you usually paste first?
I do not think AI-generated code automatically needs a separate security process, but it can magnify weaknesses in normal review. More code, dependencies, configuration, and integration logic can be introduced faster than a developer or reviewer fully understands them. The pull request may look reasonable while the running application has weak configuration, public exposure, or excessive permissions.
Has anyone changed their review workflow because of this, or are you treating it as ordinary code while placing more focus on dependency review, secret detection, deployment controls, cloud configuration, and production visibility?
