Almost every engineering organization has spent the last two years wiring agents into the development process, and the end state everyone keeps describing already has a name. Manufacturing got there first and calls it the dark factory. A plant running a lights-out shift keeps the overheads switched off, because there's no human on the floor who needs the light to work by.
Engineering leaders borrowed the term, and now the dark factory is how a lot of them talk about where software is heading. Agents write the code, pipelines test it, check gate it, and the work moves overnight while everyone sleeps. Plenty of engineering leaders are planning toward that end state, and the speed numbers give them reason to.
Zoom in on one developer, though, and the day looks like this. In 2021, they sit down in the morning, grab a cup of coffee, and dig into a bug they'd been stuck on for two days. Four answers down a Stack Overflow thread, someone three years ago describes the exact same thing, and it clicks. They write the fix, watch the build go green, push it, and feel that small hit of pride from having genuinely worked something out. That was the job, and the part of it a lot of people loved. Picture the same developer starting their day now. Waiting for them is a queue of pull requests that a model opened overnight, and the work is reading through them, catching what's wrong, steering the ones worth keeping, and closing the ones that aren't.
Both days end with merged code. The second one gets there on reviewing and vigilance, where the first one ran on writing and problem-solving. AI made your developers faster, but for a lot of teams, that speed shows up as longer hours and more context switching, and the baseline resets to the new pace. The gain shows up on every dashboard, but the cost to the person producing it rarely does.
Engineers are reviewing more code than ever
As AI takes over more of the coding process, the work itself changes. It moves from producing code to checking the code a model produced. Reviewing the work of others is a much different and more draining type of work than writing your own code. Where writing is generative and largely self-paced, reviewing is high-vigilance, arrives as interruptions, and is hard to sustain for a full day.
Reviewing AI code is also a much more isolating event. When you review a teammate's code, you usually have context, you know why they built it that way, and if you don't, there's someone to ask. Reviewing what a model wrote, you're reverse-engineering intent, with no one on the other end to share the judgment with.
These changes impact teams in different ways, because engineers are drawn to this profession for different reasons. Some people got into this profession because they love the craft of writing code itself. Others got into it because they love designing and building things, and writing was the way to do it. For the second group, AI has been largely positive; they can build things that were out of reach before, and a lot of them are more motivated than they've ever been. For the first group, the part they came for, sitting with a hard problem and working it out in code, is a thinner slice of the week now, and the reward that came with it has moved further away.
Neither group is more valuable than the other, but the cost isn't landing evenly. The people feeling the loss most are often among your strongest engineers, and what motivates them has been rearranged under them. The move toward verification work, like code review, is turning the role into something people enjoy less, and the ones having the hardest time adjusting are those who chose engineering because they found joy in solving problems themselves.
Oversight works better as part of a week than the whole of one. Rotating your engineers between writing code directly and steering agents keeps the craft available to the people who came for it, and keeps your reviewers fluent enough to catch what the models get wrong.
Use quantitative and qualitative signals to measure engineering health
The strain in that split shows up before it reaches your delivery numbers, in your engineering data and in what your developers tell you when you ask them. About 75% of engineering leaders say they're seeing real productivity gains from AI, while around 45% aren't formally measuring its impact at all, so most of that confidence rests on adoption being up and things feeling faster rather than on anything measured directly. A team can be shipping well and hitting every number right up until the person behind those numbers stops caring and starts looking for their next opportunity. That signal doesn't live in the workflow, so by the time it shows up in delivery you're already trying to backfill someone who's leaving.
And it's your best people who go first. The ones most exposed to this shift are your senior engineers because they hold the most context about how your systems work. When one of them leaves, that understanding goes with them. Some of this you can catch without asking anyone, because it shows up in your quantitative productivity data. But it’s also important to combine this data with qualitative surveys that surface friction areas within your organization. If multiple teams are having similar problems improving productivity with AI, this is a great place to focus your internal developer productivity initiatives.
Redefining code ownership for the agentic SDLC
When a developer writes code, they own it. They understand it end-to-end, and shipping it carries the responsibility of stewarding it. On the other hand, when a developer approves something a model wrote, there may not be nearly as strong a sense of ownership. But, they’re still on the hook for making sure it works.
You can see how much ownership matters in the data. When a fully autonomous agent opens a pull request that no human feels responsible for, it often just sits there. LinearB's 2026 productivity gap benchmarks report show agent-opened PRs stalling well short of the rate human-owned ones reach, not because the code is worse but because nobody steps up to shepherd work they won't get credit for. Agentic pull requests wait 5.25 times longer than manual ones just to get picked up, 17.6 hours against 3.4 at P75. A dark factory doesn't have a queue, because the machines hand off to each other. A seventeen hour wait means something in the line is waiting on a person, and nobody assigned one.
Part of that is mechanical. If a given service or path has a clear owner, an AI-generated change to it can route straight to the person whose judgment it needs, rather than landing in whichever queue has space. LinearB's gitStream lets you define who owns which parts of the codebase, so when a model opens a PR against one of them, there's an automated path to the right human instead of a hope that someone picks it up. It won't bring back the pride that comes with ownership, but it does put the accountability where it belongs, with the person best positioned to judge the change.
Don’t force humans to review every line of code
Routing review better helps, but the larger fix is reducing how much of it needs a human at all. The instinct is to have a human review everything, which made sense when throughput was lower. At today's volume, it overwhelms your engineers, and overwhelmed reviewers rubber-stamp, giving code little more than a glance before it ships to production. It's a natural response to a long queue and a short day.
The question is where you draw the line for what gets a human and what gets handled automatically. As the models and their tooling improve, you can gradually offload more of the review burden to AI agents. And as your agentic SDLC matures, you'll find opportunities to automatically merge code that passes all of your agentic and CI checks.
This is what LinearB's AI code review is built around: you decide which classes of change carry enough risk to need human judgment, the architectural calls, the security-sensitive paths, the things that are hard to walk back once they're in production, and let automated review handle the high-volume, low-risk remainder, catching the obvious problems. In LinearB data, PRs with an automated AI review go on to merge at the highest rate of any kind, lifting yield by up to five points.
Keeping the lights on for your engineers
The engineers feeling this most are usually the ones your organization can least afford to lose, and they rarely announce they're going. By the time it reaches your delivery numbers, the decision has already been made.
A factory only goes dark when no one on the floor needs to see. Yours still has people on it, reading everything the machines produced overnight and carrying responsibility for code they didn't write, in a job many of them never chose. You can see how they're holding up in the same place you see your delivery, in who absorbs the review load, in how long agent-authored work sits before anyone picks it up, and in what your developers tell you when you ask them. LinearB brings both halves together, split by who wrote the code and cut by team.
You already know how your delivery is going. Now you can find out how your people are doing.
