Don’t kill the code reviews; just move the human checkpoint upstream to reviewing intent, specs, plans, constraints, and acceptance criteria. Code is actually the least important part of the reviews.

Code review has become the bottleneck. AI generates code faster than any human can read it, and asking another AI to do the reading doesn’t solve the underlying problem. The way out is to move the human checkpoint upstream, to the point where intent is defined, before any code is written.

The review bottleneck

Code review as a quality gate was already showing cracks even before AI coding tools. Microsoft research analyzed 1.5 million review comments across five major projects and found that as change size grows, the share of useful comments shrinks. Not fewer comments, less useful ones. We already stopped reading code for the most part.

Then AI coding tools arrived and broke the model entirely. Teams with high AI adoption are now merging 98% more PRs, while review times have climbed 91%.

We’ve all experienced how unreliable agents writing code can be, and no one wants to ship AI slop into production, so engineering teams keep telling themselves, “We caught AI doing dumb things once, so we must always check it.” They tell themselves that code review is the quality gate, but in reality, either PRs sit for days or engineers skim 500-line diffs and rubber-stamp approvals.

AI code review is still a code review

There is no way we’re outreading the machines. And when humans can’t keep up, the instinct is to use AI to review AI-generated code. Teams are already doing this with Cursor rules files, AGENTS.md configurations, and dedicated AI review tools. A senior engineer codifies years of review standards into a rules file. 

Engineers are creating their own AI-powered skill to review the code. Sometimes they also use famous personalities, asking AI to review code like Linus Torvalds or Kent Beck! The LLM reads incoming PRs against it. Developers skim the output and merge.

This approach inherits three failure modes that no amount of prompt tuning will solve. 

The first is non-determinism: the same code can produce different reviews in multiple runs. That is not a quality gate. 

The second is missing intent: the LLM reads a diff in isolation, pattern-matching against its training data without understanding what the code was supposed to do. 

The third is duplicate blind spots: when the same model writes the code and reviews the code, it misses the same things both times. You have not added a check. You have added a mirror.

“When the same model writes the code and reviews the code, it misses the same things both times. You have not added a check. You have added a mirror.”

Teams that built these rules files did the right thing. They articulated what they cared about. The mistake was dropping those standards into a system that cannot reliably enforce them.

Three conditions have to be met for a team to get off the PR-review treadmill without losing quality. Each is a maturity step, and each needs to be in place before the next one delivers real value.

1: Codify code review feedback into deterministic checks

There are two types of code review comments: something about coding standards, organizational standards, or expectations; and behavior/judgment-based comments – how a particular logic should function.

The first one should be a guardrail that can be checked through AST. Behavior can also be verified through execution tests; however, we should still review this during the human checkpoint.

Most standards that teams enforce repeatedly; things like “every new endpoint must have tracing spans” or “error paths must emit metrics” or “auth failures must be logged with structured fields,” are either statically checkable through AST analysis or verifiable through execution tests. 

A rule like “new endpoints must have OTel spans” becomes an AST check on route handler decorators. “Error paths emit metrics” becomes an execution test: hit the endpoint with bad input and assert that the counter increments.

When teams actually pull their last 100 PR review comments and sort them into three buckets (deterministic, execution-testable, genuine judgment), you might end with a split around 45/30/25. Three-quarters of review feedback may be codifiable. The work to codify it is real, but it is finite. Once a check is written, it never needs a reviewer again. This is where we can and should leverage AI and beat AI slop with AI.

2: Move the human checkpoint upstream

I’m not saying we should ‘dangerously skip reading code’ and stop reviewing AI-written code. The reviewer isn’t absent here; they’re more present than ever, just earlier.

Instead of reviewing a 400-line diff after the code exists, the reviewer reads an 8-line on intentpec before it does: acceptance criteria, non-goals, blast radius. The reviewer’s job shifts from “Does this look right?” to “Are we solving the right problem with the right constraints?” which is closer to an RFC review than a line-by-line code review.

“The reviewer’s job shifts from ‘Does this look right?’ to ‘Are we solving the right problem with the right constraints?'”

This is also where the knowledge-sharing function of review survives. When AI writes code, intent exists in a prompt that was never saved, a ticket that doesn’t capture the decision-making, or only in the engineer’s head. The implementation gets preserved. The reasoning behind it does not. 

