Основатель Cursor: в посткодовую эпоху «вкус» будет становиться всё более ценным

Автор: Xin

Cursor, один из самых быстро растущих продуктов в истории, достиг годового повторяющегося дохода (ARR) в $100 млн всего через 20 месяцев после релиза. За следующие два года он преодолел отметку в $300 млн ARR и продолжает задавать тон трансформации методов разработки программного обеспечения командами инженеров и продуктовых отделов. На начало 2025 года у Cursor насчитывается более 360 тыс. платных пользователей.

Майкл Трелл — соучредитель и генеральный директор Anysphere, материнской компании Cursor. Вместе с тремя однокурсниками из MIT он основал компанию и вывел Cursor на рынок за три месяца. Майкл Трелл крайне редко дает интервью в формате подкастов, ранее появляясь лишь в шоу Lex Fridman Podcast. В этом выпуске он рассказывает о прогнозах по наступлению «эпохи пост-кода», контринтуитивных инсайтах при создании Cursor и видении будущего развития профессии инженера.

Данный материал основан на подкасте Lenny's Podcast, ниже представлен полный перевод.

- Цель Cursor — создать совершенно новый подход к программированию: Люди в будущем будут видеть псевдокод, структурно близкий к естественному языку. Пользователи сохранят мощный контроль над всеми деталями программного обеспечения, имея возможность мгновенно вносить изменения и проводить итерации.

- «Вкус» (taste) будет становиться всё более ценным: Суть «вкуса» заключается в четком понимании того, «что именно нужно создавать».

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

- Ключевой этап собеседований в Cursor — двухдневный практический тест: Эти задания являются имитационными, но позволяют кандидатам за два дня создать реальные рабочие результаты. Это не просто проверка «готовы ли мы работать вместе», но также важный инструмент привлечения талантов. На ранних этапах стартапа единственным весомым аргументом для присоединения команды часто становится коллектив, который кажется достойным общих усилий.

Главная проблема программирования в стиле чат-бота — отсутствие точности

Lenny: Мы уже обсуждали, что произойдет в эпоху пост-кода. Как вы видите дальнейшее развитие Cursor? Как технологии перейдут от традиционного кода к другим формам?

Michael Truell:Цель Cursor — создать совершенно новый метод программирования, отличный подход к созданию ПО. Вам достаточно кратко описать компьютеру свои намерения, а то, как программное обеспечение должно работать и выглядеть, определяете вы сами.

По мере развития современных технологий мы уверены, что способны открыть принципиально новый метод создания ПО, который будет превосходить текущие стандарты по уровню, эффективности и удобству использования. Этот процесс кардинально отличается от современной разработки.

Я хочу сравнить это с несколькими популярными взглядами на будущее ПО, некоторые из которых мы категорически отвергаем.

Одна точка зрения гласит, что создание ПО останется схожим с нынешним, с основным упором на текстовые редакторы и формализованные языки программирования, такие как TypeScript, Go, C, Rust. Другая предполагает, что вам достаточно вводить инструкции в чат-бота, чтобы он строил ПО и随时 его модифицировал. Такой стиль общения с чат-ботом напоминает диалог с вашим инженерным отделом.

Мы считаем, что обе эти концепции проблематичны.

Основной недостаток программирования в стиле чат-бота — нехватка точности. Если вы хотите дать людям полный контроль над внешним видом и функционалом ПО, вам нужны более точные способы указания необходимых изменений, вместо того чтобы писать в чате роботу «обнови эту часть моего приложения», после чего всё удаляется.

С другой стороны, ошибочна и мировоззренческая установка на то, что ничего не изменится, ведь технологии лишь становятся мощнее.В мире пост-кода, который мы envision, выражение логики ПО будет ближе к английскому языку.

Представьте, что она существует в более структурированной форме, приближаясь к псевдокоду. Вы сможете писать логику ПО, редактировать её на более высоком уровне и легко ориентироваться в ней. Это не будет набором непонятных тысяч строк эзотерического кода. Напротив, он станет понятнее, проще для чтения и навигации. Мы стремимся к тому, чтобы сложные символы и структуры кода эволюционировали в более удобную для человека форму.

В эпоху пост-кода всё более ценным станет чувство вкуса

Lenny: Это глубокая мысль, я хочу убедиться, что все поймут вашу позицию. Представляете ли вы себе переход таким образом, что люди перестанут видеть код и перестанут мыслить категориями JavaScript или Python? Вместо этого появится более абстрактная форма выражения, псевдокод, ближе к английским синтаксическим конструкциям.

Michael Truell: Мы полагаем, что оно действительно дойдет до этой стадии. Мы верим, что для достижения этого этапа необходимо участие и продвижение со стороны профессиональных инженеров текущего поколения. Люди в будущем по-прежнему останутся у руля.

Человек сохранит мощный контроль над всеми деталями ПО и не станет轻易 отказываться от этого контроля. При этом человек получит возможность молниеносно вносить изменения и проводить итерации. Будущее не будет зависеть от процессов, скрытых в бэкенде, протекающих медленно и занимающих недели.

Lenny: Это подводит к вопросу: для современных инженеров или тех, кто рассматривает возможность стать инженером, дизайнером или продуктовым менеджером, какие навыки, по вашему мнению, будут становиться всё более ценными в эпоху пост-кода?

