What engineering teams are getting wrong in 2026

Ask any engineering leader how AI has changed their team, and you'll get an optimistic answer. Ask them to prove it with a number, and most go quiet.

That gap is the story of 2026. Individual engineers are faster than they've ever been. Teams, in a lot of cases, aren't. We talked to our own engineering team, the people who've spent the last year building and shipping Upsun Dispatch™ and living through exactly this shift, and the same tension came up again and again: what makes one person dramatically more productive can make the group around them slower, messier, and harder to manage.

Here's what they told us.

Cost is turning into a reliability problem

Ask an engineering team building AI workflows about their biggest surprise this year, and a lot of them will say the bill.

Patrick Dawkins, Principal Software Engineer, described the same coding task costing a dollar most of the time and ten dollars occasionally, with no way to know which one you're getting until the task finishes. Guillaume Moigneu, Upsun's Field CTO, saw a single pull request review range from five cents to forty dollars.

The fix isn't cutting spend. It's visibility: costs tracked in real time, by workflow and by team, with budgets set before the surprise rather than explained after it.

Nobody has a baseline to measure against

Most organizations can't actually prove the productivity gains they believe they're getting, because almost none of them measured anything before they started.

Without a "before" number, every claim about AI-driven speed is a guess dressed up as a metric. Teams that invested early in baseline measurement are the ones who can walk into a budget conversation with an actual case. Everyone else is arguing from a feeling.

One fast engineer can slow down a whole team

Guillaume Moigneu has been writing software for 28 years. He watched what happens when one person on a small team adopts agents faster than everyone else.

"If you're in a team of maybe three or four people, if you had one engineer like this, that would create a lot of issues for the others," he told us. 

One person shipping 50 AI-assisted changes over a weekend doesn't feel like a win to the rest of the team on Monday morning. It feels like a backlog. 

"You wake up and you see Patrick has been working all weekend, and you see he's made like 50 different changes, and you're like, 'Oh, I need to redo everything, I need to make sure everything works.' That's a mess."

Individual velocity and team velocity aren't the same metric, and optimizing for one can quietly tax the other.

Human attention doesn't scale the way agents do

Patrick Dawkins built an internal tool that reviews merge requests before a human sees them. He also learned the limits of supervising more than one agent at a time.

Running a single agent is manageable. Once it can run unsupervised for a while, boredom sets in, and you start a second one. Then a third. "You're thinking about three different things at the same time," Dawkins said. "I don't think you can really do that for more than a few hours a day before you just burn out."

That's a hard constraint, not a training problem. Teams that treat "run more agents" as a free productivity lever tend to find this out the expensive way.

Local agents created a governance blind spot

For most of late 2025, engineers ran agents on their own laptops. In hindsight, Dawkins says, it created real risk.

"Only you can see what the agent's doing on your laptop. It's not visible for the rest of your organization," he said. "If an engineer is spending thousands of dollars in their AI tool, you don't see the results, or you might see the result but you don't see why it costs so much. And you don't see if customer data is being sent to the wrong place."

Close the laptop, and the agent stops. And because everything ran locally, nobody outside that one engineer's machine had visibility into spend, output, or what left the building.

Most teams are further behind than they think

One internal framework we came across breaks AI adoption into stages, and it's a useful gut check for where your team actually sits.

It starts with individuals adopting AI on their own, no leadership position, no policy, everyone buying their own subscriptions. That's normal, even healthy, as a starting point. The trouble is what comes next: some engineers pull far ahead of others, each building private tools and prompts that never get shared. Then a few teams industrialize their workflows while others keep working like it's 2024. The gap between the fastest and slowest teams becomes visible, and leadership usually can't explain why.

That's the moment most organizations are in right now, whether or not they'd admit it.

Trust is a dial, not a switch

The clearest mental model in our conversations came from Moigneu: treat an agent like a new hire.

"At the beginning, you explain to them what the work is, what the rules are, and then for the first month or two, you trust but verify," he said. "For agents, that's the same thing. At the beginning, we implement what we call human gates, where after each critical or risky task, a human has to review what the agent has done and approve, reject, or discuss it."

The gate isn't the point. The feedback loop is. As a workflow proves itself reliable, gates lift. Change a button color, and you don't need five approvals. Touch how you report taxes to a government, and you probably want more than one.

The job is shifting from writing code to judging it

Every engineer we spoke with described the same shift: less time typing, more time reviewing, verifying, and deciding whether AI-generated work is actually correct.

Moigneu frames it as a move from code crafter to architect. "You are the one responsible for everything written by an LLM," as Patrick Dawkins put it. "Reading every single line of code, understanding what it does, is super important."

What separates the teams getting this right

Strip out the specifics, and a pattern holds across every conversation. 

The teams struggling in 2026 are optimizing for the individual engineer, running agents with no visibility into cost or output, and skipping straight to full automation without a real trust-building period. 

The teams doing better are treating AI adoption as an organizational design problem: shared standards instead of private setups, a trust dial instead of blind faith, cost visibility instead of end-of-month surprises.

None of this is exotic. It's the same discipline engineering teams have always needed when they scale past one person. AI just made the timeline for learning it a lot shorter.

This is exactly the pattern Upsun Dispatch™ was built around, because we hit it ourselves first: agents running in a shared layer instead of on individual laptops, human gates that lift as trust is earned instead of staying on forever, and cost tracked in real time instead of discovered at the end of the month.

• New here? Read the introduction to Upsun Dispatch
• Want to help build it? Apply to the founding design partner cohort