Reviewing specs in the intent-driven verification process changes that. Reviewers reading acceptance criteria are reading the decisions behind the implementation, not the implementation itself. The decisions that matter, the ones currently lost in prompt conversations with agents, become the reviewable artifact.

In practice, this does not require a formal methodology. A Jira ticket with a few sentences on scope, a short list of acceptance criteria, and a note on what is out of scope can serve as the spec. The format matters less than the discipline of defining intent before generating code.

Use LLMs where deterministic can’t reach

Some review feedback is genuine judgment: pattern recognition over context or questioning an architectural choice. This is where LLMs earn their place, not as the primary check but as a scoped fallback.

The wrong approach is one where an LLM reads a diff and produces free-form opinions. The right approach is a separate verifier agent with no shared context with the implementing agent, a scoped prompt, and structured output with file references and reasoning for each finding. Let the verifier agent capture evidence using a deterministic methodology (screenshots, API responses, server logs) to reduce the likelihood of hallucinations.

Replace code reviews with verifying intent

This is the system we are building at Aviator. Verify accelerates code reviews with verified intent. Specs are written collaboratively with AI, reviewed and approved by humans, implemented with whatever coding tool the team prefers (Cursor, Copilot, Claude Code, or manual), then verified deterministically against each acceptance criterion.

Before submitting the change, your coding agent reviews the discussion and submits the intent and behavior details to Aviator. These get reviewed and approved by humans.

The difference from AI code review is fundamental. The same code always produces the same verification result. The system checks against declared intent rather than whatever the model notices on a given run. Verification becomes a matter of checking the output against agreed-upon criteria, not of trying to reverse-engineer intent from the implementation.

How long would it take for your team?

Here’s the homework for you. Pull your team’s last 1,000 PR review comments; it should take no more than a couple of hours. Sort each one, asking, is this deterministic, is this execution-testable, or is this genuine judgment? The first two are your guardrail backlog, concrete, finite, and prioritizable. The third is what’s left for humans (and LLMs).

From there, review the behavior, the intent, and the decision made while making the changes. These are the decisions the author makes while providing feedback to the agent in a terminal or IDE. Then review the evidence

Don’t kill the code reviews; “code” is actually the least important part of the reviews.

The post How long before we stop reading the code? appeared first on The New Stack.

Every platform team eventually reaches the same awkward moment. The first few Bicep files were clean. A virtual network here, a storage account there, maybe…

I am happy to announce that the updated edition of my free ebook, Blazor Succinctly , published by Syncfusion , is now available. What the Book Covers Rather than walking through disconnected snippets, the book covers the core elements of Blazor and then puts them to work by building a complete sample application: a Syncfusion Help Desk .     Along the way, the sample application demonstrates the things you actually have to deal with in a production app: Impleme

The One Where I Found My Way to DevRel

If you’ve watched Friends, you’ll know that life rarely goes according to plan. One day, you’re helping a friend move a couch while yelling “Pivot!”, and the next, you’re wondering how you ended up there in the first place.

My career has felt a little like that.

Growing up, I was always drawn to creative pursuits. You could usually find me with a book in hand, experimenting with calligraphy, sketching something random, writing poetry, baking a new dessert, or trying out a recipe I found somewhere online. Technology wasn’t the obvious destination (even though I love building!), storytelling was.

That love for explaining things eventually led me into technical writing.

Building docs for developers

I started working with startups, creating everything from API documentation and user guides to onboarding content and developer-facing resources. I loved the challenge of taking something complex and making it easier to understand. There was something deeply satisfying about helping someone go from “What does this even mean?” to “Oh, now I get it.”

For a while, I thought documentation was the destination. Plot twist! It wasn’t.

When I joined JDoodle (an web-based IDE), I found myself spending more time talking to developers. I wasn’t just writing for them anymore. I was listening to them, learning how they built things, understanding their frustrations, and seeing firsthand what made them excited about technology.

The more conversations I had, the more I realized something. The thing I enjoyed most wasn’t just creating documentation. It was connecting with people.

Finding my place in devrel

I started attending developer events and conferences. Then came product demos. Then booth duty. Then community conversations. Then hackathons. Then organizing internal events.

Somewhere along the way, what started as “I need to understand developers better so I can write better documentation” turned into “I genuinely love being part of developer communities.”

