Seven bets I'd make about engineering in 2026

I’ve been having the same conversation with engineering leaders for the last twelve months, and the question underneath every other question is the same: what is actually happening, and what should we do about it?

Most engineering organizations have not answered that question on the record. They’re running on a collection of half-articulated assumptions, accumulated from conflicting sources, that nobody has been asked to defend. The most useful thing a team can do in 2026 is decide, out loud, what it believes is happening and what it intends to do about it.

What follows is what I believe today. I’ve changed my mind about pieces of it over the last eighteen months. I’ll probably change my mind about other pieces in the next eighteen. This is not a forecast. It’s the working hypothesis I use when I sit down with engineering leaders and figure out what to do next.

I’ve written it as three observations and seven bets. The observations are the world I think we’re all operating in. The bets are what I would do, and what I recommend the teams I work with do, given that world. The split matters. People who get the observations right and the bets wrong end up with elegant decks and no shipped work. People who place the bets without naming the observations end up shipping the wrong thing, fast.

What I think is happening

One. Software gets written, increasingly, by machines under human direction. Three years ago this was a speculation people held in different strengths. It’s now visible in every team I’m close to. The proportion of code that originates as a human typing into a buffer is falling. It’s being replaced by code that originates as a human writing a paragraph, a model proposing a patch, and a second pass by a human or another model to keep the patch honest. This is true for the teams that have built a practice around it. It’s also true, more quietly, for the teams that haven’t, because the senior engineers on those teams are doing it in private and not telling anyone.

The shape of the work changes. The bottleneck of a feature is no longer the typing. It’s the specification, the review, the test design, the recovery from a model that confidently produced the wrong thing. The skills that were valuable when typing was the bottleneck are not the same skills that are valuable when review is the bottleneck. Some engineers I know are thriving on the new shape. Others are quietly miserable. Almost no team has acknowledged this transition out loud.

Two. The amount of software a given company can credibly ship is going up by an order of magnitude. Not because the engineers are better. Because the cost of producing a working artifact has fallen. The internal tool that wasn’t worth building in 2023, because three months of an engineer’s time would have built it, is worth building in 2026 because two days of engineering time and some model calls will build it. I’ve watched this happen inside several teams over the last year. The backlog stops being a queue. It becomes a portfolio.

The interesting consequence is not that more things get shipped. It’s that the question what is worth shipping gets harder. When you can build any reasonable feature in a week, the cost of shipping the wrong feature goes up, not down. The teams that win the next two years are not the teams that ship the most. They’re the teams that delete the most, archive the most, and refuse the most. Engineering throughput stops being the constraint. Judgment becomes the constraint.

Three. Engineering judgment is the new scarce resource, and it’s the moat. This is the observation I’m most sure about. The talent that becomes more valuable over the next two years is the talent that knows what to build, what to leave alone, when to rewrite, and when to wait six months for the model to get cheaper. That talent is rare today. It will be rarer in twelve months, because everybody will be hiring for it, and because the conditions that produce it (a long arc inside one product, deep relationships with users, scar tissue from prior rewrites) are not faster to produce just because the model got better.

I say this with a small caveat. Senior engineers, in my experience, are also the slowest to convert their judgment into work that uses AI well. I’ve written about this elsewhere. The conversion is doable, and once it happens it tends to flip suddenly. But the gap between “has the judgment” and “uses the tools fluently” is the gap most engineering organizations are quietly trying to close right now, and it’s a real gap.

The bets

The observations above are what I think is true about the world. The bets below are what I think a sensible engineering organization should do about it. I’ve ordered them roughly by how soon the cost of not making them shows up, with the earliest first.

One. Bet on your infrastructure being rebuilt for machine traffic. CI, version control, code review, observability, deploy pipelines. All of these were designed for the rate at which humans push commits and open pull requests. Agents push commits faster. They open pull requests faster. They run tests in patterns that nothing in your CI was tuned for. The teams I’ve watched start running agents at scale this year hit the limits of their CI within a quarter. Pipelines that took eight minutes now take forty. Git operations on the monorepo got slow enough to be felt. The merge queue stopped behaving.

The fix is rarely a new tool. It’s a series of small rebuilds: faster test selection, smarter sharding, agent-aware rate limits on the API surface of your code host, parallel review paths that don’t deadlock on the same shared reviewer. The companies that treat their developer infrastructure as a human-rate system will spend most of Q3 firefighting it. I’d invest in this earlier. The cost of getting ahead is small. The cost of falling behind is two months of low morale and a roadmap nobody believes.

Two. Bet on someone owning the orchestration layer. The work of running agents is starting to look, organizationally, the way build engineering looked in 2014. Somebody has to own the planner. Somebody has to own the policy that says which agents can touch which parts of the codebase. Somebody has to write the post-mortem when an agent ships a regression on a Saturday. In most companies today, this work is being done by a tech lead in their spare evenings. It is not sustainable. It will become a role. The companies that recognize it as a role earlier will be the ones that don’t end up with their best engineer burned out from agent firefighting.

I don’t have a settled name for this role yet. “AI platform engineer” is closest, but it understates the orchestration piece. Whatever it ends up being called, the work is real, it is full-time, and the person doing it is not the same person as your strongest product engineer. Hiring for it now is hard. Growing into it from a senior platform engineer who is interested is, in my experience, the most reliable path.

Three. Bet on your context being the moat, not the model. The model your competitor is using is the same model you are using, plus or minus a generation. The model will keep getting better, and most of that improvement will be uniformly distributed across whoever pays for it. The thing your competitor doesn’t have is your code, your incident history, your customer support transcripts, your design documents, your half-finished migration from the old auth system. That’s the moat. It’s also, in most companies I walk into, a pile of disconnected systems with no single addressable surface that a model can be pointed at.

