The 2026 State of AI Engineering — Barr Yaron, Amplify Partners

How do you describe the state of a field that changes while you are making the slides? Model announcements provide a steady stream of news, but a different question matters for engineering: what are people actually building and operating? Barr Yaron, an investment partner at Amplify, runs an annual survey to capture that practice. The 2026 survey was conducted with Notion and Vercel and received 1,048 responses.

AI engineering is a discipline, not a single job title. Respondents include founders, CTOs, engineers and product people across company sizes. For the third year, the sample skews toward experienced software engineers who are comparatively new to AI. Among respondents with more than ten years of software experience, over half have three years or less of AI experience. The median new engineer has nearly as much AI experience as the median software veteran: one group is learning a new paradigm, while the other has barely known software without it. These results describe survey respondents, not population-wide estimates of the industry.

Doing AI at work can mean very different things, starting with the modality. Text dominates current building activity. To understand what might come next, Yaron looks at intent to adopt: among people not currently building with a modality, what share plan to use it? The denominator is current nonusers, not all respondents.

Among current audio nonusers, 56% plan to adopt it, compared with 37% in the 2025 survey. Audio leads adoption intent in both years. That measures stated plans, not completed adoption; the year-to-year comparison also describes separate annual survey samples rather than tracking the same teams.

The largest realized change is elsewhere: the share of respondents using image generation and reporting that it works well rose from 18% to 36%. This is a combined usage-and-satisfaction measure, not the share using images in any form. Yaron connects the change to improving products, including Nano Banana, Nano Banana 2 and ChatGPT Images 2.0. Her explanation is that image generation crossed a usefulness threshold—from conspicuously flawed outputs, such as malformed hands, into real work. The survey records the adoption change; it does not establish that particular releases caused it.

The public debate often treats open-weight and closed models as competing destinations. Production usage is less exclusive: 94% of respondents report using closed models, and 45% report using open-weight models. Those categories overlap. More than 90% of open-weight users also use closed models, so open weights primarily augment the model portfolio rather than replace it.

Asked for their top three model-selection considerations, only 5% of respondents include whether a model is open or closed. Quality leads, followed by agentic capabilities such as tool calling and cost, which Yaron describes as tied. Only one in five names reliability. Her interpretation is that reliability may have become a threshold requirement: once candidate models are reliable enough, teams choose among them on quality, capability and price. That is a hypothesis about the ranking, not evidence that reliability no longer matters.

Model diversity extends beyond the open-versus-closed distinction: 87% of teams use more than one model. The survey identifies several ways to select a model for a particular job:

• Route by task type. The most popular approach assigns different kinds of work to different models.
• Compare outputs. Run multiple models and compare their responses.
• Route by cost. Let spending considerations influence which model handles the work.

These approaches preserve access to models with different strengths instead of assuming one model should handle everything.

At the same time, more than half of respondents say their organization is beginning to standardize on fewer AI tools. Some consolidate particular layers while remaining flexible elsewhere. Standardization is happening in platforms and tools, while the model layer remains diverse. A common operating environment can therefore coexist with multiple model choices.

Managing multiple models and AI workflows brings the usage bill into product design. Cost regularly shapes how ambitiously 40% of respondents use AI; another 36% say it sometimes does. Together, roughly three quarters adjust their ambitions based on cost. Finding a useful application is only part of the decision: teams also have to decide how much of that application they can afford to run.

Cost and token usage rank second among production monitoring concerns, below quality. Yaron compares this attention to monitoring an SLA: spending has become an operational constraint that teams watch continuously, rather than a bill considered only after the product is built. The comparison describes engineering attention, not a contractual service guarantee.

Agents make the operational stakes more concrete. As attention shifts toward harness engineering—the surrounding software that runs and constrains agents—the survey asks what permissions agents actually have. Reported agent use reaches 95%, roughly double the previous year, a figure Yaron herself says seems high. Among respondents building with agents, reported write access rises from 52% to 89%.

These are two separate changes: more respondents use agents, and a greater share of agent users grant write permissions. Together, they produce a more-than-threefold increase in the share of all respondents using write-enabled agents. The conditional write-access percentage alone did not triple. The distinction matters because write-enabled agents can change data inside systems, moving beyond reading, summarizing and drafting into actions with persistent consequences.