Michael Truell: Я считаю, что «вкус» (taste) будет становиться всё более ценным. Когда говорят о вкусе в сфере ПО, легко подумать о визуальной составляющей: приятные глазу анимации, подбор цветов, UI, UX и так далее.

Визуальная часть критически важна для продукта. Но, как я упоминал ранее, вторая важная половина касается логики продукта и принципов его работы.

У нас есть множество инструментов для проектирования визуала, но код остается лучшей формой выражения логики работы ПО. Вы можете показать макеты в Figma или粗略 наметить структуру в заметках. Но только когда у вас появляется работающий прототип, логика начинает проявляться отчетливо.

Инженеры будущего станут больше похожи на «дизайнеров логики». Им потребуется точно формулировать намерения, смещая фокус с внутреннего «как реализовать» на высокоуровневое «что реализовать» и «что это такое». А это означает, что «вкус» приобретет большее значение в разработке ПО.

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

Но я верю, что будущие инженеры ПО смогут отказаться от чрезмерного микроконтроля деталей, как это бывает сейчас, и постепенно перейдем от скрупулезной детализации к большему акценту на «вкус».

Lenny: Это наталкивает меня на мысль о vibe coding. Не похоже ли это на описанный вами подход, где нет нужды глубоко задумываться о деталях, а лучше следовать потоку?

Michael Truell: Я вижу определенную связь. То, что сегодня называют vibe coding, выглядит мне как спорная творческая парадигма массового генерирования кода без должного понимания его внутренних деталей. Такой подход порождает немало проблем. Не понимая фундаментальных нюансов, вы довольно быстро обнаружите, что ваш проект разросся настолько, что его становится невозможно изменить.

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

Сейчас нам еще не хватает способности позволить «вкусу» по-настоящему управлять сборкой ПО. Проблема vibe coding или аналогичных паттернов заключается в том, что хотя вы и можете создать рабочий продукт, значительная часть решений принимает ИИ неуклюжим образом, и вы теряете полный контроль над этим процессом.

Lenny: Вы упомянули «вкус». Что именно под ним подразумевается?

Michael Truell: Четкое понимание того, «что именно нужно создавать». И способность всё легче трансформировать эту идею в конкретное программное обеспечение, которое выглядит именно так и работает именно так.

В отличие от нынешней ситуации, когда у вас и вашей команды есть идея продукта, затем требуется «переводческий слой», требующий огромных усилий и рабочего времени, чтобы перевести замысел в формат, понятный и исполнимый компьютером.

«Вкус» мало связан с UI. Возможно, термин «вкус» не совсем точен, но его сердцевина заключается в правильном восприятии того, «что должно быть построено».

Рождение Cursor стало результатом исследования одного вопроса

Lenny: Мне бы хотелось вернуться к истокам Cursor. Многие слушатели наверняка еще не знают, как всё начиналось. Вы создаете один из самых быстрорастущих продуктов в истории. Cursor уже глубоко меняет методы создания продуктов людьми, а возможно, и всю отрасль в целом. С чего всё началось? Какие моменты раннего пути запомнились вам больше всего?

Michael Truell: Cursor родился в результате нашего исследования одного ключевого вопроса и во многом продиктован нашими размышлениями о том, как технологии ИИ будут развиваться и совершенствоваться в ближайшие десять лет. Здесь было два поворотных момента.

Первый — знакомство с бета-версией Copilot. Это был наш первый опыт взаимодействия с практичным ИИ-инструментом, который реально приносил пользу, а не был просто впечатляющим демо. Copilot оказался одним из самых ценных инструментов разработки, которые мы применяли, и нас это очень вдохновляло.

Второй момент — публикация рядом компаний, включая OpenAI, ряда исследований о масштабировании моделей. Эти работы показали, что даже без прорывных новых идей простое увеличение размеров моделей и объема обучающих данных делает возможности ИИ всё мощнее. К концу 2021 — началу 2022 года мы обрели глубокую уверенность в перспективах ИИ-продуктов: эта технология неизбежно выйдет на стадию зрелости.

Оглядываясь по сторонам, мы заметили, что, несмотря на обилие разговоров о том, как строить модели, практически никто не погружается глубоко в конкретные области интеллектуального труда, чтобы осмыслить, как эта область будет развиваться с прогрессом ИИ.

Это породило вопросы: когда технология созреет, что изменится в этих конкретных областях? Какой примет окончательный вид рабочий процесс? Как эволюционируют инструменты, которые мы будем использовать для работы? Каким уровнем должна обладать модель, чтобы поддерживать эти изменения? И если масштабирование моделей и предварительное обучение больше не будут давать существенный прирост, как продолжать двигать границы технических возможностей?

Ошибка, которую Cursor допустил изначально, заключалась в том, что мы выбрали нишу с минимальной конкуренцией и довольно скудный сектор. Никто бы не стал обращать внимания на такую скучную область.

Все тогда думали, что программирование — это горячая и увлекательная тема, а мы решили, что там и так слишком много игроков.

Первые четыре месяца мы фактически работали над совершенно другим проектом — автоматизацией и усилением процессов в машиностроении, создавая инструменты для механиков.

Но с порога столкнулись с проблемами. Ни я, ни мой сооснователь не были инженерами-конструкторами. Хотя у нас были друзья в этой сфере, наше понимание было крайне поверхностным, можно сказать, «слепыми, ощупывающими слона». Как нам интегрировать существующие модели в машиностроение? Мы пришли к выводу, что придется с нуля разрабатывать собственную модель. Это оказалось крайне сложным решением, так как в открытом доступе практически нет данных о 3D-моделях различных инструментов и компонентов вместе с инструкциями по их созданию, да и получение таких моделей из закрытых источников было равно сложной задачей.

