Engineering Leadership

Claude Code Review and the New Economics of Verification

Anthropic’s new Claude Code Review feature is one of the clearest signs yet that the economics of AI development are shifting from generation toward verification.

The March launch is aimed at Teams and Enterprise customers and uses multiple specialized review agents to examine pull requests in parallel, verify findings, and rank issues by severity. Anthropic says reviews typically take around 20 minutes, cost roughly $15-$25 per PR, and increased substantive feedback from 16% of PRs to 54% internally. For large pull requests over 1,000 lines, 84% reportedly received findings.

GitHub Copilot's Real Upgrade Is Choice, Not Just More Models

On February 26, GitHub expanded access to Claude and Codex for Copilot Business and Copilot Pro users, following the earlier February rollout to Pro+ and Enterprise. On paper, this is a pricing and availability update. In practice, it is a product-definition change.

GitHub is turning Copilot from a branded assistant into a control surface for multiple coding agents.

Why This Is Bigger Than It Sounds

For a long time, the framing around Copilot was simple: GitHub had an assistant, and the main question was how good that assistant was. With Claude and Codex available directly inside GitHub workflows, the framing changes.

Codex Security and the Rise of AI Reviewing AI

The next big shift in AI-assisted software development is not more code generation. It is AI for verification.

OpenAI’s new Codex Security research preview, announced in early March 2026, is a good signal of where the market is going. The product scans repositories commit by commit, builds repository-specific threat models, validates findings in isolated environments, and ranks issues with proposed fixes. OpenAI says early adopters used it to detect more than 11,000 critical and high-severity vulnerabilities while cutting false positives by more than 50%.

Why AI Is Hurting Your Best Engineers Most

The productivity story on AI coding tools has a flattering headline: senior engineers realize nearly five times the productivity gains of junior engineers from AI tools. More experience means better prompts, better evaluation of output, better use of AI on the right tasks. The gap is real and it makes sense.

But there’s a hidden cost buried in that same data. The tasks senior engineers are being asked to spend their time on are changing—and not always in ways that use their strengths well. Increasingly, the work that lands on senior engineers’ plates in AI-augmented teams is validation, review, and debugging of AI-generated code—a category of work that is simultaneously less interesting, harder than it looks, and consuming time that used to go to architecture, design, and mentorship.

GitHub's Agent Control Plane: What Enterprise AI Governance Actually Looks Like

On February 26, 2026, GitHub made its Enterprise AI Controls and agent control plane generally available. The timing is notable: it came in the same week that Claude and Codex became available for Copilot Business and Pro users, and as GitHub Enterprise Server 3.20 hit release candidate. The GA isn’t a coincidence—it reflects an industry that has moved from “should we let agents into our codebase?” to “how do we govern agents that are already in our codebase?”

The PR Tsunami: What AI Code Volume Is Doing to Your Review Process

AI coding tools delivered on their core promise: developers write less, ship more. Teams using AI complete 21% more tasks. PR volume has exploded—some teams that previously handled 10–15 pull requests per week are now seeing 50–100. In a narrow sense, that’s a win.

But there’s a tax on that win that most engineering leaders aren’t accounting for: AI-generated PRs wait 4.6x longer for review than human-written code, despite actually being reviewed 2x faster once someone picks them up. The bottleneck isn’t coding anymore. It’s review capacity, and it’s getting worse as AI generation accelerates.

SERA and the Case for Open-Source Coding Agents That Know Your Repo

If your team has tried Cursor, Copilot, or other AI coding tools and found them underwhelming on your codebase—wrong conventions, missing context, generic suggestions—you’re running into a fundamental limit: those models are trained and optimized for the average repo, not yours. In early 2026, AI2 (Allen Institute for AI) released SERA (Soft-Verified Efficient Repository Agents), an open-source family of coding agents built for something different: specialization to your repository through fine-tuning, at a cost that makes it realistic for more teams.

Why Mandating AI Tools Backfires: Lessons from Amazon and Spotify

Two stories dominated the AI-and-work conversation in early 2026. Amazon told its engineers that 80% had to use AI for coding at least weekly—and that the approved tool was Kiro, Amazon’s in-house assistant, with “no plan to support additional third-party AI development tools.” Around the same time, Spotify’s CEO said the company’s best engineers hadn’t written code by hand since December; they generate code with AI and supervise it. Both were framed as the future. Both also illustrate why mandating AI tools is a bad way to get real performance benefits, especially for teams that are already skeptical or struggling to see gains.

