DEV Community: Jake Lundberg

How to Tell If a New Tool Will Become One More Thing You Mute

Jake Lundberg — Mon, 09 Nov 2026 17:17:34 +0000

You've probably muted a bot at some point. Or maybe a whole channel.

It usually starts out fine. The tool posts something useful, people read it. It's a win! But then it posts again. And again. And again. Pretty soon it's just part of the background. In a channel where everything is technically an alert, nothing actually gets read.

So when a team hears about a new tool, a really common reaction is "not another thing I have to keep track of." I've certainly had this reaction myself...

I've been building a tool that tells teams which pull requests need a closer look. The hardest part of building something like that is the line between useful and nagging. Cross it and you've taught the team to ignore you.

Here are the questions I'd ask about any tool before letting it into your team's day.

Does it show up where you already work?

A heads-up is only worth something if people actually see it. A dashboard nobody opens catches nothing.

The best place for a signal is the one people already look at. If you have to remember to go check somewhere new, you probably won't.

Does it keep one thing up to date, or keep adding more?

Some tools post a new comment every time something changes. After a few pushes, the thread is a wall of bot messages, and you have to dig to find the real conversation.

One note that stays current is a lot easier to live with than ten that pile up.

Does it tell you why?

A flag with no reason behind it is hard to trust. If a tool says a change is risky, it should say what made it risky...so you can decide for yourself if it's right.

Does it know when to stop?

Nobody really reads a list of 30 things. It looks like a wall of text, and people skim right past it. A short list of the ones that matter most is a lot more likely to get read.

Can you set your own line?

Every team is different. What's risky enough to slow down for on one team might be totally normal on another. A tool that decides that for you is going to be wrong for somebody.

Can you turn it off?

If a tool stops being worth it, getting rid of it should be easy. A tool that's hard to remove is asking you to trust it a lot up front.

How I'm answering these with Merge Lantern

Here's how I'm trying to stay on the useful side of that line with Merge Lantern.

The risk score shows up right on the pull request, where the review already happens. It's one comment, and it gets updated in place as new commits come in. There's no pile of bot messages to crawl through.

Risky PRs also get a label, so you can see them in the pull request list without even having to open anything. Low-risk PRs don't get a label at all, so the list stays quiet.

Every score comes with the reasons. There's a short note on why it scored the way it did, plus the signals that fired, like a database migration or no tests changed.

The daily digest shows 5 pull requests, and that's it. Anything longer starts to look like a wall of text.

Each repo can set its own risk bands in a config file, so your team decides where its own line is.

And if it stops being worth it, you can take a repo away from it on GitHub, or uninstall it.

What I'm still working on

I don't have all of this figured out yet. Right now, a low-risk PR gets the same kind of note as a risky one, just calmer. My current thinking is that it should show what didn't fire...no sensitive code touched, tests changed along with the code, the author has worked in that area before. A low score with no reason behind it is hard to trust too.

That's the bar I'm holding it to. If it ever turns into noise, it has failed at its job.

What's made you mute a tool in the past?

I'm building Merge Lantern, risk intelligence for small engineering teams. It flags which open pull requests most need senior eyes before they merge, in one short daily digest. It's early, and the first 5 design partners get their first 3 months free. If your team feels this problem, join the waitlist at mergelantern.com.

[Boost]

Jake Lundberg — Thu, 05 Nov 2026 01:05:33 +0000

Hackers exploited automated mention emails

Jack

Nov 4

How Hackers Weaponized DEV.to's Mention System to Spread a Phishing Scam

#security #devto #phising #community

3 min read

The Thing That Makes a Small Team Fast Is What Makes It Fragile

Jake Lundberg — Mon, 02 Nov 2026 18:23:42 +0000

Small teams are fast. I don't think that surprises anyone.

There's less to coordinate. Fewer meetings, fewer approvals, fewer people to keep in the loop. I saw a post a while back that put it well...the question leaders should keep asking is "what's the smallest group that can own this problem end-to-end?" Ownership scales a lot better than coordination.

I agree with all of that...but there's also a part of it that I think gets skipped a lot.

Where the speed comes from

A small team is fast because the whole problem lives in two or three heads. Nobody has to write a long doc or wait on another team. The people who need to know already know.

That's also exactly what makes it fragile.

When one of those people leaves, a big chunk of how things actually work leaves with them. A big team might barely notice, but a small team feels it right away.

"Owns it" quietly turns into "only two people understand it"

Nobody really decides this...it just happens.

From the outside, everything looks great...the team ships fast and everyone knows who to ask. But that's the problem...everyone knows who to ask, because the answers only live in a couple of heads.

So the target is still the right one. Go for the smallest group that can own the problem end-to-end. Just watch for the day "they own it" turns into "only two people actually understand it."

What actually leaves with them

When someone leaves, the cost usually gets counted as a job posting plus a few months for the new person to ramp up. Honestly, I think that number is way too low, because most of what walks out the door didn't only showed up in a commit.

