[1/2] Hard Won Lessons from Building Effective AI Coding Agents (Рубрика #Agents)
Интересный доклад от Nik Pash, Head of AI в Cline с основной мыслью в том, что надо перестать усложнять или почему умный scaffolding убивает AI-агентов. До Cline Ник работал инженером в Meta Reality Labs (2019-2021), Yandex (Image Search), Samsung Electronics. Основные тезисы доклада следующие
1️⃣ Горькая правда в том, что scaffolding устарел
Годами разработчики компенсировали слабость моделей clever scaffolding'ом: RAG-индексацией, search trees, хитрыми системами tool calling. Проблема в том, что сейчас frontier-модели побеждают без этих абстракций. То есть capability beats scaffolding. Ник приводит пример Gemini 3.0, что вышел недавно и сразу возглавил Terminal-Bench leaderboard с результатом 54.2% без какой-то агентской обвязки (если глянуть сейчас, то в лидер борде впереди все-таки agentic + model комбинации). Кстати, Terminal-Bench — это интересный "unopinionated generic stripped down harness". Там нет никакого graph search, RAG, индексации — только терминал и задача "разберись сам"
2️⃣ Context engineering tricks — played out
Ник откровенно говорит, что вместо отдельных трюков для контекста теперь есть стандартный playbook для поддержки каждой новой модели (Sonnet 4 → 4.5, Gemini 2.5 → 3.0, GPT-5 → 5.1). Tweaks тривиальны, выигрыши маргинальны. По мнению Ника эта тема исчерпана. Новизны в ней не осталось.
3️⃣ Настоящий bottleneck — это бенчмарки и среды для RL (reinforcement learning)
Собственно тут зарыта основная мысль доклада: можно построить cleanest agent в мире, но это не улучшит capability модели даже на 1%. Ник говорит
По его мнению модели не "вдруг стали лучше" в использовании инструментов — они стали лучше, потому что построены RL environments, которые заставили их практиковать конкретные действия: обработку моделей отказов, повторов, обработки ошибок. Каждый скачок в reasoning пришел из benchmark'а. Каждый скачок в agent reliability — из RL environment.
Дальше Ник рассказывает как превратить задачи реального мира в данные для тренировок. Cline построил систему под названием "RL Environments Factory" — pipeline для автоматического превращения реальных coding задач в RL environments для обучения моделей. Выглядит это так
Phase 1: Qualification — фильтрация задач
Sub-агенты работают параллельно, проверяя, подходит ли задача для превращения в RL environment:
- Origins: существует ли репозиторий? Доступен ли starting commit? Open source?
- Journey: что пользователь на самом деле пытался решить? Какова была суть задачи?
- Outcome: можем ли найти commits/PRs, которые решили проблему в реальности?
Откидываются задачи вида: вайбкодинговвый slop, тривиальные задачи, задачи без надежных start/end states[4]
Phase 2: Building RL Environment
- Archaeology: реконструировать оба состояния (до/после) локально
- Documentation: задокументировать все obstacles и dependencies
- Containerization: упаковать в Docker, убрать Git (чтобы агенты не могли reward hack)
- Verifier: определить, как проверять результат
Интересно, что примерно этим же подходом пользовались ребята из whitepaper "Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks", о котором я рассказывал раньше.
4️⃣ Все делают RL environments но никто ими не делится
И тут Ник открыто говорит о том, что каждая крупная agent lab собирает эти данные, то есть все делают какую-то версию RL environment building за кулисами. Но никто не говорит об этом. Эти компании ссылаются на internal benchmarks, но вы никогда не сможете их изучить, потому что они не публикуют их открыто. Эти данные настолько ценны, что их никто не шарит. Agent labs стоят между реальными инженерами, работающими над реальными задачами, и моделями — у них уникальная роль в истории.
В продолжении я расскажу, а что предлагают ребята из Cline, чтобы улучшить ситуацию
#AI #ML #Agents #Software #Engineering #Architecture
Интересный доклад от Nik Pash, Head of AI в Cline с основной мыслью в том, что надо перестать усложнять или почему умный scaffolding убивает AI-агентов. До Cline Ник работал инженером в Meta Reality Labs (2019-2021), Yandex (Image Search), Samsung Electronics. Основные тезисы доклада следующие
1️⃣ Горькая правда в том, что scaffolding устарел
Годами разработчики компенсировали слабость моделей clever scaffolding'ом: RAG-индексацией, search trees, хитрыми системами tool calling. Проблема в том, что сейчас frontier-модели побеждают без этих абстракций. То есть capability beats scaffolding. Ник приводит пример Gemini 3.0, что вышел недавно и сразу возглавил Terminal-Bench leaderboard с результатом 54.2% без какой-то агентской обвязки (если глянуть сейчас, то в лидер борде впереди все-таки agentic + model комбинации). Кстати, Terminal-Bench — это интересный "unopinionated generic stripped down harness". Там нет никакого graph search, RAG, индексации — только терминал и задача "разберись сам"
2️⃣ Context engineering tricks — played out
Ник откровенно говорит, что вместо отдельных трюков для контекста теперь есть стандартный playbook для поддержки каждой новой модели (Sonnet 4 → 4.5, Gemini 2.5 → 3.0, GPT-5 → 5.1). Tweaks тривиальны, выигрыши маргинальны. По мнению Ника эта тема исчерпана. Новизны в ней не осталось.
3️⃣ Настоящий bottleneck — это бенчмарки и среды для RL (reinforcement learning)
Собственно тут зарыта основная мысль доклада: можно построить cleanest agent в мире, но это не улучшит capability модели даже на 1%. Ник говорит
Models only get better when labs train on something hard. And benchmarks, not agent cleverness... determine what frontier models learn to do next.
По его мнению модели не "вдруг стали лучше" в использовании инструментов — они стали лучше, потому что построены RL environments, которые заставили их практиковать конкретные действия: обработку моделей отказов, повторов, обработки ошибок. Каждый скачок в reasoning пришел из benchmark'а. Каждый скачок в agent reliability — из RL environment.
Дальше Ник рассказывает как превратить задачи реального мира в данные для тренировок. Cline построил систему под названием "RL Environments Factory" — pipeline для автоматического превращения реальных coding задач в RL environments для обучения моделей. Выглядит это так
Phase 1: Qualification — фильтрация задач
Sub-агенты работают параллельно, проверяя, подходит ли задача для превращения в RL environment:
- Origins: существует ли репозиторий? Доступен ли starting commit? Open source?
- Journey: что пользователь на самом деле пытался решить? Какова была суть задачи?
- Outcome: можем ли найти commits/PRs, которые решили проблему в реальности?
Откидываются задачи вида: вайбкодинговвый slop, тривиальные задачи, задачи без надежных start/end states[4]
Phase 2: Building RL Environment
- Archaeology: реконструировать оба состояния (до/после) локально
- Documentation: задокументировать все obstacles и dependencies
- Containerization: упаковать в Docker, убрать Git (чтобы агенты не могли reward hack)
- Verifier: определить, как проверять результат
Интересно, что примерно этим же подходом пользовались ребята из whitepaper "Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks", о котором я рассказывал раньше.
4️⃣ Все делают RL environments но никто ими не делится
И тут Ник открыто говорит о том, что каждая крупная agent lab собирает эти данные, то есть все делают какую-то версию RL environment building за кулисами. Но никто не говорит об этом. Эти компании ссылаются на internal benchmarks, но вы никогда не сможете их изучить, потому что они не публикуют их открыто. Эти данные настолько ценны, что их никто не шарит. Agent labs стоят между реальными инженерами, работающими над реальными задачами, и моделями — у них уникальная роль в истории.
В продолжении я расскажу, а что предлагают ребята из Cline, чтобы улучшить ситуацию
#AI #ML #Agents #Software #Engineering #Architecture
❤5👍3❤🔥2
[2/2] Hard Won Lessons from Building Effective AI Coding Agents (Рубрика #Agents)
Продолжая рассказ про этот доклад, надо рассказать про Cline-Bench - open source benchmark для реальных задач, который анонсирует Cline. Каждая задача внутри бенча это:
- Starting repo snapshot (git commit hash)
- Real prompt from user
- Ground truth tests на основе кода, который реально зашипился
Этот бенч
- Полностью open source, no secret sauce, no locked datasets
- Любой может использовать для SFT, RL, eval
- Любой может поучаствовать
Как контрибьютить
1. Работайте над open source проектом с включенным Cline Provider
2. Opt into cline-bench initiative
3. Если frontier model застрял и вы вмешались, чтобы починить — это идеальный кандидат для benchmark
В общем, просто используйте Cline, наблюдайте, где модель struggles, и Cline подберет эти задачи в open-source benchmark.
P.S.
Если подбивать мысли из доклада, то можно вынести следующее
1. Для инженеров, использующих AI coding agents
- Перестаньте over-engineering scaffolding. Проще = лучше
- Фокусируйтесь на capability модели, а не на умных абстракциях
- Ваши real-world failure cases — самые ценные данные для экосистемы
- Contribution в open benchmarks помогает всем
2. Для исследователей и разработчиков моделей
- Сдвиг от scaffolding tricks к environment design
- Качество верификатора критично: надо ориентироваться на outcome, а не имплементацию
- Автоматизация создания RL environments из реальных задач
- Измеряйте модели на реальных engineering work, а не на паззлах
3. Для компаний, строящих AI products
- Доступ к real-world engineering data — ключевое конкурентное преимущество
- RL environments > clever prompting
- Benchmarks drive capability improvements
- Open source collaboration ускоряет прогресс всей индустрии
#AI #ML #Agents #Software #Engineering #Architecture
Продолжая рассказ про этот доклад, надо рассказать про Cline-Bench - open source benchmark для реальных задач, который анонсирует Cline. Каждая задача внутри бенча это:
- Starting repo snapshot (git commit hash)
- Real prompt from user
- Ground truth tests на основе кода, который реально зашипился
Этот бенч
- Полностью open source, no secret sauce, no locked datasets
- Любой может использовать для SFT, RL, eval
- Любой может поучаствовать
Как контрибьютить
1. Работайте над open source проектом с включенным Cline Provider
2. Opt into cline-bench initiative
3. Если frontier model застрял и вы вмешались, чтобы починить — это идеальный кандидат для benchmark
В общем, просто используйте Cline, наблюдайте, где модель struggles, и Cline подберет эти задачи в open-source benchmark.
P.S.
Если подбивать мысли из доклада, то можно вынести следующее
1. Для инженеров, использующих AI coding agents
- Перестаньте over-engineering scaffolding. Проще = лучше
- Фокусируйтесь на capability модели, а не на умных абстракциях
- Ваши real-world failure cases — самые ценные данные для экосистемы
- Contribution в open benchmarks помогает всем
2. Для исследователей и разработчиков моделей
- Сдвиг от scaffolding tricks к environment design
- Качество верификатора критично: надо ориентироваться на outcome, а не имплементацию
- Автоматизация создания RL environments из реальных задач
- Измеряйте модели на реальных engineering work, а не на паззлах
3. Для компаний, строящих AI products
- Доступ к real-world engineering data — ключевое конкурентное преимущество
- RL environments > clever prompting
- Benchmarks drive capability improvements
- Open source collaboration ускоряет прогресс всей индустрии
#AI #ML #Agents #Software #Engineering #Architecture
Telegram
Книжный куб
[1/2] Hard Won Lessons from Building Effective AI Coding Agents (Рубрика #Agents)
Интересный доклад от Nik Pash, Head of AI в Cline с основной мыслью в том, что надо перестать усложнять или почему умный scaffolding убивает AI-агентов. До Cline Ник работал…
Интересный доклад от Nik Pash, Head of AI в Cline с основной мыслью в том, что надо перестать усложнять или почему умный scaffolding убивает AI-агентов. До Cline Ник работал…
❤7🔥4👍3
Developer Experience in the Age of AI Coding Agents (Рубрика #Agents)
Посмотрел интересное выступление Max Kanat-Alexander, Executive Distinguished Engineer в Capital One, где он рассказывал про DevEx в эпоху AI-агентов или как не утонуть в уже существующем legacy и новосозданном legacy, генерящегося агентами в ускоренном режиме:) Макс ранее работал Tech Lead в Google (над Code Health) и Principal Staff Engineer в LinkedIn (над Developer Productivity). Также он написал книги "Code Simplicity" и "Understanding Software", которые я пока не прочел:)
Основные тезисы доклада такие
1️⃣ Не сражайтесь с Training Set
Используйте стандартные инструменты. Если вы написали свой пакетный менеджер или используете редкий язык — агент будет тупить. Он обучен на open source стандартах. Чем "скучнее" и стандартнее ваш стек, тем умнее на нём работает AI.
2️⃣ CLI > GUI
Агентам нужны API и CLI, а не браузер. Заставлять агента "кликать" через GUI — дорого и ненадежно. Если у инструмента есть текстовый интерфейс, агент справится с ним быстрее и точнее.
3️⃣ Тесты должны быть детерминированными
Агенту ничего не говорит ошибка `500 Internal Error`. Ему нужны четкие сообщения валидаторов. Инвестиция в качественные сообщения об ошибках в тестах и линтерах — это инвестиция в автономность агента. Критично что тесты должны бежать быстро (30 секунд, а не 20 минут). Агент запускает их в цикле. Медленный CI убьёт продуктивность агента.
4️⃣ Документируйте "Зачем", а не "Что"
Агент видит код и понимает, что он делает. Но он не был на ваших митингах и не умеет читать мысли.
В документации теперь нужно писать контекст: бизнес-цели, внешние ограничения, форму данных на входе. То, чего нет в коде.
5️⃣ Проблема Code Review (Порочный цикл)
Написание кода превращается в чтение. Количество PR-ов растет экспоненциально.
Но, если у вас слабый процесс ревью, вы начнете "штамповать" (LGTM) плохой код от агентов. Кодовая база деградирует, агенту становится сложнее в ней работать, он пишет еще больше чуши → получается порочный круг. Решение в том, чтобы распределять нагрузку по ревью (не слать всё в общий канал "кто-нибудь гляньте") и жестко держать планку качества.
🚀 Что это значит для разработки?
- Рефакторинг легаси обязателен. Если человек не может понять структуру проекта без "тайных знаний", агент там просто галлюцинирует. Хорошая структура кода теперь — экономическая необходимость.
- Сдвиг парадигмы. Мы переходим от написания кода к верификации. Навык быстро читать и валидировать чужой код становится важнее навыка быстро печатать.
- Золотое правило. Всё, что хорошо для AI-агента (быстрые тесты, внятные ошибки, стандартные инструменты), хорошо и для человека. Даже если AI завтра исчезнет, эти инвестиции окупятся для людей. Забавно, что это очень похоже на "золотое правило морали", универсальный этический принцип, который гласит: «Поступай с другими так, как хочешь, чтобы поступали с тобой»,
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Посмотрел интересное выступление Max Kanat-Alexander, Executive Distinguished Engineer в Capital One, где он рассказывал про DevEx в эпоху AI-агентов или как не утонуть в уже существующем legacy и новосозданном legacy, генерящегося агентами в ускоренном режиме:) Макс ранее работал Tech Lead в Google (над Code Health) и Principal Staff Engineer в LinkedIn (над Developer Productivity). Также он написал книги "Code Simplicity" и "Understanding Software", которые я пока не прочел:)
Основные тезисы доклада такие
1️⃣ Не сражайтесь с Training Set
Используйте стандартные инструменты. Если вы написали свой пакетный менеджер или используете редкий язык — агент будет тупить. Он обучен на open source стандартах. Чем "скучнее" и стандартнее ваш стек, тем умнее на нём работает AI.
2️⃣ CLI > GUI
Агентам нужны API и CLI, а не браузер. Заставлять агента "кликать" через GUI — дорого и ненадежно. Если у инструмента есть текстовый интерфейс, агент справится с ним быстрее и точнее.
3️⃣ Тесты должны быть детерминированными
Агенту ничего не говорит ошибка `500 Internal Error`. Ему нужны четкие сообщения валидаторов. Инвестиция в качественные сообщения об ошибках в тестах и линтерах — это инвестиция в автономность агента. Критично что тесты должны бежать быстро (30 секунд, а не 20 минут). Агент запускает их в цикле. Медленный CI убьёт продуктивность агента.
4️⃣ Документируйте "Зачем", а не "Что"
Агент видит код и понимает, что он делает. Но он не был на ваших митингах и не умеет читать мысли.
В документации теперь нужно писать контекст: бизнес-цели, внешние ограничения, форму данных на входе. То, чего нет в коде.
5️⃣ Проблема Code Review (Порочный цикл)
Написание кода превращается в чтение. Количество PR-ов растет экспоненциально.
Но, если у вас слабый процесс ревью, вы начнете "штамповать" (LGTM) плохой код от агентов. Кодовая база деградирует, агенту становится сложнее в ней работать, он пишет еще больше чуши → получается порочный круг. Решение в том, чтобы распределять нагрузку по ревью (не слать всё в общий канал "кто-нибудь гляньте") и жестко держать планку качества.
🚀 Что это значит для разработки?
- Рефакторинг легаси обязателен. Если человек не может понять структуру проекта без "тайных знаний", агент там просто галлюцинирует. Хорошая структура кода теперь — экономическая необходимость.
- Сдвиг парадигмы. Мы переходим от написания кода к верификации. Навык быстро читать и валидировать чужой код становится важнее навыка быстро печатать.
- Золотое правило. Всё, что хорошо для AI-агента (быстрые тесты, внятные ошибки, стандартные инструменты), хорошо и для человека. Даже если AI завтра исчезнет, эти инвестиции окупятся для людей. Забавно, что это очень похоже на "золотое правило морали", универсальный этический принцип, который гласит: «Поступай с другими так, как хочешь, чтобы поступали с тобой»,
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
YouTube
Developer Experience in the Age of AI Coding Agents – Max Kanat-Alexander, Capital One
It feels like every two weeks, the world of software engineering is being turned on its head. Are there any principles we can rely on that will continue to hold true, and that can help us prepare for the future, no matter what happens? Max uses research,…
👍15❤6🔥3
“We Play on the Offensive.”An Interview with Revolut Founder Nikolay Storonsky (Рубрика #Leadership)
Посмотрел интересное интервью Николая Сторонского, основателя компании Revolut ($75 млрд оценка), что он дал Елизавете Осетинской, иностранному агенту. В этом интервью Николай рассказал о том, как строить компанию, где работают только топ-таланты. Но сначала стоит поговорить про масштаб компании сегодня (кстати, я про Revolut уже как-то рассказывал)
- 12,000 сотрудников (5,000 core team, 7,000 support/sales)
- 1,200 разработчиков, примерно ~30-40% всей команды — это engineering + product + data science
- 45M пользователей, 15M daily active
- $6B выручка, $2B прибыль (2025 план: $9B/$3B)
- 40 стран, экспансия в 60+ рынков
Компания фокусируется на найме hgih avievers (достигаторов). Сам Николай провел много тысяч интервью и так формулирует свои критерии
- Топ-1-5% везде — от школы до предыдущих мест работы
- STEM-бэкграунд с доказанным track record
- Problem-solving end-to-end — должны приходить с решениями, а не проблемами
- Амбициозные цели — цитата Николая из интервью, что мне понравилась "почти всё можно достичь, что подчиняется законам физики"
- Готовность увольнять слабых - большинство боятся этого делать
Отдельно Николай отметил, что они не берут
- Классических банкиров — "низкое качество талантов, они maintainers, а не builders"
- Средних исполнителей — "как только начинаешь работать со средними людьми, они приходят: 'У нас проблемы, что делать?' Мы таких не любим"
Интерес подход Николая к текучке - regrettable attrition наддо держать небольшим (1.5% в квартал), а forced attrition надо разгонять до 10-20% в год (чтобы прощаться со слабыми). По мнению Николая это работает, так как
- Постоянная фильтрация открывает лестницу для новых талантов
- Ранние сотрудники уходят мультимиллионерами (топ-менеджеры заработали $50-80M на вторичных продажах акций)
- Компенсация выше банков: зарплата + бонусы + акции для всех 5K core team
Николай поделился следующими культурными ценностями, что приняты в компании
1. Never Settle — ставь амбициозные цели и достигай их
2. Think Deep — глубокий анализ, логика, zero bullshit
3. Dream Team — маленькие команды из звёзд
4. Get Things Done — ownership без микроменеджмента
5. Deliver Wow — перфекционизм для долгосрочного качества
Отдельно много фокуса на AI и автоматизации работы (кстати, я уже разбирал подход к автоматизации процессов разработки в Revolut). Конкретно в этом интервью речь была про риск менеджмент и compliance:
- LLM обрабатывают 400,000+ страниц регуляций, автоматически экстрагируют obligations и линкуют к контролям
- ML-модели на 200+ параметрах (IP, транзакции, connections) — точность выше аналитиков-людей
- 75% customer support автоматизировано через чатботы и голосовых ассистентов
Подход Николая к управлению такой командой достигаторов выглядит так
1. Flat-структура
- Нет кабинета даже у CEO — работает с open space
- 40+ direct reports + 30 "bright young people" (ex-McKinsey/IB/фаундеры) в office of CEO для теневого аудита performance
2. KPI-driven всё
- Еженедельные 1:1 по 15 минут: Jira, метрики, проблемы
- Понедельник/вторник — department reviews
- Net performance 70%+, attrition <1.5% в квартал для сильных
3. Radical Honesty (примерно как в книге Radical Candor (Радикальная прямота), о которой я уже рассказывал)
- Нет политики, только данные
- Фидбек прямой, без эмоций
- Любой может подойти к любому
4. Продуктовый подход
- Команды 8-10 человек, bootstrap 9-18 месяцев
- Kill <25% продуктов по gross profit
- Интервьюеры обучаемы: их precision/recall трекают, худших 25% убирают
#Engineering #Leadership #Hiring #Culture #AI #Management #Startup
Посмотрел интересное интервью Николая Сторонского, основателя компании Revolut ($75 млрд оценка), что он дал Елизавете Осетинской, иностранному агенту. В этом интервью Николай рассказал о том, как строить компанию, где работают только топ-таланты. Но сначала стоит поговорить про масштаб компании сегодня (кстати, я про Revolut уже как-то рассказывал)
- 12,000 сотрудников (5,000 core team, 7,000 support/sales)
- 1,200 разработчиков, примерно ~30-40% всей команды — это engineering + product + data science
- 45M пользователей, 15M daily active
- $6B выручка, $2B прибыль (2025 план: $9B/$3B)
- 40 стран, экспансия в 60+ рынков
Компания фокусируется на найме hgih avievers (достигаторов). Сам Николай провел много тысяч интервью и так формулирует свои критерии
- Топ-1-5% везде — от школы до предыдущих мест работы
- STEM-бэкграунд с доказанным track record
- Problem-solving end-to-end — должны приходить с решениями, а не проблемами
- Амбициозные цели — цитата Николая из интервью, что мне понравилась "почти всё можно достичь, что подчиняется законам физики"
- Готовность увольнять слабых - большинство боятся этого делать
Отдельно Николай отметил, что они не берут
- Классических банкиров — "низкое качество талантов, они maintainers, а не builders"
- Средних исполнителей — "как только начинаешь работать со средними людьми, они приходят: 'У нас проблемы, что делать?' Мы таких не любим"
Интерес подход Николая к текучке - regrettable attrition наддо держать небольшим (1.5% в квартал), а forced attrition надо разгонять до 10-20% в год (чтобы прощаться со слабыми). По мнению Николая это работает, так как
- Постоянная фильтрация открывает лестницу для новых талантов
- Ранние сотрудники уходят мультимиллионерами (топ-менеджеры заработали $50-80M на вторичных продажах акций)
- Компенсация выше банков: зарплата + бонусы + акции для всех 5K core team
Николай поделился следующими культурными ценностями, что приняты в компании
1. Never Settle — ставь амбициозные цели и достигай их
2. Think Deep — глубокий анализ, логика, zero bullshit
3. Dream Team — маленькие команды из звёзд
4. Get Things Done — ownership без микроменеджмента
5. Deliver Wow — перфекционизм для долгосрочного качества
Отдельно много фокуса на AI и автоматизации работы (кстати, я уже разбирал подход к автоматизации процессов разработки в Revolut). Конкретно в этом интервью речь была про риск менеджмент и compliance:
- LLM обрабатывают 400,000+ страниц регуляций, автоматически экстрагируют obligations и линкуют к контролям
- ML-модели на 200+ параметрах (IP, транзакции, connections) — точность выше аналитиков-людей
- 75% customer support автоматизировано через чатботы и голосовых ассистентов
Подход Николая к управлению такой командой достигаторов выглядит так
1. Flat-структура
- Нет кабинета даже у CEO — работает с open space
- 40+ direct reports + 30 "bright young people" (ex-McKinsey/IB/фаундеры) в office of CEO для теневого аудита performance
2. KPI-driven всё
- Еженедельные 1:1 по 15 минут: Jira, метрики, проблемы
- Понедельник/вторник — department reviews
- Net performance 70%+, attrition <1.5% в квартал для сильных
3. Radical Honesty (примерно как в книге Radical Candor (Радикальная прямота), о которой я уже рассказывал)
- Нет политики, только данные
- Фидбек прямой, без эмоций
- Любой может подойти к любому
4. Продуктовый подход
- Команды 8-10 человек, bootstrap 9-18 месяцев
- Kill <25% продуктов по gross profit
- Интервьюеры обучаемы: их precision/recall трекают, худших 25% убирают
#Engineering #Leadership #Hiring #Culture #AI #Management #Startup
YouTube
«Мы играем в нападение». Интервью с основателем Revolut Николаем Сторонским
НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН И РАСПРОСТРАНЕН ИНОСТРАННЫМ АГЕНТОМ ЕЛИЗАВЕТОЙ НИКОЛАЕВНОЙ ОСЕТИНСКОЙ ЛИБО КАСАЕТСЯ ДЕЯТЕЛЬНОСТИ ИНОСТРАННОГО АГЕНТА ЕЛИЗАВЕТЫ НИКОЛАЕВНЫ ОСЕТИНСКОЙ 18+
Выбрать премиум-апартаменты на Бали от самого креативного…
Выбрать премиум-апартаменты на Бали от самого креативного…
👍10❤6🔥3😁3
AI Trends 2026: Quantum, Agentic AI & Smarter Automation (Рубрика #AI)
Пока идут новогодние каникулы, можно глянуть предсказания на 2026 год. Так я наткнулся на видео Martin Keen и Aaron Baughman из IBM, что опубликовали такой обзор про AI на 2026 год. Кстати, Martin Keen, IBM Fellow, в прошлом году записывал такое видео в одиночку и я про него рассказывал (можете сравнить с реальностью и оценить что исполнилось).
1️⃣ Мультиагентная оркестрация (Multi-Agent Orchestration)
2025 был годом AI-агентов, но ни один агент не справляется со всем. В 2026 мы увидим команды специализированных агентов, координируемых оркестратором.
2️⃣ Цифровая рабочая сила (Digital Labor Workforce)
Автономные AI-агенты становятся "цифровыми работниками", способными парсить мультимодальный ввод, выполнять workflow и интегрироваться с корпоративными системами. Ключевой элемент — human-in-the-loop AI для oversight, коррекции и стратегического управления. Это важно, так как цифровые работники обеспечивают force-multiplying эффект, работают 24/7 и масштабируются без массового найма персонала.
3️⃣ Physical AI и гуманоидные роботы
AI покидает цифровое пространство и входит в физический мир. Physical AI — это модели, которые понимают 3D-среду, физику (гравитация, трение) и могут взаимодействовать с реальностью через роботизированные системы. Для этого нужны world foundation models (WFM), генеративные модели, создающие и понимающие 3D-окружения. Про этот подход рассказывала Fei-Fei Li, крестная мать AI, в докладе "Spatial Intelligence is the Next Frontier in AI", который я уже разбирал.
4️⃣ Social Computing — коллективный AI
Мир, где множество агентов и людей работают внутри общей AI-ткани (AI fabric). Агенты и люди соединены через единое пространство, обмениваются контекстом, намерениями и действиями, создавая empathetic emergent network — коллективный интеллект или "swarm computing".
5️⃣ Verifiable AI и EU AI Act
EU AI Act вступает в полную силу к середине 2026 года. Как GDPR для AI: системы высокого риска должны быть аудируемыми и трассируемыми. Требования:
- Документация — технические доки, тестирование, риски
- Прозрачность — пользователи должны знать, что взаимодействуют с машиной
- Data lineage — откуда данные и соблюдены ли авторские права
По мнению ребят EU AI Act установит глобальный шаблон для AI-регулирования, как GDPR для privacy.
6️⃣ Quantum Utility Everywhere
По мнению ребят именно в 2026 году квантовые вычисления начнут решать реальные задачи лучше, быстрее или эффективнее классических систем. Quantum utility scale — гибридные квант-классические системы, интегрированные в повседневные бизнес-операции для оптимизации, симуляций и принятия решений. Это обусловлено тем, что мы уже видим прорывы в коррекции ошибок, модульности и гибридных алгоритмах ускоряются, а также появляются Quantum-as-a-Service от IBM, AWS, Microsoft и Google.
7️⃣ Reasoning at the Edge — мышление на устройстве
Большие модели научились "думать" через inference-time compute (step-by-step reasoning). Теперь эти способности дистиллируются в малые модели (несколько миллиардов параметров), работающие на ноутбуках и телефонах. Модели с reasoning работают локально, данные не покидают устройство, нет задержки на облако.
8️⃣ Amorphous Hybrid Computing
Будущее там, где топологии AI-моделей и облачная инфраструктура сливаются в fluid computing backbone. Модели эволюционируют за пределы чистых трансформеров, интегрируя state space models (SSM) и другие архитектуры. Одновременно облака комбинируют CPU, GPU, TPU, QPU (quantum) и нейроморфные чипы, чтобы исполнять алгоритмсы на оптимальном для инференса устройстве, обеспечивая производительность и эффективность.
Итого, 2026 обещает стать переломным годом для AI: от изолированных моделей к оркестрированным системам, от облака к edge, от цифрового к физическому.
#AI #ML #Trends #Software #Engineering #Future
Пока идут новогодние каникулы, можно глянуть предсказания на 2026 год. Так я наткнулся на видео Martin Keen и Aaron Baughman из IBM, что опубликовали такой обзор про AI на 2026 год. Кстати, Martin Keen, IBM Fellow, в прошлом году записывал такое видео в одиночку и я про него рассказывал (можете сравнить с реальностью и оценить что исполнилось).
1️⃣ Мультиагентная оркестрация (Multi-Agent Orchestration)
2025 был годом AI-агентов, но ни один агент не справляется со всем. В 2026 мы увидим команды специализированных агентов, координируемых оркестратором.
2️⃣ Цифровая рабочая сила (Digital Labor Workforce)
Автономные AI-агенты становятся "цифровыми работниками", способными парсить мультимодальный ввод, выполнять workflow и интегрироваться с корпоративными системами. Ключевой элемент — human-in-the-loop AI для oversight, коррекции и стратегического управления. Это важно, так как цифровые работники обеспечивают force-multiplying эффект, работают 24/7 и масштабируются без массового найма персонала.
3️⃣ Physical AI и гуманоидные роботы
AI покидает цифровое пространство и входит в физический мир. Physical AI — это модели, которые понимают 3D-среду, физику (гравитация, трение) и могут взаимодействовать с реальностью через роботизированные системы. Для этого нужны world foundation models (WFM), генеративные модели, создающие и понимающие 3D-окружения. Про этот подход рассказывала Fei-Fei Li, крестная мать AI, в докладе "Spatial Intelligence is the Next Frontier in AI", который я уже разбирал.
4️⃣ Social Computing — коллективный AI
Мир, где множество агентов и людей работают внутри общей AI-ткани (AI fabric). Агенты и люди соединены через единое пространство, обмениваются контекстом, намерениями и действиями, создавая empathetic emergent network — коллективный интеллект или "swarm computing".
5️⃣ Verifiable AI и EU AI Act
EU AI Act вступает в полную силу к середине 2026 года. Как GDPR для AI: системы высокого риска должны быть аудируемыми и трассируемыми. Требования:
- Документация — технические доки, тестирование, риски
- Прозрачность — пользователи должны знать, что взаимодействуют с машиной
- Data lineage — откуда данные и соблюдены ли авторские права
По мнению ребят EU AI Act установит глобальный шаблон для AI-регулирования, как GDPR для privacy.
6️⃣ Quantum Utility Everywhere
По мнению ребят именно в 2026 году квантовые вычисления начнут решать реальные задачи лучше, быстрее или эффективнее классических систем. Quantum utility scale — гибридные квант-классические системы, интегрированные в повседневные бизнес-операции для оптимизации, симуляций и принятия решений. Это обусловлено тем, что мы уже видим прорывы в коррекции ошибок, модульности и гибридных алгоритмах ускоряются, а также появляются Quantum-as-a-Service от IBM, AWS, Microsoft и Google.
7️⃣ Reasoning at the Edge — мышление на устройстве
Большие модели научились "думать" через inference-time compute (step-by-step reasoning). Теперь эти способности дистиллируются в малые модели (несколько миллиардов параметров), работающие на ноутбуках и телефонах. Модели с reasoning работают локально, данные не покидают устройство, нет задержки на облако.
8️⃣ Amorphous Hybrid Computing
Будущее там, где топологии AI-моделей и облачная инфраструктура сливаются в fluid computing backbone. Модели эволюционируют за пределы чистых трансформеров, интегрируя state space models (SSM) и другие архитектуры. Одновременно облака комбинируют CPU, GPU, TPU, QPU (quantum) и нейроморфные чипы, чтобы исполнять алгоритмсы на оптимальном для инференса устройстве, обеспечивая производительность и эффективность.
Итого, 2026 обещает стать переломным годом для AI: от изолированных моделей к оркестрированным системам, от облака к edge, от цифрового к физическому.
#AI #ML #Trends #Software #Engineering #Future
YouTube
AI Trends 2026: Quantum, Agentic AI & Smarter Automation
Ready to become a certified watsonx AI Assistant Engineer v1 - Professional? Register now and use code IBMTechYT20 for 20% off of your exam → https://ibm.biz/BdbTDQ
Learn more about AI Trends Shaping the Next 10 Years here → https://ibm.biz/BdbTDT
What…
Learn more about AI Trends Shaping the Next 10 Years here → https://ibm.biz/BdbTDT
What…
❤10👍3🔥2
Парк Львов "Земля Прайда" (Рубрика #Kids)
2 января мы с детишками и друзьями мы были в парке львов "Земля Прайда" (1 и 2 января мы провели под Клином, поэтому ехать до парка было близко). Я уже как-то рассказывал про ребят, но с тех пор они переехали на территорию побольше + завели tg-канал (или он уже был). В этот раз мы приехали после обеда да еще и в зимний день, поэтому часть животных пряталась в своих домиках и уже спала (ведь зимой дни короткие). Но мы мы, прикупив ведерки с едой для животных, смогли пройтись по територии и потренироваться в метании мяса тиграм и львам, а также покормить с рук кроликов, верблюдов, ламу, оленя ...
В общем, парк отличный
- Многие животные были выкуплены из неволи и выхожены сотрудниками парка - видно, что они достаточно вольготно живут и хорошо питаются
- На территории парка все сделано для животных и людей - вальеры для животных большие, тигры, мишки и львы живут на большой и огороженной территории, где ты поднимаешься по лестнице наверх и дальше смотришь не через прутья клетки, а как бы с высоты на зверей
За час-полтора мы быстрым темпом обошли всех животных (медленно ходить было прохладно), потом взяли по капучино для взрослых и по коле для детей в кафешке, сели в машину и поехали обратно в Москву.
#ForParents #ForKids #Family #Stories
2 января мы с детишками и друзьями мы были в парке львов "Земля Прайда" (1 и 2 января мы провели под Клином, поэтому ехать до парка было близко). Я уже как-то рассказывал про ребят, но с тех пор они переехали на территорию побольше + завели tg-канал (или он уже был). В этот раз мы приехали после обеда да еще и в зимний день, поэтому часть животных пряталась в своих домиках и уже спала (ведь зимой дни короткие). Но мы мы, прикупив ведерки с едой для животных, смогли пройтись по територии и потренироваться в метании мяса тиграм и львам, а также покормить с рук кроликов, верблюдов, ламу, оленя ...
В общем, парк отличный
- Многие животные были выкуплены из неволи и выхожены сотрудниками парка - видно, что они достаточно вольготно живут и хорошо питаются
- На территории парка все сделано для животных и людей - вальеры для животных большие, тигры, мишки и львы живут на большой и огороженной территории, где ты поднимаешься по лестнице наверх и дальше смотришь не через прутья клетки, а как бы с высоты на зверей
За час-полтора мы быстрым темпом обошли всех животных (медленно ходить было прохладно), потом взяли по капучино для взрослых и по коле для детей в кафешке, сели в машину и поехали обратно в Москву.
#ForParents #ForKids #Family #Stories
1🔥11❤8👍3
Half-Life. Как Valve создала культовый шутер от первого лица (Half-Life: Le FPS libéré. Création - Univers - Décryptage) (Рубрика #Games)
Прочитал на каникулах книгу 2016 года Яна Франсуа про Half Life, что совершила в конце 90х годов революцию в жанре FPS. Fвтор не просто решил пересказать игру - он поставил перед собой задачу проследить путь Half-Life от замысла до триумфа, а также показать, как Valve нашла свой уникальный стиль и какие решения определили успех проекта. Вообще, книга состоит из трех частей: исторической, повествовательной и аналитической.
1️⃣ В исторической части рассказывается предыстория основания Valve и хроника разработки Half-Life. Франсуа описывает биографию Гейба Ньюэлла и Майка Харрингтона – бывших сотрудников Microsoft, которые в 1996 году основали Valve, вдохновившись идеей сделать нечто масштабнее типичных шутеров того времени. Читатель узнает, с какими проблемами столкнулась молодая команда: от технических ограничений движка до неудачных прототипов уровней, а также переноса релиза игры на целый год – несмотря на приближение объявленной даты выхода в 1997-м, Valve выбрала довести всё до идеала
2️⃣ В повестовательной части Франсуа буквально в хронологическом порядке пересказывает сюжет Half-Life, от утренней поездки Гордона Фримена в исследовательский центр Black Mesa до финальной встречи с таинственным G-Man. Такой подробный пересказ может удивить искушенного читателя, ведь многие сами не раз проходили игру. Однако автор делает это не ради спойлеров, а чтобы проанализировать структуру истории, отметить ключевые моменты дизайна уровней и гейм-дизайнерские приемы. Так уже получилось, что я в 1998 году, когда вышла первая Half-Life в игры еще не играл, а к выходу второй - уж не играл, поэтому эта книга помогла мне понять, а в чем же сюжет культовой игры.
3️⃣ В аналитической части автор делится выводами о наследии Half-Life и влиянии игры на индустрию. Он изучает источники вдохновения разработчиков (от классических шутеров вроде Doom до фильмов ужасов и научной фантастики), внутреннюю философию Valve и то, как успех Half-Life повлиял на дальнейшие решения студии. Он старается ответить на главный вопрос: в чем феномен Half-Life? Среди поднятых тем – новаторская для 90-х интеграция сюжета и геймплея, когда история рассказывается через окружение и скрипты событий, а не через заставки. Автор обсуждает, как Valve нашла свой стиль разработки – культура, где ценится эксперименты, командная инновация и внимание к деталям.
Отдельно стоит отметить, что Half-Life и Valve сильно повлияли на историю компьютерных игр
- Half-Life по праву считается одной из величайших игр всех времен, которая фундаментально изменила подход к созданию шутеров. До её выхода сюжет в экшен-играх подавался в лучшем случае через брифинги или ролики между уровнями. Valve же показала, как можно рассказать сложную историю внутри геймплея – игрок сам переживает все события, оставаясь в роли персонажа.
- С технической точки зрения Half-Life тоже задала планку. Игра построена на сильно модифицированном движке Quake, названном GoldSrc, и разработчики не побоялись углубиться в код предшественников, чтобы реализовать свои идеи. Результатом стали новаторские решения: продвинутый ИИ врагов, скриптовые события в реальном времени, которых раньше не видели в динамике FPS, и модульная архитектура игры, позволившая сообществу создавать тысячи модификаций (одна из них Counter-Strike)
- Half-Life 2 (2004) стала качественным скачком: ради него студия создала с нуля новый движок Source, который затем стал основой множества игр на годы вперед. Source принес индустрии новые технологии графики, анимации, физики, звука и повествования, многие из которых используются до сих пор.
- Half-Life и Half-Life 2 вместе не только задали стандарты геймдизайна, но и изменили сам подход к дистрибуции игр. Параллельно с HL2 в 2003 году Valve запустила сервис Steam, изначально – чтобы распространить обновления для сетевых игр вроде Counter-Strike, а затем – чтобы продать сам HL2 напрямую игрокам.
#Game #Design #Engineering #Software
Прочитал на каникулах книгу 2016 года Яна Франсуа про Half Life, что совершила в конце 90х годов революцию в жанре FPS. Fвтор не просто решил пересказать игру - он поставил перед собой задачу проследить путь Half-Life от замысла до триумфа, а также показать, как Valve нашла свой уникальный стиль и какие решения определили успех проекта. Вообще, книга состоит из трех частей: исторической, повествовательной и аналитической.
1️⃣ В исторической части рассказывается предыстория основания Valve и хроника разработки Half-Life. Франсуа описывает биографию Гейба Ньюэлла и Майка Харрингтона – бывших сотрудников Microsoft, которые в 1996 году основали Valve, вдохновившись идеей сделать нечто масштабнее типичных шутеров того времени. Читатель узнает, с какими проблемами столкнулась молодая команда: от технических ограничений движка до неудачных прототипов уровней, а также переноса релиза игры на целый год – несмотря на приближение объявленной даты выхода в 1997-м, Valve выбрала довести всё до идеала
2️⃣ В повестовательной части Франсуа буквально в хронологическом порядке пересказывает сюжет Half-Life, от утренней поездки Гордона Фримена в исследовательский центр Black Mesa до финальной встречи с таинственным G-Man. Такой подробный пересказ может удивить искушенного читателя, ведь многие сами не раз проходили игру. Однако автор делает это не ради спойлеров, а чтобы проанализировать структуру истории, отметить ключевые моменты дизайна уровней и гейм-дизайнерские приемы. Так уже получилось, что я в 1998 году, когда вышла первая Half-Life в игры еще не играл, а к выходу второй - уж не играл, поэтому эта книга помогла мне понять, а в чем же сюжет культовой игры.
3️⃣ В аналитической части автор делится выводами о наследии Half-Life и влиянии игры на индустрию. Он изучает источники вдохновения разработчиков (от классических шутеров вроде Doom до фильмов ужасов и научной фантастики), внутреннюю философию Valve и то, как успех Half-Life повлиял на дальнейшие решения студии. Он старается ответить на главный вопрос: в чем феномен Half-Life? Среди поднятых тем – новаторская для 90-х интеграция сюжета и геймплея, когда история рассказывается через окружение и скрипты событий, а не через заставки. Автор обсуждает, как Valve нашла свой стиль разработки – культура, где ценится эксперименты, командная инновация и внимание к деталям.
Отдельно стоит отметить, что Half-Life и Valve сильно повлияли на историю компьютерных игр
- Half-Life по праву считается одной из величайших игр всех времен, которая фундаментально изменила подход к созданию шутеров. До её выхода сюжет в экшен-играх подавался в лучшем случае через брифинги или ролики между уровнями. Valve же показала, как можно рассказать сложную историю внутри геймплея – игрок сам переживает все события, оставаясь в роли персонажа.
- С технической точки зрения Half-Life тоже задала планку. Игра построена на сильно модифицированном движке Quake, названном GoldSrc, и разработчики не побоялись углубиться в код предшественников, чтобы реализовать свои идеи. Результатом стали новаторские решения: продвинутый ИИ врагов, скриптовые события в реальном времени, которых раньше не видели в динамике FPS, и модульная архитектура игры, позволившая сообществу создавать тысячи модификаций (одна из них Counter-Strike)
- Half-Life 2 (2004) стала качественным скачком: ради него студия создала с нуля новый движок Source, который затем стал основой множества игр на годы вперед. Source принес индустрии новые технологии графики, анимации, физики, звука и повествования, многие из которых используются до сих пор.
- Half-Life и Half-Life 2 вместе не только задали стандарты геймдизайна, но и изменили сам подход к дистрибуции игр. Параллельно с HL2 в 2003 году Valve запустила сервис Steam, изначально – чтобы распространить обновления для сетевых игр вроде Counter-Strike, а затем – чтобы продать сам HL2 напрямую игрокам.
#Game #Design #Engineering #Software
🔥11❤8⚡2
[1/2] Отчеты McKinsey про Gen AI (Рубрика #AI)
Я продолжаю свое мета-исследование различных отчетов про внедрение AI и мне понравилась серия постов от McKinsey, которые системно и ритмично исследуют данный вопрос. Они начали делать это в 2023 году и продолжали в 2024 и 2025, а это уже позволяет отследить тренды и посмотреть как развивается ситуация во времени. Конкретно я поговорю про следующие отчеты
- 2023 год: The state of AI in 2023: Generative AI’s breakout year - опрос с 11 по 21 апреля 2023, 1684 респондентов, публикация 1 августа 2023
- 2024 год - начало: The state of AI in early 2024: Gen AI adoption spikes and starts to generate value - опрос с 22 февраля по 5 марта 2024, 1363 респондентов, публикация 30 мая 2024
- 2024 год - середина: The state of AI: How organizations are rewiring to capture value - опрос с 16 по 31 июля 2024, 1491 респондент, публикация 12 марта 2025
- 2025 год: The state of AI in 2025: Agents, innovation, and transformation - опрос с 25 июня по 29 июля, 1993 респондента, публикация 5 ноября 2025 года (я подробнее уже рассказывал про результаты)
Если глянуть на эти отччеты, то есть ряд метрик, что можно воспринимать как time series данные и оценивать тренды
❤️🔥 Сначала начнем с метрик проникновения и ее широты
1) “AI use/adoption in at least one business function” — главный «сквозной» KPI
Это самый стабильный KPI во всей серии: доля респондентов, у кого в компании AI используется/принят хотя бы в одной функции.
- 2023 - 55%
- 2024 (начало) - 72%
- 2024 (середина) - 78%
- 2025 - 88%
Эту метрика можно назвать метрикой проникновения (“penetration”), она отвечате на вопрос "есть ли AI хоть где-то", но плохо различает пилот vs прод.
2) “Organizations regularly using gen AI in ≥1 business function” — второй сквозной KPI (но в 2025‑выпуске Nov 2025 он не акцентирован)
- 2023 - 33%
- 2024 (начало) - 65%
- 2024 (середина) - 71%
- 2025 - NA - в тексте отчета не дано отдельной цифрой (фокус смещён на agents и AI overall)
3) “AI spreads across multiple functions” — ширина применения (частично сопоставимо)
С этим KPI сложнее: он «тот же по смыслу», но формулировки в разных отчетах разные (≥2 функции, >1 функция, ≥3 функции).
- 2023 - меньше 33% AI adopted в двух и более функциях
- 2024 (начало) - 50% — AI adopted в двух и более функциях
- 2024 (середина) - NA
- 2025: больше 66% - AI используется более чем в одной функции; и 50% — в трёх и более функциях.
Кажется, что авторов отчета меньше интересовала сравнимость данных год от года, а больше интересовал способ как померить широту охвата, поэтому вопрос про количество функций с adoption AI постепенно увеличивался
В продолжении я расскажу про оценку эффектов AI/GenAI на компании и концепцию high performers, которые лучше справляются с внедрением инструментов. Я рассказывал об этом здесь, но в продолжении поста будет видно, как критерии high performance мутируют со временем.
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Я продолжаю свое мета-исследование различных отчетов про внедрение AI и мне понравилась серия постов от McKinsey, которые системно и ритмично исследуют данный вопрос. Они начали делать это в 2023 году и продолжали в 2024 и 2025, а это уже позволяет отследить тренды и посмотреть как развивается ситуация во времени. Конкретно я поговорю про следующие отчеты
- 2023 год: The state of AI in 2023: Generative AI’s breakout year - опрос с 11 по 21 апреля 2023, 1684 респондентов, публикация 1 августа 2023
- 2024 год - начало: The state of AI in early 2024: Gen AI adoption spikes and starts to generate value - опрос с 22 февраля по 5 марта 2024, 1363 респондентов, публикация 30 мая 2024
- 2024 год - середина: The state of AI: How organizations are rewiring to capture value - опрос с 16 по 31 июля 2024, 1491 респондент, публикация 12 марта 2025
- 2025 год: The state of AI in 2025: Agents, innovation, and transformation - опрос с 25 июня по 29 июля, 1993 респондента, публикация 5 ноября 2025 года (я подробнее уже рассказывал про результаты)
Если глянуть на эти отччеты, то есть ряд метрик, что можно воспринимать как time series данные и оценивать тренды
1) “AI use/adoption in at least one business function” — главный «сквозной» KPI
Это самый стабильный KPI во всей серии: доля респондентов, у кого в компании AI используется/принят хотя бы в одной функции.
- 2023 - 55%
- 2024 (начало) - 72%
- 2024 (середина) - 78%
- 2025 - 88%
Эту метрика можно назвать метрикой проникновения (“penetration”), она отвечате на вопрос "есть ли AI хоть где-то", но плохо различает пилот vs прод.
2) “Organizations regularly using gen AI in ≥1 business function” — второй сквозной KPI (но в 2025‑выпуске Nov 2025 он не акцентирован)
- 2023 - 33%
- 2024 (начало) - 65%
- 2024 (середина) - 71%
- 2025 - NA - в тексте отчета не дано отдельной цифрой (фокус смещён на agents и AI overall)
3) “AI spreads across multiple functions” — ширина применения (частично сопоставимо)
С этим KPI сложнее: он «тот же по смыслу», но формулировки в разных отчетах разные (≥2 функции, >1 функция, ≥3 функции).
- 2023 - меньше 33% AI adopted в двух и более функциях
- 2024 (начало) - 50% — AI adopted в двух и более функциях
- 2024 (середина) - NA
- 2025: больше 66% - AI используется более чем в одной функции; и 50% — в трёх и более функциях.
Кажется, что авторов отчета меньше интересовала сравнимость данных год от года, а больше интересовал способ как померить широту охвата, поэтому вопрос про количество функций с adoption AI постепенно увеличивался
В продолжении я расскажу про оценку эффектов AI/GenAI на компании и концепцию high performers, которые лучше справляются с внедрением инструментов. Я рассказывал об этом здесь, но в продолжении поста будет видно, как критерии high performance мутируют со временем.
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Please open Telegram to view this post
VIEW IN TELEGRAM
McKinsey & Company
The state of AI in 2023: Generative AI’s breakout year
Explore McKinsey's State of AI in 2023 report, a detailed new survey that looks at how generative AI is reshaping the world's industries and workforces.
❤7🔥4⚡2👍1
[2/2] Отчеты McKinsey про Gen AI (Рубрика #AI)
Продолжая рассказ про исследования McKinsey, перейдем к метрикам рисков и «негативных последствий» (здесь есть данные, но опять сложно сравнимые)
4) “Experienced at least one negative consequence”
- 2023 - NA
- 2024 (начало) - 44% организаций испытали хотя бы одно негативное последствие от gen AI
- 2024 (середина) - 47% организаций испытали хотя бы одно негативное последствие от gen AI.
- 2025 - 51% организаций, использующих AI, испытали хотя бы одно негативное последствие (уже AI overall, не только gen AI).
5) “Inaccuracy” как ключевой риск (частично численно)
- 2023 - NA
- 2024 (начало) - риск, который значимо чаще стали пытаться митигировать по сравнению с прошлым годом; и "почти 25%" респондентов отмечают негативные последствия именно от неточности gen AI
- 2024 (середина) - NA
- 2025 - почти 33% всех респондентов сообщает о последствиях из‑за AI inaccuracy.
🤑 Ну и напоследок обсудим Value / EBIT, где метрика повторяется, но пороги и определения плавают
Здесь McKinsey даёт числа, но в разных выпусках меняется “что считаем успехом”.
6) Доля компаний с EBIT‑эффектом (разные пороги)
- 2023 - 23% респондентов говорят, что ≥5% EBIT их организаций attributable to AI (flat YoY на тот момент)
- 2024 (начало) - только 5.2% (46 и 876 респондентов) "report that a meaningful share of their organizations’ EBIT can be attributed to their deployment of gen AI"
- 2024 (середина) - 17% говорят, что ≥5% EBIT attributable to gen AI; при этом >80% не видят “tangible impact” на enterprise‑level EBIT от gen AI
- 2025 - 39% сообщают о любом EBIT impact на enterprise level от AI (и у большинства это <5%)
7) Доля "High performers" в выборке (тоже не 1‑в‑1, но похоже по масштабу)
- 2023 - AI high performers тут определяются по критерию "> 20% EBIT attributable to gen AI". Прямого указания их количества нет, но оценку можно взять из других вопросов, например, про "reskill larger portions of the workforce" где ответило 50 high performers и остальных 863 (получается оценка в 5.4% high performers)
- 2024 (начало) - “gen AI high performers” = 46 из 876 (≈5.3%) респондентов (критерий: > 10% EBIT attributable to gen AI)
- 2024 (середина) - NA (в этом отчете ничего не говорится про high performers)
- 2025 - “AI high performers” ≈ 6% респондентов (критерий другой: EBIT impact ≥ 5% + “significant value”)
В итоге, видим, что доля “топов” по self‑reported value остаётся порядка 5–6%, но из‑за смены критериев это не точный тренд. Если же глянуть на 2023 год, где 23% респондентов говорили про 5% вклад AI в EBITDA, то в 2025 году виден спад до 6% респондентов, что видят такой вклад. А значит высота достижений high performers становится ниже (или оценки влияния на EBITDA реальнее).
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Продолжая рассказ про исследования McKinsey, перейдем к метрикам рисков и «негативных последствий» (здесь есть данные, но опять сложно сравнимые)
4) “Experienced at least one negative consequence”
- 2023 - NA
- 2024 (начало) - 44% организаций испытали хотя бы одно негативное последствие от gen AI
- 2024 (середина) - 47% организаций испытали хотя бы одно негативное последствие от gen AI.
- 2025 - 51% организаций, использующих AI, испытали хотя бы одно негативное последствие (уже AI overall, не только gen AI).
5) “Inaccuracy” как ключевой риск (частично численно)
- 2023 - NA
- 2024 (начало) - риск, который значимо чаще стали пытаться митигировать по сравнению с прошлым годом; и "почти 25%" респондентов отмечают негативные последствия именно от неточности gen AI
- 2024 (середина) - NA
- 2025 - почти 33% всех респондентов сообщает о последствиях из‑за AI inaccuracy.
Здесь McKinsey даёт числа, но в разных выпусках меняется “что считаем успехом”.
6) Доля компаний с EBIT‑эффектом (разные пороги)
- 2023 - 23% респондентов говорят, что ≥5% EBIT их организаций attributable to AI (flat YoY на тот момент)
- 2024 (начало) - только 5.2% (46 и 876 респондентов) "report that a meaningful share of their organizations’ EBIT can be attributed to their deployment of gen AI"
- 2024 (середина) - 17% говорят, что ≥5% EBIT attributable to gen AI; при этом >80% не видят “tangible impact” на enterprise‑level EBIT от gen AI
- 2025 - 39% сообщают о любом EBIT impact на enterprise level от AI (и у большинства это <5%)
7) Доля "High performers" в выборке (тоже не 1‑в‑1, но похоже по масштабу)
- 2023 - AI high performers тут определяются по критерию "> 20% EBIT attributable to gen AI". Прямого указания их количества нет, но оценку можно взять из других вопросов, например, про "reskill larger portions of the workforce" где ответило 50 high performers и остальных 863 (получается оценка в 5.4% high performers)
- 2024 (начало) - “gen AI high performers” = 46 из 876 (≈5.3%) респондентов (критерий: > 10% EBIT attributable to gen AI)
- 2024 (середина) - NA (в этом отчете ничего не говорится про high performers)
- 2025 - “AI high performers” ≈ 6% респондентов (критерий другой: EBIT impact ≥ 5% + “significant value”)
В итоге, видим, что доля “топов” по self‑reported value остаётся порядка 5–6%, но из‑за смены критериев это не точный тренд. Если же глянуть на 2023 год, где 23% респондентов говорили про 5% вклад AI в EBITDA, то в 2025 году виден спад до 6% респондентов, что видят такой вклад. А значит высота достижений high performers становится ниже (или оценки влияния на EBITDA реальнее).
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Книжный куб
[1/2] Отчеты McKinsey про Gen AI (Рубрика #AI)
Я продолжаю свое мета-исследование различных отчетов про внедрение AI и мне понравилась серия постов от McKinsey, которые системно и ритмично исследуют данный вопрос. Они начали делать это в 2023 году и продолжали…
Я продолжаю свое мета-исследование различных отчетов про внедрение AI и мне понравилась серия постов от McKinsey, которые системно и ритмично исследуют данный вопрос. Они начали делать это в 2023 году и продолжали…
❤6👍4🔥3
Dispatch from the Future: building an AI-native Company (Рубрика #AI)
Посмотерл претенциозный доклад Dan Shipper, сооснователя и CEO Every. Он запустил Every в 2020 году вместе с Nathan Baschez, а сегодня Every — это команда из 15 человек, которая управляет 6 бизнес-юнитами и 4 продуктами, публикует ежедневную рассылку об AI и консалтит.
Как по мне масштаб компании небольшой, но тезисы амбициозные и интересные, поэтому я привел их здесь
1️⃣ Квантовый скачок при 100% adoption
Разница между организацией, где 90% инженеров используют AI, и организацией со 100% adoption — это не 10%, а 10x. Если хотя бы 10% команды использует традиционные методы разработки, вся организация откатывается к старым процессам. Физика разработки меняется только при полном переходе.
2️⃣ 2. Один разработчик = продакшн-приложение
В Every каждый из четырех продуктов построен одним инженером. Это не игрушки: Cora (AI email assistant) обрабатывает тысячи почтовых ящиков, Monologue (speech-to-text) используют для написания миллионов слов в неделю, Spiral (AI writing partner) генерирует контент с миллионами показов. 99% кода написано AI-агентами — никто не пишет код руками.
3️⃣ От code editor к делегированию агентнам
Ключевое изменение — переход от редактора кода к terminal-based workflow с Claude Code, который убирает традиционный code editor и позволяет делегировать задачи агентам. Это открывает возможность параллельного выполнения: разработчики запускают 4 окна с агентами одновременно, работая над разными фичами.
4️⃣ Demo culture vs Memo culture
Когда код становится дешевым, компании переходят от "memo culture" (писать документы и убеждать коллег) к "demo culture" — можно за пару часов сделать прототип и показать. Это позволяет делать более странные и интересные вещи, которые сложно описать словами, но легко почувствовать.
5️⃣ Compounding Engineering
Every разработала методологию Compounding Engineering: каждая фича делает следующую фичу проще, а не сложнее. Цикл состоит из 4 этапов:
- Plan (40%): агенты изучают кодовую базу и создают детальные планы
- Work (20%): агенты пишут код и тесты
- Review (20%): оценка качества через тесты, код-ревью, субагентов
- Compound (20%): кодификация всех learnings в промпты, субагентов, slash-команды
6️⃣ Вторичные эффекты
Полный AI-adoption разблокирует неочевидные преимущества:
- Tacit code sharing: агенты могут читать репо соседних проектов и переносить паттерны в другой стек без явных библиотек
- Новички продуктивны с первого дня: вся организационная база знаний закодирована в claude.md файлах
- Cross-app commits: разработчики фиксят баги в чужих продуктах, потому что это просто
- Polyglot stack: каждый продукт может использовать свой язык и фреймворк — AI справляется с трансляцией
- Менеджеры коммитят код: даже CEO может коммитить production code между встречами
7️⃣ Fractured Attention Programming
AI позволяет работать с "раздробленным вниманием", когда раньше нужен был 3-4 часовой фокус-блок. Теперь: вышел из встречи → дал задачу агенту → пошел на другую встречу → вернулся к готовому результату → сделал PR.
Это влечет за собой следующие изменения для разработки
1) Изменения экономики разработки
- Параллелизм вместо последовательности: с агентами разработчик работает с 3-4 задачами одновременно в разных worktrees, а не с одной, как было раньше
- Снижение стоимости старта: prototype-first подход становится доминирующим
- Инверсия роли разработчика: код пишут агенты, разработчики становятся "оркестраторами"
2) Трансформация процессов
- Новые примитивы: появляются agents.md файлы с контекстом проекта, кастомные субагенты для специфичных задач и т.д (это способ кодификации знаний организации)
- Сдвиг от документации к артефактам: агенты читают код и другие примитивы напрямую
- Изменение hiring: больше не нужны недели на онбординг и не так важно знание конкретного стека
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Посмотерл претенциозный доклад Dan Shipper, сооснователя и CEO Every. Он запустил Every в 2020 году вместе с Nathan Baschez, а сегодня Every — это команда из 15 человек, которая управляет 6 бизнес-юнитами и 4 продуктами, публикует ежедневную рассылку об AI и консалтит.
Как по мне масштаб компании небольшой, но тезисы амбициозные и интересные, поэтому я привел их здесь
1️⃣ Квантовый скачок при 100% adoption
Разница между организацией, где 90% инженеров используют AI, и организацией со 100% adoption — это не 10%, а 10x. Если хотя бы 10% команды использует традиционные методы разработки, вся организация откатывается к старым процессам. Физика разработки меняется только при полном переходе.
2️⃣ 2. Один разработчик = продакшн-приложение
В Every каждый из четырех продуктов построен одним инженером. Это не игрушки: Cora (AI email assistant) обрабатывает тысячи почтовых ящиков, Monologue (speech-to-text) используют для написания миллионов слов в неделю, Spiral (AI writing partner) генерирует контент с миллионами показов. 99% кода написано AI-агентами — никто не пишет код руками.
3️⃣ От code editor к делегированию агентнам
Ключевое изменение — переход от редактора кода к terminal-based workflow с Claude Code, который убирает традиционный code editor и позволяет делегировать задачи агентам. Это открывает возможность параллельного выполнения: разработчики запускают 4 окна с агентами одновременно, работая над разными фичами.
4️⃣ Demo culture vs Memo culture
Когда код становится дешевым, компании переходят от "memo culture" (писать документы и убеждать коллег) к "demo culture" — можно за пару часов сделать прототип и показать. Это позволяет делать более странные и интересные вещи, которые сложно описать словами, но легко почувствовать.
5️⃣ Compounding Engineering
Every разработала методологию Compounding Engineering: каждая фича делает следующую фичу проще, а не сложнее. Цикл состоит из 4 этапов:
- Plan (40%): агенты изучают кодовую базу и создают детальные планы
- Work (20%): агенты пишут код и тесты
- Review (20%): оценка качества через тесты, код-ревью, субагентов
- Compound (20%): кодификация всех learnings в промпты, субагентов, slash-команды
6️⃣ Вторичные эффекты
Полный AI-adoption разблокирует неочевидные преимущества:
- Tacit code sharing: агенты могут читать репо соседних проектов и переносить паттерны в другой стек без явных библиотек
- Новички продуктивны с первого дня: вся организационная база знаний закодирована в claude.md файлах
- Cross-app commits: разработчики фиксят баги в чужих продуктах, потому что это просто
- Polyglot stack: каждый продукт может использовать свой язык и фреймворк — AI справляется с трансляцией
- Менеджеры коммитят код: даже CEO может коммитить production code между встречами
7️⃣ Fractured Attention Programming
AI позволяет работать с "раздробленным вниманием", когда раньше нужен был 3-4 часовой фокус-блок. Теперь: вышел из встречи → дал задачу агенту → пошел на другую встречу → вернулся к готовому результату → сделал PR.
Это влечет за собой следующие изменения для разработки
1) Изменения экономики разработки
- Параллелизм вместо последовательности: с агентами разработчик работает с 3-4 задачами одновременно в разных worktrees, а не с одной, как было раньше
- Снижение стоимости старта: prototype-first подход становится доминирующим
- Инверсия роли разработчика: код пишут агенты, разработчики становятся "оркестраторами"
2) Трансформация процессов
- Новые примитивы: появляются agents.md файлы с контекстом проекта, кастомные субагенты для специфичных задач и т.д (это способ кодификации знаний организации)
- Сдвиг от документации к артефактам: агенты читают код и другие примитивы напрямую
- Изменение hiring: больше не нужны недели на онбординг и не так важно знание конкретного стека
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
YouTube
Dispatch from the Future: building an AI-native Company – Dan Shipper, Every, AI & I
The central thesis is that there is a "10x difference" between an organization where 90% of engineers use AI versus one where 100% do. At 100% adoption, the fundamental physics of software engineering change: a single developer can build and maintain complex…
🔥9❤6😱2⚡1😁1
2025 LLM Year in Review by Karpathy (Рубрика #AI)
Интересное ревью 2025 года от Андрей Карпаты, где он говорит про сдвиги парадигмы, которые поменяли ландшафт LLM
1️⃣ Reinforcement Learning from Verifiable Rewards (RLVR). К классическому стеку (pretrain → SFT → RLHF) добавился большой этап reinforcement learning по "проверяемым" наградам (математика/код-паззлы). Длиннее RL-прогоны → лучше capability/$, плюс появился рычаг test-time compute ("пусть модель думает дольше").
2️⃣ Ghosts vs. Animals / Jagged Intelligence. LLM — это скорее "призраки", а не "животные". В одном месте гений, в другом — легко ломается/джейлбрейкается. Отсюда скепсис к бенчмаркам: их всё проще "обучить до смерти".
3️⃣ Cursor / new layer of LLM apps. Cursor можно воспринимать как шаблон LLM-app: отдельный слой продуктов = context engineering + оркестрация вызовов (DAG) + UI для human-in-the-loop + 🎛 autonomy slider. Отсюда появилась фраза про создание "Cursor for X".
4️⃣ Claude Code / AI that lives on your computer. Агент должен "жить" на твоей машине рядом с реальной средой (конфиги, секреты, данные, низкая латентность), а не в абстрактных облачных контейнерах.
5️⃣ Vibe coding. Интересно слышать тезисы от создателя термина vibe coding - по его мнению, порог пройден и теперь можно собирать рабочие штуки, используя самый распространенный язык программирования (английский ). Код становится дешёвым, одноразовым и пластичным (хоть ради одного прогона).
6️⃣ Nano banana / LLM GUI. Чат — это консоль 80-х. Следующий UX — визуальные артефакты (слайды, схемы, whiteboard, web-app’ы). “Nano banana” у Google — ранний намёк на направление.
А вообще, я рекомендую прочитать эти тезисы в оригинале, благо он очень короткий.
#AI #ML #Trends #Software #Engineering #Future
Интересное ревью 2025 года от Андрей Карпаты, где он говорит про сдвиги парадигмы, которые поменяли ландшафт LLM
1️⃣ Reinforcement Learning from Verifiable Rewards (RLVR). К классическому стеку (pretrain → SFT → RLHF) добавился большой этап reinforcement learning по "проверяемым" наградам (математика/код-паззлы). Длиннее RL-прогоны → лучше capability/$, плюс появился рычаг test-time compute ("пусть модель думает дольше").
2️⃣ Ghosts vs. Animals / Jagged Intelligence. LLM — это скорее "призраки", а не "животные". В одном месте гений, в другом — легко ломается/джейлбрейкается. Отсюда скепсис к бенчмаркам: их всё проще "обучить до смерти".
3️⃣ Cursor / new layer of LLM apps. Cursor можно воспринимать как шаблон LLM-app: отдельный слой продуктов = context engineering + оркестрация вызовов (DAG) + UI для human-in-the-loop + 🎛 autonomy slider. Отсюда появилась фраза про создание "Cursor for X".
4️⃣ Claude Code / AI that lives on your computer. Агент должен "жить" на твоей машине рядом с реальной средой (конфиги, секреты, данные, низкая латентность), а не в абстрактных облачных контейнерах.
5️⃣ Vibe coding. Интересно слышать тезисы от создателя термина vibe coding - по его мнению, порог пройден и теперь можно собирать рабочие штуки, используя самый распространенный язык программирования (
6️⃣ Nano banana / LLM GUI. Чат — это консоль 80-х. Следующий UX — визуальные артефакты (слайды, схемы, whiteboard, web-app’ы). “Nano banana” у Google — ранний намёк на направление.
А вообще, я рекомендую прочитать эти тезисы в оригинале, благо он очень короткий.
#AI #ML #Trends #Software #Engineering #Future
karpathy
2025 LLM Year in Review
2025 Year in Review of LLM paradigm changes
🔥8❤3😐2⚡1
История стартапа Lovable, что вырос в оценке с нуля до $6.6 млрд всего за один год (Рубрика #Startup)
Компания Lovable (изначально известная как проект GPT Engineer) была официально основана в ноябре 2023 года в Стокгольме. Ее основали Anton Osika, бывший инженер CERN (опыт в ML и физике), и Fabian Hedin, серийный предприниматель и инженер. Интересно, что история компании началась с вирального open-source проекта gpt-engineer, CLI-утилиты, которая позволяла сгенерировать кодовую базу проекта по одному текстовому промпту. Проект стал хитом на GitHub (набрал десятки тысяч звезд за дни), показав огромный спрос на автоматическую генерацию кода. Увидев интерес, основатели решили превратить инструмент в полноценный коммерческий продукт для веб-разработки и запустили в конце 2023 года коммерческую версию. А в декабре 2024 года произошел ребрендинг: платформа получила имя Lovable, чтобы отразить фокус на создании продуктов, которые «нравятся людям», и уйти от технического названия.
Если говорить про бизнес-модели, то они прошли путь
- Бесплатного open-source инструмента
- SaaS с фокусом на потребление ресурсов (usage-based pricing), где есть кредиты (что покрывают затраты на inference LLMs)
В итоге, сейчас Lovable продает не просто "редактор кода", а "результат". Вы платите за вычисления (compute credits), которые тратятся на итерации агента (написание кода, фикс багов, развертывание). И этот подход очень нравится инвесторам.
В 2025 году компания продемонстрировала одну из самых быстрых динамик роста оценки в истории европейских стартапов.
1. Pre-Series A (Февраль 2025) - $15 млн, лид-инвестор - Creandum, ангелы: Чарли Сонгхерст (экс-Microsoft), Адам Д'Анджело (CEO Quora), Томас Вольф (Hugging Face).
2. Series A (Июль 2025) - $200 млн, оценка - $1.8 млрд, лид-инвестор - Accel, участники: 20VC, byFounders, Hummingbird, Visionaries Club
3. Series B (Декабрь 2025) - $330 млн, оценка - $6.6 млрд, лид-инвесторы: CapitalG (фонд роста Alphabet/Google) и Menlo Ventures, стратегические инвесторы: NVentures (Nvidia), Salesforce Ventures, Databricks Ventures, Atlassian Ventures.
Уже в раунде B подключилились такие тяжеловесы, что видно, что Lovable воспринимается не просто как "еще один редактор", а как ключевой игрок в инфраструктуре AI-разработки.
На январь 2026 года Lovable представляет собой Full-Stack AI Builder. В отличие от Cursor (IDE для программистов), Lovable позиционируется как инструмент для создания конечного продукта, часто доступный даже не-инженерам (концепция "vibe coding" — вы описываете, что хотите, а система пишет код). Интерфейс Lovable выглядит как веб-приложение с чатом слева и живым превью приложения справа. На выходе получаются веб приложения на React, Tailwind, Node.js/Supabase код. Пользователь может видеть код, экспортировать его в GitHub и дорабатывать вручную (или при помощи других агентов). Из коробки работает интеграция с СУБД (Supabase), аутентификация и платежи. Агенты Lovable достаточно автономны - они умеют сами читать файлы проекта, находить ошибки и предлагать исправления, не требуя от пользователя указывать конкретную строку кода.
Если говорить про известные планы, то они примерно такие
1. Enterprise-сегмент: Внедрение функций Governance (управление политиками безопасности кода), чтобы крупные компании могли безопасно использовать инструмент.
2. Автономные агенты 2.0: Переход от "помощника" к "автономному инженеру", который может поддерживать проект, обновлять зависимости и рефакторить код в фоновом режиме.
3. Географическая экспансия: Открытие офисов в США (Бостон, Сан-Франциско) для агрессивного захвата американского рынка.
4. Lovable Cloud: Развитие собственной облачной инфраструктуры для хостинга приложений, чтобы пользователю вообще не нужно было думать о серверах или внешних провайдерах (Backend-as-a-Service).
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
Компания Lovable (изначально известная как проект GPT Engineer) была официально основана в ноябре 2023 года в Стокгольме. Ее основали Anton Osika, бывший инженер CERN (опыт в ML и физике), и Fabian Hedin, серийный предприниматель и инженер. Интересно, что история компании началась с вирального open-source проекта gpt-engineer, CLI-утилиты, которая позволяла сгенерировать кодовую базу проекта по одному текстовому промпту. Проект стал хитом на GitHub (набрал десятки тысяч звезд за дни), показав огромный спрос на автоматическую генерацию кода. Увидев интерес, основатели решили превратить инструмент в полноценный коммерческий продукт для веб-разработки и запустили в конце 2023 года коммерческую версию. А в декабре 2024 года произошел ребрендинг: платформа получила имя Lovable, чтобы отразить фокус на создании продуктов, которые «нравятся людям», и уйти от технического названия.
Если говорить про бизнес-модели, то они прошли путь
- Бесплатного open-source инструмента
- SaaS с фокусом на потребление ресурсов (usage-based pricing), где есть кредиты (что покрывают затраты на inference LLMs)
В итоге, сейчас Lovable продает не просто "редактор кода", а "результат". Вы платите за вычисления (compute credits), которые тратятся на итерации агента (написание кода, фикс багов, развертывание). И этот подход очень нравится инвесторам.
В 2025 году компания продемонстрировала одну из самых быстрых динамик роста оценки в истории европейских стартапов.
1. Pre-Series A (Февраль 2025) - $15 млн, лид-инвестор - Creandum, ангелы: Чарли Сонгхерст (экс-Microsoft), Адам Д'Анджело (CEO Quora), Томас Вольф (Hugging Face).
2. Series A (Июль 2025) - $200 млн, оценка - $1.8 млрд, лид-инвестор - Accel, участники: 20VC, byFounders, Hummingbird, Visionaries Club
3. Series B (Декабрь 2025) - $330 млн, оценка - $6.6 млрд, лид-инвесторы: CapitalG (фонд роста Alphabet/Google) и Menlo Ventures, стратегические инвесторы: NVentures (Nvidia), Salesforce Ventures, Databricks Ventures, Atlassian Ventures.
Уже в раунде B подключилились такие тяжеловесы, что видно, что Lovable воспринимается не просто как "еще один редактор", а как ключевой игрок в инфраструктуре AI-разработки.
На январь 2026 года Lovable представляет собой Full-Stack AI Builder. В отличие от Cursor (IDE для программистов), Lovable позиционируется как инструмент для создания конечного продукта, часто доступный даже не-инженерам (концепция "vibe coding" — вы описываете, что хотите, а система пишет код). Интерфейс Lovable выглядит как веб-приложение с чатом слева и живым превью приложения справа. На выходе получаются веб приложения на React, Tailwind, Node.js/Supabase код. Пользователь может видеть код, экспортировать его в GitHub и дорабатывать вручную (или при помощи других агентов). Из коробки работает интеграция с СУБД (Supabase), аутентификация и платежи. Агенты Lovable достаточно автономны - они умеют сами читать файлы проекта, находить ошибки и предлагать исправления, не требуя от пользователя указывать конкретную строку кода.
Если говорить про известные планы, то они примерно такие
1. Enterprise-сегмент: Внедрение функций Governance (управление политиками безопасности кода), чтобы крупные компании могли безопасно использовать инструмент.
2. Автономные агенты 2.0: Переход от "помощника" к "автономному инженеру", который может поддерживать проект, обновлять зависимости и рефакторить код в фоновом режиме.
3. Географическая экспансия: Открытие офисов в США (Бостон, Сан-Франциско) для агрессивного захвата американского рынка.
4. Lovable Cloud: Развитие собственной облачной инфраструктуры для хостинга приложений, чтобы пользователю вообще не нужно было думать о серверах или внешних провайдерах (Backend-as-a-Service).
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
🔥9❤8⚡2👍2
[1/2] State of Web Dev AI 2025 - Анализ результатов для инженеров (Рубрика #AI)
Почти год назад платформа Devographics провела первый опрос разработчиков, чтобы оценить состояние AI для веб разработки. Этот отчет я изучил еще осенью, но как-то забыл написать про него, поэтому исправлю это сейчас.
Методология отчета
Опрос проходил с 10 февраля по 10 марта 2025 года, участие приняли 4 181 веб-разработчик. Анкета изучала, как программисты применяют ИИ в работе, какие инструменты самые полезные и с какими проблемами сталкиваются. Опрос был открытым для всех желающих, поэтому в выборке, вероятно, больше энтузиастов ИИ (аудитория набрана в том числе из подписчиков State of JS/CSS). По итогам получились такие результаты
Как разработчики используют ИИ
🤖 Генерация кода – главный сценарий применения: ~82% опрошенных используют AI для написания программного кода. Для сравнения, генерацию изображений применяет лишь 38% – несмотря на шум вокруг Midjourney и др., визуальные инструменты остаются нишевыми в веб-разработке.
😑 Доля AI-кода пока невелика. У 69% респондентов ИИ генерирует меньше четверти итогового кода, и только 8% получают с помощью AI более 75% своего кода. Иными словами, для большинства разработчиков ассистенты пока пишут отдельные фрагменты, а не весь проект целиком.
⚙️ Частота и эффективность: почти половина (46%) программистов запускают генерацию кода с помощью AI несколько раз в день или чаще. Многие включили такие инструменты в свой ежедневный workflow. Более того, большинство опрошенных согласны, что AI-помощники заметно повысили их продуктивность
Популярные AI-инструменты
🤖 ChatGPT от OpenAI – абсолютный лидер по охвату: 91% веб-разработчиков хотя бы попробовали его в работе. Другие крупные модели тоже набирают пользователей: ~55–60% респондентов экспериментировали с Anthropic Claude, Microsoft Copilot (модельным бэкендом) или Google Gemini. Для сравнения, у нового xAI Grok этот показатель лишь ~25%.
🧑💻 GitHub Copilot – самый популярный coding assistant (AI-плагин для автодополнения кода). Им пользуются ~71% участников опроса, и он лидирует по доле положительных отзывов. Для сравнения, остальные ассистенты типа Tabnine или JetBrains AI сильно отстают (порядка 10–15% пользователей). Зато Supermaven выделяется: им пока пробовали <10%, но отзывы очень высокие – возможная «темная лошадка», способная выстрелить в ближайшем будущем.
Проблемные точки
⚠️ Надежность и качество кода. Галлюцинации, фактические ошибки и ограниченный контекст модели – главные препятствия для широкого применения AI-инструментов. В итоге 76% разработчиков переписывают минимум половину кода, сгенерированного ИИ, прежде чем использовать его. Нередко причина проста: полученный фрагмент не работает так, как задумано. Без тщательного ревью и тестов доверять AI-коду пока нельзя.
💰 Расходы на инструменты. Большинство разработчиков пользуются бесплатными версиями AI-сервисов: свыше 90% тратят меньше $50 в месяц, в том числе 52% не платят ничего. Компании тоже осторожны с бюджетом: ~38% команд не инвестируют в AI совсем, а ~12% уже расходуют большие суммы (> $5000 ежемесячно). Пока многие выжидают, оценивая реальную отдачу от AI-инструментов.
В продолжении рассказ про результаты опроса, что могут быть интересны техническим лидерам
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps
Почти год назад платформа Devographics провела первый опрос разработчиков, чтобы оценить состояние AI для веб разработки. Этот отчет я изучил еще осенью, но как-то забыл написать про него, поэтому исправлю это сейчас.
Методология отчета
Опрос проходил с 10 февраля по 10 марта 2025 года, участие приняли 4 181 веб-разработчик. Анкета изучала, как программисты применяют ИИ в работе, какие инструменты самые полезные и с какими проблемами сталкиваются. Опрос был открытым для всех желающих, поэтому в выборке, вероятно, больше энтузиастов ИИ (аудитория набрана в том числе из подписчиков State of JS/CSS). По итогам получились такие результаты
Как разработчики используют ИИ
⚙️ Частота и эффективность: почти половина (46%) программистов запускают генерацию кода с помощью AI несколько раз в день или чаще. Многие включили такие инструменты в свой ежедневный workflow. Более того, большинство опрошенных согласны, что AI-помощники заметно повысили их продуктивность
Популярные AI-инструменты
🤖 ChatGPT от OpenAI – абсолютный лидер по охвату: 91% веб-разработчиков хотя бы попробовали его в работе. Другие крупные модели тоже набирают пользователей: ~55–60% респондентов экспериментировали с Anthropic Claude, Microsoft Copilot (модельным бэкендом) или Google Gemini. Для сравнения, у нового xAI Grok этот показатель лишь ~25%.
🧑💻 GitHub Copilot – самый популярный coding assistant (AI-плагин для автодополнения кода). Им пользуются ~71% участников опроса, и он лидирует по доле положительных отзывов. Для сравнения, остальные ассистенты типа Tabnine или JetBrains AI сильно отстают (порядка 10–15% пользователей). Зато Supermaven выделяется: им пока пробовали <10%, но отзывы очень высокие – возможная «темная лошадка», способная выстрелить в ближайшем будущем.
Проблемные точки
⚠️ Надежность и качество кода. Галлюцинации, фактические ошибки и ограниченный контекст модели – главные препятствия для широкого применения AI-инструментов. В итоге 76% разработчиков переписывают минимум половину кода, сгенерированного ИИ, прежде чем использовать его. Нередко причина проста: полученный фрагмент не работает так, как задумано. Без тщательного ревью и тестов доверять AI-коду пока нельзя.
💰 Расходы на инструменты. Большинство разработчиков пользуются бесплатными версиями AI-сервисов: свыше 90% тратят меньше $50 в месяц, в том числе 52% не платят ничего. Компании тоже осторожны с бюджетом: ~38% команд не инвестируют в AI совсем, а ~12% уже расходуют большие суммы (> $5000 ежемесячно). Пока многие выжидают, оценивая реальную отдачу от AI-инструментов.
В продолжении рассказ про результаты опроса, что могут быть интересны техническим лидерам
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps
Please open Telegram to view this post
VIEW IN TELEGRAM
2025.stateofai.dev
State of AI 2025
1❤6👍3👎1🔥1
[2/2] State of Web Dev AI 2025 - Анилиз для руководителей (Рубрика #AI)
Продолжая рассказ про отчет, надо отметить, что AI-инструменты влияют не только на код, но и на организацию работы команд разработки. Ниже – ключевые инсайты для технических лидеров о том, как интеграция ИИ меняет рабочие процессы, роли и затраты.
AI в процессах и продуктивности команды
🤖 Часть ежедневного workflow. AI-инструменты прочно вошли в повседневную практику: 59% опрошенных согласны, что ИИ стал неотъемлемой частью их разработки. Почти половина инженеров (46%) запускают генерацию кода с помощью AI несколько раз в день – фактически AI уже выступает “вторым пилотом” для разработчиков на многих задачах.
📈 ROI – рост производительности. Большинство инженеров отмечают, что AI-средства сделали их продуктивнее. Для менеджера это означает ускорение доставки: рутинные этапы (шаблонный код, документация, тесты) можно поручить ИИ и выполнить быстрее, освободив команду для творчества и решения сложных проблем.
🛠 Интеграция инструментов. Специализированные AI-IDE пока нишевы – лишь ~42% респондентов пробовали такие среды. Команды предпочитают добавлять AI-функции в знакомые IDE (VS Code, IntelliJ и др.), а не переходить на новые редакторы, поэтому эффективнее внедрять AI-плагины в существующий стек, чем заставлять всех осваивать совершенно новые решения.
💰 Бюджеты на AI. Многие компании осторожничают: ~38% вообще не тратят на AI-сервисы, тогда как ~12% уже инвестируют серьёзно (> $5000 в месяц). Большинство разработчиков также ограничивается бесплатными инструментами (94% платят <$50 в мес, из них ~52% — $0).
Кадры, структура и риски
🧑💼 Навыки и новые роли. Важный новый skill – умение эффективно пользоваться AI. Средний разработчик уже попробовал почти 4 разных AI-модели, экспериментируя в поисках лучших инструментов. Навык написания грамотных промптов и проверки AI-результатов становится частью профессии. В некоторых компаниях появляются роли вроде AI-евангелиста или внутреннего эксперта, обучающего команду работе с ИИ.
🎓 Поддержание экспертизы. Нельзя допустить деградации навыков из-за чрезмерной зависимости от AI. 60% респондентов согласны, что переизбыток автоматизации может снизить общий уровень квалификации разработчиков. Чтобы этого не случилось, лидерам стоит поощрять полноценные ревью и разбор AI-кода – особенно для роста джунов. Обсуждение решений, полученных от ИИ, должно стать частью обучения: инженеры должны понимать, почему код работает, а не только получать ответ от машины.
🔒 Контроль качества и риски. Руководителю важно встроить AI в процесс контроля. Нужно определить правила: требовать автотесты и ревью для кода, сгенерированного AI, и ограничивать применение генерации в критичных модулях. Основные проблемы ИИ никуда не делись: модель все еще может галлюцинировать, упускать контекст или выдавать уязвимый код. Поэтому ясно обозначьте, где команда может полагаться на AI, а где обязателен ручной контроль.
🚀 Конкурентное преимущество. Правильно внедренный AI – это ускоритель для команды, а не замена живым инженерам. Опрос показывает, что AI по-прежнему дополнение, а не угроза: он ускоряет написание кода, но не отнимает рабочие места (лишь около четверти специалистов видят в ИИ угрозу для своей работы). Как отметил один из экспертов, «те, кто научатся использовать AI, получат преимущество»
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps
Продолжая рассказ про отчет, надо отметить, что AI-инструменты влияют не только на код, но и на организацию работы команд разработки. Ниже – ключевые инсайты для технических лидеров о том, как интеграция ИИ меняет рабочие процессы, роли и затраты.
AI в процессах и продуктивности команды
🤖 Часть ежедневного workflow. AI-инструменты прочно вошли в повседневную практику: 59% опрошенных согласны, что ИИ стал неотъемлемой частью их разработки. Почти половина инженеров (46%) запускают генерацию кода с помощью AI несколько раз в день – фактически AI уже выступает “вторым пилотом” для разработчиков на многих задачах.
📈 ROI – рост производительности. Большинство инженеров отмечают, что AI-средства сделали их продуктивнее. Для менеджера это означает ускорение доставки: рутинные этапы (шаблонный код, документация, тесты) можно поручить ИИ и выполнить быстрее, освободив команду для творчества и решения сложных проблем.
🛠 Интеграция инструментов. Специализированные AI-IDE пока нишевы – лишь ~42% респондентов пробовали такие среды. Команды предпочитают добавлять AI-функции в знакомые IDE (VS Code, IntelliJ и др.), а не переходить на новые редакторы, поэтому эффективнее внедрять AI-плагины в существующий стек, чем заставлять всех осваивать совершенно новые решения.
💰 Бюджеты на AI. Многие компании осторожничают: ~38% вообще не тратят на AI-сервисы, тогда как ~12% уже инвестируют серьёзно (> $5000 в месяц). Большинство разработчиков также ограничивается бесплатными инструментами (94% платят <$50 в мес, из них ~52% — $0).
Кадры, структура и риски
🧑💼 Навыки и новые роли. Важный новый skill – умение эффективно пользоваться AI. Средний разработчик уже попробовал почти 4 разных AI-модели, экспериментируя в поисках лучших инструментов. Навык написания грамотных промптов и проверки AI-результатов становится частью профессии. В некоторых компаниях появляются роли вроде AI-евангелиста или внутреннего эксперта, обучающего команду работе с ИИ.
🎓 Поддержание экспертизы. Нельзя допустить деградации навыков из-за чрезмерной зависимости от AI. 60% респондентов согласны, что переизбыток автоматизации может снизить общий уровень квалификации разработчиков. Чтобы этого не случилось, лидерам стоит поощрять полноценные ревью и разбор AI-кода – особенно для роста джунов. Обсуждение решений, полученных от ИИ, должно стать частью обучения: инженеры должны понимать, почему код работает, а не только получать ответ от машины.
🔒 Контроль качества и риски. Руководителю важно встроить AI в процесс контроля. Нужно определить правила: требовать автотесты и ревью для кода, сгенерированного AI, и ограничивать применение генерации в критичных модулях. Основные проблемы ИИ никуда не делись: модель все еще может галлюцинировать, упускать контекст или выдавать уязвимый код. Поэтому ясно обозначьте, где команда может полагаться на AI, а где обязателен ручной контроль.
🚀 Конкурентное преимущество. Правильно внедренный AI – это ускоритель для команды, а не замена живым инженерам. Опрос показывает, что AI по-прежнему дополнение, а не угроза: он ускоряет написание кода, но не отнимает рабочие места (лишь около четверти специалистов видят в ИИ угрозу для своей работы). Как отметил один из экспертов, «те, кто научатся использовать AI, получат преимущество»
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps
Telegram
Книжный куб
[1/2] State of Web Dev AI 2025 - Анализ результатов для инженеров (Рубрика #AI)
Почти год назад платформа Devographics провела первый опрос разработчиков, чтобы оценить состояние AI для веб разработки. Этот отчет я изучил еще осенью, но как-то забыл написать…
Почти год назад платформа Devographics провела первый опрос разработчиков, чтобы оценить состояние AI для веб разработки. Этот отчет я изучил еще осенью, но как-то забыл написать…
❤7🔥3⚡1
Киберспорт. Игры, деньги, два клика (The Book of Esports) (Рубрика #Game)
Прочитал на каникулах книгу Уильяма Коллиса, геймера и предпринимателя, что соосновал несколько стартапов в киберспорте и успешно продал их, получил прозвище “The Professor” за преподавание киберспорт в колледже, а сейчас он является совладельцем и соучредителем профессиональной киберспортивной команды Team Genji, которая считается №1 в мире по игре Hearthstone.
Уильям решил написать книгу, чтобы сделать понятный гайд для всех, от геймера до инвестора, от родителя киберспортсмена до технического директора, который хочет понять, что творится в этой новой сфере. В итоге, книга вышла на английском в 2020 году и стала первым всеобъемлющим обзором индустрии, а также своеобразным учебником для курсов про киберспорт.
Коллис с первых страниц обозначает амбиции: рассказать обо всех гранях киберспорта. В аннотации прямым текстом перечислено, что читатель узнает:
- Как все начиналось: от первых соревнований по видеоиграм до взрывного роста стриминга – история становления киберспорта шаг за шагом. Автор прослеживает путь от игровых автоматов и LAN-пати к аренам и онлайн-платформам.
- Связь с традиционным спортом: параллели между спортивными состязаниями и их цифровым аналогом. Коллис показывает, что принципы соревнований универсальны: будь то футбол или Dota 2 – важны навыки, командная динамика, зрелищность и дух соперничества.
- Почему успешны именно эти игры: разбирается, как League of Legends, Fortnite, StarCraft, Dota 2 и другие стали киберспортивными хитами. Здесь автор вводит понятие факторы SCAR – четыре условия, без которых игра не станет киберспортом Skill, Community, Accessibility, Reward (мастерство, сообщество, доступность, награда). Коллис показывает, что, например, StarCraft заложил основу: высокая планка мастерства, сплоченное сообщество, легкость начать играть и серьезные призы – все это сделало его глобальным явлением.
- Бизнес и инвестиции: отдельный фокус – что нужно знать компаниям, решившим вложиться в киберспорт. Автор делится стратегическими мыслями о том, на чем зарабатывают турниры, команды, стриминговые платформы. Рассматриваются модели монетизации - Коллис даже предлагает свою аббревиатуру BAMS: Blade & razors, Advertising & assets, Microtransactions, Subscriptions. Для руководителей тут ценно увидеть, как выстроена экономика индустрии: спонсорства, медиаправа, продажи внутриигровых товаров – все кирпичики большого бизнеса.
- Будущее киберспорта: Коллис заглядывает вперед, рассуждая, что ждет индустрию завтра. Поднимаются вопросы: какие новые жанры появятся (он вспоминает, как жанр королевской битвы внезапно ворвался с PUBG), не превратится ли любой видеоигровой жанр в соревнование. Интересна модель OMENS, в которой автор рассказывает про факторы, что влияют на возможность игры удержаться в топе киберспортивных игр. OMENS расшифровывается как Opportunities for competition, Monetization, Ecosystem support, Network effects, Switching costs. Не обязательно, чтобы все факторы сходились воедино, но чем их больше, тем выше шансы игры приблизиться идеалу. Кстати, тут проскальзывает интересная аналогия про кетчуп и горчицу - кетчуп имеет устойчивый вкус и ожидания, а горчицы все разные. В итоге, чтобы игра могла стать киберспортивной дисциплиной, ей стоит быть похожей на кетчуп и следовать модели OMENS
- Альтернативные версии киберспорта. В финальной главе обсуждается новый класс состязаний, способный сделать киберспортом даже Super Mario Bros. – намек на спидраны и другие нестандартные форматы из разряда «безупречных побед». Также автор говорит о грядущих сдвигах: слияние человеческих и машинных навыков, развитие ИИ в играх и другие футуристические идеи.
Отдельно отмечу, что книга написана простым языком и понятна широкой аудитории, то есть основы киберспорта в изложении Колиинса поймет даже человек далекий от игр. Одновременно автор не скучен и для старожилов: он вплетает истории о культовых матчах, курьезах индустрии, интервью с известными киберспортсменами, делая повествование «живым».
#Game #Design #Engineering #Software
Прочитал на каникулах книгу Уильяма Коллиса, геймера и предпринимателя, что соосновал несколько стартапов в киберспорте и успешно продал их, получил прозвище “The Professor” за преподавание киберспорт в колледже, а сейчас он является совладельцем и соучредителем профессиональной киберспортивной команды Team Genji, которая считается №1 в мире по игре Hearthstone.
Уильям решил написать книгу, чтобы сделать понятный гайд для всех, от геймера до инвестора, от родителя киберспортсмена до технического директора, который хочет понять, что творится в этой новой сфере. В итоге, книга вышла на английском в 2020 году и стала первым всеобъемлющим обзором индустрии, а также своеобразным учебником для курсов про киберспорт.
Коллис с первых страниц обозначает амбиции: рассказать обо всех гранях киберспорта. В аннотации прямым текстом перечислено, что читатель узнает:
- Как все начиналось: от первых соревнований по видеоиграм до взрывного роста стриминга – история становления киберспорта шаг за шагом. Автор прослеживает путь от игровых автоматов и LAN-пати к аренам и онлайн-платформам.
- Связь с традиционным спортом: параллели между спортивными состязаниями и их цифровым аналогом. Коллис показывает, что принципы соревнований универсальны: будь то футбол или Dota 2 – важны навыки, командная динамика, зрелищность и дух соперничества.
- Почему успешны именно эти игры: разбирается, как League of Legends, Fortnite, StarCraft, Dota 2 и другие стали киберспортивными хитами. Здесь автор вводит понятие факторы SCAR – четыре условия, без которых игра не станет киберспортом Skill, Community, Accessibility, Reward (мастерство, сообщество, доступность, награда). Коллис показывает, что, например, StarCraft заложил основу: высокая планка мастерства, сплоченное сообщество, легкость начать играть и серьезные призы – все это сделало его глобальным явлением.
- Бизнес и инвестиции: отдельный фокус – что нужно знать компаниям, решившим вложиться в киберспорт. Автор делится стратегическими мыслями о том, на чем зарабатывают турниры, команды, стриминговые платформы. Рассматриваются модели монетизации - Коллис даже предлагает свою аббревиатуру BAMS: Blade & razors, Advertising & assets, Microtransactions, Subscriptions. Для руководителей тут ценно увидеть, как выстроена экономика индустрии: спонсорства, медиаправа, продажи внутриигровых товаров – все кирпичики большого бизнеса.
- Будущее киберспорта: Коллис заглядывает вперед, рассуждая, что ждет индустрию завтра. Поднимаются вопросы: какие новые жанры появятся (он вспоминает, как жанр королевской битвы внезапно ворвался с PUBG), не превратится ли любой видеоигровой жанр в соревнование. Интересна модель OMENS, в которой автор рассказывает про факторы, что влияют на возможность игры удержаться в топе киберспортивных игр. OMENS расшифровывается как Opportunities for competition, Monetization, Ecosystem support, Network effects, Switching costs. Не обязательно, чтобы все факторы сходились воедино, но чем их больше, тем выше шансы игры приблизиться идеалу. Кстати, тут проскальзывает интересная аналогия про кетчуп и горчицу - кетчуп имеет устойчивый вкус и ожидания, а горчицы все разные. В итоге, чтобы игра могла стать киберспортивной дисциплиной, ей стоит быть похожей на кетчуп и следовать модели OMENS
- Альтернативные версии киберспорта. В финальной главе обсуждается новый класс состязаний, способный сделать киберспортом даже Super Mario Bros. – намек на спидраны и другие нестандартные форматы из разряда «безупречных побед». Также автор говорит о грядущих сдвигах: слияние человеческих и машинных навыков, развитие ИИ в играх и другие футуристические идеи.
Отдельно отмечу, что книга написана простым языком и понятна широкой аудитории, то есть основы киберспорта в изложении Колиинса поймет даже человек далекий от игр. Одновременно автор не скучен и для старожилов: он вплетает истории о культовых матчах, курьезах индустрии, интервью с известными киберспортсменами, делая повествование «живым».
#Game #Design #Engineering #Software
❤12👍4🔥2