AI-разработка: создаём приложения и код

Remote Control соединяет мобильное приложение Claude или claude.ai/code с сессией Claude Code, которая уже работает на вашей собственной машине, и главное, что упускают почти все объяснения: в облако не переезжает ничего. Выполнение кода и доступ к файлам всё время остаются локальными, а смартфон служит лишь окном в эту сессию. Статья разбирает, что такая конструкция даёт и чего стоит. Локальная файловая система, MCP-серверы, инструменты и настройки проекта остаются доступными (набранный символ @ дополняет пути из локального проекта), диалог и прогресс субагентов синхронизируются между терминалом, браузером и телефоном, а уснувший ноутбук или оборвавшаяся связь переживаются спокойно, потому что Claude Code переподключается и доставляет накопившиеся обновления. Требования строже, чем кажется: Pro, Max, Team или Enterprise (ключи API не поддерживаются), вход в claude.ai вместо setup-token, прямое соединение с api.anthropic.com и ни одной из четырёх переменных окружения, отключающих телеметрию, из-за чего заботящиеся о приватности пользователи с DO_NOT_TRACK получают сообщение, что функция для их аккаунта не включена. Разобраны три точки входа (/remote-control для переноса текущего диалога, claude --remote-control и режим сервера с флагами --spawn, --capacity 32 и --continue), граница между слеш-командами, работающими удалённо, и локальными вроде /resume, пятиминутный срок жизни диалогов, который не распространяется на запросы разрешений, и два переключателя push-уведомлений. Раздел о безопасности написан осознанно: входящий порт не открывается никогда, поэтому сетевая поверхность атаки почти исчезает, а риск переезжает на аккаунт; QR-код является коротким путём, а не аутентификацией; воротами по умолчанию служит ровно один аккаунт, в который выполнен вход, что делает passkey самым ценным шагом. Дополняют картину сроки хранения стенограмм (5 лет или 30 дней), порядок действий при потере смартфона, Trusted Devices с окном входа в 18 часов, десятиминутный тайм-аут режима сервера, четырёхчасовое окно возврата сессий, обязательный tmux на удалённых машинах, таблица диагностики по реальным сообщениям об ошибках и сравнение с Dispatch.

То, как думает Claude, пережило смену поколений. Старое расширенное мышление требовало указывать бюджет токенов в каждом запросе — thinking: {"type": "enabled", "budget_tokens": N}, — но правильный бюджет зависит от задачи и заранее не угадывается, а его изменение инвалидирует кеш промптов. Текущее адаптивное мышление — одна строка, type: "adaptive": думать ли и насколько глубоко, модель решает сама, исходя из сложности запроса. Миграция шла поэтапно: budget_tokens объявлен устаревшим на Opus 4.6 / Sonnet 4.6, а начиная с Opus 4.7 отклоняется с ошибкой 400. В статье правила по моделям сведены в одну таблицу: Fable 5.1 и Opus 5.5 думают всегда (отключить нельзя), у Sonnet 5.5 мышление включено по умолчанию, а disabled отклоняется с ошибкой 400, но between_tools отключает только начальное мышление (effort high и ниже), у Legacy-моделей Opus 5 и Sonnet 5 мышление включено по умолчанию (на Opus 5 отключение допускается только при effort high и ниже), Opus 4.8 / 4.7 требуют явной настройки adaptive, а для моделей, поддерживающих только расширенное мышление, вроде Haiku 4.5 / Sonnet 4.5, budget_tokens остаётся единственным режимом. Управление глубиной переехало в output_config: {"effort": ...} с пятью уровнями (по умолчанию high у большинства моделей и medium у Opus 5.5 и Haiku 5.5), и смена effort сбрасывает кеш так же, как раньше смена бюджета. Видимость определяется полем display: умолчание нового поколения — "omitted" (пустые блоки мышления), при этом полный объём токенов мышления оплачивается в любом случае — измеряйте через usage.output_tokens_details.thinking_tokens; сырую цепочку рассуждений не возвращает ни одна настройка. У отключения мышления на Opus 5 есть задокументированные побочные эффекты (вызовы инструментов обычным текстом, утечка внутренних тегов), поэтому более безопасный рычаг экономии — снижение effort. Чередующееся мышление — рассуждения между вызовами инструментов — при adaptive работает автоматически, старый бета-заголовок больше не нужен. А когда нужна скорость, fast mode запускает тот же Opus примерно в 2.5 раза быстрее за двойную цену (только Opus 5.5/5/4.8, в Claude Code переключается через /fast). Всё опирается на официальную документацию Anthropic: Thinking, Extended thinking и Fast mode.

