Для разработчика Dots интересен не как ещё один чат с подсказками кода, а как способ связать длительную задачу с рабочим окружением. OpenAI представила продукт 29 сентября 2026 года (DevDay). Dot работает на GPT-6 Astra, имеет собственный облачный компьютер и может создавать задачи в облачных окружениях Codex. Но это не означает, что помощник получает доступ к любому репозиторию или сам становится владельцем проекта.
Дополнительные материалы на русском собраны в нашем проекте о Dots: Dots. Это не официальный вход в OpenAI и не документация для разработчиков. Ниже — практическая схема: как подготовить окружение, какие разрешения оставить выключенными и как проверять не только написанный код, но и утверждение о том, что работа действительно завершена.
Что именно связывает Dots и Codex
У Dot есть собственная облачная рабочая среда. Для работы с облачным окружением Codex его сначала нужно создать в Codex, а уже затем просить Dot использовать это окружение для облачных задач. Это важная последовательность: сообщение помощнику не создаёт автоматически любой требуемый проект, не угадывает структуру репозитория и не даёт доступ к материалам, которых нет в выбранной среде.
Такой процесс подходит для многошаговой работы: разобрать задачу, изучить доступные файлы, предложить изменение, выполнить проверку и принести результат на ревью. При этом конкретные команды, тесты и ограничения должны быть заданы в контексте проекта. Фраза «почини всё» не является техническим планом и не объясняет, какие изменения допустимы.
Как подготовить облачное окружение
- Создайте нужное окружение в Codex и убедитесь, что оно содержит ожидаемый проект.
- Опишите Dot цель задачи, исходное состояние и границы изменения.
- Укажите, какие проверки обязательны и в каком виде нужно вернуть результат.
- Попросите сначала показать план или обнаруженные препятствия, если задача затрагивает несколько частей кода.
Пример постановки:
В указанном окружении проверь ошибку в обработке формы. Сначала воспроизведи проблему и назови файл и условие, при котором она возникает. Затем подготовь минимальное исправление. Запусти доступные тесты, перечисли их результат и отдельно укажи, что проверить вручную. Не меняй публичные тексты, конфигурацию развёртывания и соседние функции без согласования.
Здесь есть объект, порядок действий, критерий доказательства и запрет на лишний объём. Если окружение не содержит нужного теста или зависимости, хороший результат — сообщить об ограничении, а не заполнить пробел предположением.
Локальный компьютер по умолчанию закрыт
Облачное окружение Codex не равно вашему ноутбуку. Доступ Dots к локальному компьютеру — отдельная возможность, изначально выключенная. Его включают через настольное приложение ChatGPT; разрешение можно отозвать. При подключении Dot может создавать Work или Codex-задачи и использовать локальные навыки. Локальный браузер используется только когда облачный браузер недоступен.
Для разработчика это означает два разных маршрута:
- в облаке работают с заранее созданным окружением и его материалами;
- локально работают с файлами и инструментами конкретного компьютера после отдельного разрешения.
Не включайте локальный доступ без необходимости. Для небольшого исправления обычно достаточно ограниченного облачного проекта. Если нужен локальный файл или браузер, укажите это в задаче и заранее определите границы действия.
Пользовательские правила для технической работы
В Dots можно задать, как помощник должен поступать с чувствительными действиями: выполнить без вопроса, сделать после предварительного разрешения, спросить перед действием или передать решение человеку. Для кода полезно начинать с консервативного режима. Пусть Dot читает, анализирует и предлагает изменения, а запись в важную ветку, публикацию или отправку сообщения выполняет человек после проверки.
Такие правила не заменяют ревью. OpenAI предупреждает, что Dot может ошибаться. Поэтому отчёт «готово» нельзя принимать без просмотра диффа, тестов и поведения сценария.
Полезное правило проекта может звучать так: «Перед изменением перечисли затронутые файлы и риск. Не трогай секреты и настройки развёртывания. Если тест не запустился, покажи причину. Внешние сообщения и публикации только после моего подтверждения». Это пример понятной пользовательской инструкции, а не техническая документация.
Как проверять код и отчёт о работе
Проверка результата должна отвечать на четыре вопроса:
- Изменён ли именно тот код, который отвечает за проблему?
- Есть ли тест или воспроизводимый шаг, показывающий исправление?
- Не нарушено ли соседнее поведение?
- Какие части остаются непроверенными из-за отсутствия данных или инструментов?
Попросите краткий отчёт: цель, изменённые файлы, команды проверки, результат, ручные шаги и риски. «Тесты пройдены» должно означать конкретный набор тестов; если они не запускались, это нужно указать.
Для интерфейса проверьте сценарий, где возникла ошибка; для серверного кода — граничные случаи и формат ошибок. Конфигурацию сравните с ожидаемым окружением и согласуйте отдельно. Эти шаги не выполняются автоматически вместе с патчем.
Как не расширить задачу случайно
Широкий запрос легко принять за разрешение на архитектурную переделку. Зафиксируйте неизменяемые части: интерфейс, тексты, зависимости, схему данных и развёртывание. Укажите, допустим ли рефакторинг или нужна минимальная правка.
Вместо «ускорь страницу» задайте: «Измерь сценарий, назови узкое место, предложи изменение только в компоненте списка. Не меняй библиотеку, разметку и серверные настройки. Покажи измерения до и после, если они доступны». Так исправление не превращается в набор несвязанных улучшений.
Когда Dots полезнее одного запроса
Для объяснения функции, небольшого фрагмента или идеи рефакторинга может хватить обычного диалога. Dots стоит рассматривать, когда работа продолжается: появились новые замечания, меняются файлы, нужно сопоставлять результаты нескольких проверок или возвращаться к незавершённым пунктам.
При этом постоянный помощник не отменяет Codex как рабочую среду и не заменяет инженера, который принимает решение о выпуске. Его ценность — удерживать цель, готовить следующие шаги и приносить изменения в форме, пригодной для проверки. Чем важнее код, тем яснее должны быть границы, доказательства и процедура остановки.
FAQ
Нужно ли создавать окружение Codex заранее?
Да. Согласно справке OpenAI, окружение нужно создать в Codex до того, как вы попросите Dot использовать его для облачной задачи.
Получает ли Dot доступ к моему ноутбуку автоматически?
Нет. Локальный доступ необязателен и по умолчанию выключен. Для него нужно отдельное подключение через настольное приложение ChatGPT, а разрешение можно отозвать.
Может ли Dot работать с локальным браузером?
При включённом локальном доступе справка OpenAI описывает создание Work или Codex-задач и использование локальных навыков. Локальный браузер используется только когда облачный браузер недоступен. Без такого разрешения остаётся облачная среда.
Достаточно ли отчёта «код готов»?
Нет. Проверьте дифф, конкретные тесты, ручной сценарий и ограничения. Если проверка не выполнялась, это должно быть явно указано.
Безопасный рабочий цикл
Создайте окружение, сформулируйте узкую задачу, оставьте локальный доступ выключенным, если он не нужен, и задайте правила для действий. Затем попросите Dot вернуть не только изменения, но и доказательства проверки. Такой цикл превращает помощь в разработке в проверяемую работу: человек сохраняет контроль над кодом и публикацией, а помощник берёт на себя часть анализа и подготовки.