The leading controls are human approvals and permission gating. One decides whether an action may proceed; the other limits which actions are available at all. Yaron compares this relatively blunt toolkit to managing an intern. Below those leading approaches, practices scatter across task decomposition, retrieval, memory and sandboxing. There is no settled control layer, and she singles out memory and persistent context as areas likely to evolve.

About two thirds cite hallucination or losing context mid-task as their greatest frustration with agents. This is a report about what frustrates users, not an instrumented breakdown of failure rates. It nevertheless explains why control cannot stop at tool permissions: an agent can have valid access and still act on an incorrect belief or forget an earlier constraint.

Evaluation remains the most frequently named stack challenge, but its lead over other problems is narrowing. In total, 96% of survey respondents report a problem with their stack. The disagreement is over which problem matters most, suggesting a broad set of infrastructure needs rather than one dominant missing component. Even within evaluation, teams use multiple methods, and informal vibe review remains the most common.

Build-versus-buy choices across eight stack layers reveal a practical boundary. Every layer has a mix of approaches, but teams most often buy inference and model serving while retaining more of the logic that determines their product’s behavior.

The distinction is relative, not a rule that every team follows. Serving infrastructure is broadly reusable; prompts, retrieval-augmented generation and evaluations sit closer to what makes a particular application useful.

Existing choices also appear persistent: buyers show limited interest in building, and builders show limited interest in buying. That suggests established boundaries are not about to disappear, although stated intentions alone do not prove technical lock-in.

Across organizations ranging from solo founders to large enterprises, the sentiment is strongly positive. In this builder-heavy sample, 97% report a net positive organizational effect. The leading benefit is not simply faster execution; it is cheaper failure. Teams can try more ideas, build more prototypes and place more bets before committing to an approach. Yaron’s description of trying things as nearly free captures the change in experimentation, not a measured absence of cost.

Lower generation cost also creates more output to review. Over nine in ten respondents report some negative downstream effects. Common concerns include erosion of deep technical skills and understanding of the codebase, alongside increased review burden. Positive net impact and negative consequences are compatible: teams can value the additional experiments while still struggling to inspect, understand and maintain the work those experiments produce.

The organizational change reaches role boundaries: 81% say AI blurs the line between engineering and product, design and marketing. Shipping software is a particularly visible example. More than a third of teams have non-developers shipping features, mostly smaller or internal work.

The change also reaches customers: 17% report non-developers regularly shipping customer-facing features across the stack. Even when non-developers are not shipping, a third of teams see them producing useful prototypes, front-end mocks and other artifacts. These are distinct levels of participation—exploring an idea, shipping internal functionality and delivering customer-facing features—but each expands who can contribute directly to software creation.

Current satisfaction does not eliminate concern about what comes later. AI improved job satisfaction for 76% of respondents, while 59% fear today’s AI code creates long-term liabilities. Only a third call software engineering a solved problem, and Yaron cautions that people define software engineering differently. Respondents are also unsure what will happen with hiring. The immediate experience can be happier and faster while the long-term maintenance burden remains unresolved.

The five-year questions move from present experience into speculation:

The AGI question deliberately asks about a declaration, not demonstrated achievement. Likewise, the transformer result is mostly uncertainty, not a consensus around a successor architecture. The space-compute responses are closely divided, and the yes/no figures do not exhaust the responses.

The closing picture is a discipline moving from discovering useful applications to operating their consequences. Positive organizational impact and improving image tools encourage more experimentation, while audio attracts the strongest adoption intent. Cost constrains how far teams take those experiments. Open weights add choices inside increasingly consolidated tool stacks, and write-enabled agents make control more consequential. The emerging division of labor is recognizable: buy more of the inference infrastructure, keep more of the product logic close, and work out how to govern systems that can now change the world they read.

The full 2026 AI Engineering Report includes every chart and additional breakdowns beyond the presentation. Yaron closes by inviting questions for the next survey: what engineers need to understand in 2027 will depend on what they build—and what becomes difficult to operate—between now and then.