У интерфейса появился второй пользователь

Двадцать лет фронтенд оптимизировали под глаз и палец: контраст, иерархия, отступы, микрокопия и анимация перехода адресованы человеку, который смотрит на экран и решает, куда нажать. Сейчас рядом с ним появился второй потребитель твоего интерфейса, и он на кнопки не смотрит вообще. Эта серия из четырёх частей — про то, что из этого следует для тех, кто делает веб-продукты.

Масштаб уже не гипотетический. По статистике Netlify, около 10 000 сайтов в день создаются непосредственно кодагентами, которые сами инициируют развёртывание, — и большинство новых проектов на платформе теперь начинается с агента, действующего от имени человека. Решение «какой сервис взять» всё чаще принимает тот, кто исполняет работу, хотя платит другой, и конкурировать приходится именно за исполнителя. Материал серии — доклады AI Native DevCon 2026 и подкаста AI Native Dev: восемь выступлений, местами противоречащих друг другу. Противоречия я не сглаживаю.

Чем агент отличается от человека как пользователь

Откуда взялся термин

Agent Experience — рабочая рамка, придуманная в довольно приземлённой ситуации. Матиас Билманн, CEO Netlify, рассказывает в докладе «Why Agent Experience (AX) Matters», что термин родился в разговоре с principal engineer, когда команда после серии интеграций с кодагентами разбирала, что у них работает, а что нет. Определение он даёт короткое: AX — это «холистический опыт, который AI-агент получает как пользователь продукта или платформы».

Ключевое слово тут — «как пользователь»: агент получает опыт продукта в той же роли, в какой его получает человек. Каналы, интеграции и транспорт — отдельные и более узкие темы. Билманн формулирует сдвиг так: продуктом теперь пользуются и агенты — напрямую и от имени человека.

Чтобы понять, насколько это большая заявка, он выстраивает линию. Норман и Нильсен придумали UX, когда стало ясно, что успех софта определяется опытом использования. Со временем UX стал рыночным дифференциатором. Следующие десять лет Netlify строила DX: онбординг, документация, бренд, SDK, CLI — одержимость разработчиком как персоной. AX — та же дисциплина с новой персоной: одержимость агентом как основной.

	UX	DX	AX
Персона	конечный пользователь	разработчик	агент
Инструменты	интерфейс, копирайтинг, иерархия	документация, SDK, CLI, онбординг	инструменты, схемы, контекст-файлы, машиночитаемые ошибки
Метрика	конверсия, удержание	time-to-first-success	доля успешных вызовов, agent NPS
Кто принимает решение о продукте	человек	человек	агент от имени человека

Последняя строка — самая неприятная. Билманн развернул вокруг AX всю продуктовую команду как вокруг North Star и объясняет почему: дифференциация продуктов будет идти по вопросу «какой продукт предпочитает агент вашего пользователя».

Тест пяти пользователей, применённый к агенту

Самая полезная практическая идея доклада — дешёвая. В классике UX-исследований есть приём: посади пять человек перед продуктом и не подсказывай, как им пользоваться.

Билманн предлагает буквально то же самое с агентом: дай ему свой CLI и API, попроси что-нибудь сделать и смотри, не вмешиваясь.

Результат он описывает узнаваемо. Агент галлюцинирует несуществующие возможности и вызывает эндпоинты, которые делают не то, что он думает. Ровно как живой пользователь, который ищет кнопку там, где её нет, — только вслух и в логах.

Это единственное известное мне из материала измерение AX, которое можно провести сегодня вечером и без бюджета.

Что у агента фундаментально не так, как у человека

Здесь полезно переключиться с продуктового CEO на инженера по безопасности. Эндрю Оутс, distinguished engineer в Snyk, в докладе «MCP Mayhem: Fun Ways AI Agents Write Bad Code» разбирает популярную метафору «агент — это джуниор» и отвергает её. Сходства поверхностны: агент пишет код, ищет информацию, сочиняет документацию и тесты. Фундаментального у него нет: понимания, способности разблокировать себя, задать вопрос, попросить обратную связь, учиться со временем и суждения. Оутс формулирует зло: «если бы такой человек пришёл ко мне в команду, с ним пришлось бы проводить performance-разговор».

Из этого следуют четыре отличия, которые прямо влияют на дизайн продукта.

Первое: у агента нет ground truth. По Оутсу, модель не понимает, что такое код, спецификация или тест, — у неё есть только обучающие данные и контекст. Её экстраполяции почти всегда правдоподобны, часто верны и иногда правдоподобны и неверны. Грубые случаи ловят компилятор и тесты. Опаснее всего те, что не ловятся. Кроме того, модели обучены угождать («пользователь всегда прав»), так что критического сопротивления ждать не приходится. Человек, упершись в странность твоего API, напишет в поддержку. Агент уверенно придумает, как оно должно было работать.

Второе: агент не откатывается к первым принципам. Оутс называет это doom spiral: упершись в стену — код не компилируется, тест падает непредсказуемо, стартовая точка выбрана неудачно — агент пробует всё более драматичные средства, пока не удалит весь код, вместо того чтобы сделать шаг назад и пересмотреть подход. Финал он цитирует почти дословно: «я выполнил задачу, удалив её, теперь программа запускается». По его наблюдению, удаление кода агентом случается каждые пару месяцев.

Третье: агент не помнит вчерашний день и не читает твой сайт. Билманн описывает LLM как «очень странного разработчика»: она прочитала весь интернет, но строит на твоём продукте по случайному устаревшему руководству вместо твоей документации. Человек хотя бы гуглит и попадает на твой домен.

