Лучшие среды для разработки: какую нейросеть выбрать
Лучшие нейросети для разработки сравниваю по месту выполнения правки: Claude Code локально, Codex Cloud в подготовленной среде и обсуждение кода в LibraChat.
Д
Денис
Продакт LibraChat
12 мин чтения
Проект открыт на ноутбуке, рядом работает маленький сервер, вход в нужный сайт сохранён в браузере. Кажется, всё готово: осталось поручить изменение помощнику. Но где он будет его выполнять? Выбирая лучшие инструменты для разработки, я сначала выясняю, где нейросеть будет менять и проверять код. Копия файлов в другом месте ещё не означает, что там воспроизводится мой рабочий день.
Меня как продакта раздражает ответ «у меня прошло», после которого полчаса выясняют, что именно прошло и на каком компьютере. Особенно когда изменение затрагивает несколько файлов. В одном поправили чтение данных, во втором преобразование, в третьем экспорт. Красивую разницу версий видно сразу. Зависимость от вчера вручную установленной библиотеки можно заметить значительно позже.
Ниже сравню три конкретных маршрута: Claude Code в локальном проекте, Codex Cloud с подготовленной средой и обсуждение кода в LibraChat. Критерий один: где появляется изменение, где его проверяют и что понадобится следующему человеку для повторения. Возможности сверены с официальной документацией; учебная ситуация с расписанием служит предлагаемым сценарием выбора.
Сначала найди компьютер, на котором живёт проверка
Представь небольшой проект для кружка: он читает расписание занятий и собирает календарный файл. Теперь к занятию нужно добавить отдельное поле «аудитория». Это правка чтения, внутреннего представления и экспорта. Для разговора о среде я специально беру простую функцию продукта: здесь легко отделить содержание изменения от условий его запуска.
На ноутбуке автора лежат учебный входной файл и настройки. Просмотр календаря открывается через уже запущенный локальный сервер. У коллеги есть только репозиторий. Если он получает три исправленных файла, но не знает, откуда взялся вход и как открыть просмотр, работа передана наполовину. Причина может вообще не касаться качества предложенного кода.
Мне помогает короткая таблица, которую заполняют до поручения. В ней нет рейтингов скорости: это выбор подходящего места для действия.
Маршрут · Где окажется работа · Что подготовить · Что получить обратно
Claude Code в локальном проекте — Файлы и команды в выбранном проекте на компьютере — Понятную исходную версию, учебные данные, способ запуска — Правку и сведения о проверке в этой локальной среде
Codex Cloud — Отдельная рабочая область задачи на базе опубликованной среды — Репозиторий, зависимости, инструменты и необходимую конфигурацию среды — Изменения задачи, вывод выполненных проверок и условия воспроизведения
LibraChat — Обсуждение переданного кода и описания — Нужные фрагменты, структуру проекта, описание условий запуска — Объяснение, предложения к правке и план проверки, который выполняют отдельно
Первую строку я выберу, если воспроизведение привязано к подготовленному компьютеру. Вторую — когда команда готова выделить повторяемое облачное рабочее место. Третью — если сейчас мешает непонимание устройства изменения: например, непонятно, почему новое поле теряется между чтением и экспортом. Размер проекта сам по себе этот выбор не делает.
Claude Code локально: удобство рядом с уже работающим проектом
В официальном обзоре Claude Code описаны чтение кодовой базы, редактирование файлов и выполнение команд. Есть несколько интерфейсов, включая терминал, редакторы, настольное приложение и браузер. Здесь я рассматриваю именно работу в локальном проекте через терминал; наличие у продукта других вариантов не превращает локальную сессию в облачную.
Для нашего расписания сильная сторона такого выбора понятна: можно работать рядом с тем местом, где уже воспроизводится задача. Но «рядом» нужно превратить в точное указание. Я бы записал каталог проекта и исходную версию, назвал учебный файл и отдельно указал команду проверки. Тогда «проверь экспорт» перестаёт означать случайный запуск из соседней папки.
Есть неприятная тонкость. Человек часто воспринимает состояние своего ноутбука как свойство проекта. «Это же у нас всегда установлено». Только у нас может означать одну машину. Для первой локальной правки это удобно, для передачи результата — источник вопросов. Поэтому я прошу разделять два результата: изменение кода и обнаруженные условия его запуска.
Допустим, учебный файл лежит вне репозитория. В описании результата должна появиться не только фраза о проверке, но и указание, какой вход использовался. Сам файл затем нужно сохранить в разрешённом месте или заменить воспроизводимым учебным образцом. Иначе коллега повторит команду, получит ошибку отсутствующего файла и начнёт искать дефект в чужой правке.
Для меня локальный маршрут оправдан, когда выяснение таких зависимостей сейчас дешевле на подготовленном компьютере. При этом первая успешная проверка ещё не закрывает вопрос передачи. Следующим действием будет собрать условия повторения. Платить за другой инструмент только ради более уверенного слова «готово» смысла не вижу.
Local и Worktree: два каталога могут оставаться на одной машине
В Codex тоже есть локальные варианты. Справка о режимах среды различает Local, работающий в текущем каталоге проекта, и Worktree, изолирующий изменения в Git worktree. Оба выполняются на компьютере пользователя. Cloud — отдельная удалённая рабочая область из опубликованной среды.
Это различие легко потерять из-за слова «изолировать». Отдельное дерево файлов помогает развести правки, но выбор Worktree сам по себе не отправляет вычисления на другую машину. В своей карточке я поэтому развожу две строки: «где находятся изменяемые файлы» и «где исполняется проверка». Они отвечают на разные вопросы.
В учебном проекте могут одновременно жить исправление аудитории и эксперимент с форматом названия занятия. Смешивать их в одном наборе изменений неудобно. Разведение рабочих деревьев помогает обсуждать отдельные задачи. Но для каждого места запуска всё равно требуется понять, какие настройки и входные файлы доступны именно там. Путь, однажды записанный для основного каталога, нельзя бездумно объявлять универсальным.
Я бы выбирал Local для понятной работы непосредственно в текущем каталоге. Worktree рассматривал бы для отдельной правки, которую нужно держать в стороне от текущей. А переход к Cloud обсуждал бы уже через подготовку другого места исполнения. Тогда разговор с разработчиком занимает пять минут и не превращается в спор о том, какой значок выглядит современнее.
Codex Cloud: подготовить стартовую среду и начать из неё задачу
Облачный маршрут требует отдельной подготовки. В документации Codex Cloud описаны выбор репозиториев, подготовка зависимостей и инструментов, проверка настройки, сохранение и публикация среды. Выбрать среду для задачи и создать либо опубликовать её — разные действия.
Для нашего кружка я бы сначала собрал учебный комплект: репозиторий, вымышленное расписание, необходимые зависимости и описание просмотра результата. Затем проверил бы, что подготовленное место позволяет выполнить нужный путь от входа до календаря. Только после этого поручал бы добавление аудитории. Так сбой подготовки не смешивается с ошибкой нового поля.
Особенно полезно заранее выписать, что осталось на ноутбуке. Согласно справке о режимах, локальные файлы, запущенные процессы, входы в браузере и доступ через VPN автоматически в Cloud не переносятся. Поэтому обещание «там будет тот же проект» я перевожу в четыре предметных вопроса:
Есть ли в облачной среде необходимый учебный вход, а не только исходный код?
Чем там заменяется локальный сервер просмотра и нужен ли он для данной проверки?
Какая часть задачи требует внешнего сервиса и разрешённого доступа к нему?
Можно ли принять правку на воспроизводимом примере, не привязывая её к личному браузеру автора?
Например, ручной вход в календарный сайт на ноутбуке не доказывает, что облачная задача сможет проверить импорт туда. Я разделил бы приёмку: формирование календарного файла проверяется в подготовленной среде, а импорт в выбранный интерфейс — человеком в названном месте. Если нужен единый сквозной путь, его придётся подготовить отдельно. Молчаливо склеивать эти две проверки нельзя.
Такой выбор подходит команде, которая хочет повторять поручения с известной отправной точки. Он хуже подходит ожиданию «пусть помощник просто увидит мой компьютер». Здесь время уходит прежде всего на описание рабочего места. Для регулярных задач это может быть полезной инвестицией, для разового вопроса о трёх строках — чрезмерным началом.
Есть простой способ сравнить два маршрута до большой переделки. Дай ответственному за каждый вариант одинаковую карточку среды и попроси отметить недостающее. В локальном варианте может выясниться, что запуск давно держится на незаписанной настройке. В облачном — что доступный репозиторий ещё не содержит нужного учебного образца. Это разные затраты на подготовку, их полезно увидеть до выбора подписки.
Для расписания я отдельно отметил бы два уровня готовности. Первый: программа создаёт календарный файл из сохранённого входа. Второй: этот файл корректно открывается там, где им будут пользоваться. Если второй шаг доступен только человеку, так и назначаю его человеку. От инструмента жду ясного результата первого шага, а от приёмки — завершения второго. Такая договорённость оставляет меньше места для взаимных ожиданий «я думал, ты уже посмотрел».
Почему новая задача может вести себя иначе, чем вчерашняя
Вот место, где я остановился бы перед выводом о качестве помощника. В существующей задаче установили недостающий инструмент, после чего экспорт заработал. На следующий день открыли новую, и снова ошибка. Кажется, что продукт забыл решение. Но сначала нужно проверить, что именно сохранили и откуда стартовала новая работа.
Документация Cloud различает новую задачу из подготовленной опубликованной среды и продолжение существующей с её сохранёнными файлами, незакоммиченными изменениями и установленными инструментами. Изменения задачи не обновляют общую стартовую среду. Для обновления настройки предусмотрена повторная публикация; уже существующие задачи сохраняют своё состояние.
Применительно к расписанию я бы завёл журнал из трёх пунктов. Первый — что добавлено в код проекта. Второй — что сделано только внутри текущей задачи для проверки. Третий — какое из этих условий нужно включить в настройку будущих задач. У каждого пункта свой адресат: ревьюер правки, человек, воспроизводящий запуск, и ответственный за стартовую среду.
Условный пример: проверка требует учебный файл с новой колонкой. Добавить его в текущую рабочую область достаточно, чтобы исследовать поведение здесь. Для следующего поручения нужно отдельно решить, где хранится этот образец и как он окажется у исполнителя. Запись «проверено на расписании» не передаёт сам образец и не объясняет его происхождение.
Мне нравится вопрос «повторится ли это в новой задаче?». Он обнаруживает скрытую ручную подготовку быстрее длинного обсуждения памяти агента. И подсказывает следующий шаг: не просить заново угадать окружение, а сохранить нужное условие в подходящем месте. Для рабочего результата важна не только сегодняшняя удачная сессия, но и понятный старт завтрашней.
LibraChat: сначала разобрать переход между файлами
Иногда подготовку среды откладывают по понятной причине: ещё неясно, что нужно менять. В расписании аудитория читается, но в календарь не попадает. Я могу передать в LibraChat относящиеся к этому фрагменты и попросить объяснить путь поля. Это задача обсуждения кода. Выполнение проекта, применение предложения и проверка экспорта остаются отдельными действиями.
Вот запрос, с которого я начал бы такой разбор:
В учебном проекте поле «аудитория» проходит через чтение, преобразование и экспорт. Ниже три фрагмента и названия их файлов. Объясни, где значение может потеряться. Сначала назови недостающий контекст. Затем предложи план согласованной правки и перечисли, какие условия запуска понадобятся для её проверки. Если проверка зависит от сервиса вне проекта, выдели её отдельно.
В таком разговоре полезен именно список неизвестного. Если непонятно, как открывается экспорт, я узнаю это до настройки удалённой среды. Если хватает одного уточнения структуры данных, возможно, полноценное поручение агенту пока вообще не нужно. Я бы открыл LibraChat для обсуждения фрагментов, сохранил список условий и уже с ним выбирал место выполнения.
Общий выбор формата помощи разобран в статье о ChatGPT для программирования. Здесь мне нужен более узкий итог: куда отправится работа после обсуждения. Предложенный текст исправления ещё надо перенести в выбранный проект, а описание будущей проверки — отличить от вывода реально выполненной команды.
Что я попрошу передать вместе с многофайловой правкой
Лучшие нейросети для разработки помогают ровно настолько, насколько команда умеет продолжить полученную работу. Поэтому в конце я принимаю комплект, в котором можно найти ответы без пересказа всего разговора. Для учебного проекта он выглядит так:
Исходная версия проекта и перечень изменённых файлов с назначением каждого изменения.
Место выполнения: локальный каталог, отдельное рабочее дерево или конкретная облачная задача.
Учебный вход и условия запуска, включая зависимости и необходимые внешние службы.
Команда фактической проверки, её результат и отдельно то, что осталось непроверенным.
Способ повторить проверку в следующем рабочем месте и человек, принимающий оставшуюся часть.
Важен четвёртый пункт. «Предлагаю запустить» и «запустил» должны занимать разные строки. При облачной проверке формирования файла ручной импорт на ноутбуке не стоит отмечать выполненным заодно. При локальном запуске не стоит обещать, что новая облачная задача получит те же условия без подготовки.
Если выбираешь разговор с кодом, сначала сопоставь нужные функции с текущими условиями LibraChat. Для агентного маршрута начни с карточки среды, а затем оценивай подходящий продукт. Попробуй сейчас заполнить пять строк из списка выше для своего первого поручения: по ним станет видно, где заканчивается убедительное объяснение и начинается воспроизводимая правка.
