{"id":502364,"date":"2026-06-20T10:43:18","date_gmt":"2026-06-20T10:43:18","guid":{"rendered":"https:\/\/www.newsbeep.com\/il\/502364\/"},"modified":"2026-06-20T10:43:18","modified_gmt":"2026-06-20T10:43:18","slug":"time-to-clean-up-human-slop-why-ai-now-reviews-code-better-than-your-teammate","status":"publish","type":"post","link":"https:\/\/www.newsbeep.com\/il\/502364\/","title":{"rendered":"“Time to clean up human slop”: Why AI now reviews code better than your teammate."},"content":{"rendered":"

As AI models now take over the core processes of writing code, the conversation has shifted to how effectively we can use AI itself to review<\/a> the codebases currently being created. If the consensus here suggests we should move the human checkpoint upstream, the question of just exactly where human developers should be working now comes to the fore.\u00a0<\/p>\n

It\u2019s a pain point that surfaces in teams where a mandatory peer review now risks serving mostly as a rubber stamp. A pull request sits in a peer review channel for a couple of days before another developer, who arguably has very little context for what the software engineer did in the first place, finally becomes available\u2026 only to say, \u201cLet\u2019s gamble. Try merging.\u201d<\/p>\n

\u201cWe must realize that it\u2019s time to clean up \u2018human slop\u2019 i.e. a class of error that humans make far more often than AI does. For these types of mistakes, an AI reviewer is much more reliable than a tired human.\u201d
\u2014Avital Tamir, groundcover.<\/p>\n

The pros outweigh the cons, I guess<\/p>\n

In most developer shops, this scenario still plays out; perhaps because there\u2019s some level of infinite optimism that says the pros outweigh the cons, perhaps also because it creates a sense of standardization and order in the software team.<\/p>\n

It\u2019s a question that\u2019s been nagging Avital Tamir<\/a> for some time in his capacity as a software engineer at groundcover<\/a>, a cloud-native observability platform company.\u00a0<\/p>\n

Calling for a change in the way software teams handle the code review process at large, Tamir tells The New Stack that he\u2019s not suggesting we turn over to all-out cowboy-coding chaos \u2013 he\u2019s simply making the case that the way we\u2019ve been doing code reviews for the past two decades needs to change with the times.<\/p>\n

\u201cThere\u2019s a lot of discourse about AI slop like hallucinations, misunderstood context and confident wrongness, and those are real concerns,\u201d Tamir says. \u201cBut we must also realize that it\u2019s time to clean up \u2018human slop,\u2019 i.e., a class of error that humans make far more often than AI does. For these types of mistakes, an AI reviewer is much more reliable than a tired human.\u201d<\/p>\n

A working example of human sloppiness<\/p>\n

The kind of human slop Tamir describes may be a familiar scene for many developers. Once a feature is complete, the programmer opens a pull request. Then it sits, marinating for a while. The developer pings their colleagues on Slack. Nothing happens on the first day, but after 48 hours, someone comments with a nitty-gritty niggle about variable naming or a question already answered in the code.\u00a0<\/p>\n

The developer fixes these nuisance factors, primarily because arguing takes longer than just fixing an inconsequential element of the code structure. After that, finally, an LGTM<\/a> (\u201clooks good to me\u201d) arrives.<\/p>\n

\u201cWhat did that accomplish?\u201d asks Tamir. \u201cA feature that could have shipped Tuesday ships Friday. Your competitor ships on Tuesday, finds the real bug on Wednesday, and fixes it on Thursday. Meanwhile, you\u2019ve spent two days in review limbo, optimizing for plausible deniability instead of iteration speed.\u201d<\/p>\n

He asks us to consider what that review time is actually catching.\u00a0<\/p>\n

\u201cThe bugs that really hurt, like race conditions, data edge cases, or failure modes under load, are rarely spotted by someone reading code in isolation without full system context,\u201d Tamir clarifies. \u201cThe feedback that does come through tends to be stylistic such as: \u2018use early returns<\/a>\u2019, \u2018extract a function\u2019 and so on\u2026 things that good static analysis should have caught automatically.\u201d<\/p>\n

If we multiply this process across dozens of engineers, multiple pull reviews per week, and multi-reviewer policies, it\u2019s not unreasonable to argue that the compounding cost becomes substantial, ultimately manifesting as lost shipped features and learning cycles.<\/p>\n

\u201cSelf-review isn\u2019t no review. It is a process designed to place review responsibilities more directly in the hands of the software engineer with the most context, and that\u2019s typically going to be the original author, obviously. Using an AI-augmented review process.\u201d <\/p>\n

The case for rigorous self-review<\/p>\n

Tools such as CodeRabbit<\/a> allow developers to codify a team\u2019s stylistic conventions as rules (\u201cuse early returns,\u201d \u201cprefer composition over inheritance,\u201d \u201ckeep functions under 50 lines\u201d) and apply them consistently to every pull request. Also in this space, we find Claude Code Review<\/a>, a new multi-agent tool designed to identify software bugs before a human reviewer even sets eyes on the code; Qodo<\/a> with its agentic software code development and review functions; and Greptile<\/a> for AI code review services, among others.\u00a0<\/p>\n

\u201cWith these types of resources at our disposal, I ask again: if AI is writing and reviewing the code, and a human with full context of the requirements has already verified the behavior, what gap does the asynchronous human approver fill when we should be championing rigorous self-review?\u201d argues Tamir.<\/p>\n

\u201cThe uncomfortable truth is that a lot of code review is just theater. It creates the appearance of rigor without reliably delivering it.\u201d<\/p>\n

But, he cautions, self-review isn\u2019t no review. It is a process designed to place review responsibilities more directly in the hands of the software engineer with the most context, and that\u2019s typically going to be the original author, obviously. Using an AI-augmented review process, Tamir describes his typical flow as follows:<\/p>\n

Work closely with the AI through every edit to read each change, steer it when needed, and understand what shifted and why.<\/p>\n

Run a full test suite on the code, and verify that \u201ccoverage\u201d (i.e., all lines of code that exist do in fact execute in the test) is meaningful, not just present.<\/p>\n

Manually verify the behavior end-to-end before opening a pull request for the code written thus far.\u00a0\u00a0<\/p>\n

Open the pull request and let the AI review tool run. Loop its comments back to the coding AI, decide which to act on and which to dismiss, and iterate.<\/p>\n

Merge, then monitor. Check error rates and metrics. Own the outcome.<\/p>\n

\u201cThat process is more rigorous than waiting 48 hours for an LGTM,\u201d\u00a0 Tamir says. \u201cPlus, it puts accountability exactly with the person who understands the problem. The uncomfortable truth is that much code review is just theater. It creates the appearance of rigor without reliably delivering it.\u201d<\/p>\n

It\u2019s a question of trust<\/p>\n

Given the presence of these kinds of AI-code review tools today and the propositions being made here, we may ultimately get down to questioning the fabric of software engineering team structure and the management approach that oversees it.\u00a0<\/p>\n

This brings trust into the picture. Tamir suggests that if leadership doesn\u2019t trust software engineers to review their own work responsibly, \u201cthat\u2019s a hiring problem, not a process problem\u201d in real terms.\u00a0<\/p>\n

\u201cTrust in high-performing teams is built through outcomes: shipping features that work, owning failures and fixing them fast, proactively sharing knowledge, and including colleagues in decisions. Those behaviors create a track record that a peer review approval queue does not,\u201d he concludes.<\/p>\n

Teams considering embracing some or all of these techniques may want to start with a low-risk internal software tool, or perhaps a greenfield service or a non-customer-facing system. In concert with this approach (and while the team measures its success, deployment frequency, rollback rate, etc.), they can reserve synchronous human collaboration for higher-stakes decisions.\u00a0<\/p>\n

This way, team collaboration might really start to matter and make a difference, and we could shift from LGTM to looks really good to me.<\/p>\n

\t<\/p>\n

\n\t\t\t\tYOUTUBE.COM\/THENEWSTACK\n\t\t\t<\/p>\n

\n\t\t\t\tTech moves fast, don’t miss an episode. Subscribe to our YouTube
\n\t\t\t\tchannel to stream all our podcasts, interviews, demos, and more.\n\t\t\t<\/p>\n

\t\t\t\tSUBSCRIBE<\/p>\n

\t<\/a><\/p>\n

Group
\n Created with Sketch.<\/p>\n

\t\t<\/p>\n

\t\t\t\t\t<\/p>\n

\n\t\t\t\t\t\t\tAdrian Bridgwater is a technology journalist with three decades of press experience. He has an extensive background in communications, starting in print media, newspapers and also television. Primarily working as an analysis writer dedicated to a software application development \u2018beat\u2019,…\t\t\t\t\t\t<\/p>\n

\t\t\t\t\t\tRead more from Adrian Bridgwater\t\t\t\t\t\t<\/p>\n

\t\t<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"As AI models now take over the core processes of writing code, the conversation has shifted to how…\n","protected":false},"author":2,"featured_media":502365,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[345,343,344,85,46,125],"class_list":["post-502364","post","type-post","status-publish","format-standard","has-post-thumbnail","category-artificial-intelligence","tag-ai","tag-artificial-intelligence","tag-artificialintelligence","tag-il","tag-israel","tag-technology"],"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/posts\/502364","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/comments?post=502364"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/posts\/502364\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/media\/502365"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/media?parent=502364"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/categories?post=502364"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/tags?post=502364"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}