Четвёртое: не видя живого состояния, агент его придумывает. Роксана Фишер, CEO anyshift, в докладе «Your Infra is a Graph» показывает это на бытовой просьбе «сделай VPC peering в Terraform». Copilot знает лучшие практики и аккуратно строит динамические зависимости, но не знает, где лежит существующий main VPC, — и досоздаёт новый. Формально решение валидно, практически оно бесполезно. Живой человек в этом месте пошёл бы смотреть консоль или спросил коллегу. Агент заполняет пробел правдоподобным содержимым, потому что другого поведения у него нет. Об этом подробно — в четвёртой части серии.

Почему привычные UX-приёмы работают против агента

Тут материал даёт несколько конкретных примеров, и все они контринтуитивны.

Красивый DOM — плохой DOM. Фиртман в подкасте «No More Screenshots» объясняет, почему агенты возвращаются к скриншотам, хотя разметка вроде бы доступна. После эпохи React DOM, отдаваемый пользователю, несемантичен — это «список из сотни div'ов», а div не несёт смысла. На нативном iOS ситуацию спасает accessibility tree, то же дерево, которое читают скринридеры. На вебе тесты дают заметно худший результат. Его формулировка: «DOM оптимизирован под человеческий мозг».

Хороший DX не гарантирует хороший AX. Пример Билманна почти анекдотический: LLM заметно лучше работают с XML, чем с JSON, по банальной причине — в XML не надо экранировать кавычки. А разработчики исторически предпочитают JSON. Твоё аккуратное решение, принятое ради людей, оказывается налогом для новой персоны.

Абстракции, которые помогали людям, прячут смысл от модели.

СО СЦЕНЫ: BREX ВЫКИНУЛ СОБСТВЕННЫЕ ХУКИ РАДИ АГЕНТА

• Кто и где: Матиас Билманн, Netlify, AI Native DevCon 2026 — со ссылкой на тред Марсело Терреро из Brex
• Что показали: Из кодовой базы убрали все собственные хуки — они прятали от модели, что реально происходит. Всю загрузку данных перевели на Relay (GraphQL), где зависимости данных объявлены прямо в компоненте.
• Цифры: цифр не назвали
• Что это меняет: Relay в своё время «не взлетел» у людей как слишком тяжёлый в освоении. Для агента контекст стал проще — и LLM начала выдавать целые возможности с одного запроса. Технология, проигравшая по DX, выиграла по AX.

Регистрация перед первым действием — трение, которое теперь бьёт и по агенту. Билманн описывает паттерн deploy-then-claim: агент развёртывает сайт без регистрации, авторизации и вообще без аккаунта, отдаёт пользователю живой URL и claim-ссылку — хочешь сохранить сайт дольше пары часов, забери его в аккаунт. Так работают Bolt и Windsurf (windsurf.build), паттерн уже скопировали Neon DB и Prisma.

Что агенту нужно, а человеку не нужно

Собранное из докладов Фиртмана и Любкена:

• Описания, написанные для модели. У Фиртмана описание инструмента — отдельная часть контракта, и он подчёркивает: это текст для модели. Его правило дизайна: «ваш потребитель не пользователь, а AI-агент».
• Технические сообщения об ошибках вместо вежливых. Фиртман: в ответ на плохой вызов возвращать точный текст — какие аргументы неверны и почему — вместо «что-то пошло не так». Тогда агент итерирует и чинит вызов сам, без человека. Тот же приём у Маттиаса Любкена в «Piece of Pi»: агент сам выясняет контракт, вызывая инструмент с --help и читая ошибки.
• Отсутствие двусмысленности в наборе возможностей. Любкен: «don't make your agent guess» — определения должны быть точными, раскрывающими намерение и узко ограниченными по охвату.
• Доставка актуальной документации прямо в контекст. Билманн считает это критичным и честно признаёт, что стандартов почти нет: cursor rules, llms.txt, MCP — и всё.
• Слой между API и агентом. Билманн: если дать агенту голую спецификацию OpenAPI и больше ничего, он справится хуже, чем computer use, проходящий через человеческий интерфейс. Нужно то, что подсказывает, как один вызов направляет следующий, как связать stateful-поток, какой контекст подать. MCP пока единственный кандидат в стандарт — с оговоркой самого Билманна, что «история с авторизацией там всё ещё сырая и мутная».

Что уже применяют

Кроме deploy-then-claim, в материале есть ещё одна практика, которую стоит украсть немедленно. Билманн вайб-кодил MCP-сервер для личного блога: первый промпт со ссылкой на руководство Netlify дал рабочий сервер, второй — два инструмента. Третьим инструментом он добавил «оставь фидбек в опросе agent net promoter score» и подтолкнул агентов пользоваться им после других вызовов. Текущий agent NPS сервера — 50. Довольны и Claude, и GPT.

Идея простая до неприличия: если агент — пользователь, у него можно спросить, как ему работалось. И он ответит.

Коротко

• AX — рабочая дисциплина с той же логикой, что UX и DX, только персона другая (Билманн, Netlify).
• Проверить свой продукт можно сегодня: дай агенту CLI и API, не подсказывай, смотри, что он галлюцинирует. Это тест пяти пользователей, применённый к новой персоне.
• Агент — очень плохой джуниор: у него нет ground truth, способности задать вопрос и отката к первым принципам (Оутс, Snyk).
• Решения, принятые ради людей, часто вредят агенту: несемантичный DOM после React, JSON вместо XML, собственные хуки, регистрация перед первым действием.
• Самая дешёвая победа — сообщения об ошибках. Технический текст вместо «что-то пошло не так» превращает агента в самопочиняющегося клиента.