Cursor CEO: Going Beyond Code, Superintelligent AI Agents, And Why Teste Still Matters (Рубрика #AI)

Посмотрел интересное интервью Michael Truell с Garry Tan. Они говорили про будущее разработки и это действительно интересно, ведь Майкл — соучредитель и генеральный директор Anysphere, компании, создавшей Cursor, один из самых быстрорастущих AI-инструментов для кодирования. А Гарри — президент и генеральный директор Y Combinator, известного стартап-акселератора. Это интервью было 11 июня и оно проходило во время Demo Day Y Combinator Summer 2025, где представляются новые компании из текущего набора Y Combinator. Ниже представлены ключевые идеи интервью в моей интерпретации

1. Революционное видение будущего программирования
Основная цель Cursor — изобрести новый тип программирования, где разработчики смогут просто описывать желаемый результат, а не писать сложный код. Майкл предвидит, что программисты будут становиться "дизайнерами логики", фокусируясь на высокоуровневом проектировании, а не на написании низкоуровневого кода. Интересно, что раньше часто говорили про языки программирования новых поколений, например, третьим поколением были стандартные C, C++, C#, Java и JavaScript, но люди говорили про четвертое поколение. Но оно особо не полетело:) А теперь новым поколением языков программирования похоже будет plain english/russian/whatever text (но лучше с правильными промптами). Интересно, что Майкл считает, что за следующие 5-10 лет произойдет значительное изменение в способах создания софта.

2. Текущее состояние AI в программировании
Наибольшие изменения уже заметны в небольших кодовых базах, где разработчики могут работать на более высоком уровне абстракции. В среднем разработчики используют AI для написания 40-50% кода в Cursor, но все еще требуется человеческий контроль и понимание. Майкл говорит о том, что vibe coding пишется без глубокого понимания и не рекомендуется для долгосрочных проектов (а для прототипов он отлично подходит)

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

4. История и эволюция Cursor
Команда основателей из MIT первоначально работала над AI для автоматизированного проектирования (CAD), но позже переключилась на программирование. GitHub Copilot и исследования OpenAI о масштабируемости моделей стали ключевыми источниками вдохновения для создания Cursor. Вместо создания расширения для условного VSCode команда решила разработать собственный редактор, что оказалось важным преимуществом.

5. Рост и успех компании
Anysphere достигла оценки в 9,9 миллиардов долларов после привлечения 900 миллионов долларов инвестиций. Компания достигла 100 миллионов долларов годового дохода всего за 20 месяцев после запуска, а затем выросла до 300 миллионов за два года и более 500 миллионов к середине 2025 года. Cursor используется в крупных технологических компаниях, включая OpenAI, Stripe, Spotify и других.

6. Будущее AI и программирования
Способность создавать программное обеспечение станет доступной гораздо большему числу людей. Появится больше специализированного программного обеспечения для конкретных отраслей благодаря снижению барьеров для разработки. Несмотря на автоматизацию, "чувство вкуса" останется незаменимым человеческим качеством — оно позволяет определить, что именно нужно создать и как это должно работать.

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

#AI #ML #Software #DevEx #Engineering #Development

[1/3] Enabling the Study of Software Development Behavior With Cross-Tool Logs (Рубрика #Management)

Прочитал наконец-то исследование, вышедшее в 2020 году, где авторы из Google рассказали про создание своей системы InSession, которая позволяет проводить комплексный анализ поведения инженеров путем интеграции логов от множества инструментов разработки. Ценность исследования в том, что разработчики - это одна из самых затратных частей разработки софта, поэтому даже небольшие улучшения продуктивности могут принести значительные результаты. InSession отличалось от других подобных инструментов тем, что собирало не только данные из IDE, но и не требовало установки на рабочие машинки инженеров (данные собирались из существующих облачных инструментов).

Если говорить про саму систему, то она состояла из следующих ключевых частей
1. События (Events)
Событие - это отдельное использование инструмента или системы разработчиком или от имени разработчика. Для каждого типа логов был свой импортер, который трансформировал данные в общий формат событий. Сами события были разных типов
- Фронтенд-события: инициируемые разработчиком активно (например, нажатие кнопки интерфейса)
- Бэкенд-события: происходящие асинхронно от имени разработчика (например, cron-задания)
- Мгновенные события: с неопределенной конечной точкой
- Длительные события: с установленным временем начала и окончания
2. Артефакты
Для большинства событий собиралась еще дополнительная метаинформация, которую авторы называли артефактами. Они были двух типов
Идентифицирующие задачу артефакты: идентифицируют конкретную задачу разработки для группировки связанных событий
Информационные артефакты: предоставляют контекстную информацию о событии
3. Сессии
Собственно события объединялись в сессии при помощи группировок, которые
- Происходят в один день
- В течение временного интервала (10 минут)
- Имеют одинаковые идентифицирующие задачу артефакты (или не имеют никакую)
4. Метрики
Система выводит семь ключевых метрик поведения разработчиков:
- Время кодирования - время написания или maintaining кода
- Время рецензирования - время на ревью кода
- Время сопровождения (shepherding) - время на доработки кода по результатам обратной связи с code review
- Время исследования - время на изучение документации
- Время разработки - время на разработческие активности любого типа (что не покрыты другими категориями)
- Время работы с электронной почтой
- Время, проведенное на встречах

Если говорить про источники данных для InSession, то это множество инструментов, включающих
- Buganizer - система отслеживания ошибок
- Code Search - инструмент поиска и просмотра кода
- Cider - веб-IDE
- Blaze - распределенная система сборки
- Critique - инструмент рецензирования кода
- Gmail и Calendar - здесь тянулись ограниченные метаданные
- Еще более 90 инструментов командной строки

Продолжение обзора этой интересной статьи в следующем посте.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

[2/3] Enabling the Study of Software Development Behavior With Cross-Tool Logs (Рубрика #Management)

Продолжая рассказ про эту статью, надо рассказать про принципы конфиденциальности, способы валидации, пример исследования, а также про последствия создания методологии InSession и где она дальше засветилась. Ну а начнем мы с принципов конфиденциальности, которым следовали авторы
- Сбор данных только от сотрудников
- Фокус на рабочих инструментах
- Отказ от сбора контента, созданного сотрудниками
- Шифрование хранимых данных
- Аудируемый доступ к данным
- Запрет на отчетность по индивидуальным сотрудникам без согласия (интересно, что на практике соблюдение этого принципа ооочень трудно добиться)
- Уничтожение данных после установленного периода хранения (3 года)

Для валидации полученных измерений авторы решили сравнить их с поведенческими самоотчетаим (diaries). Авторы провели исследование с 25 инженерами Google, которые создавали дневники своей деятельности, затем сравнили эти дневники с данными сессий, используя показатель согласия PABAK (Prevalence and Bias Adjusted Kappa). Результаты показали высокое согласие для времени рецензирования (0.81), кодирования (0.69) и исследования (0.70).

Дальше авторы провели эксперимент для оценки эффекта readability certification инженеров на время рецензирования. Readability certification - это сертфикация о том, что инженер знает идиомы языка и правила написания принятые в Google. Гипотеза была в том, что при получении инженером сертификации по readability
- Ревьюверам придется тратить меньше времени на ревью
- Инженерам придется тратить меньше времени на доработки по комментариям ревьюверов (shepherding)

При анализе влияния процесса читаемости кода они применили линейную регрессию с контролем стажа разработчика, количества рецензентов и размера изменения, а также включили случайный эффект для идентичности автора. И они получили такие результаты
- Для C++: время рецензирования сократилось на 4.5%, время shepherding - на 10.5%
- Для Java: время shepherding сократилось на 10.0%
- 88% инженеров, завершивших процесс читаемости Java, согласились с утверждением о положительном опыте

Это исследование значительно повлияло на подходы к измерению продуктивности разработчиков в индустрии. Система InSession стала основой для ответа на долгосрочные вопросы программной инженерии, такие как "делают ли типы разработку более эффективной?". Подход Google к измерению поведения разработчиков через кросс-инструментальные логи вдохновил другие организации на создание аналогичных систем.

Методология придуманная авторами упоминалась и в следующих статьях, например
- "What Improves Developer Productivity at Google? Code Quality" (2022) - исследование использовало методологию, разработанную в InSession, для изучения панельных данных и установления причинно-следственных связей между качеством кода и продуктивностью разработчиков. Я уже разбирал эту статью
- "Predicting developers' negative feelings about code review" (2020) - работа применила данные InSession для предсказания негативных межличностных взаимодействий во время рецензирования кода, используя 90-й процентиль времени рецензирования и сопровождения.
- "The pushback effects of race, ethnicity, gender, and age in code review" (2022) - исследование использовало инфраструктуру данных InSession для изучения влияния демографических факторов на процесс рецензирования кода.

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

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

What your CEO must know about AI (Рубрика #AI)

Посмотрел интересное выступление Хьюберта Мистела, Senior AI Researcher в компании Novartis. Хьюберт руководит командой исследователей искусственного интеллекта в области разработки лекарств, а также преподает машинное обучение и науку о данных в Dublin Business School. Это выступление состоялось на конференции AI Engineer World's Fair 2025 — крупнейшем техническом ИИ-событии года, которое прошло 3-5 июня 2025 года в Сан-Франциско. Ниже представлены ключевые идеи выступления в моей интерпретации

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

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

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

3. Новая реальность рынка труда
Доменные знания и интеллект становятся дешевыми и легкодоступными, а это значит, что
- Компаниям и сотрудникам стоит стремиться к мультидисциплинарным знаниям
- Появятся новые роли: "майнеры рабочих процессов", "люди-оркестраторы ИИ"
- ИИ ускоряет "деятелей" — разница в производительности может достигать не 10x, а 100x (похоже на отсылку к 10x инженерам)

4. Демократизация создания агентов
Критически важно дать возможность сотрудникам самостоятельно создавать агентов с помощью no-code/low-code инструментов, для этого нужно следующее
- Когнитивная самоосознанность — понимание собственных мыслительных процессов
- Способность переводить ментальные шаги в конкретные инструкции
- Доступ к инструментам быстрого создания агентов

5. Этические вопросы
Есть два критических вопроса, которые надо решить для дальнейшего распространения агентов:
- Готовы ли мы не просто делегировать задачи, а позволить ИИ-агентам управлять процессами?
- Какие ценности заложить в агентов и как разрешать конфликты между человеком и ИИ?

6. Практические рекомендации для руководителей
- Аудит стратегии: если ваша AI-стратегия остается актуальной при замене "AI-агент" на "ML" — она устарела
- Картирование рабочих процессов: детальное понимание workflows критично для получения максимальной выгоды
- Готовность к трансформации: организационная структура компании может кардинально измениться
- Инвестиции в контекст: контекст становится новой нефтью, важнее самих данных

В общем, у Хьюберта получилась интересное выступление о революции AI-агентов, которая уже началась и к которой стоит быть готовым.

#AI #ML #Software #Engineering #Development #Agents #Architecture

Интервью с Максимом Евдокимовым про современных CPO, крутые продукты и сложные решения (Рубрика #Management)

Посмотрел с большим интересом интервью с Максимом Евдокимовым, бышим коллегой, который когда-то был CPO в Т-Банке, CPO в hh.ru, большим директором в Сбере, гендиром Okko, а сейчас занимает должность CPMO (Chief Product and Marketing Officer) в Bir Bank, крупнейшем розничном банке Азербайджана. Ниже я выделил основные моменты интервью с моей точки зрения

1. Начало карьеры и опыт в телекоме
Максим рассказал о своем первом заработке в качестве дворника еще в школьные годы. Профессионально он начал работать в 1995 году в торговой компании, для работы хватило знания английского языка и компьютера. Позже, в 2001 году, он попал в финскую компанию Sonera, что стало началом его карьеры в телекоме. По словам Максима, телеком-компании в начале 2000-х были главными драйверами развития цифровых технологий, хотя тогда еще не существовало многих современных терминов и фреймворков. Работа в Мегафоне научила его фокусироваться на клиенте и его потребностях, а также формировать пользовательскую потребность, а не просто отвечать на существующие запросы. Интересно, что сейчас телеком компании - это скорее консерваторы:)
2. Опыт в Тинькофф Банке
В Тинькофф Банк (ныне Т-Банк) Максим пришел в 2013 году после 12 лет работы в телекоме. Первым его проектом был "Тинькофф Wallet" — мобильный кошелек с входом по номеру телефона, который был запущен в декабре 2013 года. Из-за регуляторных изменений проект пришлось трансформировать, и Максим перешел к управлению клиентской частью мобильной платформы банка. Одним из значимых достижений Максима в Тинькофф было внедрение концепции лайфстайл-банкинга и запуск сторис в банковском приложении. Тинькофф стал первым банком на европейском рынке, использовавшим формат сторис для персонализированных предложений клиентам.
3. Продуктовый подход и управление
Максим поделился своим видением продуктового подхода, который он называет "продакт-менеджмент от Евдокимова". Его ключевой принцип: лучше сделать продукт на "твердую четверку" и потом довести до "пятерки", чем выпустить "тройку с минусом" и никогда к ней не вернуться. Он выступает против использования термина MVP (Minimum Viable Product) и предпочитает концепцию MLP (Minimum Lovable Product) — ограниченного, но очень хорошего продукта. По его мнению, для крупной компании неприемлемо делать некачественные продукты, так как это создает репутационные и конкурентные риски.
4. Текущая роль в Bir Bank
В Bir Bank Максим отвечает за продукты и маркетинг. Он рассказал о двух основных задачах в своей текущей роли:
- Построение эффективных продуктовых процессов, так как банк переживает "болезнь роста"
- Развитие экосистемной повестки, чтобы клиенты банка могли увидеть ценностное предложение от других активов экосистемы
По оценке Евдокимова, финтех и банкинг в Азербайджане отстают от российского рынка примерно на 5-7 лет, но в некоторых аспектах, например, в цифровом правительстве и связке бизнеса с государством, некоторые вещи сделаны даже лучше.
5. Ключевые выводы и идеи
Максим подчеркивает важность "ownership" (чувства собственности) в продуктовых командах. По его мнению, идеальная команда — это единомышленники, где каждый отвечает за весь продукт, а не только за свою зону ответственности. Он считает, что в организации нужно развивать культуру доверия и ответственности, чтобы люди могли проявлять инициативу. Причины неудач в продуктовом подходе часто кроются в головах менеджмента, включая акционеров. Для разных стадий развития организации нужны разные управленческие лидеры, и важно вовремя принимать решения о смене руководства.

В общем, подкаст получился достаточно интересным:)

#ProductManagement #Management #Leadership #Software #Engineering #Career

[1/3] What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time (Рубрика #Productivity)

На эту интересную статью 2025 года от компании "Meta" я наткнулся во время подготовки обзора статьи "Enabling the Study of Software Development Behavior With Cross-Tool Logs" (мой обзор: 1, 2 и 3). И хоть деятельность организации "Meta" запрещена на территории РФ, но читать их инженерный whitepaper достаточно интересно. Основная идея этого исследования - это измерение продуктивности разработки софта через метрику Diff Authoring Time (DAT), которая представляет собой активное время разработчика на создание изменений в коде (диффов), которые по сути своей напоминают MR (merge requests). Это время собирается при помощи системы телеметрии, интегрированной с системой контроля версий, IDE и операционной системой .

Ключевая ценность этого исследования для Meta это
- Переход от интуитивных оценок к научному подходу измерения продуктивности на основе DAT
- Измерения DAT направлены не на оценку performance конкретных разработчиков, а на оценку эффекта инструментов и процессов на продуктивность
- Этот подход дает возможность проведения a/b экспериментов изменения тулинга и процессов - по утверждению авторов они уже ее обкатали на 20 проектах, про три из которых они рассказывают в статье
- Важно, что часть экспериментов можно катать с гранулярностью на уровне diffs (эксперименты, что прозрачны для инженеров), а часть на уровне когорт инженеров (те, где изменения явно видны и не позволяют менять подход для разных diffs - например, переключение между версиями IDE)

Забавно, что авторы утверждают, что-то в стиле того, что их исследование впервые в индустрии предоставляет количественные доказательства влияния различных инструментов и методов разработки на продуктивность в реальной корпоративной среде. Видимо, они не читали исследований ребят из Google, например, то, что я упоминал выше от 2020 года:)

Если говорить про струткру модели, то она состоит из следующих частей
1. Основной алгоритм точного сопоставления
Отслеживание активности в IDE: Система фиксирует время работы в интегрированной среде разработки
Интеграция с системой контроля версий: Связывает временные сессии с конкретными коммитами через Sapling (система контроля версий Meta)
Алгоритм сдвига влево: Каждый коммит CHx приписывается к IDE-сессии s(x-1), которая предшествует ему
2. Дополнительные эвристики
Anchor Sessions: Захватывает активность, предшествующую точному совпадению, для более полного покрытия времени разработки
Обработка крайних случаев: Автоматическое исключение checkout'ов и фильтрация нерелевантной активности
3. Система телеметрии с защитой приватности
OS-уровневая телеметрия: Отслеживание активности на уровне операционной системы
Интеграция с инструментами: Плагины для VS Code, Sapling и других инструментов разработки
Неперекрывающиеся измерения: DAT гарантирует, что время между различными диффами не пересекается для одного разработчика

В итоге, мы получаем следующие ключевые свойства модели
- Неперекрываемость: DAT(D123) ∩ DAT(D987) = ∅ для одного пользователя, где D123 и D987 - это два разных diffs
- Ограниченность: DAT не может превышать 24 часа в день
- Агрегируемость: В отличие от других метрик, DAT можно корректно суммировать

Продолжение обзора в следующем посте.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes