Решения·Разработка
Каждая сессия поднимает свой cloud computer, клонирует repo и режет свою ветку. Агент воспроизводит failure, пишет patch, гоняет suite и открывает change request. Вы ревьюите diff, а не transcript.
Передача работы
Не архитектура. Длинный хвост под ней — воспроизведения, bump'ы, флейки, механическая миграция по двумстам файлам. Работа с чёткой спецификацией, мелкая поштучно и вместе — причина, почему больше ничего не выходит. Именно такую сессия делает хорошо.
Берёт репорт, собирает кейс на своей машине и возвращается с падающим тестом или причиной, почему воспроизвести не удалось. Сессия, которая не воспроизвела, так и говорит — не выдумывает fix для бага, которого не видела.
Гоняет suite в цикле, изолирует, какой тест реально падает и как часто, и находит общее состояние или timing-предположение под ним. В change request — частота падений до и после.
Обновляет, собирает, гоняет suite, читает changelog на breaking notes, патчит call site'ы, которые сдвинулись. Если suite красный — всё равно открывает change request, с failures в описании, а не с заявлением «зелёный».
Один rename, один перенос API, одно включённое lint-правило — тривиально на файл и невыносимо в масштабе. Работает файл за файлом на своей ветке и кладёт один diff на ревью.
Читает ошибки дня, кластеризует по root cause, а не по тексту сообщения, ранжирует по числу затронутых людей и доводит верхний пункт до patch.
Сравнивает описанное поведение с фактическим и правит документ под код — или помечает код как ошибочный. Оба варианта один тип коммита: здесь всё — файл.
Результат
Результат engineering-сессии — то, что разработка и так ревьюит. Новый артефакт учить не нужно, summary доверять не надо — изменение есть изменение, а тесты на машине, где его писали, либо прошли, либо нет.
Агент коммитит на ветку сессии и открывает change request в main. В ревью приходит diff с описанием — тот же объект, что открыл бы коллега.
Песочница — реальная Linux-машина: агент сам ставит зависимости, собирает и гоняет suite. Change request, пришедший красным, так и написан в описании — без заявления «зелёный».
Сессии не делят working tree. Двадцать могут идти по одному repo одновременно — каждая на своей ветке и своём компьютере, не мешая друг другу.
Куда дотягивается
Engineering-сессия уже имеет самый сильный reach на платформе — большая часть работы внутри клонированного repo. Коннекторы закрывают остальное; каждый credential резолвится на сервере, не внутри машины.
Клонируется в песочницу при старте сессии, на свежей ветке. У агента shell, файловая система и полная история — может bisect'ить, гонять suite и читать коммит, который ввёл строку, которую собирается менять.
Читает issues, комментарии и состояние ветки, пишет обратно, где вы разрешили. Neuro OS сам открывает change request; коннектор — для всего вокруг.
Тянет тикет, с которого началась сессия, читает acceptance criteria и постит ссылку на change request, когда работа готова. Тикет остаётся источником правды по scope.
Живой канал. Упомяните бота в треде — тред становится сессией; ответ и любой файл возвращаются в тот же тред.
Укажите Neuro OS на OpenAPI или Postman spec, GraphQL endpoint, удалённый MCP-сервер или bare HTTP base URL. Каждая операция становится инструментом, который агент может вызвать.
Всё, чего нет в Easy connect, доступно через MCP, OpenAPI, GraphQL или raw HTTP — честный ответ для внутреннего сервиса без публичной записи в каталоге.
Как это работает
Та же механика сессий, три способа запуска. Изоляция и ревью не меняются от триггера.
Опишите баг в Slack-треде или запустите сессию из веб-приложения или CLI. На ваше сообщение — реакция, а не пост бота; ответ приходит в тот же тред.
Поставьте действие в Ask — запуск встанет на вызове и покажет action с аргументами. Согласовали — тот же вызов завершается, сессия продолжается с того же места.
Разбор ночных исключений в 06:00. Или подключите alerting к подписанному webhook — paging event открывает сессию с payload инцидента уже в prompt.
Контроль
Интересный вопрос про автономного инженера — не что он может написать, а что может залить. Вот ответ, сформулированный точно.
Агент не может мержить в main. Разрешение существует — админ может выдать — но grant живёт в config, и расширение само изменение на ревью. Скрытого дефолта нет.
Из коробки — разрешающий режим: действие идёт, пока вы не сказали иначе. Поставьте Ask там, где нужна пауза, и Block там, где действие недопустимо. Мы честнее сказать дефолт, чем дать думать, что выбран безопасный.
Одна одноразовая Linux-машина на сессию, на своей ветке. Общее только снаружи — поэтому reach решают коннекторы, а не машина.
Песочница несёт один токен с областью проекта без сторонних ключей. Шлюз расшифровывает credential на сервере и прикрепляет к исходящему вызову.
Шлюз, который резолвит credential, же пишет запись: action, агент, человек или триггер за сессией, исход и кто отпустил удерживаемый вызов.
Та же платформа
Один проект, один набор коннекторов, память, которая накапливается. Каждая команда пишет навыки под свою работу — вторую систему не поднимают.
«Ничего не мержится само. Вы ревьюите diff на ветке — suite уже прогнан — а не transcript о том, что могло измениться.»
Любая модель, ваши ключи. Neuro OS в вашем облаке, VPC или на вашей инфраструктуре.
