Devin Cloud проще всего представить как того же Devin, только мощнее и без привязки к ноутбуку. Половина этого верна и потому опасна. Cloud-сессия действительно запускается на собственной VM с рабочим столом, браузером и computer use и продолжает работу после того, как вы закрыли ноутбук. Но слова мощнее и без ноутбука означают ещё и в другом окружении, а именно эту часть наивная картинка опускает.
Наивный ход отсюда - перекинуть текущую локальную задачу в облако как есть и ждать, что там она продолжится с того же места. Кажется логичным: агент тот же, репозиторий тот же, значит и состояние то же. Первое действие handoff это ощущение подкрепляет - передача выглядит как продолжение в облаке, одним движением.
Ломается это на границе окружения: отдельная VM - это отдельная файловая система, отдельная сеть и отдельное состояние. Cloud не видит вашего локального незакоммиченного состояния: в облако уезжает только то, что попало в репозиторий и в конфигурацию окружения. Незакоммиченные правки, локально запущенные сервисы, переменные из вашей оболочки - всё это остаётся на вашей машине, и агент в облаке честно работает без них.
Профессиональный механизм здесь - собрать окружение задачи явно, а не надеяться на невидимый перенос. Облаку передают репозиторий и ветку, шаги setup, секреты через поддерживаемый механизм и критерии готовности. Результат возвращается не изменениями на вашем диске, а веткой и pull request, которые вы затем проверяете. То есть Cloud - это не продолжение вашей сессии, а самостоятельный запуск из зафиксированного состояния. Setup описывает, как окружение приводится в рабочее состояние: установка зависимостей, миграции, запуск нужных сервисов - всё то, что на вашей машине давно сделано и потому невидимо, а в чистой VM должно быть выполнено заново.
Почему облако устроено как отдельная поверхность, а не как удалённая копия вашего ноутбука. Долгий горизонт возможен именно потому, что VM не зависит от вашей машины: она переживает закрытую крышку, разрыв сети и перезагрузку клиента. Ценой за эту независимость и становится то, что облако не знает ничего, что вы не передали ему явно. Нельзя одновременно быть независимым от вашей машины и видеть её незафиксированное состояние - это одна и та же граница, взятая с двух сторон.
Цена невнимания к этой границе двойная. Первая - функциональная: задача, которой нужны ваши локальные сервисы или незакоммиченные файлы, в облаке честно исполнится не с тем состоянием, и результат окажется мимо. Вторая - безопасность: отдельная машина - это отдельная поверхность атаки. Network policy, доступ к репозиторию и секреты настраивают по минимуму, а production-credentials не передают ни в prompt, ни в tracked-файлы - там они переживут задачу и станут утечкой.
Оправдан Cloud там, где нужен именно долгий и изолированный ход: продолжительный reproduction, широкий прогон тестов, отдельный PR, задача, которой полезно чистое окружение без вашего локального мусора. Признак такой задачи - вам не жаль закрыть ноутбук, пока она идёт, и вы можете описать её вход и выход, не ссылаясь на то, что сейчас открыто у меня локально. Полезно заранее прикинуть, воспроизводится ли задача на чистой машине по одному описанию, - если нет, её сначала доводят до воспроизводимости, а уже потом отправляют в облако.
Проверять результат облачной работы стоит по pull request в чистом окружении, а не по ощущению, что агент что-то сделал. Зелёные проверки в облаке ценны именно тем, что прошли без вашей локальной обвязки: если тест зелёный там, он опирается на переданное окружение, а не на случайно запущенный у вас сервис. Diff в PR читают так же, как любой чужой diff, - потому что для вашей машины он и есть чужой.
Отсюда инженерный вывод: относитесь к облачной задаче как к запуску на чужой машине, а не как к продолжению своей. Всё, что нужно для воспроизведения и проверки, должно быть внутри репозитория, конфигурации окружения и критериев готовности; всё, что вы держите в голове или в незакоммиченном виде, для облака не существует. Это следствие устройства, а не придирка: граница окружения объективна и не обходится удобным допущением.
Типичный провал - агент в облаке не видит мой файл и почему тесты падают, у меня же локально всё зелено. Симптом один: состояние, на которое рассчитывали, осталось на вашей машине - незакоммиченным, в локальном сервисе или в переменной оболочки. Прежде чем винить агента, проверьте, что всё нужное закоммичено и передано, а секреты переданы безопасным механизмом, а не строкой в промпте, - чаще всего расхождение объясняется именно границей окружения.