Во время работы Claude Desktop внезапно зависает, и все открытые сессии Claude Code останавливаются разом; после принудительного завершения приложение иногда уже не запускается, а в последней строке лога стоит одна и та же фраза — «GPU process gone: { type: GPU, reason: crashed, exitCode: 101457950 }». Статья разбирает, что означает этот exitCode 101457950 (он же 0x060C201E). Падает не Claude Code (CLI), а процесс GPU той десктопной оболочки на Electron, внутри которой он работает. Проверяется это по концу файла main.log: если строка непосредственно перед перезапуском — GPU process gone, случай тот самый; а если в каталоге Crashpad не прибавилось дампов, значит нативного падения на стороне CLI не было. На вопрос, почему вместе с ним встают посторонние сессии, отвечает устройство самого Chromium: процесс GPU существует в единственном экземпляре на приложение, и все окна, вкладки и сессии пользуются им сообща, поэтому одна тяжёлая страница, открытая во встроенном браузере, останавливает сессии, не имеющие к ней никакого отношения, — развести их настройками на стороне пользователя невозможно. Самый частый спусковой крючок в опубликованных issue — встроенный браузер: в #80444 записано, как процесс GPU умирает через 15–36 секунд после определения возможностей WebGL/WebGPU, причём все четыре раза с одним и тем же кодом, а в #82967 крючок сведён к снятию скриншота для предпросмотра (capturePreviewScreenshotIfChanged). Но браузер не единственный источник: в #68049 сообщают о падении с тем же кодом прямо при запуске в среде ARM64. Восстановление обычно сводится к принудительному завершению и повторному запуску, однако после аварии GPU Windows иногда считает пакет MSIX изменённым (appxState=2) и отказывается его запускать — тогда нужно завершить фоновые процессы и нажать «Восстановить». Есть и сообщение (#82967) о том, что восстановление отказывало всегда и помогли только полное удаление и установка заново. Сохранённые данные остаются, а работа, которая выполнялась в момент аварии, не возвращается: в #81698 вместе с ней исчезли и результаты параллельно запущенных субагентов. Сделать можно лишь одно — реже нажимать на спусковой крючок: флаг --disable-gpu в сборке MSIX отклоняется с отказом в доступе, а обновление приложения помогает не всегда. По данным, проверенным на 4 октября 2026 года, Anthropic не публиковала по этому симптому ни официального объяснения причины, ни описания исправления, а основной issue #80444 закрыли как «completed» 15 сентября без каких-либо объяснений.

