Inefficient review process for code and features, leading to excessive time spent on reviews compared to feature development

Signals over time

3 observed signals across 1 sources, tracked for 8 days. Confidence: low.

What people are saying Observed

• “I think this is definitely a legit failure mode with this model. We’ve hit some parts of it. For example, a plan reviewer kept pushing a technically valid but negligible security finding through five review rounds and about $70 before a human closed it as won’t-fix. The "Research Department" ran every three hours and was filing around 8 new issues a day, more than we could review. Review nits used to spawn new issues of their own. What helped us maintain a degree of sanity is that every stage records tokens, time, and cost in a ledger, so these show up as numbers rather than vibes. The fixes were mostly about giving a stage permission to stop. Plan review can now propose won’t-fix when the exposure is negligible. Research runs daily, with a cap on unreviewed proposals. Small fixes now ride along in the PR instead of becoming new issues. The other thing is that the quality bar should match the domain. Our migration tools move customer data into a database, so our question was “would we be embarrassed to have merged this?” For small apps I’d agree most of this is overkill.”

  Hacker News · complaint

• “Rolt: a reviewer for the PRs Cursor writes. Our team lets Cursor agents write most PRs now, and review became the bottleneck. The bugs mostly got caught; the slop didn’t: helpers rewritten instead of reused, dead branches, code that ignores the repo’s own patterns. So we built Rolt, a GitHub App that reviews each PR against the whole codebase and comments like a staff engineer: bug first, slop second, with the line and the fix. Bugs-only, balanced or thorough modes. Pay per review from $1, no seats up to 5 authors, 10 free credits. I’m one of the builders; I’d love to hear where it’s wrong or noisy. https://www.rolt.ai 1 post - 1 participant Read full topic”

  RSS Feeds · complaint

• “> How do you measure that? Vibes. Reviews take way more time than new features, and often utilize 3 subagents at a time - it's not uncommon to have reviews take 3 hours when the feature only took 15 minutes. The numbers here are just estimates, though - I don't keep track. "10x to 20x tokens on review" is probably underestimating review cost, if anything. I don't review all code, but I do spend down-time reading code. When I find obviously bad code/patterns/whatever, I don't just fix it directly - I work to create automated tests (like static analysis, almost) or adjust or create prompts and tools for agents (either for review stage or initial implementation) to solve that class of issue, instead of just that instance of it. I never review the first iteration. I review it after the agents have already poured a ton of time into it, if ever. I do sometimes watch agents work, and redirect them if I see them doing something dumb. But, usually, I have 5+ agents running, not counting sub-agents, and I'm just messing with the apps myself to find the next feature to create or polish.”

  Hacker News · frustration