The METR Study One Year Later: When AI Actually Slows Developers

In early 2025, METR (Model Evaluation and Transparency Research) ran a randomized controlled trial that caught the industry off guard. Experienced open-source developers—people with years on mature, high-star repositories—were randomly assigned to complete real tasks either with AI tools (Cursor Pro with Claude) or without. The result: with AI, they took 19% longer to finish. Yet before the trial they expected AI to make them about 24% faster, and after it they believed they’d been about 20% faster. A 39-point gap between perception and reality.

Getting Your Team Unstuck: A Manager's Guide to AI Adoption

You’ve got AI tools in place. You’ve encouraged the team to use them. But the feedback is lukewarm or negative: “We tried it.” “It’s not really faster.” “We don’t see the benefit.” As a manager, you’re stuck between leadership expecting ROI and a team that doesn’t feel it.

The way out isn’t to push harder or to give up. It’s to change how you’re leading the adoption: create safety to experiment, narrow the focus so wins are visible, and align incentives so that “seeing benefits” is something the team can actually achieve. This guide is for engineering managers whose teams are struggling to see any performance benefits from AI in their software engineering workflows—and who want to turn that around.

The Trust Collapse: Why 84% Use AI But Only 33% Trust It

Usage of AI coding tools is at an all-time high: the vast majority of developers use or plan to use them. Trust in AI output, meanwhile, has fallen. In recent surveys, only about a third of developers say they trust AI output, with a tiny fraction “highly” trusting it—and experienced developers are the most skeptical.

That gap—high adoption, low trust—explains a lot about why teams “don’t see benefits.” When you don’t trust the output, you verify everything. Verification eats the time AI saves, so net productivity is flat or negative. Or you use AI only for low-stakes work and conclude it’s “not for real code.” Either way, the team doesn’t experience AI as a performance win.

Measuring What Matters: Getting Real About AI ROI

When a team says they don’t see performance benefits from AI, the first question to ask isn’t “Are you using it enough?” It’s “How are you measuring benefit?”

A lot of organizations track adoption (who has a license, how often they use the tool) or activity (suggestions accepted, chats per day). Those numbers go up and everyone assumes AI is working. But cycle time hasn’t improved, quality hasn’t improved, and the team doesn’t feel faster. So you get a disconnect: the dashboard says success, the team says “we don’t see it.”

Why Your Team Isn't Seeing AI Benefits (And It's Not the Tools)

You rolled out AI coding tools. You got licenses, ran the demos, and encouraged the team to try them. Months later, the feedback is lukewarm: “We use it sometimes.” “It’s okay for small stuff.” “I’m not sure it’s actually faster.” Nobody’s seeing the dramatic productivity gains the vendor promised.

If this sounds familiar, you’re not alone. Research shows that while 84% of developers use or plan to use AI tools, only 55% find them highly effective—and trust in AI output has dropped sharply. Adoption doesn’t equal impact. The gap between “we have AI” and “AI is helping us ship better, faster” is where most teams get stuck.

Will Junior Developers Survive the AI Era?

Every few months, I see another hot take claiming that junior developer roles are dead. AI can write code faster than entry-level developers, the argument goes, so why would companies hire someone who’s slower and less reliable than Copilot?

It’s a scary narrative if you’re early in your career. It’s also wrong—but not entirely wrong, which makes it worth examining carefully.

Junior developers aren’t becoming obsolete. But the path into the profession is changing, and both new developers and the leaders who hire them need to understand how.

The AI Burnout Paradox: When Productivity Tools Make Developers Miserable

Here’s an irony that nobody predicted: AI tools designed to make developers more productive are making some of them more miserable.

The promise was straightforward. AI handles the tedious parts of coding—boilerplate, repetitive patterns, documentation lookup—freeing developers to focus on the interesting, creative work. Less toil, more thinking. Less grinding, more innovating.

The reality is more complicated. Research shows that GenAI adoption is heightening burnout by increasing job demands rather than reducing them. Developers report cognitive overload, loss of flow state, rising performance expectations, and a subtle but persistent feeling that their work is being devalued.

Comprehension Debt: When Your Team Can't Explain Its Own Code

Technical debt is a concept every engineering leader understands. You take a shortcut now, knowing you’ll need to come back and fix it later. The debt is visible: you can point to the code, explain what’s wrong with it, and estimate the cost of fixing it.

AI-generated code is introducing something different—and arguably worse. Researchers have started calling it “comprehension debt”: shipping code that works but that nobody on your team can fully explain.