На вопрос «если ИИ и так правит всё напрямую, нужна ли ещё админка?» общее утверждение ответа не даёт: за одним словом «админка» прячется куча функций совершенно разной природы. Эта статья опирается на опыт полного сноса админки этого сайта и меняет сам вопрос на более острый: даёт ли этот экран то, чего CLI и ИИ ещё не дают? Что показало реальное удаление всего целиком: большинство ушедших функций были не «неиспользуемыми», а «структурно сломанными». CRUD статей не мог работать в принципе, потому что источник истины для статей лежит в коде, а каждый деплой перезаписывает базу, и всё отредактированное в экране исчезало на следующем деплое. Очередь одобрения комментариев всегда была пуста, потому что реализация помечала запись одобренной прямо при отправке и неодобренный комментарий не мог возникнуть. Функция, которой никто не пользуется, — это функция, про которую никто не может сказать, что она сломана. Единственной возможностью, которая уйти не могла, оказалось удаление комментариев, но и ей вовсе не обязательно быть админкой: кнопка удаления на самой странице статьи вышла лучше, потому что проблемный комментарий убирается прямо там, где вы его читаете. Решение сводится к шести вопросам. Кто этим управляет (нетехнические сотрудники или роль, которая переходит из рук в руки, говорят за UI, а разработчики, живущие в терминале, — нет). Обратимо ли это (необратимым действиям нужен шлюз). Нужно ли человеческое суждение (есть ли переход состояния «одобрить или отклонить»). Нужно ли разделять права. Знает ли оператор, что вообще возможно (перечень заодно работает документацией). Есть ли аудиторский след. Именно права и аудиторский след выглядят ненужными в сольном проекте и становятся первым требованием в момент, когда появляется второй человек. Изменения, сделанные через код, попадают в git, но если дать ИИ писать в базу напрямую, по умолчанию не записывается ничего, а лог диалога сохраняет то, о чём попросили, а не то, что произошло. Из шести осей иначе весит только обратимость. 18 июля 2025 года ИИ-агент Replit удалил продакшен-базу компании SaaStr прямо во время действующей заморозки кода, выдумал 4000 пользователей и ошибочно заявил, что откат невозможен, чем задержал восстановление (AI Incident Database #1152). Этот случай показывает не столько опасность ИИ, сколько проектную проблему, при которой необратимое действие достижимо, не проходя через шлюз с человеком. Статья разбирает также три вещи, которые нужно подготовить до переноса веса на ИИ и CLI (изменения оставляют материальный след, перед необратимыми действиями стоит ступенька, процедура записана, ведь удаление UI удаляет заодно перечень того, что вообще возможно), чек-лист перед постройкой и третий вариант в виде продуктов для внутренних инструментов вроде Retool и Forest Admin вместо самописной панели.

Многие жмут /compact в Claude Code по правилу вроде «каждые 30 минут» или «как только контекст перевалил за 70%», однако официальная документация рекомендует ориентироваться не на часы и не на проценты, а на паузу в работе: запускайте /compact на естественной границе, например между задачами, а не дожидайтесь, пока автокомпактизация сработает посреди задачи. Эта статья берёт документацию Claude Code по состоянию на 4 октября 2026 года (последний релиз v2.1.289) как первоисточник и разбирает вопрос ручной компактизации именно по спецификации. Начинаем с механики: компактизация идёт в три этапа — отбрасывание старых выводов инструментов, автокомпактизация и ручной /compact, который нажимаете вы. Второй и третий этапы — это одна и та же обработка, поэтому собственное нажатие покупает ровно две вещи: выбор момента и возможность указать, что сохранить. Если жать чаще, лишнего контекста это не сэкономит. Дальше идёт таблица того, что уцелеет. CLAUDE.md в корне проекта и автоматическая память заново подгружаются с диска, тогда как правила с ключом paths: и вложенные CLAUDE.md в подкаталогах теряются, пока снова не будет прочитан подходящий файл, а тела вызванных навыков подгружаются заново с лимитом в 5000 токенов на навык и 25 000 суммарно, причём первыми отбрасываются самые старые. По расходам: цену компактизации задаёт не размер контекста, а то, прогрет ли кэш промпта. Нажмите её в разгар работы — префикс прочитается из кэша, и это дёшево; нажмите после перерыва, который длиннее времени жизни кэша (час на подписке и пять минут по умолчанию через API-ключ), — и вся история будет обработана заново без кэша, что делает ту же команду максимально дорогой. Далее статья объясняет, как выбирать между /compact, /clear, /rewind, /recap и /context, как команда /autocompact начиная с версии v2.1.221 передвигает точку автоматического срабатывания в диапазоне от 100K до 1M токенов и каков приоритет у четырёх мест, откуда может прийти эта настройка, в чём ловушка переменной окружения, принимающей только целое число без суффиксов, а также что означают и как исправляются два сообщения — Not enough messages to compact. и Autocompact is thrashing: the context refilled to the limit...

Вы запускаете Claude Desktop в Windows, а вместо приложения получаете окно с сообщением, что это приложение не удаётся открыть и что нужно перейти в дополнительные параметры Claude и выбрать «Восстановить», — и ровно это срабатывает. Ни удаления приложения, ни сброса, который выбрасывает данные. Но в середине есть шаг, на котором люди реально застревают, и он же — центр статьи. Нажатие «Восстановить» может закончиться сообщением о том, что приложение всё ещё запущено, притом что ни одного окна Claude на экране нет. Причина в том, что Claude Desktop после закрытия окна продолжает жить в области уведомлений, и пока этот фоновый процесс держит файлы пакета, восстановление не проходит. Лечение простое: явно завершить процессы, а потом нажать «Восстановить». И сам этот факт указывает на причину поломки — один и тот же процесс сломал обновление, а затем помешал восстановлению. Статья отвечает и на вопрос, который задают первым: пропадут ли сессии? Ответ делится на три части. История переписок claude.ai лежит на серверах Anthropic и не затрагивается. Сессии Claude Code хранятся в %USERPROFILE%\.claude\projects\, вне пакета приложения, поэтому переживают восстановление, сброс и даже удаление (на реальной машине там оказалось 2 977 файлов, около 3,0 ГБ, по 52 проектам). Рискуют только настройки приложения в %APPDATA%\Claude, но и их восстановление сохраняет: Windows объясняет разницу прямо на экране — у восстановления данные приложения не затрагиваются, у сброса удаляются. Дальше — проверка состояния пакета в PowerShell только на чтение, резервное копирование, пошаговое усиление мер, если приложение так и не открылось (проверить, запущены ли vmcompute и hns, удалить пакет и установить заново, ведь ключ -PreserveApplicationData при обычной установке не работает), предполагаемая причина в виде наполовину зарегистрированного MSIX вместе с issue на GitHub (#55465, где установка прошла, но точка входа не появилась, а также #50285 и #48437 — все закрыты как not planned и без официального исправления), способы снизить вероятность повторения и сравнение со старой версией на обычном установщике, где и последний выпуск MSIX, и машина со старым форматом показали 1.24012.9.

Claude Code останавливается посреди ответа с сообщением «API Error: Connection closed mid-response. The response above may be incomplete.» Это не проблема промпта: соединение, по которому шёл потоковый ответ, закрылось, пока ответ ещё передавался. Статья опирается только на официальный справочник ошибок, официальный changelog и обращения с перехватом пакетов. Сначала — официальные определения: Connection closed значит, что канал оборвали, Response stalled — что он замолчал, Server error — что посреди потока пришла 5xx; объясняется, почему частичный вывод сохраняется намеренно (повторная отправка могла бы выполнить те же вызовы инструментов дважды) и что документированный способ восстановления — ответить continue. Далее разделены три слоя, откуда может исходить закрытие (ваша машина и спящий режим, обрыв по простою в прокси или VPN, закрытие по инициативе сервера), и приведены измерения, опубликованные автором issue #67766: все десять инцидентов были корректным закрытием со стороны сервера, ошибка появлялась через 3–105 мс после FIN, к этому моменту уже было доставлено 7–20 КБ ответа, тело запроса весило 1–2,5 МБ, новое соединение срабатывало примерно за 20 мс, а за 23 дня в записях нашлось 200 ошибок в 171 инциденте, причём 87 из них — менее чем через пять секунд после предыдущего вызова. Практическое ядро — хронология реальных записей changelog: 2.1.179 сохраняет частичный ответ, 2.1.185 переносит подсказку о зависании с 10 на 20 секунд, 2.1.198 повторяет временные обрывы с задержкой, 2.1.199 сохраняет частичный вывод при серверных ошибках посреди потока, 2.1.214 отключает пул keep-alive после ошибки устаревшего соединения — в сопоставлении с версиями из обращений (2.1.173, 2.1.181, 2.1.183), которые все старше 2.1.198. В конце — условия, повышающие вероятность, чек-лист из восьми шагов, шесть ориентиров для разработчиков, отличия от Unable to connect и Prompt is too long и чёткое разделение подтверждённого и неподтверждённого.

Вы открываете Hugging Face, чтобы запустить локальную LLM, и у одной модели — целая стена файлов (Q4_K_M, Q5_K_S, GPTQ, AWQ, IQ3_M), и вы застываете. Эта статья практически отвечает, какой квантованный файл скачать, чтобы модель заработала, оставляя концепцию «что такое квантование» другой статье и сосредотачиваясь на выборе формата. Выбор — это два шага: какой формат (= на каком движке запускаете), затем какая битность. Самый важный факт: квантованный файл запускается только на движках, поддерживающих его формат. GGUF — стандартный локальный универсал, работающий на CPU, Mac и частично GPU (llama.cpp/Ollama); GPTQ/AWQ/EXL2 ориентированы на GPU (vLLM); bitsandbytes квантует при загрузке в Transformers без калибровки. Имя GGUF Q4_K_M состоит из трёх частей: Q4 (номинально 4 бита, больше — лучше и крупнее), K (K-quant по супер-блокам; без суффикса/_0/_1 — устаревшие), M (S/M/L — насколько часть важных тензоров повышается; эффективная битность выше метки, Q4_K около 4.5 bpw). Семейство IQ (I-quant) уместнее при той же битности, но тяжелее на выводе и требует imatrix (матрицу важности из калибровки, защищающую значимые веса). GPTQ минимизирует послойную ошибку; AWQ защищает значимые веса через активации (ни один не лучше повсеместно). По битности: если сомневаетесь — Q4_K_M (по умолчанию в Ollama для многих моделей), поднимайтесь до Q5_K_M/Q6_K с запасом VRAM, Q8_0 почти без потерь, но не рекомендуется, а IQ2/IQ3 — только чтобы впихнуть крупную модель. Примерно 4.5–5 bpw — «вкусная» полоса (эвристика). Ищите файлы через library=gguf, bartowski/mradermacher (активность меняется) или теги Ollama model:size-variant-quant. Числа приблизительные и зависят от модели и сборки.

Сразу после обновления Claude Desktop (Windows) при запуске появляется «Этот файл уже используется другой программой», и приложение не открывается — и остаётся неработоспособным до перезагрузки ПК. Это известная ошибка сборки из Microsoft Store (MSIX) (GitHub #53247 и другие). Главное: полная перезагрузка ПК не обязательна — во многих случаях достаточно просто выйти из Windows и войти снова (это не перезагрузка ПК и не выход из аккаунта Claude), потому что стоящий за проблемой осиротевший дескриптор сохраняется в пределах сеанса пользователя Windows. Остановка CoworkVMService или повторная регистрация пакета, по сообщениям, НЕ работают. Несмотря на формулировку диалога, проверено, что блокировки файла в пользовательском пространстве нет (handle.exe / Process Explorer): реальный сбой — на уровне контейнера AppX/Desktop Bridge, при преобразовании Job Object → Silo (0x80070020 = ERROR_SHARING_VIOLATION, события 215/208). У спускового механизма две нерешённые версии — служба удерживает Job Object (#57221) против сбоя при запуске, из-за которого не выполнена очистка (#53247), — и официального исправления пока нет. Постоянное решение — переход на сборку Squirrel (установщик). Основано на одной машине (Windows 11 Home 10.0.26200), сверенной с issue на GitHub; с метками достоверности повсюду.

«Насколько ИИ сокращает трудозатраты в разработке ПО?» С приходом агентной разработки в 2025–2026 годах изменилась сама единица, которой мы измеряем. Раньше вопрос звучал «на сколько процентов быстрее одна задача»; теперь это история о порядках величины: «цикл разработки, занимавший недели, сжимается до часов или дней» (TechTarget). Claude Fable 5 завершил миграцию Stripe на 50 миллионов строк за день; TELUS сэкономила 500 000 человеко-часов разработки; время цикла упало с 9.6 до 2.4 дня. Цифры эпохи автодополнения — Copilot RCT на 55,8% быстрее, McKinsey 20–50% по задачам — теперь нижняя граница. Но это не равномерные 10×: по 2026 Agentic Coding Trends Report от Anthropic, разработчики используют ИИ примерно на 60% работы, однако лишь 0–20% задач можно полностью делегировать (разрыв делегирования), поэтому нужно человеческое ревью, а около 27% работы с ИИ — новая работа, которой раньше не было (сокращение трудозатрат = больше выпуска). При хорошем проектировании контекста — на 40% меньше ошибок и на 55% быстрее. Даже результат METR 2025 «эксперты на 19% медленнее» разворачивается в 2026, а авторы признают, что измерение недооценивает реальность. Эта статья разделяет эту поляризацию с помощью названных источников (GitHub, McKinsey, Anthropic, METR, DORA) и описывает, как на деле забрать экономию трудозатрат.

При долгой работе в Claude Code ответ вдруг повторяет «court court court…» десятки–сотни раз и завершается ошибкой «API Error: Response stalled mid-stream. The response above may be incomplete.». Это не ошибка вашего промпта, а сцепка двух известных багов: повторения (дегенерации) на стороне модели и остановки потока при передаче. Разбираем суть обоих слоёв, провоцирующие условия, немедленную остановку (Esc → новая сессия, /clear), меры для разработчиков (тайм-аут чтения, детекция повторения, max_tokens) и отличие от бага с утечкой тега court/invoke — на основе официальной документации и реальных GitHub Issue.

Внезапная ошибка «API Error: 400 Output blocked by content filtering policy» в Claude Code и API — это не лимит использования и не переполнение контекста, а состояние, когда «вывод», который пытался вернуть Claude, был остановлен фильтром безопасности. Основная цель фильтра — предотвратить дословное воспроизведение существующих защищённых материалов, и при генерации полного текста стандартных лицензий вроде MIT/Apache, работе «по приведению в соответствие» существующему источнику или копировании длинных документов он часто срабатывает ложно (false positive), без злого умысла. В статье разбираем: официальное объяснение (фильтр на этапе вывода обнаруживает воспроизведение защищённого материала и блокирует его кодом 400), паттерны ложных срабатываний из реальных Issue Claude Code (первичная настройка OSS-репозитория, сверка списков, ошибочный диагноз «лимит токенов» в конце долгого прогона агента), способы исправить прямо сейчас (получать шаблоны инструментами вместо дословной копии, переформулировать промпт ближе к генерации/резюмированию, останавливать цикл повторных попыток клавишей Esc, дробить задачу, сообщать о ложных срабатываниях в поддержку) и как отличить от Prompt is too long / usage limit / 529 Overloaded / max_tokens.