В итоге мы очнулись и осознали, что машиностроение нам не особо близко, и это не та сфера, которой мы готовы отдать всю жизнь.

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

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

Вы считаете, что существующие инструменты испытывают нехватку амбиций или потенциала, и здесь еще много чем заняться. Я думаю, это крайне ценный инсайт. Даже если ниша кажется пересыщенной, как ситуация с GitHub Copilot, если вы замечаете, что текущие решения недостаточно амбициозны, не отвечают вашим стандартам или имеют структурные изъяны, внутри по-прежнему кроются колоссальные возможности. Верно?

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

Потолок во многих направлениях чрезвычайно высок. Глядя по сторонам, даже взяв лучшие инструменты в любой конкретной области, можно увидеть, что на ближайшие годы предстоит выполнить огромный объем работы. Такая широта пространства и высокие ограничения уникальны для сферы разработки ПО, по крайней мере в контексте ИИ.

Dogfooding был в приоритете с самого начала

Lenny: Давайте вернемся к вопросу IDE (Integrated Development Environment, интегрированная среда разработки). У вас несколько разных стратегий, остальные компании тоже экспериментируют.

Один путь — создать IDE специально для инженеров и встроить туда возможности ИИ. Второй — полностью перейти на模式 AI Agent, как в продукте Devin. Третий — сосредоточиться на создании исключительно сильной модели для кодинга, стремясь сделать лучшую в мире модель для разработки.

Что подтолкнуло вас окончательно выбрать путь IDE?

Michael Truell: Те, кто с самого начала сфокусировался исключительно на разработке моделей или пытался достичь полной сквозной автоматизации программирования, пытались построить нечто совершенно отличное от нас.

Наш главный фокус — гарантировать, что люди сохраняют контроль над каждым решением в используемом ими инструменте.相比之下, они чаще конструируют будущее, где ИИ берет на себя весь процесс и отвечает за все решения самостоятельно.

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

Но у таких моделей есть серьезные ограничения. Наша product strategy с самого начала опиралась на Dogfooding («проедание» собственного продукта): мы ежедневно активно используем Cursor сами и никогда не выпускали функций, которые не приносили бы пользы нам лично.

Мы сами являемся конечными пользователями, и это дает нам реалистичное представление о возможностях технологий прямо сейчас.Мы считаем, что человеку жизненно важно оставаться «в кабине пилота», ИИ не может и не должен брать на себя всё.

По личным причинам мы также стремились дать пользователю этот контроль. Так мы не стали просто очередным модельным провайдером и дистанцировались от подхода сквозной разработки, отнимающего человеческий контроль.

Что касается выбора в пользу создания собственной IDE вместо плагина для существующих сред, мы исходили из убеждения, что программирование будет происходить через подобные модели и способы работы радикально изменятся в ближайшие годы. Масштабируемость существующих сред разработки слишком ограничена. Если вы считаете, что UI и парадигмы кодинга претерпят революцию, вам необходим полный контроль над самим приложением.

Lenny: Я знаю, что сейчас вы работаете над IDE, возможно, это ваша предвзятость, ваше видение будущего. Но мне любопытно: считаете ли вы, что значительная часть будущей работы будет выполняться ИИ-инженерами в Slack или подобных инструментах?有一天 ли такая интеграция войдет в Cursor?

Michael Truell: Идеальный сценарий подразумевает легкое переключение между этими средами. Иногда хочется оставить ИИ работать автономно; иногда вы захотите вытащить результаты его работы и эффективно координировать действия с ним; иногда вновь вернуть управление алгоритму.

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

Суть IDE со временем радикально трансформируется. Именно поэтому мы решили создать собственный редактор, так как он будет непрерывно развиваться.Эта эволюция включает возможность забирать задачи из разных интерфейсов, таких как Slack или системы трекинга задач; сама стеклянная панель, на которую вы смотрите изо дня в день, тоже претерпит огромные изменения. Сейчас мы рассматриваем IDE как основное место сборки программного обеспечения.

Самые успешные пользователи AI консервативны в технологиях

Lenny: Мне кажется, многие, обсуждая агентов и ИИ-инженеров, недооценивают один факт: мы в значительной степени станем «менеджерами по инженерии», руководящими множеством пока не слишком умных подчиненных. Вам придется тратить массу времени на проверку, утверждение и детальную постановку задач. Как вы относитесь к этому вызову? Существуют ли способы упростить этот процесс?

Звучит крайне непросто, и каждый, кто управлял крупными командами, прекрасно понимает боль: «Опять эти подчиненные таскают ко мне сырую работу разного качества, нервы на пределе».

Michael Truell: Да, возможно, в конечном итоге нам придется вести индивидуальные беседы с каждым агентом.

Мы наблюдали, что наиболее успешные пользователи ИИ проявляют относительный технологический консерватизм. Я уверен, что текущие самые эффективные пользователи сильно полагаются на функции вроде «Прогноз следующего редактирования» (Next Edit Prediction) в нашем инструменте. В их стандартный рабочий процесс наш ИИ встроен естественно, заранее предполагая следующее действие. Также они превосходно умеют сужать объем задач для ИИ, делая рамки запроса более четкими и компактными.

