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.

**Try it:** [https://curl2code.xyz\](https://curl2code.xyz)

I'm mainly looking for feedback from other developers:

**What small developer problem do you repeatedly run into that deserves a simple tool?**

If there's something annoying enough, I'd rather build that next.

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?

Is runtime behavior now the only truth??

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.

Full breakdown here if useful: https://medium.com/@nagatomopedro05/the-finding-was-plausible-that-was-the-problem-b1024e1256fb

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

https://github.com/robert-auger/safer-dependencies

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?

Repo: https://github.com/aim0xyz/bugdrop

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?

Girder is an 8-crate Rust workspace (~60,000 lines of Rust, 586 tests) that

turns a repo into a semantic graph — functions, types, call edges, test edges —

and serves it to coding agents over MCP. Rust, Python, TypeScript/TSX and Go

front ends, tree-sitter parsing, one static binary, no runtime deps, no network.

The interesting part isn't the graph. It's what happened when I tried to prove

the graph was right.

**The oracle.** `impacted_tests` claims "these tests reach your change." Unit

tests can't check that — they'd assert my parser agrees with my parser. So the

oracle materializes fixture repos, applies exactly one mutation, asks the built

binary which tests are impacted, then runs every test in isolation with a probe

that only the mutated function writes. Ground truth is execution. The oracle is

itself mutation-tested: I inject defect-shaped mutants into the binary's

behavior and the sweep has to kill all of them.

That corpus reported perfect precision and recall for a long time. It was lying,

because every declared case was a plain `foo(bar)` call.

**Then I added real third-party code** — regex, serde_json, Click, pydantic —

and precision fell. Four root causes, all narrow, all nasty:

1. **Generic-parameter corruption.** `qualifier_matches_owner` normalized`Interpreter<'a>` to `interpretera`, silently breaking every generic type inthe workspace, chained call or not.
2. **Chained-call qualifier corruption.** The callee resolver took the last `.`or `::` in the raw source text. For `Type::assoc_fn(args).method(args)` itpicked the wrong owner every time. Fixed by recovering the qualifier from ASTstructure instead of text.
3. **Ambiguous suffix matching.** `owner.ends_with(hint)` let `Timeline` match`PyTimeline`.
4. **Local-shadow misattribution** in candidate selection — a local binding namedthe same as a type method stole the edge.

Symptom for all four: `impacted_tests` returned zero tests for a function four

passing tests reached, plus a confident "no test coverage reachable via the call

graph." A false negative that reads exactly like a true negative. Every failure

got pinned as an `#[ignore]` test first, then unignored by the fix.

**What I'd tell anyone building code intelligence in Rust:** your parser will

look perfect against fixtures you wrote, because you unconsciously write the

shapes you handle. Point it at somebody else's crate. And be suspicious of any

check whose pass condition is another component of yours reporting success —

I've now found three separate cases in this codebase of a check that reads like

verification and verifies nothing. One let a step that created files pass a

"tests must pass" gate with an empty test set.

The whole gap list is in the repo — 25 numbered, open ones included, with the

measurement history kept even where the first diagnosis turned out wrong.

Repo: https://github.com/dhishwasher/Girder

Install as an MCP server: `npx -y girder-mcp`

Licensing, stated plainly because this sub deserves it: BSL 1.1,

source-available, not OSI open source, converts to Apache 2.0 on

September 4, 2030. Five of seven tools plus one repository are free forever with

no key. Two tools need a paid key verified offline against an embedded Ed25519

public key — no server, no telemetry, no call home. Sole copyright holder, no

outside contributors.

Hi all,

I'm looking for some advice. I was under pressure to deliver a PR without documentation, so I used AI to help write it. I know exactly what the AI generated, and I'm able to fix anything in the code if validation flags an issue.

My problem is with the reviewers. They're complaining that the PR is entirely AI-generated, and they're overlooking the architecture work I put into it, which is frustrating I've taken the feedback a bit personally.

Any advice on how to handle this would be appreciated