I discovered that my favorite moments weren’t necessarily publishing a new document or updating an API reference.

They were moments like:

• Watching a developer finally solve a problem after a conversation.
• Seeing people get excited during a product demo.
• Helping organize hackathons where creativity and technology collide.
• Meeting builders who were passionate about bringing their ideas to life.
• Learning something new from every event I attended.

As it turns out, the skills that drew me to writing in the first place translated surprisingly well into developer advocacy.

At their core, documentation and developer advocacy are both about empathy. They require understanding your audience, telling clear stories, and helping people succeed.

Joining the Okta community

Looking back, it makes perfect sense. The person who loved books, writing, art, and storytelling didn’t leave those interests behind when entering tech. She simply found a new audience.

Today, I’m incredibly excited to continue that journey at Okta.

I’ll be working alongside developers, creators, builders, and community members who are shaping the future of identity and security. I’m looking forward to learning, sharing, creating content, attending events, and most importantly, connecting with the people who make this community so special.

As Phil Dunphy said, “When life gives you lemonade, make lemons. Life will be all like, ‘What?!’” My career may not have followed a traditional path, but somehow it led me exactly where I wanted to be.

I’m excited to meet all of you. If you see me at an event, or find me on socials, come say hello. I’d love to hear what you’re building.

Most of Apple's current AI ideas are roughly the same as everyone else's AI ideas. A chatbot you can ask questions; quick ways to create or summarize text; bizarre, borderline creepy image-generation tools. The company spent most of its WWDC keynote playing catch-up with the state of the AI art, announcing Siri features you can already find on Android phones and in the Claude and ChatGPT apps. The pitch, in so many cases, is just "this thing you know, but on your iPhone now."

But a few minutes after I downloaded the first developer beta of iPadOS 26 (I didn't want to risk it on my Mac or my iPhone, both of which are too important to my dail …

Read the full story at The Verge.

The UK’s National Cyber Security Centre (NCSC) is urging organizations to take a closer look at their software dependencies as supply chain attacks continue to rise. The agency highlights how attackers are increasingly exploiting trusted open‑source packages to spread malicious code across systems.

According to the NCSC, modern development relies heavily on third‑party and open‑source components. This creates complex dependency chains, where a single compromised package can impact many systems quickly. Automated processes (like CI/CD pipelines) and implicit trust in packages allow malicious code to spread rapidly without human review.

Additionally, incidents targeting ecosystems such as npm and PyPI demonstrate how attackers can infiltrate developer tools and distribute malware at scale. Attackers exploit several weaknesses in modern software development, including secure developer environments, complex and highly connected dependency networks, automated processes that install and run code without manual checks, and open publishing systems with limited verification.

Common attack methods used in these campaigns include hijacking legitimate maintainer accounts to inject malicious updates, taking control of abandoned or unmaintained packages, and publishing deceptive packages with similar names to trick developers (a tactic known as typosquatting). Moreover, attackers often reuse stolen credentials to expand their reach and compromise more packages through self‑propagation.

How to detect and prevent supply chain compromises?

To detect a potential compromise, organizations should take a proactive approach by regularly auditing their software dependencies and reviewing recent updates for anything unusual. Moreover, IT admins must monitor systems, networks, and development pipelines for suspicious activity, along with using dependency scanning tools to identify known vulnerabilities or malicious packages. They should also check for unauthorized access to developer accounts, tokens, or registries to detect early signs of an attack.

If a compromise is suspected, immediate steps should be taken to reduce risk. This includes pausing automatic updates that could introduce malicious code, manually reviewing new dependencies or version changes, and rotating any exposed credentials. It’s also important to enforce multi‑factor authentication for developer and registry accounts, as well as to rely on trusted or private package sources to further strengthen defenses against ongoing threats.

In the long term, organizations should focus on building stronger security practices within their development lifecycle. Moreover, maintaining a clear inventory of all dependencies, such as through a software bill of materials (SBOM), helps improve visibility and control. It’s also important to reduce unnecessary dependencies, manage updates carefully, secure development workflows and credentials, and follow established frameworks like the Software Security Code of Practice to minimize exposure and strengthen resilience against supply chain attacks.

The post NCSC Warns Of Rising Software Supply Chain Attacks Targeting Open-Source Packages appeared first on Petri IT Knowledgebase.