Cursor изнутри
Недавно вышла немного рекламная, но легкая и интересная статья от The Pragmatic Engineer о том, как устроен Cursor узнутри.

В начале статьи просто любопытные цифры о Cursor. Дальше автор рассказывает нам о технологическом стеке. Из интересного:
- TypeScript – бизнес-логика, критические штуки на Rust
- Turbopuffer – основное KV-хранилище, держит зашифрованные файлы + Merkle-деревья для синка
- Pinecone – векторная БД для семантического поиска по коду
- Datadog, PagerDuty, Sentry, Amplitude для обзервабилити
- Linear – для таск трекинга (рекомендую попробовать для тех, кто не пробовал, интересное решение)

Cursor не хранит наш код на своих серверах. Когда вы отправляете запрос в Chat, происходит следующее:
1. Запрос уходит на сервер
2. Сервер решает, что это – вопрос о коде, и запускает векторный поиск по embedding'ам, которые заранее были созданы на сервере во время “индексации” проекта
3. По результатам векторного поиска сервер понимает, какие файлы могут быть релевантны и запрашивает эти конкретные файлы обратно у клиента
4. Клиент шлёт нужные части кода (зашифрованно) – только те, что реально понадобились
5. Сервер “собирает” полный контекст и запускает inference для ответа
6. Ответ возвращается в чат

Отдельно стоит рассказать, как Cursor узнаёт, какие файлы изменились, и переиндексирует только их. Для используются Merkle-деревья:
1. каждый файл разбивается на чанки, каждый чанк хешируется
2. хеши объединяются попарно и формируют узлы следующего уровня
3. в результате строится дерево, корневой хеш которого отражает состояние всего проекта – аналогичное дерево строится и на клиенте, и на сервере

Каждые ~3 минуты клиент сравнивает свой корневой хеш с серверным:
– если хеши совпадают – индекс остаётся прежним
– если отличаются – обход дерева точно выявляет изменённые чанки, и переиндексирует только их

#ai