Connecting those surfaces is unglamorous. It’s the kind of work that does not photograph well in a board deck. I think it’s the highest-leverage work an engineering organization can do in 2026. The teams that have done it, a small handful so far, have agents that can answer real questions about real systems. The teams that haven’t are running agents that are, functionally, the same agents the rest of the industry has.

Four. Bet on governance becoming a substrate, not a department. Identity, audit, policy, deployment guardrails. Today, in most organizations, these live with a team that gets pulled in when something is about to go to production. Over the next two years, every model call your product makes will pass through some version of these controls, and the controls will need to be code, not a Jira ticket to security. This is partially regulatory pressure, which I expect to keep increasing in the EU and the US over the next eighteen months. It’s also partially the simple fact that an agent that can act on your behalf needs the same audit trail a human acting on your behalf needs, and you don’t want to be the company that retrofits that audit trail after the first incident.

I don’t think this means hiring a large governance team. I think it means treating governance as a platform concern, owned by the same people who own observability and deploy. Some of the teams I work with have started doing this. The ones that have are quieter about AI risk than the ones that haven’t, which I read as a good sign.

Five. Bet on three modes coexisting in the same codebase. Human-owned. Agent-assisted. Agent-autonomous. Different parts of your product will run at different mixtures of these. The auth path will probably stay mostly human-owned for a long time. The internal admin tooling will go agent-autonomous earlier than is comfortable. The customer-facing product will live somewhere in the middle, and the line will move month by month. The organizations that try to settle on a single uniform mode will be wrong about the parts where another mode would have worked.

The implication for team structure is that the engineers who are best in one mode are not always the engineers who are best in another. A team that’s great at agent-assisted product work might be, in my experience, only mediocre at autonomous batch work. I’ve seen this enough times that I now ask about it explicitly in the first conversation with a leader. The honest answer almost always reshapes the staffing plan.

Six. Bet on pricing moving away from per-seat. Both for what you buy and what you sell. If you’re paying twelve dollars per seat per month for a developer tool and your developers each have four agents running in parallel, the vendor is not going to leave money on the table for very long. The pricing will shift to consumption. Plan for it on the cost side now, because the line item that is currently predictable will become less so. On the revenue side, if your product is sold per seat and an agent could plausibly be the buyer rather than the user, you have until somewhere in 2027 before that pricing model strains. Some of the teams I work with have started running consumption-based experiments alongside their subscription tier. I don’t know yet whether the bet was right. I’m increasingly sure that not running the experiment is the wrong bet.

Seven. Bet on culture being the hardest part. This is the one I’ve been most wrong about, and I keep being wrong in the same direction. I keep underestimating how much of the work is convincing senior engineers that the new way of working is real, convincing leaders that shipping a bad version on Friday is fine, and convincing boards that the absence of a thirty-page strategy deck does not mean the absence of a strategy. The technical pieces of an AI transition are, in retrospect, the easy pieces. The cultural pieces are where things stall, where promising teams stop moving, and where the difference between two superficially similar companies turns out to matter.

I have no shortcut for this one. The pattern that works, every time I’ve seen it work, is one team shipping one thing visibly, with leadership cover, and then a second team and a third. The companies that try to roll out a “culture of AI” by training and decree, without the visible wins, do not get the culture. The companies that get the visible wins first end up with a culture without ever having declared one.

What I am not betting on

A few things people ask me about, where my answer is that I am not making the bet.

I’m not betting on a single dominant agent runtime, or framework, or vendor. The space is still moving too fast. The companies that have committed early to one stack have not, in my experience, outperformed the ones that stayed at arm’s length and replaced components every six months. I expect this to remain true through at least the end of 2027.

I’m not betting on autonomous agents replacing engineering teams. Not because the technology won’t be capable. Because the work that engineering teams do is increasingly judgment, relationships, and context. None of those things scale with model capability the way code generation does.

I’m not betting on the open-source / closed-model question resolving cleanly either way. I expect both to keep coexisting. I expect the right answer for any given company to depend on data sensitivity, cost profile, and on-call appetite. That decision is best made per workload, not per organization.

I’m not betting on a sudden plateau in model capability. I’m also not betting on a sudden takeoff. Both are popular positions in the discourse. Both pay better as content than as planning premises. My working assumption is steady, uneven, occasionally surprising improvement, and that has served the planning I do with leaders better than either extreme.

A note on these bets

The seven bets above are not independent. Several reinforce each other. The infrastructure bet and the orchestration bet share a hire. The context bet and the governance bet share a data model. The pricing bet and the culture bet share an audience: both are board-level questions before they’re engineering ones. I’ve rarely watched a company make one of these bets cleanly without something downstream of another bet showing up six weeks later.

I’ve also rarely watched a company make all seven at once. The most effective engineering organizations I’m working with have made two or three of them, and made them well. They’re using the next quarter to make a fourth. The least effective have a slide deck listing all seven and have shipped nothing against any of them. The deck is not the bet.

If I had to compress the whole post to one paragraph, it would be this. The thing that is changing is not the technology, exactly. The technology is changing, but the technology has been changing for two years and most of the visible difference is downstream of how organizations are responding to it. The bet that matters most is the bet on responding sooner, smaller, and more honestly than your peers. The companies I’m watching pull ahead are not the companies with the cleverest stacks. They’re the companies that placed a small bet, watched it work, and placed the next one before the rest of the industry had agreed on a playbook.

I’ll probably write a version of this post in a year and disagree with parts of this one. That is the work.

Made with BlueTip 🦋 (https://www.bluetip.ai)