Если учитывать временные затраты на ревью кода, взаимодействие с агентами сводится в основном к двум моделям. Первая: вы тратите время upfront на детальную постановку задачи, затем ИИ работает автономно, после чего вы проверяете результат. Ревью завершено — задача закрыта.

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

При этом мы регулярно замечаем, что те, кто использует эти инструменты максимально эффективно, предпочитают декомпозировать задачи и сохранять их управляемыми.

Lenny: Это редкость. Давайте вернемся к моментам вашего первого создания Cursor. Когда вы поняли, что продукт готов? Когда решили выпустить его и посмотреть, что произойдет?

Michael Truell: Когда мы только начали собирать Cursor, сильно опасались, что разработка затянется, и мы долго не сможем выйти наружу. Первая версия Cursor была полностью создана нами с нуля вручную. Сейчас мы используем VS Code в качестве базы, подобно тому, как многие браузеры используют Chromium.

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

Мы двигались с молниеносной скоростью, полностью создавая свой редактор с нуля параллельно с ИИ-компонентами. Примерно через пять недель мы полностью перешли на свой редактор, окончательно отказавшись от предыдущего, и начали активно использовать новый инструмент на практике. Осознав его достаточную полезность, мы отдали его тестированию сторонним пользователям, проведя крайне короткий бета-тест.

От написания первой строки кода до публичного релиза Cursor прошел всего около трех месяцев.Наша цель — передать продукт пользователям как можно скорее и итерировать по обратной связи.

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

Три месяца на релиз, годовой ARR достиг ста миллионов долларов

Lenny: Мне импонирует ваша скромность в оценке результатов. Насколько мне известно, вы подняли ARR с нуля до $100 млн примерно за год-полтора. Это историческое достижение.

Какие ключевые факторы обеспечивают успех? Вы только что назвали использование собственного продукта одним из них. Но выпустить продукт за три месяца невероятно. Каков секрет?

Michael Truell: Первая версия, законченная за эти три месяца, не была идеальной. Поэтому мы сохраняли постоянное ощущение срочности, осознавая, что многое можно улучшить.

Наша высшая цель — по-настоящему создать новую парадигму программирования, автоматизирующую подавляющую часть привычной сейчас кодогенерации.Какими бы ни были текущие успехи Cursor, нам всё ещё ощущается большая дистанция до этой высшей цели, всегда остаётся масса вещей, требующих реализации.

Чаще всего мы не зацикливаемся на первом релизе, а сконцентрированы на непрерывной эволюции продукта, неустанно улучшая и шлифуя инструмент.

Lenny: После тех трех месяцев произошел ли какой-то переломный момент, когда всё взлетело?

Michael Truell: Честно говоря, начальный рост казался довольно медленным, возможно, из-за нашей нетерпеливости. Но общий темп продолжал нас поражать.

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

Конечно, на старте такой экспоненциальный рост визуально ощущается медленным из-за низкой базы, поэтому поначалу не просматривалось внезапного взлета.

Lenny: Звучит как классический пример «построй его, и они придут». Вы просто собрали инструмент, который понравился вам самим, после релиза людям он тоже пришёлся по душе, и они рекомендовали его другим.

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

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

Мы вкладывали все усилия в шлифовку продукта: сначала создали инструмент, который понравился нашей команде, затем итерировали по фидбеку ядра пользователей. Может звучать просто, но реализовать грамотно непросто.

Направление для поиска многогранны, маршрутов развития продукта множество. Одна из трудностей — сохранить фокус, стратегически отбирать ключевые фичи и расставлять приоритеты.

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

Мы разрабатываем продукт для миллионов пользователей, что требует максимальной оптимизации на продуктовом уровне. Но другое измерение качества лежит в плоскости углубления научных исследований и разработки моделей, их постоянной оптимизации в критических сценариях. Балансировка между двумя направлениями всегда сопряжена с вызовами.

Самое контринтуитивное — непредвиденная необходимость разработки собственной модели

Lenny: На сегодняшний день при сборке Cursor и создании ИИ-продуктов что показалось вам самым контринтуитивным?

Michael Truell: Самое контринтуитивное для меня — то, что изначально мы вовсе не планировали строить собственные модели. Когда мы заходили в эту сферу, компании уже давно делали ставку на тренировку моделей с самого старта. Мы просчитали стоимость и ресурсы для тренировки GPT-4 и четко понимали, что это не в наших силах.

На рынке уже существует масса отличных моделей, зачем усложнять себе жизнь, копируя сделанное другими? Особенно в части предварительного обучения (Pre-training), которое требует обучения нейросети с нулем знаний всему интернету. Поэтому изначально мы вообще не рассматривали этот путь. С первых дней мы ясно видели, что существующие модели выполняют далеко не всё, что могли бы, из-за отсутствия подходящих инструментов для их интеграции. Тем не менее, мы инвестировали огромные усилия в разработку собственных моделей.

Потому что каждое «волшебное мгновение», которое вы чувствуете при использовании Cursor, в значительной степени обусловлено нашими кастомными моделями.Процесс шел постепенно. Сначала мы попробовали обучить свою модель под один конкретный кейс, потому что никакая базовая модель не справлялась с ним удовлетворительно, и получили удачный результат. Затем распространили этот подход на другой кейс — тоже успешно, и так пошли дальше.