The Case Against Daily Standups in 2026

I’ve been thinking about daily standups lately—specifically, whether they still make sense for engineering teams in 2026.

This isn’t a “standups are terrible” rant. I’ve run teams with effective standups and teams where standups were pure theater. The question isn’t whether standups are universally good or bad; it’s whether the standard daily standup format still fits how engineering teams work today.

My conclusion: for many teams, it doesn’t. Here’s why.

From Code Writer to AI Orchestrator: The Changing Developer Role

There’s a narrative circulating in tech circles: developers are evolving from “code writers” to “AI orchestrators.” The story goes that instead of typing code ourselves, we’ll direct AI agents that write code for us. Our job becomes coordination, review, and high-level direction rather than implementation.

It’s a compelling vision. It’s also significantly oversimplified.

Research shows that developers can currently “fully delegate” only 0-20% of tasks to AI. That’s not nothing, but it’s far from the wholesale transformation some predict. The reality of how developer roles are changing is more nuanced—and more interesting—than the hype suggests.

The 32% Problem: Why Most Engineering Orgs Are Flying Blind on AI Governance

Here’s a statistic that should concern every engineering leader: only 32% of organizations have formal AI governance policies for their engineering teams. Another 41% rely on informal guidelines, and 27% have no governance at all.

Meanwhile, 91% of engineering leaders report that AI has improved developer velocity and code quality. But here’s the kicker: only 25% of them have actual data to support that claim.

We’re flying blind. Most organizations have adopted AI tools without the instrumentation to know whether they’re helping or hurting, and without the policies to manage the risks they introduce.

The AI Productivity Paradox: Why Experienced Developers Are Slowing Down

There’s something strange happening in software development right now, and I think we need to talk about it.

Recent research has surfaced a troubling finding: experienced developers working on complex systems are actually 19% slower when using AI coding tools—despite perceiving themselves as working faster. This isn’t a minor discrepancy. It’s a fundamental disconnect between how productive we feel and how productive we actually are.

As someone who’s been experimenting with AI tools extensively (and writing about the results), this finding resonates with my experience. Let me break down what’s happening and what it means for engineering teams.

Building a Second Brain: A Review on Knowledge Management

I’ve been drowning in information for years. I’m constantly consuming content—technical documentation, team meeting notes, one-on-one conversations, architecture decisions, industry articles, conference talks, and the list goes on. The problem isn’t the volume; it’s that I’ve never had a good system for capturing, organizing, and actually using all of this knowledge when I need it.

That’s why Tiago Forte’s “Building a Second Brain” caught my attention. The premise is simple but powerful: create a system outside your head to store and retrieve information, so your actual brain can focus on thinking and creating rather than remembering.

How To Series: Standard Work Week

How many hours should employees expect to work per week? According to Jason Fried of Basecamp, 40 hours per week is more than enough. There are countless studies that have found that employees working more than 40 hours per week on a sustained basis see their productivity dwindle. I would expect that it is also a leading cause of burnout of employees.

Who wants a workforce of overworked, burnt out, and tired employees that keep seeing their performance dwindle over time? Instead, I’d much prefer a well-rested and well-rounded workforce that is able to maintain their performance over the long haul.

How Not To: Normal Working Hours

I was working at a company that was extremely strict about ensuring that their employees were working between 8am and 5pm during the week, and I had taken a Friday and a Monday off to enjoy some much needed relaxation away from work. I returned on Tuesday morning to discover that there were multiple customer emergencies that had to be taken care of, and would require working extra hours to be able to coordinate addressing the issue with outside consultants with minimal impact to the customer’s business. It took a couple of days to resolve that issue, and the rest of the week to get all the customer issues back in order. In all, over that Tuesday and Wednesday, I logged over 30 hours, and assuming a standard 40 hour work week, I worked almost 50 hours in those 4 working days that week.

How do you handle a developer that doesn't play by the rules?

Software development teams are fickle groups. It seems everyone has their own pet peeves that set them off, and a group that is cohesive and functioning well can quickly turn into one that shows little output for the time spent working.

In order to create and nurture a software development team takes leadership that understands all of the idiosyncrasies of their team members, and ensure that no one member derails the rest of the team. While some may use this as a way to discriminate against entire groups of people, if done properly, should only be utilized to maintain harmony after all hiring and performance decisions have been made.

The Number 1 Cause of the Not Invented Here Syndrome

