Последний раз, когда вы открывали VS Code? Claude Code вытесняет редактор из дока

«Когда вы в последний раз открывали VS Code?» — с такого вопроса начинается короткий пост @adocomplete, одного из заметных голосов вокруг Claude Code. Дальше признание: сегодня он наконец убрал редактор из дока на своём Mac и не удивится, если к концу года тот будет удалён совсем. Один пост — не исследование, но он удачно фиксирует сдвиг, о котором многие думают, а вслух говорят пока немногие. Разберёмся, что стоит за формулой «Claude Code вместо VS Code» и насколько всерьёз её стоит принимать.

Что на самом деле сказано, а что нет

Важно читать пост аккуратно. Автор не заявляет, что редакторы кода умерли, и не даёт цифр или бенчмарков. Это личное наблюдение: привычка открывать VS Code по десять раз на дню сменилась привычкой формулировать задачу агенту в терминале. Иконка в доке — просто маркер. Если она больше не нужна, значит, значительная часть работы, ради которой редактор открывали, ушла в другое место.

Кроме того, это говорит человек из самой экосистемы Claude Code. Его опыт — ранний и, возможно, нетипичный: он живёт в агентном рабочем процессе целыми днями. Для разработчика, который каждый день вручную правит большую кодовую базу с тонкой архитектурой, картина может выглядеть иначе.

Почему редактор перестаёт быть центром

Классический цикл выглядел так: открыть файл, найти место, набрать код, запустить, поправить. Редактор был главным инструментом, потому что человек был главным автором. С агентом цикл другой: описать намерение, дать агенту прочитать проект, получить изменения, проверить результат. Набор текста в этой схеме почти исчезает, а вместе с ним исчезает и главная причина держать редактор открытым.

Что остаётся от IDE? Навигация по коду, подсветка, отладчик, просмотр диффов. Всё это по-прежнему полезно, но роль меняется: из «места, где пишут» редактор превращается в «окно, через которое смотрят». А смотреть можно и другими способами — диффами в терминале, ревью в системе контроля версий, запуском тестов.

Новые узкие места

Когда писать код становится дёшево, дорогим становится понимание того, что именно написано. Узкое место смещается от скорости набора к качеству проверки: насколько хорошо вы читаете чужие изменения, насколько надёжны ваши тесты, насколько чётко сформулирована задача. Это и есть главный вопрос новой модели работы — не «чем писать», а «чем проверять».

Кому это подходит уже сейчас

Отказ от редактора проще всего даётся тем, чьи задачи хорошо описываются словами и проверяются тестами: скрипты, автоматизация, веб-сервисы, инфраструктурный код, небольшие и средние проекты. Именно там агент справляется быстро и предсказуемо, а ручная правка нужна редко.

Сложнее с задачами, где важно держать в голове много неявного контекста, или с кодом, который приходится читать глубже, чем писать: отладка запутанных систем, работа с чужим легаси, тонкая оптимизация. Там визуальная навигация и привычные инструменты IDE пока выигрывают.

• Подходит: типовые фичи, рефакторинг по чёткому описанию, написание тестов, инфраструктурные скрипты.
• Пока с оговорками: сложная отладка, работа с незнакомой архитектурой, задачи без автоматической проверки.

Вывод

Пост про убранную иконку — скорее индикатор настроений, чем доказательство. Но показателен сам вопрос: когда вы в последний раз открывали редактор и зачем? Если честный ответ — «чтобы посмотреть, что наделал агент», то процесс уже сместился, и стоит инвестировать не в плагины для набора текста, а в тесты, ревью и чёткие постановки задач. Редактор, возможно, и доживёт до конца года на диске — но вряд ли останется главным инструментом разработчика.