Ключевой момент при разработке моделей — точно выбирать цели и не изобретать велосипед. Мы сознательно уходим от областей, где топ-модели работают безупречно, и концентрируемся на их слабых местах, размышляя, как их закрыть.

Lenny: Многих удивляет, что у вас есть собственная модель. Когда говорят о Cursor и аналогичных продуктах, их часто называют «оболочкой поверх GPT», считая лишь надстройкой над ChatGPT или Sonnet. Но вы сказали, что у вас своя модель. Можете рассказать про технический стек?

Michael Truell: Действительно, мы используем передовые базовые модели во множестве сценариев.

Для ключевых элементов пользовательского опыта Cursor мы опираемся преимущественно на собственные модели, особенно там, где базовые модели не справляются из-за стоимости или скорости. Яркий пример — автодополнение.

Для непосвященных это может быть сложно осмыслить. Кодинг — уникальная рабочая задача. Пор的全部内容 вашей работы на следующие 5, 10, 20 минут или даже полдня полностью предсказуемы исходя из ваших текущих действий.

В сравнении с написанием текстов многие знакомы с автодополнением в Gmail или подсказками при редактировании сообщений и писем. Но эти функции имеют ограничения, так как по одному лишь написанному тексту редко понятно, что вы напишете дальше.

Но при коде, изменив одну часть репозитория, вам зачастую需要同步 отредактировать другие, причем эти правки очевидны.

Автодополнение расширенного типа — одна из центральных функций Cursor. Оно предсказывает серии ваших следующих шагов, работая кросс-файлово и внутри одного файла в разных позициях.

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

Также возникает специфический технический вызов: модель должна уметь дополнять не просто токены обычного текста, но целые序列 диффов (changesets) — предсказывать грядущие добавления или удаления на основе уже внесенных в репозиторий правок.

Под эту задачу мы провели специализированную тренировку модели, и она оказалась крайне эффективной. Этот модуль полностью自主研发, без единого обращения к базовым моделям. Мы не делаем на него пиар, но это сердце Cursor.

Еще один сценарий применения собственных моделей — усиление производительности крупных моделей вроде Sonnet, Gemini или GPT, особенно на этапе ввода и вывода данных.

На входном этапе наша модель просматривает весь репозиторий, отбирая релевантные фрагменты для подачи в крупные модели. Можно представить это как мини-Google, заточенный под поиск по коду.

На выходном этапе мы обрабатываем предложения по правкам от крупных моделей, используя наши узкоспециализированные алгоритмы для детализации. Высокоуровневую архитектуру доверяют более мощным моделям, которые тратят токены на общую дирекцию. А более мелкие, быстрые и узкопрофильные модели, применяя техники reasoning optimization, конвертируют эти высокие намерения в полноценный, исполняемый код.

Такой подход радикально улучшает качество выполнения узких задач и значительно ускоряет реакцию. Скорость для нас — ключевой метрический показатель.

Lenny: Это здорово. Недавно я брал интервью у CPO (Chief Product Officer) OpenAI Кевина Вейла в подкасте. Он назвал это ансамблем моделей (Ensemble of models).

Они тоже задействуют сильные стороны каждой модели. Использование дешевых моделей дает огромную экономическую выгоду. Обучаете ли вы свои модели на базе открытого кода вроде LLaMA?

Michael Truell: В этом вопросе мы прагматичны и не хотим изобретать велосипед. Поэтому стартуем от лучших готовых pre-trained моделей на рынке, обычно open-source, иногда сотрудничаем с компаниями, не раскрывающими веса. Нам не так важно иметь прямой доступ или возможность читать матрицы весов строчно, как способность эффективно проводить training и post-train.

Потолок ИИ-продуктов сопоставим с персональными компьютерами и поисковиками прошлого века

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

Michael Truell: Я признаю, что существуют традиционные методы формирования user inertia и защиты. Но в конечном счете необходимо непрерывно создавать лучший продукт.Я твердо верю, что потолок ИИ огромен, и любые барьеры могут быть преодолены в любую секунду.

Этот рынок отличается от традиционного софта или B2B-сегмента. Похожий исторический пример — поисковые системы конца 90-х — начала 00-х. Второй пример — эра персональных компьютеров и мини-компьютеров 70-х-90-х.

Потолок ИИ-продуктов исключительно высок, продукты итеративно обновляются. Вы можете непрерывно извлекать огромную отдачу с каждого дополнительного часа работы умного сотрудника и каждой дополнительной доллара R&D. Такое состояние может длиться очень долго. Недостатка в новых функциях для разработки не будет никогда.

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

Для нас это, возможно, немного горькая реальность. Но для мира в целом — обнадеживающая истина. Впереди возникнет множество лидеров рынка, еще слишком много ценных функций ждут создания.

До видения на пять-десять лет нам еще далеко, и наша задача — поддерживать двигатель инноваций на максимальных оборотах.

Lenny: Звучит как формирование «потребительского» рва. Постоянное предоставление лучшего продукта, чтобы пользователи хотели возвращаться, в отличие от Salesforce, где сотрудников удерживают корпоративными контрактами.

Michael Truell: Да. Ключ в том: если в вашей сфере скоро исчезнет ценная деятельность, перспективы печальны. Но если в неё продолжают поступать значительные инвестиции, усилия талантливых специалистов создают ценность, вы получаете эффект масштаба в R&D и можете углублять технологии, строя барьеры.