One of the quickest ways to get a new internal tool bootstrapped is to utilize an existing design, making slight adjustments to ensure the design matches the requirements of the current project. Instead of using another internal tool as the basis for the new design, I used a design that was purchased specifically for this project.

This particular design was unique in that there were multiple working examples using AJAX, pure HTML, and AngularJS. While it was nice having supposed working examples, when you start to look at the readme file for how to get this functionality working on your own hosting setup, thats when the niceties disappear. Specifically when lookng at the readme file for AngularJS, it effectively says: “Because this is a well-known JavaScript framework, we are not including any documentation for how it works or how to get started with our design”. Granted, the inner workings of AngularJS need not be covered in the readme, but a simple walkthrough of what to expect this design to do would make things much more user/developer friendly.

The Top Sign You Hired The Wrong Developer

I have been a part of the interview process at a few different companies now, and there is one thing that I have seen correlate completely with how useless a developer hire is. If the hiring manager ever brings me a resume that mentions how many conferences a candidate attends or gives talks at, I will immediately rule that candidate out for the purposes of the development position I am interviewing for.

Top Job Applicants Never Stop Learning

From time to time, my job allows me to be a part of the hiring process for our technical positions. Unfortunately for some of the applicants, I repeatedly come away from these interviews amazed at the responses I get from pretty standard and basic technical questions related to Web Development.

Recently we were looking for a front-end web developer that was good at UX and design and proficient at HTML, CSS, and JavaScript. One of the things that we tend to ask everyone is to rate themselves on a scale of 1 to 10 as to how good they are with each technology. The majority of responses are in the 5-8 range with the corresponding answers to the questions about each techology falling about in the range you would expect. A couple of applicants were brave enough to rate themselves at a 9.5 out of 10 on HTML, CSS, and JavaScript, leading us to believe they were “exceptional applicants”.

Do you have too many big balls?

Managing a software development team can be a difficult task when everything is moving along exactly as expected. When you add in the paradigm shift of Agile Software Development with Scrum, management doesn’t always have the same insights into what makes up an efficient use of a development team’s time. For the rest of this post, lets assume that we are working with a 2 week sprint, with the first day half-used for sprint planning, and the last day half used for the sprint retrospective.

Estimating Software Development Projects is Hard

As a software developer, working with non-technical management and end users to define a deadline for when a project will be ready to use or how long it will take from start to end of a project is an extremely complex task. Unfortunately, the non-technical audience thinks that it should be simple to give some sort of estimation on the fly without detailed analysis of the project and what it involves, as it seems simple for them to estimate tasks that are like ones they have done before.

Micromanagement Ruins Teams

It seems that the management thinking these days is that managers should empower their employees to make decisions and implement the actions behind these decisions. This works great when you have a team and management that has mutual trust with a mutual goal. However, when the manager does not trust the members of the team, or thinks that they have to be the one to make every decision or have input into every task, the empowerment disappears.

Top 5 Ways to Make a Developer Your Enemy

Developers are known to be some of the most finicky employees you will encounter in the workplace. However, this is a list of things that will annoy or infuriate developers and non-developers alike.

1. Have the IT Manager send an email to all staff saying that all computers will have a keylogger installed. – This one is wrong on so many levels, the least of which is that it shows how little faith the company has in its employees and breeds mistrust of authority.
2. As a Manager or Team Lead, take ideas and suggestions from meetings with your team, and pass them off to upper management as your own. – This just reeks of someone that is only in it to gain more and more power.
3. As a Manager, don’t take the heat when things go wrong and blame the lowest-level employee instead. – I’ve seen senior management that is supposed to keep track of projects, ignore the project, and when it is the due date, blame those doing actual work on the project, throwing them under the bus.
4. As a new employee, on your second day of work, tell anyone that will listen or is within earshot that you are able to rewrite the entire codebase in three short months. Bear in mind, this codebase is over 7 years old and has a team of more than 20 developers working on it, but of course the newbie can rewrite the entire thing in no time flat.
5. As Management, when a developer hands in his/her resignation, schedule a meeting to try to first place a guilt trip on said employee to convince them to stay. If that doesn’t seem to work, then threaten to give the employee negative referrals if they don’t rescind the resignation and continue working for the company. Keep in mind that this occurred in a right to work state, meaning that there is no agreement in place that the employer would not wait a day or week or month and fire the employee without cause, just out of spite for wanting to work elsewhere.

These are just some of the things that will anger a software developer, so, be aware to avoid these if it matters at all to you.