LOVED: How to Rethink Marketing for Tech Products (Loved. Продуктовый маркетинг по любви)
Дочитал эту книгу Мартина Лаученко на этих зимних каникулах (а начинал читать еще пару лет назад). Книга оставила у меня смешанные чувства - вроде и автор хороший и тема интересная, а книга читалась через силу. Вообще, Мартина - опытный эксперт, что когда-то участвовала в разработке и маркетинге Microsoft Word и Netscape Navigator, а сейчас является партнёром Silicon Valley Product Group. Интересно, что книга стала бестселлером среди книг о маркетинге технических продуктов, хотя в переводе названия эта нацеленность на технические продукты исчезла. Ключевые идеи книги такие
1️⃣ Отличный технологичный продукт сам по себе не гарантирует успеха - нужна продуманная маркетинговая стратегия. Лаученко объясняет, что продуктовый маркетинг - это стратегическая функция, формирующая восприятие продукта рынком.
2️⃣ Мартина выделяет четыре роли продуктувого маркетолога: амбассадор, стратег, сторителлер и евангелист. Эти роли последовательно связывают продукт с аудиторией: знакомят пользователей, формируют ожидания, “влюбляют” в продукт и вдохновляют рассказывать о нём другим. Если подробнее, то
- Ambassador - это "мост" между рынком и командой. Он помогает синхронизировать инсайты о пользователях/рынке внутрь компании и обратно, чтобы это реально влияло на решения: что строим, как упаковываем, как продаём. Это не "владелец" продукта/маркетинга, а именно амбассадор диалога: помогать команде слышать сигнал и корректировать курс.
- Strategist - отвечает за то, "куда идём через 12–18 месяцев". Эта роль про долгий горизонт: продуктовый маркетинг смотрит на то, кем вы должны стать для рынка, и что нужно сделать сегодня, чтобы рынок вас так воспринимал завтра (включая что строить, как упаковать, какой GTM-механикой идти)
- Storyteller - отвечает не просто за копирайтинг, а про управление тем, как рынок объясняет себе вашу ценность: это больше, чем "правильные слова". Очень практичная эвристика из интервью: объясняйте продукт так, будто разговариваете с умным восьмиклассником - это выбивает жаргон и заставляет докопаться до сути.
- Evangelist - эта роль "делает так, чтобы другие рассказывали за нас". В современном мире важнее то, что скажут другие, а не то, что вы скажете сами. Поэтому задача - вооружить людей "атомарными тезисами", которые легко пересказать: тезис, пример, ROI-история, короткая формула ценности.
3️⃣ Фокус на рынке, не только на продукт: книга учит начинать не с функций, а с реальных потребностей. Собирайте обратную связь от пользователей и держите в фокусе market-product fit (сначала понять нужды рынка, потом создавать решение). Иными словами, ценность продукта определяется готовностью рынка его принять, а не наоборот.
4️⃣ Go-to-Market как часть стратегии: план вывода на рынок нужно продумывать с первого дня, а не после релиза. В книге показано, как продукт обгонял конкурентов не за счёт новых фич, а благодаря лучшему позиционированию и истории о ценности. Например, сервис Pocket вырвался вперёд, сумев чётко донести, чем он полезнее альтернатив. Правильный нарратив способен переломить исход рыночной борьбы. Отдельно интересно рассказано про календарь для планирования релизов. Смысл в том, чтобы договориться, что релизы бывают разных "классов", и от класса зависит:
- Сколько заранее готовится маркетинг/сейлз/саппорт
- Какие активы нужны (доки, кейсы, сравнения, pricing/packaging)
- Какая “цель релиза” (тихий rollout vs попытка пробить новый сегмент)
Почему эту книгу интересно почитать инженерам и техническим руководителям?
Хотя книга о маркетинге, написана она для широкой аудитории технических специалистов - без перегрузки жаргоном. Инженерам Loved поможет взглянуть на свой продукт глазами рынка. Она даст техническим специалистам понимание, как соединить два мира - продукт и рынок. Разработчики узнают, как эффективно доносить ценность своих решений, выстраивать доверие пользователей и сотрудничать с маркетингом, чтобы их проекты не просто работали, но и становились любимыми.
#Marketing #Startup #Economics #Software #Engineering
Дочитал эту книгу Мартина Лаученко на этих зимних каникулах (а начинал читать еще пару лет назад). Книга оставила у меня смешанные чувства - вроде и автор хороший и тема интересная, а книга читалась через силу. Вообще, Мартина - опытный эксперт, что когда-то участвовала в разработке и маркетинге Microsoft Word и Netscape Navigator, а сейчас является партнёром Silicon Valley Product Group. Интересно, что книга стала бестселлером среди книг о маркетинге технических продуктов, хотя в переводе названия эта нацеленность на технические продукты исчезла. Ключевые идеи книги такие
1️⃣ Отличный технологичный продукт сам по себе не гарантирует успеха - нужна продуманная маркетинговая стратегия. Лаученко объясняет, что продуктовый маркетинг - это стратегическая функция, формирующая восприятие продукта рынком.
2️⃣ Мартина выделяет четыре роли продуктувого маркетолога: амбассадор, стратег, сторителлер и евангелист. Эти роли последовательно связывают продукт с аудиторией: знакомят пользователей, формируют ожидания, “влюбляют” в продукт и вдохновляют рассказывать о нём другим. Если подробнее, то
- Ambassador - это "мост" между рынком и командой. Он помогает синхронизировать инсайты о пользователях/рынке внутрь компании и обратно, чтобы это реально влияло на решения: что строим, как упаковываем, как продаём. Это не "владелец" продукта/маркетинга, а именно амбассадор диалога: помогать команде слышать сигнал и корректировать курс.
- Strategist - отвечает за то, "куда идём через 12–18 месяцев". Эта роль про долгий горизонт: продуктовый маркетинг смотрит на то, кем вы должны стать для рынка, и что нужно сделать сегодня, чтобы рынок вас так воспринимал завтра (включая что строить, как упаковать, какой GTM-механикой идти)
- Storyteller - отвечает не просто за копирайтинг, а про управление тем, как рынок объясняет себе вашу ценность: это больше, чем "правильные слова". Очень практичная эвристика из интервью: объясняйте продукт так, будто разговариваете с умным восьмиклассником - это выбивает жаргон и заставляет докопаться до сути.
- Evangelist - эта роль "делает так, чтобы другие рассказывали за нас". В современном мире важнее то, что скажут другие, а не то, что вы скажете сами. Поэтому задача - вооружить людей "атомарными тезисами", которые легко пересказать: тезис, пример, ROI-история, короткая формула ценности.
3️⃣ Фокус на рынке, не только на продукт: книга учит начинать не с функций, а с реальных потребностей. Собирайте обратную связь от пользователей и держите в фокусе market-product fit (сначала понять нужды рынка, потом создавать решение). Иными словами, ценность продукта определяется готовностью рынка его принять, а не наоборот.
4️⃣ Go-to-Market как часть стратегии: план вывода на рынок нужно продумывать с первого дня, а не после релиза. В книге показано, как продукт обгонял конкурентов не за счёт новых фич, а благодаря лучшему позиционированию и истории о ценности. Например, сервис Pocket вырвался вперёд, сумев чётко донести, чем он полезнее альтернатив. Правильный нарратив способен переломить исход рыночной борьбы. Отдельно интересно рассказано про календарь для планирования релизов. Смысл в том, чтобы договориться, что релизы бывают разных "классов", и от класса зависит:
- Сколько заранее готовится маркетинг/сейлз/саппорт
- Какие активы нужны (доки, кейсы, сравнения, pricing/packaging)
- Какая “цель релиза” (тихий rollout vs попытка пробить новый сегмент)
Почему эту книгу интересно почитать инженерам и техническим руководителям?
Хотя книга о маркетинге, написана она для широкой аудитории технических специалистов - без перегрузки жаргоном. Инженерам Loved поможет взглянуть на свой продукт глазами рынка. Она даст техническим специалистам понимание, как соединить два мира - продукт и рынок. Разработчики узнают, как эффективно доносить ценность своих решений, выстраивать доверие пользователей и сотрудничать с маркетингом, чтобы их проекты не просто работали, но и становились любимыми.
#Marketing #Startup #Economics #Software #Engineering
❤10👍3🔥2
Конструктор орбитальной станции
Где-то полгодика назад я купил себе конструктор с космической станцией, но никак не доходили руки его собрать. Но в каникулы я сделал над собой усилие и собрал его - теперь он стоит у меня в кабинете. А рядом с ним лего фигурки космонавта и Маленького Принца (в некотором роде тоже космического путешественника). В общем, выглядит стильно и мне нравится:)
Где-то полгодика назад я купил себе конструктор с космической станцией, но никак не доходили руки его собрать. Но в каникулы я сделал над собой усилие и собрал его - теперь он стоит у меня в кабинете. А рядом с ним лего фигурки космонавта и Маленького Принца (в некотором роде тоже космического путешественника). В общем, выглядит стильно и мне нравится:)
👍17🔥9❤6
[1/3] Octoverse 2025: A new developer joins GitHub every second as AI leads TypeScript to #1 (Рубрика #Engineering)
В конце октября появился очередной отчет Octoverse от GitHub, где авторы рассказывают про состояние дел в мире OSS (Open Source Software), а точнее о состоянии экосистемы разработки софта на GitHub. В 2025 году в отчете рассказывают про рекордный рост сообщества разработчиков в 2025 году и кардинальное влияние инструментов искусственного интеллекта на процесс разработки и выбор технологий.
Но начать стоит с методологии, так как она в отличие от многих других похожих отчетов основана не на опросах (что хорошо и позволяет оценить что происходит реально с репозиториями, кодом, разработчиками):
- Источник и период данных: отчет основан на анализе всех активностей пользователей на платформе GitHub за период с 1 сентября 2024 года по 31 августа 2025 (это так называемый Octoverse Year). Данные получены непосредственно из событий на платформе (коммиты, pull request’ы, issue и др.) – преимущественно из публичных репозиториев, если не оговорено иначе. Такой подход позволил сопоставлять метрики год к году с учётом сезонности (для трендов использовали сравнение одного и того же месяца в 2024 и 2025).
- Охват и размер выборки: тут тоже все здорово - отчет Octoverse опирается на всю популяцию разработчиков на GitHub, которых в 2025 году стало больше 180 миллионов (на 36 млн больше, чем годом ранее).
- Географическая представленность: данные отражают глобальное распределение разработчиков. Быстрее всего сообщество растёт в Азии и других развивающихся регионах, а Индия вышла на первое место по скорости добавления разработчиков (более 5.2 млн за год), а также на второе место по размеру сообщества (сразу после США).
- Отраслевая представленность: в конексте отчета разработчиком считают любого пользователя GitHub, связанный с созданием ПО. Отчёт охватывает как открытые проекты, так и корпоративные: хотя 81,5% всех зафиксированных вкладов пришлось на приватные репозитории (внутренние компании разработки), более 63% всех репозиториев на GitHub остаются публичными или open source. Иными словами, анализ учитывает и повседневную корпоративную разработку, и масштабную открытую экосистему, на которую она опирается.
- Дополнительные исследования: Отчёт носит количественный характер, основанный на телеметрии GitHub, а не на анкетировании. Однако авторы включили точечные качественные данные – например, серии интервью с разработчиками о практике ревью кода, чтобы оценить пользу нового инструмента GitHub Copilot Code Review. Результаты этих интервью встроены в анализ, например, 72,6% опрошенных отметили рост эффективности кода-ревью благодаря ИИ.
Ну а теперь, когда стало ясно почему отчет так интересен, стоит перейти к его результатами и ключевым выводам
👀 Основные показатели экосистемы Octoverse 2025
- Общее число проектов достигло 630 миллионов, AI-проектов – 4,3 млн, а разработчиков –-более 180 миллионов
- Количество публичных contributions (commits, PRs, gits, ...) - 1,12 млрд, в среднем 43,2 млн слияний pull request’ов в месяц (+23% г/г)
- Самыми популярными языками стали TypeScript и Python
Эти рекордные цифры отражают главные тренды 2025 года - беспрецедентный рост сообщества и широкое внедрение ИИ-технологий в разработку
Ну а в следующих постах мы обсудим ключевые результаты более подробно.
#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture
В конце октября появился очередной отчет Octoverse от GitHub, где авторы рассказывают про состояние дел в мире OSS (Open Source Software), а точнее о состоянии экосистемы разработки софта на GitHub. В 2025 году в отчете рассказывают про рекордный рост сообщества разработчиков в 2025 году и кардинальное влияние инструментов искусственного интеллекта на процесс разработки и выбор технологий.
Но начать стоит с методологии, так как она в отличие от многих других похожих отчетов основана не на опросах (что хорошо и позволяет оценить что происходит реально с репозиториями, кодом, разработчиками):
- Источник и период данных: отчет основан на анализе всех активностей пользователей на платформе GitHub за период с 1 сентября 2024 года по 31 августа 2025 (это так называемый Octoverse Year). Данные получены непосредственно из событий на платформе (коммиты, pull request’ы, issue и др.) – преимущественно из публичных репозиториев, если не оговорено иначе. Такой подход позволил сопоставлять метрики год к году с учётом сезонности (для трендов использовали сравнение одного и того же месяца в 2024 и 2025).
- Охват и размер выборки: тут тоже все здорово - отчет Octoverse опирается на всю популяцию разработчиков на GitHub, которых в 2025 году стало больше 180 миллионов (на 36 млн больше, чем годом ранее).
- Географическая представленность: данные отражают глобальное распределение разработчиков. Быстрее всего сообщество растёт в Азии и других развивающихся регионах, а Индия вышла на первое место по скорости добавления разработчиков (более 5.2 млн за год), а также на второе место по размеру сообщества (сразу после США).
- Отраслевая представленность: в конексте отчета разработчиком считают любого пользователя GitHub, связанный с созданием ПО. Отчёт охватывает как открытые проекты, так и корпоративные: хотя 81,5% всех зафиксированных вкладов пришлось на приватные репозитории (внутренние компании разработки), более 63% всех репозиториев на GitHub остаются публичными или open source. Иными словами, анализ учитывает и повседневную корпоративную разработку, и масштабную открытую экосистему, на которую она опирается.
- Дополнительные исследования: Отчёт носит количественный характер, основанный на телеметрии GitHub, а не на анкетировании. Однако авторы включили точечные качественные данные – например, серии интервью с разработчиками о практике ревью кода, чтобы оценить пользу нового инструмента GitHub Copilot Code Review. Результаты этих интервью встроены в анализ, например, 72,6% опрошенных отметили рост эффективности кода-ревью благодаря ИИ.
Ну а теперь, когда стало ясно почему отчет так интересен, стоит перейти к его результатами и ключевым выводам
👀 Основные показатели экосистемы Octoverse 2025
- Общее число проектов достигло 630 миллионов, AI-проектов – 4,3 млн, а разработчиков –-более 180 миллионов
- Количество публичных contributions (commits, PRs, gits, ...) - 1,12 млрд, в среднем 43,2 млн слияний pull request’ов в месяц (+23% г/г)
- Самыми популярными языками стали TypeScript и Python
Эти рекордные цифры отражают главные тренды 2025 года - беспрецедентный рост сообщества и широкое внедрение ИИ-технологий в разработку
Ну а в следующих постах мы обсудим ключевые результаты более подробно.
#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture
The GitHub Blog
Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1
In this year’s Octoverse, we uncover how AI, agents, and typed languages are driving the biggest shifts in software development in more than a decade.
❤7👍2🔥2
[2/3] Octoverse 2025: A new developer joins GitHub every second as AI leads TypeScript to #1 (Рубрика #Engineering)
Продолжая рассказ про очередной ежегодный отчет от GitHub о состоянии экосистемы разработки софта на платформе, расскажу подробнее про его результаты.
📈 Беспрецедентный рост сообщества
- Платформа пополнилась более чем 36 миллионами новых разработчиков - это самый высокий абсолютный рост за всю историю наблюдений
- азработчики создали около 121 млн новых репозиториев за год (до 630 млн всего)
- Число коммитов достигло почти 1 миллиарда в 2025 году (+25% к 2024)
- Ежемесячно сливалось порядка 43,2 млн pull request’ов (+23% к 2024)
Такая динамика совпала с запуском бесплатной версии GitHub Copilot в конце 2024, которая привлекла волну новых пользователей и проектов.
🤖 ИИ стал неотъемлемой частью разработки
Генеративный ИИ за год превратился из новинки в стандартный инструмент разработчика.
- На GitHub уже насчитывается порядка 4,3 миллиона репозиториев, связанных с AI (расчет через проставление тегов репозиториям и выделение части тегов как относящихся к AI проектам).
- Свыше 1,1 млн публичных проектов используют SDK для работы с большими языковыми моделями (LLM) - и 693 тыс. из них созданы всего за последние 12 месяцев (рост +178% год к году)
- Новички сразу внедряют AI в работу: почти 80% новых разработчиков начинают использовать автодополнение GitHub Copilot уже в первую неделю работы с кодом
Всё это подтверждает, что ИИ-инструменты теперь ожидаемы “по умолчанию” в среде разработчиков. Рост использования AI-средств сопровождается и ростом вклада в код: за год было слито рекордные 518,7 млн pull request’ов (+29% к предыдущему году), а общее число вкладов в открытые проекты превысило 1,12 млрд (+13% г/г).
🚀 TypeScript вышел на 1-е место среди языков
Впервые за последнее десятилетие сменился лидер по популярности языков программирования на GitHub: в августе 2025 года TypeScript обогнал Python (а также давнего лидера JavaScript) и стал самым используемым языком на платформе. Стремительный рост TypeScript обусловлен сразу двумя факторами
1. Современные фронтенд-фреймворки (React, Angular и др.) генерируют шаблоны проектов на TS по умолчанию
2. Команды всё чаще предпочитают строго типизированный код при использовании ИИ: развитая типизация TypeScript делает автосгенерированный AI-код более надежным
За год сообщество TypeScript выросло на ≈1,05 млн разработчиков (+66% г/г), тогда как Python прибавил ~850 тыс. (+48% г/г). Несмотря на потерю первого места, Python остаётся ключевым языком для задач ИИ и науки о данных - у него 2,6 млн активных контрибьюторов, а Jupyter Notebook по-прежнему служит основной средой экспериментов (≈403 тыс. репозиториев внутри AI-проектов). Совокупно сообщества TypeScript и Python теперь насчитывают >5,2 млн разработчиков (около 3% всех активных пользователей GitHub).
Такой сдвиг подтверждает: ИИ влияет не только на скорость кодинга, но и на выбор технологий - команды охотнее доверяют AI-сгенерированный код языкам со строгой типизацией, особенно для продакшн-систем.
💯 ИИ меняет предпочтения и практики разработки
Данные Octoverse указывают на явную связь между внедрением AI-инструментов и эволюцией стека технологий разработчиков
- Начиная с 2025 года, рост популярности Python идёт почти параллельно с JavaScript/TypeScript, что свидетельствует об универсальном влиянии ИИ на разные экосистемы - от веб-разработки до анализа данных.
- Появляются новые подходы к работе с кодом, такие как "vibe coding"
- AI-ассистенты заметно снизили порог входа: если ИИ продолжит упрощать создание ПО, число людей, способных “кодить”, может резко возрасти
- На горизонте эра автономных помощников (AI agents). Уже появились инструменты, которые могут самостоятельно сгенерировать код, запустить тесты и даже открыть pull request для проверки человеком
В заключении погорим про мир open source и влиянии AI на продуктивность разработки, а также приведем выводы.
#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture
Продолжая рассказ про очередной ежегодный отчет от GitHub о состоянии экосистемы разработки софта на платформе, расскажу подробнее про его результаты.
📈 Беспрецедентный рост сообщества
- Платформа пополнилась более чем 36 миллионами новых разработчиков - это самый высокий абсолютный рост за всю историю наблюдений
- азработчики создали около 121 млн новых репозиториев за год (до 630 млн всего)
- Число коммитов достигло почти 1 миллиарда в 2025 году (+25% к 2024)
- Ежемесячно сливалось порядка 43,2 млн pull request’ов (+23% к 2024)
Такая динамика совпала с запуском бесплатной версии GitHub Copilot в конце 2024, которая привлекла волну новых пользователей и проектов.
🤖 ИИ стал неотъемлемой частью разработки
Генеративный ИИ за год превратился из новинки в стандартный инструмент разработчика.
- На GitHub уже насчитывается порядка 4,3 миллиона репозиториев, связанных с AI (расчет через проставление тегов репозиториям и выделение части тегов как относящихся к AI проектам).
- Свыше 1,1 млн публичных проектов используют SDK для работы с большими языковыми моделями (LLM) - и 693 тыс. из них созданы всего за последние 12 месяцев (рост +178% год к году)
- Новички сразу внедряют AI в работу: почти 80% новых разработчиков начинают использовать автодополнение GitHub Copilot уже в первую неделю работы с кодом
Всё это подтверждает, что ИИ-инструменты теперь ожидаемы “по умолчанию” в среде разработчиков. Рост использования AI-средств сопровождается и ростом вклада в код: за год было слито рекордные 518,7 млн pull request’ов (+29% к предыдущему году), а общее число вкладов в открытые проекты превысило 1,12 млрд (+13% г/г).
🚀 TypeScript вышел на 1-е место среди языков
Впервые за последнее десятилетие сменился лидер по популярности языков программирования на GitHub: в августе 2025 года TypeScript обогнал Python (а также давнего лидера JavaScript) и стал самым используемым языком на платформе. Стремительный рост TypeScript обусловлен сразу двумя факторами
1. Современные фронтенд-фреймворки (React, Angular и др.) генерируют шаблоны проектов на TS по умолчанию
2. Команды всё чаще предпочитают строго типизированный код при использовании ИИ: развитая типизация TypeScript делает автосгенерированный AI-код более надежным
За год сообщество TypeScript выросло на ≈1,05 млн разработчиков (+66% г/г), тогда как Python прибавил ~850 тыс. (+48% г/г). Несмотря на потерю первого места, Python остаётся ключевым языком для задач ИИ и науки о данных - у него 2,6 млн активных контрибьюторов, а Jupyter Notebook по-прежнему служит основной средой экспериментов (≈403 тыс. репозиториев внутри AI-проектов). Совокупно сообщества TypeScript и Python теперь насчитывают >5,2 млн разработчиков (около 3% всех активных пользователей GitHub).
Такой сдвиг подтверждает: ИИ влияет не только на скорость кодинга, но и на выбор технологий - команды охотнее доверяют AI-сгенерированный код языкам со строгой типизацией, особенно для продакшн-систем.
Данные Octoverse указывают на явную связь между внедрением AI-инструментов и эволюцией стека технологий разработчиков
- Начиная с 2025 года, рост популярности Python идёт почти параллельно с JavaScript/TypeScript, что свидетельствует об универсальном влиянии ИИ на разные экосистемы - от веб-разработки до анализа данных.
- Появляются новые подходы к работе с кодом, такие как "vibe coding"
- AI-ассистенты заметно снизили порог входа: если ИИ продолжит упрощать создание ПО, число людей, способных “кодить”, может резко возрасти
- На горизонте эра автономных помощников (AI agents). Уже появились инструменты, которые могут самостоятельно сгенерировать код, запустить тесты и даже открыть pull request для проверки человеком
В заключении погорим про мир open source и влиянии AI на продуктивность разработки, а также приведем выводы.
#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Книжный куб
[1/3] Octoverse 2025: A new developer joins GitHub every second as AI leads TypeScript to #1 (Рубрика #Engineering)
В конце октября появился очередной отчет Octoverse от GitHub, где авторы рассказывают про состояние дел в мире OSS (Open Source Software)…
В конце октября появился очередной отчет Octoverse от GitHub, где авторы рассказывают про состояние дел в мире OSS (Open Source Software)…
❤3⚡1🔥1
[3/3] Octoverse 2025: A new developer joins GitHub every second as AI leads TypeScript to #1 (Рубрика #Engineering)
В заключении разбора отчета от GitHub погорим про мир open source и влиянии AI на продуктивность разработки, а также приведем заключительные выводы
🌐 Open source в эпоху ИИ: рост и новые лидеры
- Активность в открытых репозиториях достигла исторических максимумов. В 2025 году было зафиксировано 1,128 млрд вкладов в публичные и open source-проекты (+13% г/г). В целом на GitHub уже 395 млн открытых репозиториев (+20% г/г), а за год сообщество слило 518,7 млн pull request’ов в публичных проектах (+29% г/г).
- Бурный рост связан, в том числе, с ИИ-бумом: 6 из 10 самых быстрорастущих проектов года - это инструменты для ИИ-инфраструктуры (фреймворки для запуска моделей, оркестрации и т.п.). Например, vllm, ollama, ComfyUI, Continue и т.д.
- При этом 60% из топ-10 самых популярных репозиториев по числу контрибьюторов тоже связаны с ИИ – сообщество вкладывается в базовые AI-библиотеки и движки вроде HuggingFace Transformers, llama.cpp, а также в AI-функции популярных инструментов (например, OpenAI Codex для VS Code)
- Но open source-экосистема не ограничивается одной лишь сферой AI. Рядом с взлётом ИИ-проектов сохраняют сильные позиции и классические направления: например, открытый игровой движок Godot, домашняя IoT-платформа Home Assistant и фреймворк Expo для мобильной разработки стабильно входят в топ проектов по числу контрибьюторов
- Анализ показывает, что помимо ИИ, разработчики проявляют повышенный интерес к инструментам повышения эффективности
-- Средствам для детерминированной сборки и управления зависимостями (Nix, UV) – “чтобы код работал на любой машине”
-- Высокопроизводительным фреймворкам (Tailwind CSS, Ghostty) для получения быстрых результатов
-- К проектам, дающим больший контроль над средой (например, защищённые браузеры как Zen Browser)
- Продолжается и тренд на децентрализацию соцсетей: успех платформы Bluesky показывает спрос на открытые протоколы и независимость
🚀 ИИ повышает продуктивность разработки.
2025-й ознаменовался скачком продуктивности: по всем ключевым метрикам разработчики стали делать больше и быстрее, отчасти благодаря новым AI-инструментам. Ежемесячно на GitHub теперь
- Закрывается ≈4,25 млн issue (против ~3,4 млн в 2024)
- Слияний pull request’ов стало 43,2 млн (против ~35 млн в 2024)
- Объём коммитов увеличился с ~65 млн до 82 млн в месяц
Весной 2025, после запуска превью Copilot “coding agent” (март) и релиза Copilot Code Review (апрель), эти показатели резко пошли вверх. В марте разработчики закрыли на 1,4 млн issue больше, чем в феврале, а в июле 2025 было закрыто рекордные 5,5 млн issue за месяц. Сами разработчики подтверждают эффективность AI-помощников: по результатам интервью, 72,6% пользователей Copilot Code Review сообщили, что авто-рекомендации ИИ улучшили их процесс ревью кода. В целом, рост активности (на +25–30% г/г по разным сигналам) говорит о том, что ИИ-инструменты не только экономят время при написании кода, но и позволяют быстрее доводить задачи до завершения, снижая "трение" в командной работе.
В общем, из этого отчета видно, что
- Сообщество разработчиков растёт и меняется стремительнее, чем когда-либо, и одна из главных причин - интеграция AI в ежедневную практику программирования
- Искусственный интеллект уже стал стандартным помощником, ускоряя развитие проектов и влияя на выбор языков (первое место TypeScript во многом обязано AI-трендам).
- AI-проекты захватывают центр внимания в open source сообществе, но одновременно экосистема остаётся многообразной: наряду с ИИ, востребованы инструменты для надёжных сборок, производительности и свободы пользователей
Дальше будует еще веселее - по мере развития AI-инструментов мы уже видим с какой скоростью меняется индустрия разработки софта и профессии инженеров, технических руководителей, продуктовых менеджеров и т.д. Жить в эпоху технологических революций жутко интересно:)
#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture
В заключении разбора отчета от GitHub погорим про мир open source и влиянии AI на продуктивность разработки, а также приведем заключительные выводы
- Активность в открытых репозиториях достигла исторических максимумов. В 2025 году было зафиксировано 1,128 млрд вкладов в публичные и open source-проекты (+13% г/г). В целом на GitHub уже 395 млн открытых репозиториев (+20% г/г), а за год сообщество слило 518,7 млн pull request’ов в публичных проектах (+29% г/г).
- Бурный рост связан, в том числе, с ИИ-бумом: 6 из 10 самых быстрорастущих проектов года - это инструменты для ИИ-инфраструктуры (фреймворки для запуска моделей, оркестрации и т.п.). Например, vllm, ollama, ComfyUI, Continue и т.д.
- При этом 60% из топ-10 самых популярных репозиториев по числу контрибьюторов тоже связаны с ИИ – сообщество вкладывается в базовые AI-библиотеки и движки вроде HuggingFace Transformers, llama.cpp, а также в AI-функции популярных инструментов (например, OpenAI Codex для VS Code)
- Но open source-экосистема не ограничивается одной лишь сферой AI. Рядом с взлётом ИИ-проектов сохраняют сильные позиции и классические направления: например, открытый игровой движок Godot, домашняя IoT-платформа Home Assistant и фреймворк Expo для мобильной разработки стабильно входят в топ проектов по числу контрибьюторов
- Анализ показывает, что помимо ИИ, разработчики проявляют повышенный интерес к инструментам повышения эффективности
-- Средствам для детерминированной сборки и управления зависимостями (Nix, UV) – “чтобы код работал на любой машине”
-- Высокопроизводительным фреймворкам (Tailwind CSS, Ghostty) для получения быстрых результатов
-- К проектам, дающим больший контроль над средой (например, защищённые браузеры как Zen Browser)
- Продолжается и тренд на децентрализацию соцсетей: успех платформы Bluesky показывает спрос на открытые протоколы и независимость
2025-й ознаменовался скачком продуктивности: по всем ключевым метрикам разработчики стали делать больше и быстрее, отчасти благодаря новым AI-инструментам. Ежемесячно на GitHub теперь
- Закрывается ≈4,25 млн issue (против ~3,4 млн в 2024)
- Слияний pull request’ов стало 43,2 млн (против ~35 млн в 2024)
- Объём коммитов увеличился с ~65 млн до 82 млн в месяц
Весной 2025, после запуска превью Copilot “coding agent” (март) и релиза Copilot Code Review (апрель), эти показатели резко пошли вверх. В марте разработчики закрыли на 1,4 млн issue больше, чем в феврале, а в июле 2025 было закрыто рекордные 5,5 млн issue за месяц. Сами разработчики подтверждают эффективность AI-помощников: по результатам интервью, 72,6% пользователей Copilot Code Review сообщили, что авто-рекомендации ИИ улучшили их процесс ревью кода. В целом, рост активности (на +25–30% г/г по разным сигналам) говорит о том, что ИИ-инструменты не только экономят время при написании кода, но и позволяют быстрее доводить задачи до завершения, снижая "трение" в командной работе.
В общем, из этого отчета видно, что
- Сообщество разработчиков растёт и меняется стремительнее, чем когда-либо, и одна из главных причин - интеграция AI в ежедневную практику программирования
- Искусственный интеллект уже стал стандартным помощником, ускоряя развитие проектов и влияя на выбор языков (первое место TypeScript во многом обязано AI-трендам).
- AI-проекты захватывают центр внимания в open source сообществе, но одновременно экосистема остаётся многообразной: наряду с ИИ, востребованы инструменты для надёжных сборок, производительности и свободы пользователей
Дальше будует еще веселее - по мере развития AI-инструментов мы уже видим с какой скоростью меняется индустрия разработки софта и профессии инженеров, технических руководителей, продуктовых менеджеров и т.д. Жить в эпоху технологических революций жутко интересно:)
#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Книжный куб
[1/3] Octoverse 2025: A new developer joins GitHub every second as AI leads TypeScript to #1 (Рубрика #Engineering)
В конце октября появился очередной отчет Octoverse от GitHub, где авторы рассказывают про состояние дел в мире OSS (Open Source Software)…
В конце октября появился очередной отчет Octoverse от GitHub, где авторы рассказывают про состояние дел в мире OSS (Open Source Software)…
❤7👍2🔥2
[1/2] Архитектура платформы Lovable (Рубрика AI)
Раньше я уже рассказывал историю стартапа Lovable, что вырос в оценке с нуля до $6.6 млрд всего за один год. А в этой серии постов я хотел рассказать про то, что умеет этот продукт и как концептуально выглядит его архитектура. История собрана на основании публичных выступлений представителей компании (типа таких), а также утечек промптов навроде такой. Кроме того, можно почитать исходники проекта, с которого начинался Lovable, а именно gpt-engineer (и точечно промпты оттуда).
⚙️ Технологический стек и инфраструктура
Платформа Lovable генерирует полноценный исходный код веб-приложений и опирается на современные веб-технологии:
- На фронте используется React/TypeScript, а для стилизации по умолчанию применяется Tailwind CSS и блоки дизайн-системы на основе shadcn/ui (на базе Radix), а для иконок - lucide-react
- Для управления данными на клиенте встроены современные инструменты, например React Query (TanStack) для работы с серверными данными
- Генерируемый код следует принятым практикам: компоненты небольшие (до ~50 строк), приложение сразу адаптивное (responsive) и структурировано в духе атомарного дизайна Atomic Design
На бэкенде Lovable интегрируется с Supabase - это облачная платформа на базе PostgreSQL, которая
- Предоставляет базу данных
- Аутентификацию пользователей
- Хранение файлов и серверлесс-функции
Благодаря этой интеграции Lovable может автоматически создавать таблицы БД, настроивать авторизацию и даже развёртывать серверный код (например, обработчики оплаты или обращения к внешним API) в виде Edge Functions Supabase. Интересно, что не только Lovable хорошо получил денег на дальнейшее развитие, но и Supabase получил суммарно $300 млн (Series D + E) - я рассказывал про это при обзоре "Databases in 2025: A Year in Review by Andy Pavlo "
В итоге, архитектура приложения, создаваемого в Lovable, выглядит так: фронтенд на React/TypeScript/Tailwind/Atomic Desing + Supabase-бэкенд. Все это генерируется и настраивается AI в рамках единого процесса, без необходимости вручную поднимать что-то. Одновременно это можно опубликовать прямо на поддомене *.lovable.app (или кастомном домене) и пошарить пользователям. Для всего это не нужно обладать техническими знаниями - справится даже продакт.
Во втором посте я расскажу про агентскую архитектуру + инфраструктуру и устройство самой платформы.
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
Раньше я уже рассказывал историю стартапа Lovable, что вырос в оценке с нуля до $6.6 млрд всего за один год. А в этой серии постов я хотел рассказать про то, что умеет этот продукт и как концептуально выглядит его архитектура. История собрана на основании публичных выступлений представителей компании (типа таких), а также утечек промптов навроде такой. Кроме того, можно почитать исходники проекта, с которого начинался Lovable, а именно gpt-engineer (и точечно промпты оттуда).
Платформа Lovable генерирует полноценный исходный код веб-приложений и опирается на современные веб-технологии:
- На фронте используется React/TypeScript, а для стилизации по умолчанию применяется Tailwind CSS и блоки дизайн-системы на основе shadcn/ui (на базе Radix), а для иконок - lucide-react
- Для управления данными на клиенте встроены современные инструменты, например React Query (TanStack) для работы с серверными данными
- Генерируемый код следует принятым практикам: компоненты небольшие (до ~50 строк), приложение сразу адаптивное (responsive) и структурировано в духе атомарного дизайна Atomic Design
На бэкенде Lovable интегрируется с Supabase - это облачная платформа на базе PostgreSQL, которая
- Предоставляет базу данных
- Аутентификацию пользователей
- Хранение файлов и серверлесс-функции
Благодаря этой интеграции Lovable может автоматически создавать таблицы БД, настроивать авторизацию и даже развёртывать серверный код (например, обработчики оплаты или обращения к внешним API) в виде Edge Functions Supabase. Интересно, что не только Lovable хорошо получил денег на дальнейшее развитие, но и Supabase получил суммарно $300 млн (Series D + E) - я рассказывал про это при обзоре "Databases in 2025: A Year in Review by Andy Pavlo "
В итоге, архитектура приложения, создаваемого в Lovable, выглядит так: фронтенд на React/TypeScript/Tailwind/Atomic Desing + Supabase-бэкенд. Все это генерируется и настраивается AI в рамках единого процесса, без необходимости вручную поднимать что-то. Одновременно это можно опубликовать прямо на поддомене *.lovable.app (или кастомном домене) и пошарить пользователям. Для всего это не нужно обладать техническими знаниями - справится даже продакт.
Во втором посте я расскажу про агентскую архитектуру + инфраструктуру и устройство самой платформы.
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6🔥6⚡1
[2/2] Архитектура платформы Lovable (Рубрика AI)
Продолжая рассказ про архитектуру Lovable расскажу про агентский workflow + инфраструктуру и устройство самой платформы.
🤖 AI-движок и агентская архитектура
В основе Lovable – мощные модели генерации кода на естественном языке. Платформа использует несколько крупных языковых моделей (LLM) от ведущих провайдеров для кодогенерации(в 2025 году говорилось про модели от OpenAI и Anthropic). Особенностью Lovable является агентная архитектура AI (кстати: сам workflow можно увидеть в системном промпте, также полезно глянуть промпт с описанием инструментов)
- Система не просто дописывает код построчно, а воспринимает проект целиком и планирует решение прежде, чем писать код
- Сначала система анализирует запрос пользователя и формирует план приложения, затем пошагово генерирует фронтэнд, бэкэнд, API и даже документацию в соответствии с этим планом
Такой подход "смотрит на приложение в целом" позволяет получить согласованную архитектуру проекта и избежать ситуаций, когда AI ломается на середине задачи. Например, в этом обзоре отмечается, что Lovable способен из одного промпта создать полнофункциональный прототип (UI, база данных, авторизация, API) за считанные часы. Это стало возможным благодаря тому, что AI-агент “понимает” спецификацию целиком перед кодированием.
🚀 Инфраструктура платформы
- Сам сервис Lovable представляет собой облачное веб-приложение с собственным редактором и механизмом генерации кода. Фронтенд платформы (интерфейс, с которым работает пользователь) вероятно тоже написан на React/TS.
- Для хранения проектов и контроля версий Lovable использует интеграцию с Git-репозиториями. Каждому проекту соответствует репозиторий исходного кода: изменения, которые вносит AI, автоматически коммитятся, и пользователь при желании может подключить GitHub и синхронизировать проект для работы вне Lovable. Такая архитектура обеспечивает full code ownership: разработчик может в любой момент вывести код из платформы, продолжить работу локально и развернуть на своей инфраструктуре
- Масштабируемость обеспечивается за счёт вышеупомянутых облачных сервисов - Supabase берёт на себя хранение данных и выполнение серверных функций, а для хостинга фронтенда можно задействовать, например, Netlify или встроенный хостинг Lovable.
- Платформа генерирует проект как набор реальных файлов (включая package.json со всеми зависимостями, README и т.д.), поэтому развёртывание не требует проприетарного рантайма - код совместим с обычными Node.js-инструментами. В FAQ Lovable подчёркивается, что сгенерированный код продакшен-готов и следует лучшим практикам по масштабируемости, безопасности и поддерживаемости.
В будущем я еще расскажу про то, как выглядит процесс работы с Lovable и что происходит под капотом.
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
Продолжая рассказ про архитектуру Lovable расскажу про агентский workflow + инфраструктуру и устройство самой платформы.
В основе Lovable – мощные модели генерации кода на естественном языке. Платформа использует несколько крупных языковых моделей (LLM) от ведущих провайдеров для кодогенерации(в 2025 году говорилось про модели от OpenAI и Anthropic). Особенностью Lovable является агентная архитектура AI (кстати: сам workflow можно увидеть в системном промпте, также полезно глянуть промпт с описанием инструментов)
- Система не просто дописывает код построчно, а воспринимает проект целиком и планирует решение прежде, чем писать код
- Сначала система анализирует запрос пользователя и формирует план приложения, затем пошагово генерирует фронтэнд, бэкэнд, API и даже документацию в соответствии с этим планом
Такой подход "смотрит на приложение в целом" позволяет получить согласованную архитектуру проекта и избежать ситуаций, когда AI ломается на середине задачи. Например, в этом обзоре отмечается, что Lovable способен из одного промпта создать полнофункциональный прототип (UI, база данных, авторизация, API) за считанные часы. Это стало возможным благодаря тому, что AI-агент “понимает” спецификацию целиком перед кодированием.
- Сам сервис Lovable представляет собой облачное веб-приложение с собственным редактором и механизмом генерации кода. Фронтенд платформы (интерфейс, с которым работает пользователь) вероятно тоже написан на React/TS.
- Для хранения проектов и контроля версий Lovable использует интеграцию с Git-репозиториями. Каждому проекту соответствует репозиторий исходного кода: изменения, которые вносит AI, автоматически коммитятся, и пользователь при желании может подключить GitHub и синхронизировать проект для работы вне Lovable. Такая архитектура обеспечивает full code ownership: разработчик может в любой момент вывести код из платформы, продолжить работу локально и развернуть на своей инфраструктуре
- Масштабируемость обеспечивается за счёт вышеупомянутых облачных сервисов - Supabase берёт на себя хранение данных и выполнение серверных функций, а для хостинга фронтенда можно задействовать, например, Netlify или встроенный хостинг Lovable.
- Платформа генерирует проект как набор реальных файлов (включая package.json со всеми зависимостями, README и т.д.), поэтому развёртывание не требует проприетарного рантайма - код совместим с обычными Node.js-инструментами. В FAQ Lovable подчёркивается, что сгенерированный код продакшен-готов и следует лучшим практикам по масштабируемости, безопасности и поддерживаемости.
В будущем я еще расскажу про то, как выглядит процесс работы с Lovable и что происходит под капотом.
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6🔥5👍2
[1/2] John Schulman on dead ends, scaling RL, and building research institutions (Рубрика #AI)
Посмотрел очередной эпизод подкаста "Cafe Cursor", в котором общались Michael Truell и John Schulman. Майкл - это со-основатель Cursor, а John - со-основатель OpenAI и человек, предложивший RLHF (reinforcement learning from human feedback), технологию, лежащую в основе ChatGPT. Сейчас Джлн в Thinking Machines в роли chief scientist. В этом подкасте Джон делится инсайтами о том, как всё было устроено в OpenAI с 2016 года, что пошло не так, и куда движется reinforcement learning. Основные моменты интервью ниже
1️⃣ Speedrunning ChatGPT: могли бы сделать в 2018
Шульман считает, что с полным hindsight ChatGPT-3.5 можно было собрать ещё в 2018–2019 силами 2–3 человек на паре GPU-боксов. Секрет не в масштабе compute, а в умном post-training: правильный fine-tuning датасет компенсирует меньшую модель. Сравнивает с nanoGPT (один человек, один бокс, полгода). Вывод: масштабирование важно, но умные трюк > брут форса.
2️⃣ Ранний OpenAI
В 2016–2017 OpenAI был как академическая группа люди работали по 1–3 человека над whitepapers по своему вкусу. Например, был интересный проект Universe как попытка создать универсального RL-агента на сотнях видеоигр и веб-задач. Идея была правильной, но на 10 лет опередила время - тогда модели не генерализовались, система была неукдюжей. Позже пришли результаты в Dota и Procgen (эмуляция игр). Направление роботов тогда тоже было тупиковым, но полезным - оно прокачало команду на больших engineering-проектах и обучило людей системной работе.
3️⃣ Почему value functions не в моде?
В современном RLHF и verifiable rewards (даже на 10k+ токенов) функции ценности (value functions) не сокращают вариативность. Шульман ждёт их камбека, но пока Policy Gradient-методы побеждают на коротких горизонтах.[1]
4️⃣ Continual learning: long context + LoRA
По мнению Джона для непрерывного обучения нужны два фактора
1. In-context learning (long context) - для быстрого, short-horizon.
2. Parameter fine-tuning (LoRA) - для long-horizon knowledge, требующего ёмкости.
Scaling может решить проблему и без новых идей, но Шульман ждёт прорывов, которые сдвинут scaling laws.
5️⃣ Brittle generalization: люди vs модели
Модели круты in-context (как люди), но хуже на длинных горизонтах - застревают, где человек способен к само-коррекции. Почему? Люди заточены эволюцией на 80-летний таймлайн. Неясно, это временное или фундаментальное ограничение. Тестировать на десятилетия эквивалентно запуску evals на декады, что проблематично
6️⃣ Будущее reinforcement learning: GANs 2.0 и multi-agent игры
Шульман ждёт возврата идей из 2010-х:
- Co-training generators + verifiers (как GANs) - это про самоусиливайщийся цикл: лучше reasoning → лучше verifier → лучше generator.[1]
- Multi-agent games** (zero-sum/debate) - автоматический curriculum + теоретические гарантии из complexity theory (polynomial judge создаёт стимулы для сложных проблем (условно, NP-проблем)). Debate game от OpenAI/Anthropic - недооценённая идея.
В продолжении я расскажу про другие интересные тезисы, навроде подходов к руководству исследованиями или замедления получения прорывных результатов.
#Engineering #AI #Metrics #Software #Architecture #RnD #ML
Посмотрел очередной эпизод подкаста "Cafe Cursor", в котором общались Michael Truell и John Schulman. Майкл - это со-основатель Cursor, а John - со-основатель OpenAI и человек, предложивший RLHF (reinforcement learning from human feedback), технологию, лежащую в основе ChatGPT. Сейчас Джлн в Thinking Machines в роли chief scientist. В этом подкасте Джон делится инсайтами о том, как всё было устроено в OpenAI с 2016 года, что пошло не так, и куда движется reinforcement learning. Основные моменты интервью ниже
1️⃣ Speedrunning ChatGPT: могли бы сделать в 2018
Шульман считает, что с полным hindsight ChatGPT-3.5 можно было собрать ещё в 2018–2019 силами 2–3 человек на паре GPU-боксов. Секрет не в масштабе compute, а в умном post-training: правильный fine-tuning датасет компенсирует меньшую модель. Сравнивает с nanoGPT (один человек, один бокс, полгода). Вывод: масштабирование важно, но умные трюк > брут форса.
2️⃣ Ранний OpenAI
В 2016–2017 OpenAI был как академическая группа люди работали по 1–3 человека над whitepapers по своему вкусу. Например, был интересный проект Universe как попытка создать универсального RL-агента на сотнях видеоигр и веб-задач. Идея была правильной, но на 10 лет опередила время - тогда модели не генерализовались, система была неукдюжей. Позже пришли результаты в Dota и Procgen (эмуляция игр). Направление роботов тогда тоже было тупиковым, но полезным - оно прокачало команду на больших engineering-проектах и обучило людей системной работе.
3️⃣ Почему value functions не в моде?
В современном RLHF и verifiable rewards (даже на 10k+ токенов) функции ценности (value functions) не сокращают вариативность. Шульман ждёт их камбека, но пока Policy Gradient-методы побеждают на коротких горизонтах.[1]
4️⃣ Continual learning: long context + LoRA
По мнению Джона для непрерывного обучения нужны два фактора
1. In-context learning (long context) - для быстрого, short-horizon.
2. Parameter fine-tuning (LoRA) - для long-horizon knowledge, требующего ёмкости.
Scaling может решить проблему и без новых идей, но Шульман ждёт прорывов, которые сдвинут scaling laws.
5️⃣ Brittle generalization: люди vs модели
Модели круты in-context (как люди), но хуже на длинных горизонтах - застревают, где человек способен к само-коррекции. Почему? Люди заточены эволюцией на 80-летний таймлайн. Неясно, это временное или фундаментальное ограничение. Тестировать на десятилетия эквивалентно запуску evals на декады, что проблематично
6️⃣ Будущее reinforcement learning: GANs 2.0 и multi-agent игры
Шульман ждёт возврата идей из 2010-х:
- Co-training generators + verifiers (как GANs) - это про самоусиливайщийся цикл: лучше reasoning → лучше verifier → лучше generator.[1]
- Multi-agent games** (zero-sum/debate) - автоматический curriculum + теоретические гарантии из complexity theory (polynomial judge создаёт стимулы для сложных проблем (условно, NP-проблем)). Debate game от OpenAI/Anthropic - недооценённая идея.
В продолжении я расскажу про другие интересные тезисы, навроде подходов к руководству исследованиями или замедления получения прорывных результатов.
#Engineering #AI #Metrics #Software #Architecture #RnD #ML
YouTube
John Schulman on dead ends, scaling RL, and building research institutions
A conversation with John Schulman on the first year LLMs could have been useful, building research teams, and where RL goes from here.
00:00 - Speedrunning ChatGPT
09:22 - Archetypes of research managers
11:56 - Was OpenAI inspired by Bell Labs?
16:54 -…
00:00 - Speedrunning ChatGPT
09:22 - Archetypes of research managers
11:56 - Was OpenAI inspired by Bell Labs?
16:54 -…
❤5👍5🔥2
[2/2] John Schulman on dead ends, scaling RL, and building research institutions (Рубрика #AI)
Продолжая рассказ об этом крутом интервью, хочется рассказать о тезисах, что связаны с руководством исследовательскими командами, а также подсветить основные мысли, что показались мне полезными.
7️⃣ Как строить исследовательские команды: hands-on vs hands-off
Интересные размышления про архетипы руководителей исследований
- Hands-on (кодит, читает код, deep technical feedback) - он ориентирован на проекты для достижения целей, может рулить командами с начинающими специалистами, работает в режиме execution этого проекта
- Hands-off (работает как консультант, дает советы по карьере, мотивирует) - больше работает в формате exploratory research, а в команде должны быть senior люди
Но основной ключ в адаптивности - исследования меняются и что работало 7 лет назад, может не сработать сейчас. Ранний OpenAI был peacetime (exploratory), новые labs (Thinking Machines) - wartime (надо догнать SOTA (state of the art результаты) + выстроить исследовательскую культуру)
8️⃣ День из жизни исследователя
Шульман работает в кофейнях (шум вокруг + ноутбук + идеи), потом execution: код, review docs/plots/код коллег. Использует Cursor и Claude Code для кодинга, GPT-5 Pro для литературы/детализации идей/обратной связи по поводу написания. Совет от Джона: держите research notebook (ещё важнее с LLM для контекста)
9️⃣Замедление прогресса: 10x исследователей ≠ 10x идей
За 10 лет число ML-researchers выросло в 10–100x, но "consequential" идеи (типа scaling laws) не ускорились. Причины:
- Низковисящие результаты исчерпаны
- Выше уровень (больше baselines, экспериментов)
- Сдвиг типов: раньше был рисковые люди, а сейчас более традиционные (engineering > research taste)
Но качество растёт: старые papers (70–90-е) имели слабую строгость.
🔟 Thinking Machines: philosophy и Tinker
Новая лаборатория Шульмана. Философия не только в том, чтобы догнать SOTA, но и прокачать исследовательскую мышцу и заложить культур. У этой лабы уже есть инструмент Tinker - low-level API для fine-tuning (Python scripts без GPU hassle), для продвинутых ML-инженеров. План эволюционировать в full-stack продукт для менее продвинутых инженеров.
Мне показалось это интересным с разных сторон
1. Для лидеров тут есть идеи про переключение между hands-on и hands-off в зависимости от фазы проекта и зрелости людей
2. Для инженеров объяснение, что ИИ-лаборатории это не магия - в работе много тупиков, предвзятости и то, что культура важнее процессов.
3. Для исследователей есть мысли про возвращение RL (verifiers, multi-agent), про движение в сторону непрерывного обучения, а также про важность новых исследований даже во время работы законов масштабирования (которые говорят, что больше данных и больше GPU - лучше результат)
#Engineering #AI #Metrics #Software #Architecture #RnD #ML
Продолжая рассказ об этом крутом интервью, хочется рассказать о тезисах, что связаны с руководством исследовательскими командами, а также подсветить основные мысли, что показались мне полезными.
7️⃣ Как строить исследовательские команды: hands-on vs hands-off
Интересные размышления про архетипы руководителей исследований
- Hands-on (кодит, читает код, deep technical feedback) - он ориентирован на проекты для достижения целей, может рулить командами с начинающими специалистами, работает в режиме execution этого проекта
- Hands-off (работает как консультант, дает советы по карьере, мотивирует) - больше работает в формате exploratory research, а в команде должны быть senior люди
Но основной ключ в адаптивности - исследования меняются и что работало 7 лет назад, может не сработать сейчас. Ранний OpenAI был peacetime (exploratory), новые labs (Thinking Machines) - wartime (надо догнать SOTA (state of the art результаты) + выстроить исследовательскую культуру)
8️⃣ День из жизни исследователя
Шульман работает в кофейнях (шум вокруг + ноутбук + идеи), потом execution: код, review docs/plots/код коллег. Использует Cursor и Claude Code для кодинга, GPT-5 Pro для литературы/детализации идей/обратной связи по поводу написания. Совет от Джона: держите research notebook (ещё важнее с LLM для контекста)
9️⃣Замедление прогресса: 10x исследователей ≠ 10x идей
За 10 лет число ML-researchers выросло в 10–100x, но "consequential" идеи (типа scaling laws) не ускорились. Причины:
- Низковисящие результаты исчерпаны
- Выше уровень (больше baselines, экспериментов)
- Сдвиг типов: раньше был рисковые люди, а сейчас более традиционные (engineering > research taste)
Но качество растёт: старые papers (70–90-е) имели слабую строгость.
🔟 Thinking Machines: philosophy и Tinker
Новая лаборатория Шульмана. Философия не только в том, чтобы догнать SOTA, но и прокачать исследовательскую мышцу и заложить культур. У этой лабы уже есть инструмент Tinker - low-level API для fine-tuning (Python scripts без GPU hassle), для продвинутых ML-инженеров. План эволюционировать в full-stack продукт для менее продвинутых инженеров.
Мне показалось это интересным с разных сторон
1. Для лидеров тут есть идеи про переключение между hands-on и hands-off в зависимости от фазы проекта и зрелости людей
2. Для инженеров объяснение, что ИИ-лаборатории это не магия - в работе много тупиков, предвзятости и то, что культура важнее процессов.
3. Для исследователей есть мысли про возвращение RL (verifiers, multi-agent), про движение в сторону непрерывного обучения, а также про важность новых исследований даже во время работы законов масштабирования (которые говорят, что больше данных и больше GPU - лучше результат)
#Engineering #AI #Metrics #Software #Architecture #RnD #ML
Telegram
Книжный куб
[1/2] John Schulman on dead ends, scaling RL, and building research institutions (Рубрика #AI)
Посмотрел очередной эпизод подкаста "Cafe Cursor", в котором общались Michael Truell и John Schulman. Майкл - это со-основатель Cursor, а John - со-основатель…
Посмотрел очередной эпизод подкаста "Cafe Cursor", в котором общались Michael Truell и John Schulman. Майкл - это со-основатель Cursor, а John - со-основатель…
❤5👍3🔥2
Lovable - как выглядит работа с продуктом (Рубрика #AI)
Я уже рассказывал про историю lovable и подход к архитектуре, а сегодня расскажу про то, как lovable популяризирует vibe-coding продуктов, когда вместо написания кода на языках программирования пользователь описывает желаемый функционал простым языком, а AI-инструмент генерирует программный код. Слоган платформы "No code. Just vibes." отражает идею, что для создания приложения достаточно сформулировать замысел и "атмосферу" продукта словами, остальное выполнит AI. Такой способ разработки особенно привлекателен для креативных непрограммистов (условных продуктовых менеджеров или основателей стартапов).
🤖 UX платформы и взаимодействие с AI
Интерфейс Lovable построен вокруг чат-коммуникации с AI-инженером. Пользователь создаёт новый проект и видит окно чата, куда можно ввести первый промпт с описанием приложения (например, какие страницы, какая функциональность нужны). AI проанализирует запрос и начнёт выдавать результат: он может отвечать частями, создавая код и описывая свои действия. Важно код генерируется и меняется в реальном времени – параллельно с общением. В рабочей области рядом с чатом отображается живой превью-приложения (iframe), которое автоматически перезагружается по мере добавления кода. Таким образом, пользователь буквально видит как его слова превращаются в работающий интерфейс.
Для инженеров в платформе есть возможность просматривать и редактировать исходный код напрямую - есть встроенный редактор кода с файловой структурой проекта, так что опытные разработчики могут вручную поправить что-то или изучить сгенерированный код. Но для разработчиков конечно интереснее возможность сделать двухстороннюю синхронизацию кода с GitHub и менять код своим привычным способом.
⚙️ Дополнительные возможности AI-редактора
Lovable снабжён рядом инструментов, делающих "vibe-кодинг" более эффективным
1. AI-агент имеет доступ к консольным логам приложения - это позволяет замкнуть агенту обратную связь и обрабатывать ошибки из браузерной консоли. То есть, если сгенерированный код упал с ошибкой или что-то не работает, модель увидит трассировку и может сразу предложить исправление, дебаггая приложение в реальном времени
2. У пользователя есть возможность загружать в проект файлы (например, изображения) или подключать сторонние API-ключи, а AI умеет ими пользоваться
3. Платформа поддерживает режим “Custom Knowledge” – пользователь может предоставить собственные данные или документацию в базе знаний проекта, чтобы AI их учитывал. Например, можно добавить текстовый документ с описанием бизнес-логики или UI-гайдов, и модель будет обращаться к нему при генерации
Всё это превращает процесс разработки в диалог с "умным напарником": вы описываете задачу или проблему, AI предлагает решение, пишет код, объясняет свои действия.
♿️ Ограничения и лучшие практики
Хотя vibe-coding заметно ускоряет разработку, пользователям нужно научиться правильно формулировать запросы и разбивать работу на этапы. Разработчики отмечают, что чрезмерно общие или расплывчатые промпты могут привести к неудачным решениям и потребовать многократных исправлений. Лучший подход - чётко описывать требования и даже прописывать план (страницы, функции, данные) перед тем как просить AI писать код. Опыт показывает, что не стоит пытаться “завайбкодить” сразу всё приложение одним сообщением, особенно если там сложная бизнес-логика. В целом же vibe-кодинг в Lovable - это про быстрые итерации и взаимодействие: пользователь задаёт направление и оценивает результат, AI предлагает реализацию. Такой цикл может многократно повторяться (платформа не ограничена одним промптом - вы продолжаете диалог сколько нужно), благодаря чему даже сложные приложения рождаются через серию уточнений и улучшений, как если бы вы вели разговор с живыми разработчиками.
P.S.
Скетч на картинке не совсем повторяет интерфейс продукта - скорее он показывает как все части связаны между собой.
#AI #Software #Engineering #Future #Architecture #Startup
Я уже рассказывал про историю lovable и подход к архитектуре, а сегодня расскажу про то, как lovable популяризирует vibe-coding продуктов, когда вместо написания кода на языках программирования пользователь описывает желаемый функционал простым языком, а AI-инструмент генерирует программный код. Слоган платформы "No code. Just vibes." отражает идею, что для создания приложения достаточно сформулировать замысел и "атмосферу" продукта словами, остальное выполнит AI. Такой способ разработки особенно привлекателен для креативных непрограммистов (условных продуктовых менеджеров или основателей стартапов).
Интерфейс Lovable построен вокруг чат-коммуникации с AI-инженером. Пользователь создаёт новый проект и видит окно чата, куда можно ввести первый промпт с описанием приложения (например, какие страницы, какая функциональность нужны). AI проанализирует запрос и начнёт выдавать результат: он может отвечать частями, создавая код и описывая свои действия. Важно код генерируется и меняется в реальном времени – параллельно с общением. В рабочей области рядом с чатом отображается живой превью-приложения (iframe), которое автоматически перезагружается по мере добавления кода. Таким образом, пользователь буквально видит как его слова превращаются в работающий интерфейс.
Для инженеров в платформе есть возможность просматривать и редактировать исходный код напрямую - есть встроенный редактор кода с файловой структурой проекта, так что опытные разработчики могут вручную поправить что-то или изучить сгенерированный код. Но для разработчиков конечно интереснее возможность сделать двухстороннюю синхронизацию кода с GitHub и менять код своим привычным способом.
Lovable снабжён рядом инструментов, делающих "vibe-кодинг" более эффективным
1. AI-агент имеет доступ к консольным логам приложения - это позволяет замкнуть агенту обратную связь и обрабатывать ошибки из браузерной консоли. То есть, если сгенерированный код упал с ошибкой или что-то не работает, модель увидит трассировку и может сразу предложить исправление, дебаггая приложение в реальном времени
2. У пользователя есть возможность загружать в проект файлы (например, изображения) или подключать сторонние API-ключи, а AI умеет ими пользоваться
3. Платформа поддерживает режим “Custom Knowledge” – пользователь может предоставить собственные данные или документацию в базе знаний проекта, чтобы AI их учитывал. Например, можно добавить текстовый документ с описанием бизнес-логики или UI-гайдов, и модель будет обращаться к нему при генерации
Всё это превращает процесс разработки в диалог с "умным напарником": вы описываете задачу или проблему, AI предлагает решение, пишет код, объясняет свои действия.
♿️ Ограничения и лучшие практики
Хотя vibe-coding заметно ускоряет разработку, пользователям нужно научиться правильно формулировать запросы и разбивать работу на этапы. Разработчики отмечают, что чрезмерно общие или расплывчатые промпты могут привести к неудачным решениям и потребовать многократных исправлений. Лучший подход - чётко описывать требования и даже прописывать план (страницы, функции, данные) перед тем как просить AI писать код. Опыт показывает, что не стоит пытаться “завайбкодить” сразу всё приложение одним сообщением, особенно если там сложная бизнес-логика. В целом же vibe-кодинг в Lovable - это про быстрые итерации и взаимодействие: пользователь задаёт направление и оценивает результат, AI предлагает реализацию. Такой цикл может многократно повторяться (платформа не ограничена одним промптом - вы продолжаете диалог сколько нужно), благодаря чему даже сложные приложения рождаются через серию уточнений и улучшений, как если бы вы вели разговор с живыми разработчиками.
P.S.
Скетч на картинке не совсем повторяет интерфейс продукта - скорее он показывает как все части связаны между собой.
#AI #Software #Engineering #Future #Architecture #Startup
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥3👍2