Это действительно несет потребительский уклон. Но в основе всего лежит создание выдающегося продукта.

Lenny: Верите ли вы, что будущее за рынком «победа забирает всё», или возникнет множество дифференцированных продуктов?

Michael Truell: Я считаю рынок гигантским. Вы касались темы IDE. Некоторые исследователи, анализируя рынок IDE десятилетия, спрашивают: «Кто вообще зарабатывает на редакторах кода?» Раньше у каждого был свой набор конфигов. Лишь одна компания монетизировала отличный редактор, но её масштаб оставался ограниченным.

Некоторые делают вывод, что будущее будет таким же. Но я думаю, эта логика игнорирует один фактор: в 2010-х потенциал редакторов для программистов был физически ограничен.

Компания, зарабатывавшая на редакторах, в основном упрощала навигацию по репозиториям, отлавливала ошибки и предоставляла удобные инструменты debug. Функции ценные, но возможности инструментов для программистов, и более широкого круга knowledge workers, куда огромнее.

Наш настоящий вызов — автоматизировать массу рутинных и интеллектуальных задач.Только так мы обеспечим надежный и быстрый рост производительности в разных知识-работах.

Рынок, по моему мнению, несоизмеримо шире, чем раньше думали о developer tools. Появятся различные решения, вероятно, сформируется лидер отрасли. Возможно, это будем мы, но вопрос открытый. Эта компания создаст универсальный инструмент, помогающий создавать большую часть мирового ПО, став гигантом эпохи. Параллельно останутся инструменты для отдельных ниш или этапов life cycle разработки.

В конечном итоге само программирование может эволюционировать от формальных языков к более высокому уровню, и эти high-level инструменты станут основным объектом покупок.Я убежден, что в ИИ-программировании появится доминирующий игрок, который превратится в предприятие колоссального масштаба.

Lenny: Интересно, что Microsoft долгое время находился в эпицентре этих перемен: отличные продукты, мощная дистрибуция. Вы сказали, что Copilot раскрыл огромный потенциал ниши, но, похоже, компания не смогла занять лидирующие позиции, местами отставая. Как думаете, почему?

Michael Truell: Считаю, причины Copilot не оправдать ожиданий лежат в исторической и структурной плоскости.

Структурно проект Copilot Microsoft принес нам колоссальное вдохновение. Они совершили множество потрясающих вещей, мы сами являемся пользователями экосистемы Microsoft.

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

В таких рынках разница в ROI между продуктами минимальна. Покупать независимые инновационные решения бессмысленно, bundled-варианты гораздо привлекательнее.

Другой тип рынка особенно выгоден зрелым компаниям:когда пользователи изначально жестко привязаны к вашим инструментам, а cost switching невероятно высок.

В нашей нише пользователи легко пробуют альтернативы, выбирают сами, что им подходит. Это невыгодно гигантам, зато отлично работает для компаний с самыми инновационными продуктами.

Что до исторических причин: по моей информации, первоначальная команда, развивавшая первую версию Copilot, позже разошлась по другим компаниям и проектам. Согласовать работу всех департаментов и stakeholders в рамках одного продукта оказалось крайне сложно.

Сеньоры занижают ожидания, джуниоры завышают

Lenny: Если бы вы могли сесть рядом с каждым новым пользователем Cursor в первый раз и тихо подсказать пару рекомендаций, как лучше пользоваться, что бы вы сказали?

Michael Truell: Я считаю, что на продуктовом уровне нам предстоит решить одну важную задачу.

Сейчас большинство успешно использующих Cursor обладают определенным «чувством вкуса» по отношению к возможностям моделей.Эти пользователи понимают, какие задачи по силам Cursor и какой детализации требуют инструкции. Они распознают качество модели, её лимиты, что может, а что нет.

В текущем продукте мы плохо решили user education, даже не предоставили четких гайдлайнов.

Чтобы воспитать это «ощущение меры», дам два совета.

Во-первых, не загружайте в модель все задачи разом.Либо получите разочарование от вывода, либо слепо примете его. Лучше разбивать на маленькие блоки. Затратите то же время на финальный результат, но поэтапно. Уточняйте небольшие задачи, получайте частичные результаты, повторяйте цикл, вместо попытки прописать длинный монолитный промпт. Последний путь ведет к катастрофе.

Во-вторых, сперва пробуйте на пет-проектах, не берите сразу важные рабочие задачи.Я рекомендую разработчикам, привыкшим к legacy workflow, набраться опыта падений и выйти за пределы limits моделей.

Можно безопасно экспериментировать в side projects, максимально используя ИИ. Часто мы видим, что люди не дают ИИ шанс и недооценивают его capabilities.

Декомпонуя задачи и проактивно тестируя границы модели в безопасной среде, вы удивитесь: в ряде сценариев ИИ ошибается реже, чем ожидается.

Lenny: Правильно ли я понимаю, что нужно развивать интуицию: понимать границы возможностей модели, сколько она способна развить идею, а не просто выполнять команды? И каждый раз при выходе новой модели, например GPT-4, приходится перекалибровывать эту интуицию?

Michael Truell: Именно. В последние годы это ощущалось не так остро, как при первом контакте с LLM. Но это больная точка, которую мы хотим решить для пользователей в будущем, облегчив нагрузку. Каждая модель имеет slightly иные quirks и характер.

