Как Claude Chat написал аналог Cursor в Google AI Studio
Или как два ИИ собрали полноценный инструмент разработчика, пока человек занимался только пересылкой файлов и сообщений между ними.
---
Несколько месяцев назад я поймал себя на странном ощущении: каждый месяц улетает абонентка за Cursor, сверху - подписка на Claude Pro, периодически докупаются токены, работа завязана на удалённые сервера в другой стране. При этом главный рабочий инструмент - закрытый, недоступный для модификации и локального развёртывания.
Логичный вопрос: а почему бы не сделать свою версию такого инструмента - открываемую в обычном браузере, управляемую ИИ и полностью подконтрольную мне?
Звучало амбициозно. Особенно с учётом того, что я поставил себе дополнительное ограничение: постараться не писать код самому вообще, а использовать связку Google AI Studio + Claude Chat как "парочку разработчиков", а себе оставить роль продакта и координатора.
Спойлер: эта стратегия сработала на удивление хорошо.
---
Что в итоге получилось
На выходе родилась браузерная IDE с подключением к удалённому серверу по SSH, встроенным терминалом, файловым менеджером и ИИ-агентом, который умеет сам изучать проект, планировать работу и вносить изменения в код.
Главное - всё это живёт в браузере и опирается на внешние LLM, а не на тяжёлую локальную установку.
Интерфейс и редактор
Интерфейс намеренно сделан максимально знакомым для тех, кто привык к VS Code:
- тёмная тема и компоновка в духе классических IDE;
- в основе редактора - Monaco, то же ядро, на котором построен VS Code;
- подсветка синтаксиса для множества языков;
- три основные области:
- слева - файловый менеджер;
- по центру - редактор кода;
- справа - чат с ИИ и панель агента;
- панели можно свободно растягивать и подгонять под привычный рабочий сетап;
- у файлов есть визуальные статусы:
- несохранённые правки;
- файлы в процессе загрузки;
- синхронизированные с сервером версии.
Фактически это IDE, открывающаяся по URL, но по ощущениям очень близкая к привычному локальному окружению.
---
Подключение к серверу и работа с файлами
Браузер, разумеется, не умеет работать с SSH напрямую. Поэтому вся схема построена через небольшой прокси-сервер, который берёт на себя роль посредника.
Безопасное подключение
Используется stateless-подключение к любому SSH-серверу по логину и паролю:
- никаких агентов и демонов, которые нужно ставить на сам удалённый сервер;
- все операции идут через промежуточный Node.js-сервис;
- данные подключения не хранятся в сессии в явном виде, что уменьшает риски.
Файловый менеджер
Интерфейс работы с файлами пытается повторить опыт локального проводника:
- ленивый обход директорий - вложенные папки подтягиваются по мере раскрытия;
- создание, переименование, перемещение, копирование и удаление файлов/папок делаются прямо из IDE;
- можно выбрать корневую директорию и загрузить её рекурсивно, чтобы работать с полноценным проектом;
- изменения на стороне сервера отслеживаются и могут быть синхронизированы одним действием.
Терминал
Встроенный терминал реализован через Xterm.js:
- полноценное выполнение shell-команд на подключённом сервере;
- поддержка изменения размера окна - терминал адекватно реагирует на ресайз;
- можно запускать сборки, тесты, миграции и любые другие команды, не покидая браузер.
---
Архитектура: с чего всё стартовало
Чтобы вся эта схема заработала, нужно было решить несколько задач:
1. Организовать SSH-прокси на Node.js.
2. Придумать простую, но достаточную схему хранения данных.
3. Настроить фронтенд, который будет общаться и с сервером, и с LLM.
Прокси-сервер на Node.js
Первая версия бэкенда была максимально аскетичной:
- один сервис, принимающий запросы из браузера;
- модуль, устанавливающий SSH-сессии и пробрасывающий команды;
- упор на stateless-подход: минимум состояния между запросами, максимум явных параметров.
Всю черновую реализацию писал Google AI Studio: я описывал требования, схему взаимодействия и ограничения по безопасности, а модель выдавала код. Claude выступал в роли ревьюера: находил уязвимости, предлагал оптимизации, улучшал обработку ошибок.
После нескольких итераций получился аккуратный и достаточно надёжный слой, через который браузер может безопасно "общаться" с любым сервером по SSH.
База данных: одна таблица
Для начального этапа хватило одной таблицы, в которой хранятся:
- данные проектов;
- параметры подключений;
- история чатов с ИИ;
- метаданные по сессиям и настройкам.
Схема нарочно упрощена: всё лишнее вынесено на более поздний этап, чтобы не закапываться в преждевременную оптимизацию. Здесь ИИ тоже помогал: предлагал структуры, поля, индексы и даже обработчики миграций.
---
Фронтенд: Google AI Studio пишет, Claude проверяет
Фронтенд собирался по цепочке:
1. Я описывал требуемый функционал и примерную архитектуру компонентов.
2. Google AI Studio генерировал компоненты, хуки, стейт-менеджмент.
3. Claude делал ревью: находил расхождения с требованиями, указывал на возможные баги, улучшал архитектуру.
Так постепенно появились:
- редактор на базе Monaco;
- файловый менеджер, говорящий с бэкендом по REST/WebSocket;
- чат с ИИ;
- панель управления контекстом;
- интерфейс для ревью изменений и визуального сравнения версий.
Фактически роль человека свелась к тому, чтобы:
- формулировать требования;
- склеивать сгенерированные фрагменты;
- тестировать поведение;
- задавать новый цикл уточнений и улучшений.
---
От простого чата к автономному агенту
Первый шаг - встроить обычный чат с LLM, в который можно скинуть фрагменты кода и задать вопросы.
Следующий - сделать так, чтобы модель могла:
- читать файлы;
- предлагать изменения;
- пошагово реализовывать фичи.
Финальная цель - агент, который сам:
- сканирует структуру проекта;
- формирует план действий;
- запрашивает необходимые файлы;
- вносит точечные правки;
- отправляет их на ревью в удобном виде.
Два режима работы
В итоге агент получил два режима:
1. "Чат" - классический помощник:
- обсуждение архитектуры;
- разбор багов;
- генерация кода по запросу;
- ответы на вопросы по стеку технологий.
2. "Агент" - автономный исполнитель:
- принимает задачу в свободной формулировке;
- строит пошаговый план;
- читает нужные файлы;
- применяет правки через систему патчей;
- показывает результат и ждёт подтверждения.
Переключение между режимами происходит в интерфейсе одним щелчком.
---
Умный патчинг: почему просто write_file - плохая идея
Наивный способ интеграции ИИ в редактор - дать ему возможность перезаписывать файл целиком.
Это сразу создаёт несколько проблем:
- риск потерять несохранённые локальные изменения;
- уязвимость к рассинхронизации: модель редактировала одну версию, а в редакторе уже другая;
- один промах в разметке - и весь файл превращается в хаос.
Поэтому был сделан упор на "умный патчинг" - точечное изменение фрагментов кода.
Как работает патчинг
Алгоритм использует двухуровневый поиск:
1. Точное совпадение
Агент указывает фрагмент, который хочет заменить. Система ищет его в текущей версии файла.
Если совпадение найдено - подставляется новая версия блока.
2. Fuzzy regex
Если точное совпадение не найдено (например, в файл уже внесены правки руками), включается "размытый" поиск по шаблону.
Это позволяет найти близкий по структуре участок и аккуратно применить изменение.
В итоге:
- минимизируется риск "сломать" несвязанные части файла;
- сохраняется совместимость с ручными правками;
- уменьшается количество конфликтов между человеком и ИИ.
---
Управление контекстом: что именно видит ИИ
Одна из ключевых проблем при работе с крупными проектами - контекст. Модели ограничены по количеству токенов, и бессмысленно пытаться скормить им весь репозиторий.
Поэтому появилась отдельная панель "В контексте ИИ".
Как это устроено
- В панели отображается список файлов, которые прямо сейчас загружены в контекст.
- У каждого файла в дереве есть индикатор-иконка Brain - сразу видно, какие файлы "в памяти" у агента.
- Любой файл можно:
- добавить в контекст одним кликом;
- убрать из контекста, освобождая лимит токенов.
Дополнительно:
- при открытии файла в редакторе он может автоматически добавляться в контекст (настраивается);
- агент сам запрашивает добавление нужных файлов, когда понимает, что ему не хватает информации.
Контроль токенов в реальном времени
Чтобы не "прострелить себе ногу" чрезмерно тяжёлым запросом, в интерфейсе есть индикатор объёма контекста:
- отображается примерное количество токенов, уже занятое загруженными файлами;
- есть кнопка "Очистить всё", которая мгновенно сбрасывает контекст перед новой большой задачей.
---
Работа с изменениями: Diff, ревью и безопасный коммит
Вмешательство ИИ в код без прозрачного ревью - прямой путь к хаосу. Поэтому вокруг агента построен полноценный процесс проверки изменений.
Visual Diff Viewer
Перед тем как изменения попадут на сервер, их можно сравнить в режиме визуального диффа:
- подсвечиваются добавленные и удалённые строки;
- видна старая и новая версия файла;
- можно пошагово пройтись по каждому изменению.
Это сильно снижает тревожность: вместо "ИИ что-то поменял, надеюсь, ничего не сломал" появляется контролируемый процесс.
Массовое ревью
Если изменений много, они собираются в единое модальное окно:
- файловый список с краткими аннотациями;
- возможность принять или отклонить изменения по каждому файлу;
- быстрый просмотр диффа без переключения вкладок.
Это особенно удобно, когда агент реализует целую фичу и затрагивает десятки файлов.
История и буфер изменений
- Ведётся история изменений за текущую сессию.
- Для каждого файла можно сделать откат (Undo) к предыдущему состоянию.
- Изменения, предложенные агентом, попадают сначала в Pending changes - буфер, отделённый от реального состояния на сервере.
- Публикация изменений на сервер - отдельный, явный шаг.
Параллельно работает автосохранение рабочего состояния редактора - чтобы не потерять то, что вводит человек руками.
---
Дополнительные возможности
Вокруг основной функциональности постепенно дорос набор удобных "плюшек":
- Голосовое управление
Можно надиктовать задачу - речь автоматически транскрибируется и отправляется агенту. Это удобно, когда формулировка получается длинной или когда хочется меньше печатать.
- Облачное сохранение проектов
В базе данных хранятся:
- настройки подключений;
- история диалогов с ИИ;
- метаданные по сессиям;
- некоторые пользовательские предпочтения.
- Мониторинг токенов и символов
В интерфейсе отображается текущий расход ресурсов LLM, что помогает контролировать стоимость и избегать лишних тяжёлых запросов.
- Системный отладчик
Можно посмотреть "сырой" системный промпт, который уходит в модель:
- это помогает понять, почему агент ведёт себя так, а не иначе;
- упрощает настройку и отладку поведения.
- Логирование действий
Встроенная консоль показывает:
- все операции SSH-сервиса;
- ответы API-роутера;
- ключевые шаги агента.
- Жёсткая изоляция проекта
Агент физически не может выйти за пределы выбранной папки проекта:
- это ограничение зашито в прокси-сервис;
- любые попытки обратиться "наружу" блокируются.
---
Мультимодельность: переключение между Google Gemini, GPT, Grok и Claude
Одно из принципиальных решений - не привязываться к одной LLM.
В итоге агент умеет работать с несколькими моделями:
- Google Gemini;
- GPT;
- Grok;
- Claude.
Переключение происходит из интерфейса, без перезагрузки приложения:
- можно использовать одну модель для генерации кода;
- другую - для анализа архитектуры;
- третью - для быстрых черновиков.
Это особенно полезно, когда нужно сравнить подходы разных моделей к одной и той же задаче или использовать сильные стороны каждой под конкретный тип работы.
---
Как выглядел сам процесс "разработки двумя ИИ"
Если собрать всё воедино, рабочий процесс выглядел так:
1. Я формулировал задачу на понятном человеку языке: что нужно сделать, какие ограничения по безопасности, какой UX ожидается.
2. Отправлял запрос в Google AI Studio, просил:
- спроектировать компоненты;
- написать код;
- описать протоколы взаимодействия.
3. Полученный код и описания передавал Claude:
- просил сделать ревью;
- указать на слабые места;
- предложить улучшения.
4. Вносил правки по рекомендациям Claude:
- иногда вручную;
- иногда снова через Google AI Studio.
5. Повторял цикл до тех пор, пока функциональность не начинала вести себя стабильно.
По сути, я выступал связующим звеном между двумя ИИ, которые по очереди писали и проверяли код.
В какой-то момент стало ясно: значительную часть рутины - от прототипирования компонентов до написания серверных хендлеров - уже можно уверенно перекладывать на модели.
---
Что это значит в более широком смысле
История с "домашним Cursor'ом" на базе Google AI Studio и Claude - не только про экономию на подписках.
Это наглядный пример того, что:
- Разработку сложных инструментов можно организовать так, что человек станет скорее продукт-менеджером и архитектором, чем "руками, пишущими каждую строчку".
- Связка из нескольких LLM, распределённых по ролям (генератор кода, ревьюер, архитектор), уже сегодня способна создавать рабочие инструменты уровня "IDE с агентом".
- Открытость архитектуры и возможность локального или самостоятельного развёртывания становятся важным конкурентным преимуществом: инструмент можно адаптировать под свои процессы и требования безопасности.
- Управление контекстом, визуальный дифф и система подтверждений - критически важные элементы, если мы хотим доверять ИИ-инструменту работу с реальными проектами, а не использовать его как игрушку.
---
Итоги
В результате эксперимента получилось:
- браузерная IDE с интерфейсом в духе VS Code;
- подключение по SSH без установки агентов на сервер;
- файловый менеджер, терминал, синхронизация и статус изменений;
- ИИ-агент с двумя режимами работы - чат и автономное выполнение задач;
- умный патчинг вместо грубого перезаписывания файлов;
- управление контекстом и токенами в реальном времени;
- визуальный дифф, массовое ревью и история изменений;
- мультимодельность с возможностью быстро переключаться между несколькими LLM.
И всё это - при том, что большую часть кода писали не мои руки, а связка Google AI Studio и Claude Chat, а я занимался постановкой задач, тестированием и сведением всего в единое целое.
Опыт показал: построить свой аналог Cursor - не фантазия энтузиаста, а вполне реальный сценарий, если правильно использовать возможности современных ИИ и выстроить процесс вокруг них.
