[1/2] OpenClaw Creator: Why 80% Of Apps Will Disappear (Рубрика #AI)

Интересное и короткое интервью Peter Steinberger, создателя OpenClaw (недавно перешедшего в OpenAI) проlocal-first персональных агентов и то, как они могут "съесть" большую часть привычного софта. Интервью у него брал Raphael Schaad, Visiting Partner в Y Combinator; основатель/CEO Cron (проект купил Notion). Ниже представлены основные инсайты

1️⃣ Local-first агент ≠ «ещё один чат-бот»
Агент живёт на вашей машине/вашем сервере, поэтому может быть шлюзом между чатами и вашими инструментами: файлы, shell, браузер, интеграции - "всё, что может пользователь на компьютере". Это принципиально другой класс возможностей по сравнению с облачным ассистентом. Забавно, что создатель Manus AI рассказывал о том, как они ушли от локального агента в браузере в облако, чтобы отвязаться от локальной машинки:)

2️⃣ Магия - это tool-use + выбор кратчайшего пути
Самый показательный кейс из интервью: голосовое сообщение внезапно само транскрибировалось, хотя функциональность "явно не кодили заранее". Агент сам сделал следующие шаиг
- Определил формат аудио по заголовку (даже без расширения)
- Перегнал через ffmpeg
- Не стал ставить локально Whisper, а выбрал быстрый путь - отправить аудио в speech-to-text API через curl, потому что так быстрее получить результат

В итоге, по мнению Питера конкурентное преимущество смещается от "самой умной модели" к инструментам, оркестрации и данным/памяти пользователя

3️⃣ "80% приложений исчезнет" - речь про приложения‑контейнеры данных
Смысл тезиса не в том, что UI умрёт. А в том, что приложения, чья основная функция - ввод/хранение/менеджмент данных, становятся избыточными, если агент:
- Сам собирает контекст (файлы/логи/фото)
- Пишет/читает из хранилищ
- Планирует/напоминает
- И делает результат без отдельного “перехода в приложение”.

Отдельно проговаривается идея, что выживут продукты, сильно завязанные на специфическое железо/сенсоры.

4️⃣ Главная ценность и риск - "память" агента
Если агент становится персональным, то его “memory” - привычки, контекст, история действий, локальные файлы - это новый приватный периметр. В отчёте подчёркнуто, что такие memory‑файлы могут быть "более приватными", чем условная поисковая история. Также упоминаются файлы вроде SOUL.md / AGENTS.md / TOOLS.md как часть "инжектируемого" контекста в workspace.

5️⃣ CLI как универсальный "адаптер" для агента
Одна из инженерных мыслей, что противоречит текущему вектору: вместо специальных протоколов интеграций агентам часто достаточно обычных человеческих инструментов - CLI. Если есть --help, примеры и предсказуемые команды - агент часто "разберётся". В отчёте это подано как практичный вектор (в т.ч. обсуждение CLI vs MCP).

6️⃣ Security - не "потом", а сразу
Агент, который читает чаты/веб и имеет доступ к shell/файлам/браузеру, резко расширяет поверхность атаки. В отчёте много акцентов на базовых контролях: threat model, изоляция, allowlist, аудит, sandboxing, политики для DMs, защита от prompt injection.

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

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

[2/2] OpenClaw Creator: Why 80% Of Apps Will Disappear (Рубрика #AI)

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

Для разработчиков отсюда можно извлечь следующее
Если ваш продукт можно выразить как операции - агент сможет "съесть" ваш UI. Поэтому фокус смещается на “agent-ready интерфейсы”:
- Tool-first мышление: превратите ключевые фичи в чёткие операции (CRUD/поиск/экспорт/триггеры), которые можно дергать напрямую. Минимум - хорошая CLI или SDK + примеры.
- Документация "как для агента": понятные help‑тексты, примеры входов/выходов, ошибки, ограничения, idempotency там, где возможно.
- Нормализуйте “опасные входы”: prompt injection и неожиданные действия - это базовый режим, если агент читает DMs/почту/веб. Тестируйте это как часть фичи, а не как edge case.
- Локальная память = новый тип "секрета": думайте, что именно агент сохраняет, где лежит workspace, как чистится и бэкапится.

Если хочется посмотреть а как это работает, то можно поднять OpenClaw локально/на тестовом сервере, подключить один канал, включить pairing/allowlist, запретить опасные tool‑группы и прогнать 3 сценария: "поиск/сводка", "операция с файлами", "задача через браузер". А дальше уже оценить насколько это удобно/безопасно/перспективно.

Что это значит для техлидов и технических руководителей
- Пересоберите threat model: "агент с инструментами" - это RPA + LLM + доступ к секретам. Нужны политики: где хранятся ключи, какие каналы доверенные, какие действия требуют подтверждения, как устроена изоляция сессий/пользователей.
- Вводите governance по памяти: ретеншн, классификация данных, экспорт/удаление, audit trail - это станет не менее важным, чем логирование микросервисов.
- Контроль экономики агентности: агентные циклы могут неожиданно "жечь" стоимость из-за контекста/памяти/инструментов. Нужны лимиты, бюджеты, режимы, мониторинг.
Стратегия продукта: если тезис про "80% apps" хотя бы частично верен, дифференциаторы смещаются в
(а) данные/память
(б) безопасные интеграции
(в) доверие/комплаенс
(г) hardware/sensors/сообщества

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture)