Lenny: Идут споры: такие инструменты, как Cursor, помогают больше джуниорам или сеньорам? Делают ли они сеньоров в десять раз эффективнее или превращают джуниоров в сеньоров? Кто получает наибольшую пользу сейчас?

Michael Truell: Обе категории инженеров извлекут огромную пользу, трудно сказать, какая группа выиграет больше.

Они попадают в разные anti-patterns. Джуниоры иногда гиперопираются на ИИ, перекладывая всё на него. Но мы пока не готовы применять ИИ end-to-end в сложных профессиональных тулсах, при коллаборации десятков и сотен людей на long-term поддерживаемых репозиториях.

Что до сеньоров, не всех, adoption в компаниях часто тормозится крайне опытными коллегами, например, из DevEx команд. Они ответственны за инструменты повышения продуктивности всей организации.

Мы также наблюдаем авангардные примеры: некоторые сеньоры идут впереди, активно embracing tech. В среднем, сеньоры склонны недооценивать помощь ИИ и цепляться over existing workflows.

Сложно судить, кому польза больше. Думаю, обе группы столкнутся со своими anti-patterns, но оба класса получат выраженную выгоду от инструмента.

Lenny: Полностью логично, как полюсы спектра: одни завышают, другие недооценивают. Метaphora трех медведей.

Собеседование в Cursor сводится к двухдневному практическому тесту

Lenny: До основания Cursor чего бы вы хотели знать? Если бы могли вернуться к началу пути и дать советы раннему Майклу, что бы посоветовали?

Michael Truell: Главная сложность в том, что многие драгоценные инсайты tacit, их трудно артикулировать. Увы, в некоторых человеческих сферах нужен личный опыт провалов для уроков, либо обучение у лидеров поля.

У нас богатый опыт в найме. Мы исключительно терпеливы в Hiring. Личные визионерские установки и стратегия компании диктуют: критически важно собрать world-class команду инженеров и research-специалистов для полировки Cursor.

Поскольку приходится строить новое, мы искали talent兼具求知欲 и experimental spirit.Также ценили实事求是, умеренную审慎 и прямую коммуникацию. По мере роста компании растет и шум, сохранение хладнокровия критически важно.

За пределами продуктовых вопросов, поиск верных людей — наш главный focus, именно поэтому мы долго не расширяли штат. Все твердят, что слишком быстрый hiring чреват проблемами, но я считаю, мы спешили недостаточно: могли действовать смелее.

Наш финальный подход доказал эффективность: фокус на поиске признанных world-class талантов, иногда на recruitment уходит несколько лет.

Мы накопили бесценный опыт в myriad аспектах: оценка ideal candidates, культурный fit, standards excellence, engagement passive talent. Потребовалось время, чтобы прокачать эти skills.

Четверо молодых сооснователей Anysphere: Aman Sanger, Arvid Lunnemark, Sualeh Asif и Michael Truell

Lenny: Каким опытом делитесь с компаниями, сейчас нанимающими? Что упустили, чему научились?

Michael Truell: Изначально мы перекосили в поиск кандидатов по画像名校背景, особенно молодых, блестяще успевших в известных академических кругах.

Повезло найти ранних standout talent. Они уже очень опытные в корпоративном секторе, но согласились участвовать.

Сначала мы излишне драматизировали interest и experience. Мы наняли множество одаренной молодежи, но они отличались от senior lineup, вышедших напрямую с big stages.

Мы апгрейдили процесс interview. Создали proprietary set questions. Core环节 — приглашение кандидата на два дня совместной работы над имитационным проектом. Method works brilliantly, we continuously refine it.

Мы также учимся выявлять genuine interests, предлагать compelling packages, заводить диалог еще до active job search, презентуя opportunity.

Lenny: Есть ли любимый question на собеседовании?

Michael Truell: Изначально сомневался, что двухдневный practical assessment подойдет многим, но он показал unexpected longevity. Кандидаты проходят его от начала до конца, как реальный delivery.

Проекты стандартизированы, но дают реальный output за двое суток. Это не отнимает много времени команды: часы полудневных on-site interview распределяются на два дня, оставляя пространство для глубокой работы. Масштабировать проще.

Деньги — это тест «готовы ли вы работать с этим человеком».Ведь вы сидите двое суток, разделяете кофе и трапезы.

Изначально не ожидали, что assessment уживется, но сейчас это vital part pipeline. Крайне важно для attraction кандидатов, особенно на ранних этапах, когда продукт еще не viral и quality chưa fully mature. Единственный real pull часто становится команда, которая выглядит uniquely worth fighting for.

Двое суток позволяют кандидатам узнать нас, поверить в join intent. Result вышел远超 expectations. Это не строго interview question, а скорее prospective interviewing paradigm.

Lenny: Ultimate test — даете задачу, например, фичу в нашем кодебэйсе, collaborate dev и ship live, так?

Michael Truell: Примерно. Не передаем IP, не сливаем результат в core product line — симуляция. Обычно назначаем real two-day micro-task в our codebase. Они ведут end-to-end solo,当然 с sync touchpoints.

Мы strongly value async и onsite collaboration, почти всегда sit in office совместно.

Lenny: Сказали, метод продолжает жить. Каков current team size?

Michael Truell: Где-то 60 человек.

Lenny: Учитывая влияние, размер невелик, ждал большего. Наверное, devs max?