There's the map of how everything connects. The code stays, and anyone can read it. What leaves is things like knowing that changing one area quietly impacts two others. The team can still make the change. They just can't see what else it might touch anymore, so the side effects show up in production.

There's the list of shortcuts. Every system has patches that were only meant to hold until later. The person who left usually knew where they were. Without them, the team treats the whole thing as solid.

And there's the biggest one, if you ask me...the relationships. They might have been the person everyone DM'd to think something through, ask for advice, or share a worry. You can fill the seat. You can't really fill that.

Relying on what your seniors know

When you ask a team how they keep track of what's risky, a really common answer is that the senior people just know.

And they probably do. But that's a risk in itself! What's risky in your codebase frequently lives as gut feel in a few senior heads, and it walks out when they do.

It's easy to read that person as your most valuable engineer. They hold all the context and everyone goes through them. But that person is also a single point of failure, regardless of how good they are.

Managing it on purpose

There isn't a nice and tidy fix here. You don't want to give up the speed, and you shouldn't...especially not in today's crazy pace. Speed and fragility come from the same place, so the job is to manage the concentration on purpose. But there are a few things I'd recommend looking at:

Write down the decisions, not just the code. In my own projects, I write down the trade-offs I made, the use cases I covered, and the things I chose not to build. It takes a lot less time than it used to...I just ask the AI to sum up the decisions from the session. (You can look up ADR's if you want to learn a little more about how I am managing this.)

Use what's already broken. Your past incidents are an honest map of what's risky in your codebase. Get that map out of a couple of heads and into something the whole team can see.

Spread what you know. Making yourself irreplaceable feels like job security, but it really just makes you the single point of failure. Making the people around you better is the thing that actually lasts.

Keep the team small

None of this is an argument against small teams. They're fast for a reason. And honestly, I prefer working with small teams for a lot of reasons!

Just go in with your eyes open. The same thing that makes your team fast is what makes it fragile, and it's a lot easier to manage before someone leaves than after.

How does your team keep "owns it" from turning into "only two people understand it"?

How to Make the Business Case for Slowing Down (and When Not To)

Jake Lundberg — Mon, 26 Oct 2026 13:01:16 +0000

Last week I wrote about the two kinds of friction in an engineering process...the kind that just slows the work down, and the kind that catches risky changes before they ship. Someone left a question on that post that I think deserves a real answer.

Here's roughly what they said. The friction that slows things down shows up on every dashboard...cycle time, lead time, how long a PR sits waiting. But the friction that actually catches stuff? That doesn't show up anywhere. You only see what it was worth in an incident review, and nobody ever connects that incident back to the step that would've caught it. So how do you defend a "wait, should we?" when the case against it has numbers, and the case for it is just a story?

Honestly, I think that's how a lot of good process steps end up getting cut. And I think the fix is simpler than it sounds.

You can't out-argue a missing number

So say you raise a risk with leadership, and nothing happens. The usual advice is to communicate better...put it in business terms and be more convincing.

And sometimes that really is the problem, and better words fix it. But a lot of the time, they understood you just fine. The feature they picked has a revenue number on it. The risk you raised is a guess about something that might go wrong someday. A win you can count today beats a maybe-cost later almost every time, no matter how well you argue it.

You can't out-argue a missing number. You can go find one, though...and that's a different job than trying to be more convincing.

Your experience is already a number

Here's the part I think a lot of engineers miss...if you've been doing this a while, you probably already have the number. You just don't think of it as one.

Someone put it to me like this a while back. They couldn't prove their system stayed stable because they kept a dependency up to date. But they knew from experience that falling behind on updates causes a lot more pain down the road.

That's more than a hunch, if you ask me. They've watched what happens to teams that skip those updates, and that's real information. It just isn't in a form the business can compare against anything yet...like hours, or dollars. Until you put it in those terms, there's nothing for the other side to weigh it against.

Turning it into a number

In my experience, there's almost always some kind of number you can find for the "it's just a story" side. A couple I'd look at:

Time now vs time later. Spending an hour today on something that could cause hours of downtime later? That's a really useful number to share. But if the time involved is tiny, that tells you something too...maybe you don't need the pause after all.

Cost now vs cost later. Businesses understand money. If you can put a dollar amount on a change, it can sway a lot of decisions...and revenue lost from an outage is a powerful number. If the cost comes out low though, that's a sign you might not need the "should we?" either.

And that part matters. If you're honest about it, the numbers can tell you to drop a step just as easily as they tell you to keep it.

Sometimes the answer is "not right now"

There's one more thing, and I think it's the one engineers skip the most. Sometimes the answer to "should we?" is yes...followed by "not right now, we've got bigger priorities."

As engineers, it's really easy to get tunnel vision and only think about the technical side of a decision. But a business is more than the tech...there's sales, users, customers, money. That new feature might be the difference between landing a big client or not. It might keep a client you already have. You might be losing users to a competitor and need to stop the bleeding as fast as you can. And an imperfect feature can often keep users around, then get better later.

So even when you technically should do something, there might be a good reason not to do it right now.

Look at the whole business

It all comes back to one thing. You can't just make the technical argument. You've got to think about the business as a whole.

That's why I think it's so important for engineers to understand more about the business side of things...so the calls you push for aren't just leaning toward the tech.

AI Made Coding Faster. Now Teams Are Cutting the Process That Catches Risky Changes

Jake Lundberg — Mon, 19 Oct 2026 16:02:31 +0000

There's a piece of advice I've been seeing a lot lately...reduce friction, protect your engineers' focus, make the common path the easy path, and cut the unnecessary approvals, tickets, and handoffs.

And honestly, I think most of that is good advice. A lot of engineers end up as part-time administrators. They fight with environment setup, hunt for the right doc, and chase a permission across four different teams before they can even start on the actual problem. That stuff should go, no argument from me.

But "reduce friction" isn't the entire idea, at least the way I see it. And the missing half matters a lot more now that AI is in the picture.

AI moved the bottleneck

Coding agents made writing code a lot faster, and by now there are tons of posts about where the work went. It piled up downstream...in planning, in review queues, in QA, in release approvals. PR volume jumped, and delivery dates barely moved.

The fix I keep seeing for that is to reduce friction across the whole delivery process, so all that new code can flow through every step faster. That's where I think it starts to go wrong. When a team decides it has a speed problem, it tends to treat every bit of friction as waste, and some of that friction was actually doing a valuable job.

Two kinds of friction

The way I think about it, there are two piles.

The first is accidental friction...things like environment setup, hunting for docs, and chasing permissions across teams. That's pure tax, and it should go to zero.

The second is essential friction, which is the small "wait, should we?" before a change. In my experience that little pause is the cheapest insurance a team has.

The water filter

To explain this, I like to use an analogy of a water filter. A filter needs friction to catch anything. Take all of the friction away and nothing gets caught...the water just runs straight through. Add too much and nothing flows at all. Clean water comes from getting the balance right between the two.

Code review is friction like that...it's where the risky changes get caught before users find them.

"Make the common path the easy path" is great right up until the common path runs straight through a risky change with no speed bump left on it. Optimize away all the friction, and you usually pull the guardrails out along with the bureaucracy. And it works for a while...you feel fast, right up until that first risky change slips through with a bug in it that impacts every one of your users.

So which kind is it?

I don't have a clever framework for this. For me it comes down to the pros versus the cons. When I look at a step in our process, I ask three questions. Is there a benefit to having this friction? What do we gain by getting rid of it? And what do we lose?

If you run environment setup through those questions, there's no real benefit to it, you get time back by fixing it, and you don't lose anything.

Run the "wait, should we?" before a migration through them and you'd get a little time back by removing it. But you'd also lose the one moment where someone stops and asks whether this change could hurt users.

From my perspective, the teams getting the most out of AI, put the friction where the risk is and strip it out of everywhere else.

So before your team removes the next step from its process, it's worth asking what that step is getting you, and what you'd lose without it.

When the Same Names Fill the Reviewer Column

Jake Lundberg — Mon, 12 Oct 2026 14:44:34 +0000

Last week I wrote about setting review depth based on what a change touches. Lower risk work can get a lighter review...but higher risk work should get full attention, no matter who or what wrote it.

Someone pushed on that in the comments, which surfaced the next problem that could present itself. High risk work almost always needs experienced, senior eyes on it, which tend to be the same two or three people on your team. Look at who reviewed your high risk PRs over the last month, and you'll probably see the same names week after week.

His question was how you spread that load without lowering the bar. I think there are three things worth looking at.

A risk signal does two jobs

When you watch risk this way, it tells you when a change needs senior eyes. But it can also tell the team when it's taking on too much risk at once.

If the same few seniors are full week after week, that might be a planning problem more than a review problem. Too much high risk work is moving forward at the same time, and all of it lands on the same people. That's something to fix in scheduling and planning.

So the first place I'd look is the plan. How many high risk tickets did the team take on this sprint, and did anyone decide that on purpose?

Chisel the low-risk work away

It could also mean authors aren't breaking the work up as well as they could.

A lot of work can be split. Say one PR mixes a change to how money moves with a handful of small UI updates. The whole thing gets treated as high risk, and the whole thing goes to a senior. But the author could pull the lower risk pieces out into their own PRs, and they don't need the same reviewers. The high risk part gets smaller, and the senior review gets more focused.

This one is easy to try, and it doesn't need anyone's permission. The next time a big PR shows up, ask which parts could have gone out on their own.

Grow the list of people who can review it

The last one takes longer, but it matters the most.

As those high risk PRs come in, it's a good time for seniors to work alongside less-senior folks and coach them in those areas. Over time, more people can review the high risk work, and the load spreads without lowering the bar.

There's a second reason to do this. If only two people can review changes to billing, those two people are a single point of failure. When one of them leaves, the team loses more than a reviewer. It loses the person who knew how billing connects to everything else, where the temporary patches are, and what has broken before. Spreading that knowledge out is a risk control on its own.

Go look at the review column

You don't need a tool to start. Pull up the high risk PRs your team merged in the last month and look at who reviewed them.

How many different names do you see? And if it's the same few, which of these would you try first...planning less high risk work at once, splitting it up, or growing the list of people who can review it?

How Hard Should You Review This? Ask What It Touches

Jake Lundberg — Mon, 05 Oct 2026 12:28:06 +0000

When a pull request shows up and an agent helped write it, the first question a lot of reviewers ask is "did an agent write this?"

I get why. We built a lot of our review habits around who wrote the code. A senior engineer's change got a lighter look. A new hire's change got a closer one. Code that two people paired on often got a lighter review too, because pairing had built up a track record. Who wrote it was a quick way to guess at risk, and for a long time it worked well enough.

I think it's the wrong first question now. This post is about what I'd ask first instead.

Where my last post on this left off

Back in August I wrote about why pair programmed code earned a lighter review, and why developer-plus-agent code hasn't earned it yet. A reader took it one step further in the comments...if agent-written code hasn't earned the discount, it should need more evidence before it merges.

I don't agree with that as a starting point. If you follow it all the way, every agent-written change gets the heavy review. That includes the one-line copy fix and the routine dependency bump. With agents writing more and more of the code, that's a lot of reviewer attention going to changes that were never likely to hurt anybody.

Start with what the change touches

A lot of teams I've seen and spoken to give every change about the same review. A simple UI update and a change to how money moves get roughly the same look. With agents writing more of the code, that gets riskier. The mistakes are harder to spot, and there are a LOT more changes to look at.

So I'd start somewhere else. Before you open the diff, look at what the change touches. Billing? Auth? A database migration? An area that's broken before? Then decide how hard to look.

Is it a lower-risk area, where it's okay if AI missed something? Or is it a core function the business needs, where it calls for much more scrutiny?

Where authorship still fits

Authorship still matters...I just treat it as an adjustment after the risk level is set.

How I think about it is agent written code doesn't earn extra scrutiny just for being agent written. I look at what the change is touching to decide that. Low-risk work gets a lighter review whether a person, an agent, or both produced it. High risk work gets my full focus and attention either way.

Where authorship does move the needle is on that high risk work. Take the same high risk change. If a developer and an agent built it, it gets my full attention. If two humans paired on it, I'd probably still go a bit lighter. The pair discount hasn't gone anywhere...it just doesn't transfer.

It also moves the needle earlier. On risky work, I'd rather get senior eyes on the plan before it's ever a pull request. Once someone builds a bad idea, review can't do much with it. By then the only question left is whether to ship it or not.

Some changes may need very little review

I'll go a step further. There are PRs that would be fine with a light human touch. There are probably some that could move forward without human eyes at all. That frees up your reviewers to focus on the changes that really need them.

Where that line sits is up to each team and how comfortable they are. Lower risk still means some risk. A small change in a quiet corner can still have a bug in it. A lighter review is a bet that if something slips through there, it won't cost much. Your team gets to decide how much of that bet it's willing to make.

What I'd push for is drawing that line on purpose. Most teams inherited their review shortcuts without ever writing down what earned them. When a new kind of change shows up, like agent written code, it gets quietly sorted into whatever bucket already exists.

How to tell what a change touches

Most of this you can look up in a few seconds. In my last post I suggested three lookups before you trust any review. What paths does the change touch? What's the history of those paths? Did the tests move with the code? The same three work here. They give you a sense of how hard to look before anyone reads a line of the diff.

So, here's my question for you and your team. When a PR lands, what decides how hard someone looks at it? And if you have a lighter review lane, what has to be true for a change to get into it?

Where Trust in Automated Review Actually Comes From

Jake Lundberg — Mon, 21 Sep 2026 13:19:33 +0000

There's a tempting fix for the moment your team stops trusting its AI code review...add a second AI to check the first one.

I get why. We do the same thing with people...if a change is risky, we put two reviewers on it, because two people miss less than one. It seems like the same trick should work with models.

I don't think it does. The problem is where a model's judgment comes from. Two models trained on roughly the same internet are going to be wrong in roughly the same ways. When two human reviewers agree, that tells you something, because they built their instincts in different places...different bugs, different codebases, different scars. When two models agree, most of what you've learned is that two systems with the same blind spots read the same text. The second opinion came from the same school as the first one.

What the diff leaves out

The bigger issue is (and this applies to human review too), most of what makes a change dangerous is not visible in the diff alone. Whether the test it touched actually guards anything. Whether the author (person or agent, doesn't matter) has ever worked in that part of the system. Whether that area has a history of breaking. Whether it lands in your billing path or in some quiet corner. You can read the diff five times and you won't find most of that. So a second model re-reading the diff mostly just buys you more re-reading.

The surface of a diff is also easier to fool than we like to think. A study out of MSR '26 looked at 3,858 pull requests and found that reviewers responded more warmly to agent-written code than to code people wrote. The researchers theorize that agent output looks plausible by design, so reviewers relax without noticing they're doing it. But plausible-looking code is the thing a model produces most of the time. Judging by the surface stopped being a safe habit.

What I'd add instead

Facts. The stuff you can look up about a change instead of forming an opinion about it. What does it touch? Is there a database migration in it? Did a lockfile change? Did any tests change? Is CI green? Has the author worked in this area before? Has the area broken before? Each of those takes a few seconds to check, and a lookup can't inherit anybody's blind spots or biases.

I tried this on a real queue back in June...58 open pull requests on a public open source repo, hand scored on those signals as part of Merge Lantern's validation work. The top ranked PR touched live billing code, carried a database migration, bumped a lockfile, and had failing CI, all at the same time. 1,584 lines across 52 files. And the #2 PR was the opposite shape...265 lines, small and tidy, sitting in Stripe subscription handling with a schema change. By size it looked safe. It was not the kind of change anybody should skim...but because it was small, neat and tidy, it's very easy to assume it could have been skimmed and approved.

If you want to try this tomorrow with no tooling, do three lookups before you trust any review. What paths does the change touch? What's the history of those paths? Did the tests move with the code? A few seconds each.

I do want to be honest about the limits. These signals catch risky-SHAPED changes. They don't read the code for logic bugs, and they never will. A subtle bug in a small, well-tested change with green CI sails right through. What the signals are good for is deciding where your limited senior attention goes first.

Where a second model earns its keep

I'm not saying model reviews are worthless. An architect I compared notes with runs multi-agent review well: different providers, different evidence sources for each agent, independent timing. When his agents agree, he treats it as one more data point and keeps checking the evidence. If you run two models, that's the way to do it...make them actually different, and don't let their agreement stand in for proof.

Whoever reviews a change...a person, a model, two models arguing...the deciding question is the same. What does the evidence outside the diff say about it?

So, to end, I have a question for you and your team. When a change lands, what does your review process know about it that isn't in the diff? I think for most teams the answer is close to nothing, and that's exactly where the misses live.

Your Team Is Getting Faster at Code Review. Your Seniors are Drowning.

Jake Lundberg — Mon, 10 Aug 2026 15:28:46 +0000

Every so often I go read code that's shipped in our platform. Not to review it (that ship has already sailed)...just to see where the system is drifting.

Lately I've been finding a lot of issues. Not nitpicks or code style issues. I mean infrastructure and functional problems that are hurting how our application performs and how far it can scale.

After sitting and thinking on this (and doing some reading), I don't think my team got sloppy. If anything, they got better at code review...

What actually happened

When coding agents landed in our workflow, the volume shot up almost immediately. Every engineer on my team works with one or more agents throughout the day now, and the majority of the code going into our platform is generated that way.

Like many teams, the first thing to break in our process was the throughput. Everyone still had their own work to get done, and on top of that they suddenly had a lot more pull requests to get through. Things slowed down noticeably. A lot of people have been writing about this, and yeah, we lived it too.

Then we adjusted. My team moves through code review faster today than it did before any of this started.

So the queue problem got better. But the code coming out the other end has real problems in it.

Nobody on my team stopped caring

I want to be careful about where the blame goes here, because I don't think it belongs to the people doing the reviewing.

There's a paper from MSR '26 (Huang, Jaisri, Shimizu, Chen, Nakashima and Rodríguez-Pérez, "More Code, Less Reuse") that looked at 3,858 Python pull requests and compared agent authored ones against human authored ones. The agent pull requests carried roughly 1.87 times the semantic redundancy...code duplicating logic that already existed in the repo.

Fine, that one I could have guessed...but the second finding surprised me.

Reviewers responded to the agent pull requests more warmly than to the human ones. More neutral and positive reactions on the agent PRs. More disgust, anger, fear and surprise on the ones a person wrote. The authors' read is that agent output is generated on probability, so it looks plausible on the surface, and reviewers ease off accordingly.

Put that next to what happened on my team and it sheds some interesting light on the situation. We got faster at review because we're reviewing code that's really good at looking fine. That's different than getting better at review...but from the inside the two feel the same.

What it actually costs

Most of what I've seen getting written about has landed on devs getting overwhelmed and burning out. And I definitely see the same patterns emerging. The load is heavy and people are tired.

But burnout is not the number that shows up in a business review...

Senior engineers are spending enormous chunks of their time either reviewing everything that moves, or fixing what slipped through because a change needed senior eyes and didn't get them. That's time they aren't spending on architecture, or on the sophisticated, complicated, genuinely value driving work that mostly only they can do. Your most expensive people are buried in review queues and bug tickets.

I'll use myself, since I'm the example I can speak to honestly. I'm the most senior person on my team. I'm also the manager, the architect of the system, and lately an IC working through a steady stream of issues that reached production. I need to spend more time on reviews...but there's no more time to spend.

In all honesty, I'm drowning. And unless I find a way to identify more clearly and accurately where my attention is actually needed, I don't think this gets better on its own.

The thing that broke is the model, not the team

Somewhere in here, the review model we inherited quietly stopped working.

That model treats pull requests as roughly interchangeable. They land in one queue, they all get looked at, they all get an approval from somebody. It held up fine for a long time because a human being had to sit down and write every line first. Writing was an unofficial throttle. It isn't anymore.

So the same amount of attention now gets spread across several times the volume, and it thins out everywhere at once. The safe changes get a careful read. The dangerous ones get that same read. And I find out which was which weeks later, when I'm scrolling through merged code and I see glaring issues staring back at me.

The failure is in the model itself. It assumed every change deserves about the same scrutiny, and it's still running in a world where the volume tripled and the risk never spread itself evenly across it.

Where I've landed

This is the problem I'm building Merge Lantern for, so consider me a little biased. It leaves the reviewing up to you. There dozens of AI review tool out there today with claims to help you with the review process. That's not what Merge Lantern does. Instead, it ranks your open pull requests by how much risk they're carrying, so the senior attention you actually have lands on the changes that need it.

What I'm sure of is the shape of the problem. Attention is the scarce resource now. Spreading it evenly across everything was always a little wasteful, and it worked anyway when volume was low. Obviously it doesn't work now.

So here's the question I'm wrestling with this week...

How do you decide which pull requests get the careful read? Is it a written rule, is it a gut call, or is it whoever has time that afternoon? And if you've found a way to make that decision deliberately, I would love to hear how.

Huang, Haoming, et al. “More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-Generated Pull Requests.” arXiv:2601.21276, arXiv, 29 Jan. 2026. arXiv.org, https://doi.org/10.48550/arXiv.2601.21276

Pair Programming Earned a Lighter Code Review. AI Hasn't.

Jake Lundberg — Mon, 03 Aug 2026 20:09:43 +0000

Is writing code with an agent the same thing as pair programming?

That question has been going around lately, and there's a practical consequence sitting inside it that I don't see many people chasing down.

On a lot of teams, code that a pair of devs wrote gets a lighter code review.

I personally have never seen that written down anywhere. It's not in a policy doc and nobody voted on it. But everywhere I have worked, when a PR came from two people who built and tested it together, the review was lighter. Reviewers trusted the code more. Fewer issues got found in review. Fewer bugs slipped through afterward. So the lighter review kept looking like the right call, and it stuck.

That's a risk decision, even though it never feels like one. Somebody looked at a category of change and decided it needed less scrutiny than everything else.

And here is the part worth sitting with. Pairing earned that discount.

Pairing earned that discount

Researchers have studied pair programming for a long time, and the results are less magical than the marketing but pretty consistent.

Cockburn and Williams (2000) found pairing costs roughly 15% more development time and buys back roughly 15% fewer defects. They also measured statistically significant gains in design quality, technical skill, team communication, and resilience when someone leaves, since knowledge stops living in one person's head.

The 2009 meta-analysis from Hannay, Dybå, Arisholm and Sjøberg is more nuanced. A small positive effect on quality. A medium positive effect on duration, so pairs finish faster on the clock. A medium negative effect on effort, because they burn more total person-hours. Complexity moves the needle too: pairs are faster when the work is simple, and produce higher quality when the work is hard.

A couple caveats here, since I'm using this research to defend a practice. Neither study measured code review specifically. They measured defects and duration, and "so review gets shorter" is my personal inference from fewer defects showing up at the door. The authors of the meta-analysis also flag signs of publication bias in the pair programming literature, which is worth knowing before anyone treats these numbers as completely settled.

Even with these caveats, there's a track record here. The lighter review is resting on something real.

It was never a flat discount

The other thing about that discount is that it was never a one size fits all deal.

Two juniors pairing usually produce better code than either of them would have alone. Genuinely better. But still not as good as what comes out when a senior is in the pair. I've watched that difference play out enough times to treat it as a hard rule rather than a hunch.

So the shortcut was never "pairing gets a lighter review." It was closer to "this pair, working on this, has earned a lighter review." Everybody doing the reviewing knew that, even if nobody ever said it.

Which raises the question that made me want to write all of this stuff down...if a developer plus an agent counts as a pair, which pair is it?

AI code has not built that record

I want to be careful here, because there's a lot to consider and the tooling is moving fast. But from what I've seen up to this point, AI generated code on its own comes with a lot of problems in it. Security issues. Functional bugs. And a slower one that worries me more than the rest...people losing their understanding of their own systems, which makes those systems harder to fix the longer it goes on.

None of that earns a lighter review.

The cost moved the other direction at the same time, too. We've all read and seen how producing code got cheap. Evaluating it didn't. Nothing about an agent made reading code faster, made holding a system in your head easier, or made it quicker to spot a wrong assumption (no matter how confident the agent sounds).

So put those together. A lot of developers are working with agents right now. If that counts as pairing, it gets the lighter review. So we read less of the code, right when a lot more of it is showing up. And it's the kind that's hardest to spot problems in just by reading it.

That cost doesn't stay with the team that filed it that way. It lands on users, on clients, and on the business, usually much later.

Nobody is going to decide this in a meeting

That's the part I'm mulling over today.

No one on the engineering team is going to stand up and propose reviewing AI written code less carefully (at least I hope not). That's not how it happens. It happens when a category you already had quietly absorbs a new kind of work, and the rule attached to that category comes along for the ride. Dev + agent starts getting called pairing, pairing already had a discount, and the discount transfers without anyone explicitly deciding anything.

Most teams inherited their review shortcuts, and I'd be surprised if anyone wrote down what earned them. So when something new shows up asking to be filed under an existing category, there's nothing to check it against.

So here is what I would actually ask you to do, and then a real question.

Go find your team's review shortcuts. The paired code one. The "it's only a config change" one. The "this person's PRs are always clean" one. They exist, they're mostly unwritten, and you probably inherited at least one of them from a team you're no longer on.

Then ask what earned each one, and whether that thing is still true for the code you're merging today.

What did you find when you went looking? I am very curious whether other teams have caught this happening, or whether it's already too far along to see clearly. If you would rather talk it through than leave a comment, my inbox is open.

The Warning That Took My Site Down Was in the Log the Whole Time

Jake Lundberg — Tue, 28 Jul 2026 01:29:10 +0000

A few weeks ago, I mistakenly took my own site down for about thirty minutes.

I was wiring up a queue-based pipeline for GitHub webhooks. That needs two Cloudflare Workers: one that catches the webhook and drops the event on a queue, and a second that picks it up and does the slow work in the background. GitHub gives you ten seconds to respond, so you answer fast and do the real work after.

Two Workers means two deploys. I chained them into a single command.

Cloudflare's build system printed a warning. It said it was overriding the Worker name in my config with the name bound to the build project. One line, sitting in the middle of a wall of normal deploy output. Then the command exited zero, the way a successful command does.

What that warning actually meant is that my second Worker, all 0.39 KiB of it, had just been uploaded as a new version of the first one and promoted to live traffic. That Worker knew how to read from a queue. It had no idea what an HTTP request was. Every request to the site threw an exception until I worked out what had happened.

Thirty minutes of downtime. About two hours all in, from the bad deploy to a rebuilt setup that can't do that to me again.

Nothing about it looked wrong. The config was fine. The command was fine. The output scrolled by looking like every other deploy I've run. The one line that could have saved me was formatted like the ones around it. It didn't stop anything, because it wasn't an error. It was information.

The risk was there the whole time. Nothing showed it. Then traffic hit it.

That's not how it works in the physical world.

Walk past a construction site. You can see the risk. Someone on the fourth floor with nothing behind him. A crane swinging a load over the sidewalk. A beam carrying more than it looks like it should. You don't need a process or a meeting to notice any of that. The risk is right in front of you. Everyone who walks past does some version of assessing it, not just the person who signed off on the plans.

Software has none of that. There's nothing to look at. A risky change and a safe change are the same thing on your screen. They're just text.

So the risk stays in someone's head. Never on paper, never in the ticket.

And you know the feeling. Someone's describing a ticket in planning and something in your gut says this one is going to be worse than it sounds. Maybe you say so. Maybe it turns into an extra point on the estimate. It almost never gets written down anywhere as a fact about the work, somewhere you can look at later.

That invisibility does something worse than hide risk after you ship, though. It changes what you build in the first place.

Put a team under a real deadline and watch what gets cut. It's never the feature. The feature is the visible thing, the thing that goes in the demo. What gets cut is the test for the weird path, the handling for when the third-party call times out, the ten minutes of thought about what happens when this runs at ten times the volume. That work just vanishes, because nobody sees it not happening. Nobody demos the edge case they handled.

And "we'll fix it next sprint" only ever covers the misses you can see. The dangerous ones pass the quality bar looking fine. They ship green. Then they surface on their own schedule, weeks or months later, as an incident.

Which means the corner you cut and the incident it caused almost never land in the same sprint. From the inside they look like two unrelated events.

So what do you actually do about it?

Make it visible. That's the whole job.

Not a new process or a committee. Just moving it out of your head and onto the work itself, at the level of the individual change. This change touches auth. That one has no test for the failure path. Another lands in a part of the system that broke twice this quarter. Write it down where someone else can see it.

Once it's visible, two things change. You can weigh it, which is what the construction site gets for free. And you can defend it when the deadline shows up. The work on the chopping block finally has a name. Instead of being a vague feeling that loses every argument against a feature you can demo.

That warning was in my deploy log the entire time. It just looked like everything else.

Your 1:1s Have No Ticket, So They're the First to Go

Jake Lundberg — Mon, 20 Jul 2026 14:14:01 +0000

There are weeks where I finish my personal work after hours because I wouldn't move three meetings.

Thirty minutes each, one per person on my team. When the week goes bad, that block doesn't move, and something else pays for it.

Everybody agrees you should care about your people. It's easy advice to nod along with.

But when pressure starts to build, the first thing a tight deadline kills is the conversation that isn't about tickets.

What actually gets cut

When pressure is high and the delivery date is ugly, it's easy to throw a bunch of tickets at the team and yell march. That is not leading.

Support doesn't become impossible during crunch...it just stops being prioritized.

And it stops being prioritized for a fairly boring structural reason.

Most of what competes for that half hour leaves an artifact. A ticket closes. A PR merges. Something moves on a board, and at the end of the week you can point at it and say that thing happened. The 1:1 doesn't produce any of that. Nothing moves, nothing logs, and there's no line item anywhere that records the conversation took place, or what result that sync with your team member had.

The value it produces is uncountable in the same way. You can count the incidents you resolved. You can't count the person who didn't quietly check out, or the problem that surfaced in week two instead of week nine because there was somewhere for it to surface. The good outcome is an absence, and absences don't show up in any system you report on.

So the countable work wins by default. Not because anyone decided it should, and not because leadership is dumb about people. The scoreboard only has columns for one kind of thing.

Work that leaves an artifact tends to get protected by incentives, without anyone having to defend it. Work that doesn't leave one comes down to whether you decided it matters.

Encouragement, coaching, teaching, the non-ticketed work that actually develops people...all of it still fits in a chaotic period. There is room. But only if you've decided ahead of time that it isn't optional.

And "decided" is carrying a lot of weight in that sentence. Good intentions don't survive crunch. A defended time slot does.

The practice

So here's the actual practice. At least 30 minutes a week with each person, and it happens regardless of what else is going on. I've been running it this way for months.

I prioritize that time over most other things on my calendar, because that's the only way to keep it from getting bumped every time I get busy.

I've had stretches where I was slammed, and the 30 minutes stayed put.

My team knows how busy I am. They can see it. That's the reason this matters more than it looks on paper. My hope is that watching me hold that half hour while everything else is on fire shows them something about how I prioritize them against the rest of the work.

The one rule about what we discuss

The one thing I push my team on is don't bring ticketed work to this conversation.

That half hour is not for discussing current work. It's set aside for growth, goals, whatever they're finding hard, things they want to learn, things they're curious about, advice they're after.

It's also your single best intelligence gathering tool as a manager. It's where you find out who's a flight risk, who's quietly drowning, who secretly hates the new project...before it blows up in front of you. A status update doesn't tell you any of that.

Get their agenda before the meeting

Before each 1:1, I send the person a document to jot down what they'd like to talk about. It's their agenda, not mine.

The document has three sections.

The first one is "anything you want to chat about," and it's blank space. Their call, sitting at the top of the page above anything I bring.

The second is five questions, under a heading that says they're just there to get you thinking. They're the nudge away from ticketed work. Some of the ones I use:

What feels harder lately than it should?
In your opinion, what matters most over the next 90 days?
What has been your biggest win in the last week?
What is one thing you would like me to do differently?

The third is follow ups, if there are any. Where something from a previous week gets picked back up.

That's the whole document. It's short, and it goes out before every one of these.

Then in the actual conversation, the hard part is shutting up. Don't jump to fix. Just absorb, and take notes on their friction points.

What it costs me

Back to the cost.

When I'm genuinely slammed, holding those 90 minutes means some of my other work gets delayed. On occasion that means finishing it after hours. I'm not going to pretend "protect the time" is free advice.

I don't have a clever way around that. The time comes from somewhere. I've decided where I want it to come from, and then I pay for it.

Why the slot is the thing

The structure is simple to write down. Thirty minutes, their agenda, a few questions, no tickets. Doing it well is a different thing entirely, and that part never stops being work.

The reason I keep coming back to the time slot rather than the technique is that the technique never gets a chance if the meeting doesn't happen. Running a good 1:1 is its own hard skill. But it's a skill that only comes into play in a conversation that actually took place.

So what matters first is whether any of it still happens during the quarter where everything's late and your own calendar has turned against you.

That's the week it counts. It's also the week it quietly disappears, unless you already decided it can't.

So what's the first thing your calendar drops when the pressure comes on? And what would it actually cost you to stop dropping it?