На этих выходных мы с Гришей из клуба { между скобок} поговорили про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space. Основные моменты, что мы успели обсудить следующие
​
- Книга по System Design быстро устаревает: паттерны и требования меняются, а живой сайт можно непрерывно допиливать под практику, а не под "вечную теорию"
​- Ожидания на интервью сдвигаются от "знаешь ли ты стандартный набор сервисов и buzzwords" к умению думать как архитектор: трезво выбирать компромиссы, задавать вопросы, формализовывать требования
- Разобрали типовые ошибки кандидатов​
- - Сразу рисовать «кубики и стрелочки» без уточнения ограничений,
- - Оптимизировать за пределами реальных bottleneck’ов
- - Заучивать шаблоны задач вместо понимания инвариантов (consistency, durability, latency budgets и т.д.)
​- System Design интервью на самом деле проверяет не "знаешь ли ты Kafka", а: как ты принимаешь решения, как разговариваешь с продакт менеджером, как эволюционируешь систему от MVP до сложной архитектуры
​- Разница между "рисованием кубиков" и архитектурным мышлением: во втором случае ты всегда привязываешь решения к пользовательским сценариям, нагрузке, отказоустойчивости и стоимости владения, а не просто перечисляешь модные технологии
​- Для senior/staff обязательны темы: масштабирование хранения и вычислений, очереди и асинхрованная работа, кэширование, консистентность, observability, эволюция схемы данных и rollouts, а также работа с неопределённостью и неполными требованиями
​- Готовиться нужно не "по чек-листу задач", а системно: строить свой набор инвариантов и шаблонов мышления, прогонять реальные кейсы, а не просто зубрить решения.
​
Если говорить про инсайты для руководителей, которыми можно поделиться, то
- Интервью по SD стоит перестраивать с "угадай сервис" на разбор реального кейса: дать неполные требования, посмотреть, как кандидат уточняет, режет scope и развивает архитектуру итеративно
​Хорошее SD-интервью - это мини-совместное проектирование: вы вместе выходите хотя бы к первому адекватному приближению системы, а не к идеальной картинке из учебника.
​- Стоит явно формализовать, какие уровни архитектурного мышления вы ждёте от middle/senior/staff, и дать людям прозрачную лестницу роста (в идеале - с примерами на внутренних кейсах).
​- Вместо того чтобы ждать от команды "чтения книг по SD", проще дать живую базу практик, чек-листы и разборы постмортемов - то есть institutional knowledge, а не набор ссылок на классические книги.
​
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