Michael Truell: Следующая priority hire — larger, elite squad для continuous product polish и CX elevation. Long-term mini-scale не intend.

Partly low headcount due to massive % engineers/R&D/design internally. Many software firms at ~40 devs hit 100+ total due to heavy ops reliance и early sales dependence.

Мы изначально взяли ultra-light, product-centric model.Сейчас обслуживаем broad market base и расширяемся. Still lots of work ahead.

Lenny: ИИ-индустрия бушует, daily noise, newsletters каждую минуту. Как управляет热门核心公司 сохраняя focus? Как держите команду laser-focused на продукте, игнорируя distraction новшеств?

Michael Truell: Hire是关键. Фокус на right attitude. Верим, excel здесь, но aim higher.

Internal discussion highlight: correct character crucial. Они не гонятся за external validation, а концентрируются на building exceptional product, delivering quality work, сохраняя calm mind и emotional stability.

Hiring решает many challenges,共识 компании. Любая org needs process, hierarchy, system. Но для любых org tools, чтобы достичь expected outcome, hire right folks goes far.

Пример: engineering process light, но运转良好. Нужно добавить steps, но small scale + great hires = less bureaucracy needed.

First: hire calm people. Second: communicate deeply. Third: lead by example.

С 2021 по 2022 мы deep-dive в AI. Witnessed massive shifts в tech и mindset. Если бы вернулись в конец 2021 — начало 2022, был GPT-3, без InstructGPT, DALL-E и Stable Diffusion ещё не существовали.

Рождение image tech, появление InstructGPT, релиз GPT-4, всплеск new models, modalities, video tech. Лишь极少 повлияло на our business.Мы выработали иммунитет, знаем, какие advances truly matter.

Несмотря на шум, critical path narrow. Последние 10 лет AI academia published endless DL papers. Astonishingly, major breakthroughs born from simple, elegant, timeless ideas. Most proposed concepts failed time test или impact threshold. Current dynamics mirror DL field evolution.

Спрос на инженеров будет только расти

Lenny: Какие misconceptions об направлении ИИ и его world-changing potential остаются? Или недостаточное понимание?

Michael Truell: Всё ещё экстремальные крайности: либо всё случится завтра, либо это hype и inflation.

Мы в середине profoundly impactful tech revolution, важнее интернета, важнее любого tech shift since computer birth. Но требуется время, десятилетия, diverse teams для acceleration.

Для будущего, где компьютеры берут всё большую load, нам resolver所有这些 independent technical puzzles continuously.

Some are scientific challenges: models understanding diverse data, faster, cheaper, smarter, better aligned to关注的 modalities, acting в physical world.

Другие — human-computer collaboration: что люди должны видеть, контролировать и how interact с tech.Это десятилетие exciting work.

Одна类 team критически важна. Без self-congratulation, focus automating specific knowledge-work domains, building底层 tech, integrating best third-party. Sometimes自主研发, shaping product experience.

Их value не только给用户, но по мере scaling drive progress. Top tier build huge enterprises,期待更多 similar涌现.

Lenny: Знаю, нанимаете passionate about «want to work here and build this». Whom seek now? Specific roles/hires? Priority open positions? Contact info for interested?

Michael Truell: Много un-done tasks, many backlog. Если кажется, что特定 role не listed, свяжитесь. Bring fresh lenses, spot gaps missed.

Top 2 this year: build best-in-class product и growth. Market share grab phase. Globally, most haven't used同类 tool, others on slower competitors. Driving Cursor growth key目标.

Continuous hire top engineer, designer, researcher, plus other talent.

Lenny: Narrative: AI replaces engineers для всего кода. Reality:疯狂 hire engineers, включая base model builders. Expect inflection point demand slowdown?

Big вопрос: universal demand growth forever, or mass deployment of cursor-like agents handles dev eventually?

Michael Truell: Views as long, complex evolution, not instant switch to command-only replacement of eng dept.

Desire smooth transition, maintain human primacy. Even final state赋予人对一切的掌控权 critical, professional需决定软件应有形态. Инженеры незаменимы,多做更多.

Software需求持久. Не новость, но paradox: build seemingly simple, well-defined东西成本人力远超想象. Laymen think easy, reality hard.降低开发成本与人力一个量级, unlock more PC possibilities,無數新工具.

Lived it: biotech co internal tool. Market体验极差, unmet need. Internal tool demand vastly exceed个人开发 capacity.

Hardware sufficient long ago,理应随心所欲移动或搭建任何,现实阻碍太多. Software需求远超当前开发能力, простой生产力软件成本如拍大片.遥远未来工程师需求只会越来越大.

Lenny:未尽之言?留给听众 wisdom drop?

Michael Truell: Постоянно думаем как построить team simultaneous create new и iteratively improve product. Для успеха IDE must radically change, future形态 significantly diff.

Looking at benchmark companies, see those sustain multiple leaps, push frontier, rare.

Balance daily reflection от first principles и studying historical success case. Regularly思考.

Lenny: Заметил книги за спиной, одна про老牌计算机公司 история influential, but unfamiliar. resonates:创新思维常源于历史回顾,过往成功失败研究.

如何联系或 apply? Найти online info? Mentioned可能存在未意识岗位, where了解? How listeners help?

Michael Truell: Interested? Products и contact на cursor.com.

Lenny: Отлично. Майкл, спасибо большое за сегодняшнюю встречу.