Лаура (@poteto), инженер core-команды React Compiler, ранее работавшая в Cursor, Meta и Netflix и сейчас ведущая команду Grok Bot в xAI/SpaceX, опубликовала 30 октября 2026 года манифест: с распространением ИИ-агентов код будет поступать «непрерывным потоком», и большую часть софта придётся перестроить под новый, более быстрый темп. Пост стал ответом на расследование 404 Media о внутренней политике Proton и за сутки набрал около 287 тысяч просмотров.

image

Что произошло

30 октября 2026 года Лаура (@poteto) опубликовала в X пост-манифест. Его ядро: из-за ИИ-агентов код будет поступать «непрерывным потоком», как бурная река, поэтому большую часть софта придётся перестроить и переписать, чтобы приспособиться к новому, более быстрому темпу. Кодовая база, по её описанию, превращается в «органическую архитектуру»: вклад агентов разрастается вокруг ограничений и защитных рамок, которые проектируют люди. Отсюда её главный призыв — «сделать так, чтобы простой путь был правильным»: проектировать системы, фреймворки и языки, которые обуздают хаос агентной генерации. Поводом стало расследование 404 Media о внутренней политике Proton, опубликованное днём ранее. Позже автор отдельно отметила, что получила множество ответов о maintainability и чистом коде.

Контекст

Манифест появился на фоне расследования Joseph Cox в 404 Media «Manifestos, Fear, and 'Loser Thinking': Inside Proton's AI Reckoning», вышедшего 29 октября 2026 года. Согласно публикации, CEO Proton Энди Ян запретил инженерам «любить и вручную писать код», объявил текущий год последним, когда компания нанимает обычных инженеров, а в служебном Slack-каноне безопасности призыв проводить пентестинг перед деплоем был назван «loser thinking». Автор манифеста при этом не случайный комментатор: она работает в core-команде React Compiler, ранее — в Cursor, Meta и Netflix, а сейчас ведёт команду Grok Bot в xAI/SpaceX, поэтому её текст читают как мнение практика из самой агентной разработки. Её принцип «сделать простой путь правильным» по сути возвращает классический production-инжиниринг: надёжность при непрерывном потоке кода достигается спроектированными ограничениями, а не героическим ревью каждого изменения.

Почему это важно для индустрии

Для индустрии манифест фиксирует сдвиг инженерной парадигмы: когда агенты генерируют код непрерывным потоком, конкурентное преимущество смещается с «чистоты» отдельных функций к проектированию ограничений, guardrails и фреймворков, в которых агенты — в том числе с минимальным контекстом — не ломают систему. Написание кода становится дешёвым, а дефицитом — проверки и среды, в которых агентский поток не разрушает продукт. Принцип «make the easy path the right path» читается как готовый продуктовый roadmap: упаковывать правила, границы и автоматические проверки в инфраструктуру — агент-ориентированные API, скиллы и «agent-friendly» кодовые базы. Если тренд агентной генерации сохранится, вероятно появление де-факто стандартов «agent-friendly» структуры репозиториев и рост спроса на инструменты policy-as-code, автоматического ревью, генерации тестов и security-сканов перед деплоем — как отдельной категории рядом с AI-кодинг-ассистентами. Резонанс уже сказывается на практиках: команды, активно использующие агентов, пересматривают структуру репозиториев и пайплайны проверок, хотя платёжеспособного спроса на «новые платформы» это пока не создало — сдвиг идёт в практиках и найме, а не в бюджетах.

Почему это важно для пользователей

Практический вывод для читателей, которые работают с агентами, пишущими код: заранее проектируйте структуру проекта так, чтобы «простой путь» для агента совпадал с правильным. Сюда входят чёткие границы и guardrails, документация для агентов и автоматические проверки — тесты, CI и evals на агентские диффы; правила проекта полезно формализовать именно в документации, которую агент считывает. Второй вывод — предостережение из кейса Proton: давление на скорость ради выручки может подавлять проверки безопасности, поэтому при оценке ИИ-продуктов стоит интересоваться, как команда верифицирует код, а в собственном процессе не отменять security-этапы перед деплоем даже под дедлайном.

Что пока неизвестно / ограничения

Тезис «придётся переписать большую часть софта» — гипотеза одного практика, а не исследовательский вывод: в манифесте нет методологии, измерений и бенчмарков, нет данных о доле агентного кода, частоте регрессий или стоимости поддержки — только аналогия с крупными техкомпаниями, которые уже справлялись с лавиной кода из-за роста команд. Опыт автора в React Compiler и руководство командой Grok Bot повышают вес мнения, но допускают bias наблюдателя. Есть и техническая оговорка: большие команды порождали избыточный код с независимыми ошибками разных людей, а непрерывная генерация агентами может давать коррелированные систематические ошибки, наследующие смещения модели и обучающих данных, — разница в характере и стоимости таких сбоев пока не измерена. Кейс Proton известен по расследованию 404 Media как организационное решение без опубликованных метрик качества, так что проверять его эффективность пока не на чем. Наконец, манифест — не инструмент, а редакционный текст: в нём нет API, прайсинга или данных о latency, а прогнозы о стандартах «agent-friendly» инфраструктуры — интерпретации, действительные лишь при условии, что тренд агентной генерации сохранится.

Источники

Автор

Look at AI, редакция