Laravel Origins: A PHP Documentary (Рубрика #Engineering)

Интересный документальный фильм про фреймворк Laravel, который по моему ощущению занял нишу Ruby on Rails, но вместо Ruby тут языком выступает PHP. В фильме присуствуюте ключевые люди и именно они рассказывают историю развития проекта. Например, одна из главных ролей за Taylor Otwell, что создал Laravel и сейчас выступает как BDFL фреймворка ("benevolent dictator for life"), также там есть Jeffrey Way (автор образовательного ресурса Laracasts), Dayle Rees (автор первых книг по Laravel) и другие.

Мы видим последовательное развитие истории:
- Сначала жизнь и работу Тейлора в Арканзасе, а дальше старт проекта Laravel от caravel, где была изменена одна буква в названии коробля
- Ранний рост проекта: первые GitHub‑звезды, переход UserScape на Laravel, полугодовой период, когда Тейлор фактически фуллтайм развивал фреймворк в рамках работы
- Формирование экосистемы: очереди, миграции, пакеты, затем вокруг ядра вырастают Laravel Forge, Envoyer, Spark, Nova, Vapor, которые закрывают полный цикл от разработки до деплоя.
- Комьюнити и медиа: книги Dayle Rees, Laracasts, Laravel News, агенства вроде Tighten, появление Tailwind CSS - как побочный эффект культуры "делать инструменты для других девелоперов"
- Конференции и культура: Laracon в США, Европе, Австралии, "Laracation" как неформальные поездки, ощущение "как любимая группа в городе", а не корпоративное мероприятие.
- Социальный эффект: карьеры тысяч людей, компании уровня Apple, госструктуры США и крупные бренды (например, Winter Olympics API, Boston Celtics) на Laravel.

Ключевые инсайты из фильма такие
- Видно, как Laravel вырос как решение собственных болей Тейлора - поэтому факторы скорости, продуктивности и "fun to use" стали ядром продуктового видения, а не были выстроены от маркетинга
- Сильное, единое видение ("benevolent dictator for life") позволяет фреймворку быть цельным, последовательно эволюционировать и избегать scope creep и дрифта базовых концепций
- DevEx как продукт: документация, выразительный синтаксис, консистентная эстетика кода (вплоть до формата комментариев) - сознательно воспринимаются как конкурентное преимущество
- Коммерческая экосистема не подменяет open‑source, а дополняет его: SaaS‑продукты ведёт команда, а Тейлор фокусируется на ядре и R&D, что сохраняет качество фреймворка

Отдельно видно, что коммьюнити вокруг Laravel сложилось крепкое и отсюда тоже можно извлечь инсайты
- Осознанный дизайн культуры: с первого дня цель - "дружелюбное, chill, welcoming" сообщество, где люди чувствуют принадлежность и не боятся задавать вопросы
- Конкуренция за вклад "в плюс миру": участники соревнуются в количестве бесплатных материалов, тулов и библиотек, а не в токсичности или статусе
- Инклюзивность как практическая работа: создание Larabelles и других инициатив для вовлечения всех в профессию и коммьюнити
- Сообщество как социальный капитал: люди обсуждают, как Laravel поменял их жизнь

Для технического руководителя это напоминание о том, что
- Хороший фреймворк - это не только API, но и эстетика, документация, DX и осознанное лидерство; это так же важно, как техническая "чистота"
- Сильное ядро + продуманная коммерческая надстройка позволяют маленькой команде (порядка пяти человек) поддерживать огромную экосистему и влиять на индустрию
- Сообщество и образовательная инфраструктура (типа Laracasts) критичны для adoption не меньше, чем сам код, особенно в мире, где каждые пару лет приходит новая волна девелоперов
- Инклюзивная, по‑настоящему дружелюбная культура вокруг технологии может стать решающим фактором её популярности и longevity, а не только технические фичи

#Documentary #Software #Architecture #Leadership #Culture #Management

How to be a CEO when AI breaks all the old playbooks | Sequoia CEO Coach Brian Halligan (Рубрика #Management)

Интересная серия подкаста Лённи, в котором к нему пришел Брайан Холлиган, со‑основатель и экс‑CEO HubSpot. Они обсудили каким становится лидерство и бизнес в эпоху ИИ: как нанимать, расти и продавать, когда старые плейбуки трещат по швам. Брайан был CEO 15 лет, а теперь выступает как внутренний CEO‑коуч в Sequoia и ведёт подкаст про лидеров Long Strange Trip.

Основные инсайты примерно такие

1️⃣ Стартовая компанию проще, чем когда‑либо; масштабировать - сложнее, чем когда‑либо
ИИ и облака кратно удешевили запуск, поэтому число компаний взлетит в небеса в ближайшие 10 лет, но шум и конкуренция делают масштабирование и дифференциацию всё труднее

2️⃣ Работа CEO → бесконечный найм и орг‑дизайн
"Взрослые CEO" тратят до половины времени на рекрутинг, интервью и конструкцию exec‑команды, а не на продукт или операционку.

3️⃣ Все ужасно переоценивают своё умение интервьюировать
Инстинкт "мне кажется, он классный" почти ничего не стоит; куда важнее жёсткие blind‑references, рабочие сессии с кандидатом и правильные вопросы про повторный найм

4️⃣ Нужно нанимать "острых" (spiky), а не консенсусных людей
HubSpot перестал использовать консенсус в виде "3/4 от всех голосов" и начал брать людей с сильными плюсами и заметными минусами; это улучшило хит‑рейт

5️⃣ Люди из bigtech почти всегда не заходят компаниям на ранней стадии
Найм из Microsoft/Salesforce/Google на компанию в 50–500 человек часто даёт "импеданс‑мисмэтч": ожидания процесса и ресурсов не совпадают с реальностью стартапа

6️⃣ Базовый плейбук - команда как Red Sox‑2004: микс homegrown и пары "звёзд"
Большая часть менеджмента вырастает изнутри, плюс несколько дорогих ветеранов, а не "ковёр‑самолёт" из McKinsey/FAANG.

7️⃣ Фреймворк LOCK(S) для оценки фаундеров
- L (lovable): хочется за этим человеком идти, он вдохновляет последователей
- O (obsession): глубоко одержим проблемой, сильный founder–market fit
- C (chip on the shoulder): идиома про "затаить обиду", когда человек чувствует себя оскорбленным из-за прошлого оскорбления или предполагаемой несправедливости, тогда появляется внутренняя мотивация "доказать". Тут интересно, что я раньше не знал эту идиому и она мне нравится (кажется, что я лучше всего работаю, когда у меня есть такое чувство)
- K (knowledge): глубокое знание домена
- S (student): фанатичный студент игры, копает и историю, и современность

8️⃣ CEO может стать не любой, но одновременно и ими не только рождаются
Есть редкие "5‑tool CEOs", которые умеют кодить, продавать, вдохновлять, иметь вкус и видение (пример - Брет Тейлор), но большинству приходится добирать умения: обратная связь, детектор BS, вдохновение людей.

9️⃣ Боль №1 у фаундеров - давать фидбек и менять ранних сотрудников
Самое тяжёлое - сказать кофаундеру/раннему head of X: "ты больше не управляешь, ты - визионер/CTO, а мы нанимаем операционного лидера над тобой" и сделать это экологично, но жёстко

🔟 ИИ уже сильно бьёт по разработке и саппорту, но не по enterprise продажам
Кодинг, support, legal уже трансформируются, а enterprise‑продажи, где нужно доверие между двумя людьми, будут последними в белых воротничках, кого заменит ИИ.
Но вообще у всех будут свои персональные агенты, подключённые к почте, календарю и заметкам, которых можно звать в митинги как активного участника, а не просто как запись

Ну и финально про воронку go-to-market, которая становится ориентирована на агентов
- Воронка "Google → сайт → demo" сменится на "Gemini/Claude/ChatGPT → глубокое исследование → уже образованный клиент". Сайт станет менее важен
- На сайте будет "всезнающий аватар", который понимает продукт, цены и контекст клиента, ведёт беседу и пишет в CRM
- У сейлза на созвоне будет свой "аватар", который знает всё о продукте и клиенте и помогает отвечать в реальном времени

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

#Leadership #Management #Software #AI #ML

A Brief History of Bjarne Stroustrup, the Creator of C++ (Рубрика #Engineering)

Интересная история Бьярне Страуструпа, датского учёного в области информатики, автор языка программирования C++. Вся история снята в городке Орхус (Дания), где он родился в 1950 году и учился в университете Орхуса, там же получил магистерскую степень. Дальше он защитил PhD в Кембридже, а затем работал в Bell Labs рядом с Керниганом, Ритчи, Моррисом и др.

Ниже интересные моменты про его биографию, не все из которых я знал
- В программирование Бьярне попал "случайно": выбрал направление "математика с датологией", не понимая, что "datologi" - это компьютерные науки
- На него сильно повлиял Кристен Нюгорд (Kristen Nygaard), создатель Simula и концепции объектно‑ориентированного программирования; идеи структурирования кода в Simula до сих пор для него опорные.
- В Bell Labs Бьярне интересовался операционными системами и архитектурой машин и, не найдя подходящего языка, решил "сделать свой".
- Первый вариант языка назывался "C with Classes" - фактически C с классами в стиле Simula; затем название сменили на C++ (оператор инкремента в C), потому что это было "милое и необычное" имя.

Не забыли они обсудить и сам C++, его предназначение и историю развития
- В какой‑то момент Бьярне знал около 24 языков программирования (Snowball, Algol 68, PL/I, PL/360 и др.) - правда, он говорит, что раньше языки было проще изучать, т.к. у них не было огромного "багажа" и экосистемы.
- Бьярне описывает философию C++ метафорой: "я должен был вырастить сорняк, а не розу", т.е. язык, который выживает и растёт без постоянного "полива" автором.
- Особенно гордится тем, что у C++ не было маркетинговой кампании и "спонсора" - язык распространялся органично, через пользу и сообщество.
- Через 10 лет после появления у C++ было уже около миллиона пользователей, а сейчас оценивается порядка 7 миллионов инженеров, использующих язык.

В итоге, я себе отметил моменты
1. Роль случая - это про вход в профессию и что серьёзные карьерные траектории в ИТ часто начинаются не с продуманного плана, а с любопытства и случайного выбора.
2. Сила хороших идей и наставников - это про встречу с Нюгордом и знакомство с Simula и что один сильный ментор и одна сильная идея (ООП в Simula) могут задать направление целому поколению технологий.
3. Создание инструмента "для себя", а не для рынка - это про то, что фокус на реальной инженерной боли, а не на маркетинге, может дать шанс, что инструмент станет стандартом де‑факто.
4. Устойчивость важнее "идеальности" - тут метаформа сорняка говорит о том, что проектирование для реального мира, а не идеальной академической конструкции приводит к тому, что выживает тот, кто успешно работает в проде, а не на бумаге
5. Рост без маркетинга - это про то, что для инфраструктурных технологий органическое принятие и решённые задачи ценнее пиара.
6. Отношение к работе и мотивация - Бьярне продолжает учить, выступать и писать код, потому что ему "просто интересно видеть, как это используется, и приятно общаться с людьми". В итоге, долгосрочная мотивация строится на удовольствии от процесса и ответственности за последствия своей работы.

#Engineering #Software #Management #Leadership #Architecture

The Rise and Rise of FastAPI (Рубрика #API)

Интересная мини‑документалка о FastAPI, которая длится меньше 10 минут. В ней говорится о том, как FastAPI прошел путь сверхбыстрого роста open source проекта по траектории вида: side‑project → "индустриальный дефолт" для API на Python. После документалки мне стало интересна судьба этого проекта и кажется, что FastAPI "выстрелил" не потому что "он fast", а потому что собрал в одном месте:
- Стандарты** (ASGI, OpenAPI/JSON Schema)
- Типизацию как интерфейс** (type hints → Pydantic модели)
- DevEx как продукт (авто‑документация, предсказуемые ошибки, быстрый старт)
- Композиционную архитектуру (Starlette‑стек, middleware, зависимости)
В итоге, для команд, что его используют результаты выглядят так, что у них меньше боли на границах ответственности (APE endpoints) + быстрее интеграции + быстрее онбординг

Если говорить про вехи развития проекта, то получится следующее
1️⃣ Side‑project → фреймворк
Фокус был на создании "API без боли": валидируй вход, сериализуй выход, документируй автоматически

2️⃣ Технический стержень
- ASGI‑модель (современная I/O‑архитектура)
- Starlette как "тонкий" веб‑слой
- Pydantic как слой данных: строгая валидация/сериализация поверх type hints

3️⃣ Контракт становится "живым артефактом"
- OpenAPI генерится из кода.
- Интерактивная документация /docs и /redoc делает API‑контракт частью ежедневной разработки, ревью и интеграций

4️⃣ Снежный ком крутого DevEx (developer experience)
- Шаблоны, практики, интеграции, “как правильно” из коробки.
- Порог входа падает → adoption растёт.

5️⃣ Взросление и коммерциализация вокруг поддержки
- Когда популярность становится инфраструктурой для бизнеса, неизбежно появляются: поддержка, консалтинг, managed‑подходы, облака и т.п.
- Это меняет ожидания: "фреймворк" → "платформа вокруг фреймворка".

Если раскрывать ключевые инсайты подробнее, то получаем примерно так
1) FastAPI - это "композиция стандартов + DX", а не "магия"
FastAPI не "заменяет архитектуру". Он фиксирует удачный дефолт: типы → модели → валидация/сериализация → схема → документация.
По итогу у нас становится меньше неявных договорённостей и "случайных JSON"

2) Контракт‑ориентированная разработка - становится нормой
OpenAPI в FastAPI - не "дока на потом", а контракт в процессе:
- Проще подключать фронт
- Проще делать партнёрские интеграции
- Проще ревьюить изменения
В итоге, скорость и надежность на другом уровне

3) Производительность - следствие правильной I/O‑модели, а не цель
ASGI + async дают выигрыш только если вы:
- Не блокируете event loop
- Используете правильные драйверы/клиенты
- Умеете проводить границы sync/async
Правда, "async ради async" = быстрый путь к деградации и непредсказуемым p95/p99

4) OSS‑рост почти всегда приводит к вопросу устойчивости
Если фреймворк становится критическим для тысяч компаний, возникает давление:
- На поддержку
- На эксплуатационные "best practices"
- На продуктовую упаковку вокруг деплоя/наблюдаемости
В итоге, с точки зрения технического руководителя это уже не просто "выбор библиотеки", а уже управление зависимостью

На сайте system-design.space есть чуть более подробный разбор.

#Engineering #Architecture #DistributedSystems #Software #SoftwareArchitecture