---
title: "State of AI Engineering 2026: Agents Got Write Access"
description: "The 2026 State of AI Engineering survey of 1,048 engineers: 95% now use agents, 89% of those agents can write to real systems, and nobody has settled the control layer."
author: "MDflow"
date: 2026-08-16
reading_time: "13 min"
canonical_url: https://mdflow.cz/blog/state-of-ai-engineering-2026
md_url: https://mdflow.cz/blog/state-of-ai-engineering-2026.md
---

# State of AI Engineering 2026: Agents Got Write Access

*Published August 16, 2026 · 13 min read*


Every year Barr Yaron, an investment partner at [Amplify Partners](https://www.amplifypartners.com/), surveys practising AI engineers and presents the results at AI Engineer. This year 1,048 people answered, in partnership with Notion and Vercel. One number from the deck reframes most of the others.

Last year, 52% of teams building with agents said those agents could write data. This year it is 89% — and agent adoption itself roughly doubled, to 95% of respondents. Combine the two shifts and the share of surveyed engineers running write-enabled agents grew more than threefold in twelve months.

> **TL;DR** — The 2026 State of AI Engineering survey (1,048 respondents, run by Amplify Partners with Notion and Vercel) says agents escaped demo world: **95% of teams use them and 89% of those agents can write to real systems**, up from 52% last year. Cost became a first-class engineering constraint, evals stayed the number one stack problem for a third year, and the control layer for agents is still unsettled — the top instruments are human approvals and permission gating. If agents are now writing, the question that follows is *where they write, and how you review it*. That is the problem a markdown workspace like [MDflow](https://mdflow.cz) is built for.

## What is the State of AI Engineering survey?

**The State of AI Engineering survey is an annual census of people building with AI, run by Barr Yaron at Amplify Partners and presented on stage at the AI Engineer conference.** The 2026 edition had 1,048 respondents and was run with Notion and Vercel; the [full report](https://www.amplifypartners.com/blog-posts/the-2026-ai-engineering-report) is public.

Its most useful property is that it is not a survey of a job title. AI engineering shows up as a discipline spread across founders, CTOs, backend engineers, product people and designers. And for the third year running the same demographic pattern holds: the respondents skew senior in software and junior in AI. Of those with more than ten years of software experience, over half have three years or less of AI experience. Meanwhile the newest cohort — engineers who started their careers inside this paradigm — has nearly as much AI experience as the ten-year veterans.

That gap explains a lot of the rest of the data. These are experienced engineers applying hard-won instincts to a substrate that does not reward all of them.

## The headline: agents got write access

**The defining change in the 2026 survey is that agents stopped being read-only.** Two shifts stacked on top of each other:

| | 2025 | 2026 |
| --- | --- | --- |
| Respondents using agents | ~half | 95% |
| Of those, agents with write permissions | 52% | 89% |
| Net: all respondents running write-enabled agents | baseline | **>3× higher** |

An agent that reads, summarises and drafts fails cheaply. You read the output, you discard it, nothing happened. An agent with write access fails expensively and asynchronously — it changed something, and you find out later.

Which makes the follow-up question the survey asks the important one: how are we controlling all of this?

## The control layer is still unsettled

**The two most-used controls are human-in-the-loop approvals and permission gating — the same toolkit you would use to manage an intern.** Below those two, the answers scatter: task decomposition, retrieval, memory and persistent context, sandboxing. People are trying everything and nothing has won.

The failure modes point at the same gap. Close to two-thirds of respondents say the thing that frustrates them most about agents is hallucination or losing context mid-task. Not the plumbing — the thinking. Tool calls succeed; the agent forgets what it was doing, or confidently invents the missing piece.

Those are context problems, and they are why "memory and persistent context" appears on the control-mechanism list at all. If your control strategy for a write-enabled agent is an approval prompt, you are reviewing an action without seeing the reasoning that produced it. If the agent's working context is durable, inspectable and authored — rather than reconstructed from chat scrollback on every run — you are reviewing something you can actually check.

## Cost became a first-class engineering constraint

**Roughly three in four respondents adjust how ambitiously they use AI based on what it costs.** 40% say cost regularly shapes their decisions; another 36% say it sometimes does. Twelve months ago that was not the consensus position.

It shows up in operations too: cost and token usage is now the second most monitored thing in production, directly behind output quality. It is watched like an SLA.

The model data reinforces it. 94% of respondents use closed models in production and 45% use open-weight models — but over 90% of the open-weight users also run closed models, so open weights are augmenting rather than replacing. 87% of teams use more than one model, most commonly routing by task type. And despite the airtime the debate gets, open-versus-closed was a top-three model selection criterion for only 5% of respondents. What actually drives model choice is quality, then agentic capability like tool calling, then cost.

Reliability was named by only about one in five — most plausibly because it has become a threshold requirement rather than a differentiator, so the decision moves up the stack.

## Evals is still the number one problem

**Asked what the biggest challenge in their stack is, engineers answer "evals" — as they have every year the survey has run.** The margin over the next challenge is narrowing, but the ranking holds. Meanwhile, roughly 96% of respondents named a problem *somewhere* in their stack. They just cannot agree which layer is worst, and that disagreement is a decent map of where infrastructure still needs building.

The uncomfortable detail: the most common method for evaluating AI output is still vibe review.

The build-versus-buy data explains why nobody has sold them a fix. Across eight layers of the stack, inference and model serving is the layer people most reliably buy — few teams want to run inference infrastructure. Prompt management is the opposite: 61% build it themselves. Product logic in general — prompts, retrieval, evals — stays in-house, because everyone believes their prompts are special. Fine-tuning is the clearest "not yet": most teams simply do not do it.

## The org chart is feeling it

**97% of respondents report a net positive effect on their organisation, and the top effect is not raw speed — it is cheaper failure.** More experimentation, more prototypes, more bets, because trying something became nearly free.

That is not the whole story. More than nine in ten also report negative downstream effects, most commonly erosion of deep technical skill and of understanding of the codebase — the predictable consequence of cheap code generation. 59% fear today's AI-written code is creating long-term liabilities, and only a third would call software engineering a solved problem.

And the boundaries are dissolving. 81% say AI is blurring the line between engineering and product, design and marketing. Over a third of teams now have non-developers shipping features — mostly internal, but 17% say non-developers regularly ship customer-facing ones.

Which means the number of people and processes writing into your systems is going up on two axes at once: more agents with write access, and more humans who are not engineers shipping through them.

## Which teams should care most about the write-access shift

1. **Teams running agents on a schedule.** A cron-triggered or event-triggered agent writes when nobody is watching. The review has to happen after the fact, which means the write has to leave a trail.
2. **Teams with several agents on the same data.** Claude, Cursor, Codex, an n8n workflow and a clipper extension all writing into one store, with no way to tell whose edit is whose, is an incident waiting to be un-diagnosable.
3. **Teams where non-developers ship.** The survey's 17% figure is the interesting one. Attribution and revertability matter more when the person who triggered the change cannot read the diff.
4. **Regulated and audited environments.** "An agent did it" is not an acceptable answer to an auditor. "This token, at this time, changed these lines" is.
5. **Anyone whose agents lose context mid-task.** If two-thirds of the field names this as its top frustration, the fix is not a better model — it is making the context durable and authored rather than reassembled every run.
6. **Solo builders with long-running loops.** The cost of an unreviewable agent write is the same whether or not you have colleagues; you just find out about it more slowly.

## How MDflow fits

MDflow is a markdown workspace that AI agents can read and write over MCP and an HTTP API. It is not a sandbox, a permission proxy, or an approval queue — it does not intercept your agent's tool calls, and it will not stop an agent from doing something silly. What it addresses is narrower and, going by this survey, badly under-served: **when a write-enabled agent produces something durable, where does it land and how do you review it?**

### What already lines up today

- **Writes land as plain markdown.** Every document is a file a person can read. An agent writing into a vector index or a proprietary blob produces output you can only inspect through the same system that created it; an agent writing markdown produces output you can read in a browser, on a phone, in a diff, or in `curl`. The `.md` twin of any shared document is served raw, with YAML frontmatter.
- **The Document Log answers "what did the agents do".** `/log` is a cross-document activity feed of created, edited, shared and deleted events, with the actor on every row — `you` for browser actions, and `automated · <token name>` for anything arriving over the HTTP API or MCP server. Give each agent its own [Personal Access Token](https://mdflow.cz/docs/mcp) and the feed tells you which agent wrote what. Click an edited row for a side-panel diff of exactly what that edit changed. Deleted documents keep their who, what and when even though the document is gone.
- **Version history gives you the way back.** Document edits retain bounded previous versions with line-by-line diffs and non-destructive restore. It is deliberately owner-private and **not exposed over the API or MCP** — an agent can write, but it cannot rewrite its own history or roll back the evidence.
- **A guard against the worst accidental write.** Any body replacement that would empty a document is refused unless the request explicitly passes `confirmEmpty: true`. A client with an unloaded or cleared buffer cannot silently wipe a document. This is a small thing that stops a specific, real class of agent failure.
- **Folder descriptions are authored retrieval intent.** Each folder carries a description that says what the documents inside are for, and [`mdflow_get_context`](https://mdflow.cz/docs/mcp) ranks those descriptions *above* folder names and document titles. That is the difference between an agent guessing which context to load and being told.
- **One workspace, every surface.** The same documents are reachable from Claude, ChatGPT, Cursor and Codex over the remote MCP server (OAuth or PAT), from n8n, cron jobs and CI over the [HTTP API](https://mdflow.cz/docs/api), plus a local stdio MCP server, a VS Code extension, the [Web Clipper](https://mdflow.cz/clipper) and an iOS app. No agent is bound to one checkout on one laptop.
- **Real permission gating exists for humans.** On Teams, each member's access to a workspace is **No access**, **Read only**, or **Read, write & delete**. Agents act with the access of the token's owner.
- **Client-side encryption for what should never reach a model.** Password-based encryption happens in the browser; MDflow never holds a key, and an encrypted body is opaque to any agent that has not been given the password.

### Where we are headed

Direction, not a dated commitment. The honest gap today is credential granularity: a Personal Access Token reads and writes everything its owner owns, so "give each agent its own token" buys you attribution but not least privilege. Narrower agent credentials — read-only tokens, folder- or workspace-scoped tokens — are the natural next step, and the survey is a good argument for prioritising them. The second thread is richer structured retrieval over folder descriptions, so an agent picks the right three documents out of four hundred rather than the three that happen to match a keyword.

## The bottom line

The 2026 State of AI Engineering survey documents a field where the capability question is largely settled and the control question is wide open. Agents work, teams run several models, cost is a budget line, and 89% of those agents can now write. What nobody has is a settled answer for how to supervise them — the best available instruments are an approval prompt and a permission flag.

Part of that answer is unglamorous and available now: make the durable output human-readable, attribute every write to a named actor, keep a diff, and keep a way back.

[Start free](https://mdflow.cz/login) · [Connect an AI agent](https://mdflow.cz/docs/mcp) · [Read the API docs](https://mdflow.cz/docs/api)

## Frequently asked questions

### What is the 2026 State of AI Engineering survey?

It is an annual survey of practising AI engineers run by Barr Yaron, an investment partner at Amplify Partners, and presented at the AI Engineer conference. The 2026 edition drew 1,048 respondents and was run in partnership with Notion and Vercel. It covers what engineers build with, which models they run in production, how they control agents, what they build versus buy, and how AI is changing their teams. The full report is published by Amplify Partners.

### How many AI agents have write access in 2026?

Among teams building with agents, 89% say their agents can write data, up from 52% the year before. Because agent adoption itself roughly doubled to 95% of respondents, the share of all surveyed engineers running write-enabled agents rose more than threefold in a single year. That is the survey's headline shift: agents stopped reading, summarising and drafting, and started taking actions inside real systems.

### What do teams actually use to control AI agents?

The two most common answers are human-in-the-loop approvals and permission gating. Below those the results scatter across task decomposition, retrieval, memory and persistent context, and sandboxing, with no clear winner. The survey's own framing is that nobody has settled the control layer for agents — the dominant instruments are roughly the ones you would use to manage an intern.

### What is the biggest challenge in the AI stack in 2026?

Evals, for the third year running — though the margin over the next challenge is narrowing. Roughly 96% of respondents named a problem somewhere in their stack; they simply disagree about which layer is worst. Vibe review remains the single most common way teams evaluate AI output, ahead of any systematic method.

### How do you review what a write-enabled agent actually changed?

You need three things: writes that land in a human-readable format, a per-actor record of every write, and a diff plus a way back. In MDflow that is plain markdown documents, the Document Log at `/log` — which labels every write arriving over the HTTP API or MCP as `automated · <token name>`, so giving each agent its own token tells you which agent did what — and version history with line-by-line diffs and non-destructive restore.

## Further reading

- [The 2026 AI Engineering Report](https://www.amplifypartners.com/blog-posts/the-2026-ai-engineering-report) — Amplify Partners, the full survey with every chart
- [2026 State of AI Engineering — Barr Yaron, Amplify Partners](https://www.youtube.com/watch?v=RGe6EjucbzI) — the AI Engineer talk this post is built on
- [When AI agents write to your knowledge base](https://mdflow.cz/blog/ai-agents-write-to-knowledge-base) — the write path in more detail
- [Agent authorization: why scoped tokens matter](https://mdflow.cz/blog/agent-authorization-scoped-tokens) — the least-privilege argument
- [Context engineering for AI agents](https://mdflow.cz/blog/context-engineering-for-ai-agents) — on losing context mid-task
- [The personal monorepo: a context vault for AI agents](https://mdflow.cz/blog/personal-monorepo-for-ai-agents) — one concrete shape for durable agent context
- [MDflow MCP docs](https://mdflow.cz/docs/mcp) · [HTTP API docs](https://mdflow.cz/docs/api) · [FAQ](https://mdflow.cz/faq)