Книжный куб

"Engineers are becoming sorcerers" | The future of software development with OpenAI's Sherwin Wu (Рубрика #AI) Очередной интересный выпуск Lenny’s Podcast, в котором Ленни общается со Sherwin Wu, который руководит инженерией OpenAI API / Developer Platform. Sherwin описывает сдвиг роли инженера: от того, чтобы "писать код" к тому, чтобы «управлять флотом AI‑агентов» и принимать инженерные решения на более высоком уровне абстракции. Основные инсайты беседы такие 1️⃣ Codex стал стандартом ~95% инженеров OpenAI используют его ежедневно; работа всё чаще = управление “флотом” 10–20 параллельных AI‑агентов. Кстати, я тоже в восторге от Codex - это просто бомба. С ним я могу не просто обсудить архитектурные вопросы (которые мало с кем могу обсудить на работе), с ним я могу дальше еще и реализовать эти изменения - это просто magic 2️⃣ Ревью автоматизируется OpenAI пишет, что Codex автоматически ревьюит почти каждый PR, и это помогает мерджить ~+70% PR в неделю. 3️⃣ Скорость процесса важнее "кода руками" Ребята обсуждают кейс, где code review сократили с 10–15 до 2–3 минут. 4️⃣ Разрыв продуктивности растёт "AI power users" уезжают вперёд; ближайшие 12–24 месяца - редкое окно, чтобы прокачаться, пока роль инженера не изменилась окончательно. 5️⃣ "Models will eat your scaffolding for breakfast" Не стройте продукт/архитектуру вокруг временных костылей текущих моделей - они быстро исчезают. 6️⃣ Для техлидов/EM Меньше контроля строк кода, больше оркестрации агентов + качества процесса + измерения ROI; отдельно обсуждают, почему многие enterprise‑внедрения AI сейчас дают отрицательный ROI. Что сделать команде для того, чтобы попробовать новый процесс - Ввести паттерн: spec → агент → тесты → PR → авто‑ревью → human‑approve. - Усилить “контракт качества”: тесты/линтеры/статанализ, маленькие PR, чек‑листы. - Начать мерить: lead time PR / время ревью / дефекты после мерджа - иначе AI останется "игрушкой". Это очень перекликается с тренд отчетом на этот год от Anthropic про агентское будущее программирования, о котором я уже рассказывал. В общем, все это напоминает цитату Уильяма Гибсона

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

P.S. Я всегда хотел находиться в той части, где настоящее максимально тесно переплетается с будущим, поэтому в этом году сильно сменил карьерный трек, но об этом как-нибудь в следующий раз ... #AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

How McKinsey Plans to Survive AI (and Reinvent Consulting) (Рубрика #AI) Интересный получасовой эпизод подкаста HBR IdeaCast, в котором Adi Ignatius (HBR) разговаривает с Bob Sternfels (Global Managing Partner / фактически CEO McKinsey). Основная мысль крутится вокруг того, что AI - это на 30–50% "технология", а остальное - это оргдизайн и процессы. Если "прикрутить LLM поверх старого процесса", то будет локальная автоматизация, но не системный рост throughput. Я смотрел с большим интересом и забрал себе следующие инсайты, которые применимы и к разработке софта 1️⃣ Барьер не в модели, а в организации Колодцы, лишние handoff’ы, слои согласований съедают эффект AI сильнее, чем качество промпта. 2️⃣ "Human + agent" - это новая единица производительности У McKinsey внутри нарратив про десятки тысяч "агентов" и движение к "1 агент на человека" (правда, в интервью не ясно, а что такое "агент", поэтому не ясно с чем сравнивать цифры). То есть агентов включают в состав рабочей силы и отмечают рост их количества. 3️⃣ Коммодитизация аналитики → ценность уходит в outcomes Если анализ становится дешевле, побеждает тот, кто доставляет результат и умеет "подписаться" под эффект. Внутри компаний это аналогично: меньше "сколько тикетов закрыли", больше "какой outcome улучшили". 4️⃣ Найм/рост: resilience + обучаемость > идеальные оценки А этот пункт про изменения критериев найма сотрудников внутри McKinsey. Раньше они искали отличников, а потом поняли, что успех лучше предсказывают не отличные оценки, а успешное преодоление кризиов - лучша взять того, кто падает–встаёт, умеет учиться и работать с людьми. 5️⃣Скорость побеждает, даже если ошибок больше - при хорошем восстановлении Тут есть прямая параллель с хорошими инженерными практиками: маленькие батчи, feature flags, наблюдаемость, быстрый rollback → снижаете cost of mistakes и можете быть быстрее. Если как-то переносить инсайты на советы инженерам, то получим примерно следующее 1)Перестаньте использовать AI как "магическую кнопку". Стройте конвейер: Agent → PR → quality gates → human review (тесты/линтеры/security‑сканы не отменяются). 2) Ищите, где агент убирает handoff, а не “ускоряет написание текста”. Начинайте с end‑to‑end потока (value stream). 3) Прокачивайте навыыки из второй волны: judgment + альтернативы + контрпримеры. Просите модель не "ответ", а "риски/проверки/что может пойти не так" Для техлидов это значит следующее 1) Думайте про AI как про операционную трансформацию, а не набор пилотов. 2) Выберите 2–3 процесса и переделайте их целиком (например: triage → fix → deploy). 3) Мерьте результат outcomes‑метриками + баланс скорости/стабильности: DORA (lead time, deploy freq, MTTR, change fail rate) + DevEx/SPACE (чтобы “ускорение” не выжгло команду). 4) Управляйте агентами как продуктами: inventory + ownership + audit: (кто владелец, какие данные видит, какие инструменты вызывает, какие гейты обязаны проходить). #AI #Engineering #Leadership #Devops #Productivity #Management

Two decades of Git: A conversation with creator Linus Torvalds (Рубрика #Software) Интересный рассказ Линуса Торвальдаса о том, как 20 лет назад, в апреле 2005-го, Линус за 10 дней накатал первую версию Git. Он сделал это потому, что у разработчиков ядра Linux отобрали любимый инструмент (BitKeeper). Git родился из боли: CVS Линус терпеть не мог, SVN считал «тем же CVS». Он признаётся, что изначально писал Git "под себя", не парясь об удобстве для других. Линус всего несколько месяцев сам поддерживал Git, а уже к осени 2005 передал бразды другому разработчику – Junio Hamano (он и по сей день мейнтейнер). Торвальдс вернулся к любимому детищу (ядру Linux), а Git зажил своей жизнью. Постепенно что-то переключилось в сообществе: через пару лет народ распробовал инструмент. Особенно помог приток молодых разработчиков, для которых Git стал первой системой контроля версий. Вместо возни с устаревшим CVS они с удовольствием юзали Git и удивлялись, почему раньше было иначе. В итоге Git взлетел и практически монополизировал рынок VCS – сейчас, по словам Линуса, порядка 98% проектов на нём. Даже дочь Торвальдса однажды сказала ему, что в университетской лабе его знают больше как автора Git, а не Linux 😅. Ключевые идеи и фишки Git следующие 1️⃣ Распределённость В Git нет главного репозитория, каждый клонированный репо - полноценный. Это не просто философия, а огромное практическое удобство: разработчик может работать локально без центрального сервера, а при надобности выложить код куда угодно (GitHub и появился благодаря этой идее). Как мне кажется, это local-first приложение by design. 2️⃣ Скорость и масштабируемость Git проектировался под гигантский Linux-репозиторий, поэтому все операции (патчи, слияния) должны быть быстры. Линус шутит, что применить 100 патчей должно быть делом секунд – «не надо успевать пить кофе, пока ждёшь». 3️⃣ Надёжность данных Каждый коммит и объект помечаются крипто-хешем (SHA-1): это больше про защиту от случайной порчи или ошибок, чем про безопасность. Такая проверка целостности на каждом шаге отличала Git от предыдущих систем (в BitKeeper, например, были слабее CRC/MD5 и не всё покрывали). 4️⃣ Простота ядра В основе Git всего несколько концепций (объекты, индексы, ветки), за счёт этого первую версию удалось написать быстро и она до сих пор совместима (почти полностью) с нынешней. Всё сложное вынесено либо “наверх” (в командный интерфейс, скрипты), либо появилось позже. Интересно, что Линус, вдохновляясь философией Unix, нарочно не копировал привычные команды CVS – делал по-своему, даже названия дал другие (commit-tree, index и т.д.), чем вызывал баталии на почтовых списках. Но он сознательно ломал устои: слишком уж его раздражали старые подходы, хотелось кардинально другой инструмент. Вообще, история Git - это отличный пример, как разработчик решает свою проблему, а в результате меняет индустрию. Линус просто хотел продолжать разрабатывать ядро, не мучаясь с отвратительным инструментом, - и из этого родился Git, без которого сейчас не мыслят работу ни разработчики, ни тимлиды. Порой действительно стоит взять и сделать «как надо», даже если изначально продукт сырой и неудобный: если в основе заложены верные принципы, сообщество подтянется и доведёт до ума. Мы видим, как открытые инструменты побеждают закрытые (BitKeeper канул в лету, Git царит). Торвальдс отмечает, что теперь вокруг Git выросла экосистема, которая решает проблемы, о которых он и не думал. Например, появились расширения для больших файлов и монорепозиториев (привет корпорациям) – изначально Git не планировался для этого, но жизнь заставила. Интересна его мысль о трекере задач/багов: сейчас у каждого хостинга своя система issues, и Линусу хочется единого открытого стандарта (чтобы не было привязки к конкретному сервису). Возможно, это намёк сообществу, где ещё есть простор для инноваций 😉. #Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

Inside Argo: Automating the Future (Рубрика #DevOps) Если у вас Kubernetes в проде, то этот фильм про опенсорс проект может принести пользу - это история того, как Argo вырос из workflow‑движка в набор инструментов для автоматизации деплоев и процессов вокруг них (Workflows / CD / Rollouts / Events). В кадре появляются ключевые люди, что стояли у истоков Argo и которые в 2017 году запустили Argo и как вокруг него постепенно появлялось community и набор связанных инструментов. Также мы видим почему GitOps + Argo стали де‑факто стандартом для "предсказуемых" деплоев в cloud‑native мире. Для инженеров просмотр может быть интересен, так как - Это не "маркетинг инструмента, а кейсы взросления опенсорса: комьюнити, мейнтейнерство, стандарты качества/безопасности, и как из внутренней разработки получается индустриальный инструмент - Это про масштаб: Argo прошёл путь CNCF Incubating (2020) → Graduated (2022), и CNCF отмечает сильную индустриальную динамику принятия инструмента (adoption) На практике этот инструмент позволяет разработчикам иметь меньше ручных релизов и “магии” в пайплайнах → больше декларативности, повторяемости и отладки через Git как source of truth. А руководителям платформенных команд это дает понимание, что delivery‑контур - это продукт. Инструменты типа Argo ценны ровно настолько, насколько вы вкладываетесь в guardrails, стандарты и поддержку внутренней платформы. P.S. Более подробный разбор в моей статье на system-design.space. #Kubernetes #DevEx #PlatformEngineering #Software #Architecture #DistributedSystems

Dyad - local‑first AI app builder: как Lovable/Bolt, только на своем компьютере (Рубрика #AI) Я как-то уже рассказывал про продукт Lovable, этакий "AI app builder", в котром написал запрос → получил изменения кода → увидел превью → опубликовал на прод. Собственно, то Dyad делает ровно этот цикл, но локально. В самом репозитории Dyad прямо позиционируется как local/open‑source альтернатива Lovable/v0/Bolt (и в целом - альтернативный путь по сравнению с облачными платформами). Кстати, про подход local-first я тоже уже рассказывал, когда делал саммари на документалку и в dyad есть все признаки этого подхода - Код и проект у вас на диске: без "платформенной клетки", можно импортировать/экспортировать и свободно переходить между Dyad и обычным dev‑workflow - Bring your own keys: вы сами подключаете нужных провайдеров и модели (OpenAI/Google/Anthropic и т.д.), без принудительного вендор‑лок‑ина - Расширяемость: можно добавлять инструменты через MCP‑серверы и жить на шаблонах (templates) под разные JS‑стеки Функциональность Dyad похожа на Lovable и включает в себя - Full‑stack приложения через Supabase: быстро подключить базу, auth и server functions - Security review на базе AI: запускаете проверку, получаете находки с уровнями критичности и можете попросить AI исправить конкретную проблему; правила проверки можно подкрутить через SECURITY_RULES.md - Автоматическое versioning: каждое AI‑редактирование - это новая версия; по сути это git‑коммит. Можно открыть список версий и “restore” до последнего удачного состояния (механика похожа на git revert, история при этом не теряется) - Публикация: “publish anywhere” - GitHub/Vercel или ваш стек Если говорить про архитектуру, то это устроено следующим образом Dyad - это electron‑приложение: - UI живёт в renderer process, - Доступ к файловой системе и "применение изменений" - в main process, - Общение идёт через IPC Ключевой трюк AI-редактирования в том, что модель отвечает не "просто текстом", а в XML‑подобном формате команд. UI стримит и красиво показывает ответ, а затем main‑процесс (через response processor) применяет команды к проекту: создать/изменить/удалить файлы, добавить npm‑пакеты и т.п. Отдельно отмечается, что Dyad не стремится быть максимально "агентным" как Cursor, потому что сложные agentic‑циклы быстро становятся дорогими - поэтому чаще это “один запрос → один аккуратный проход”, с опциональным авто‑фиксом TypeScript ошибок. Подробнее про архитектуру проекта можно прочитать на сайте system-design.space, куда я выложил подробный разбор с картинками и визуализациями. #AI #Engineering #Software #Architecture #DistributedSystems #Agents #ML

[2/2] Nvidia’s Explosive Rise from Zero to Trillions (Рубрика #Documentary) Продолжая рассказ про историю Nvidia надо отметить инсайты фильма, которые пришли ко мне после его просмотра 1️⃣ Платформа съедает продукт NVIDIA выиграла не только “чипом”, а тем, что сделала программируемую платформу: CUDA - это не “одна библиотека”, а экосистема (компилятор, тулкит, профилинг, библиотеки). В итоге возникает “липкость” и сетевой эффект вокруг железа - редкость для hardware‑бизнеса. 2️⃣ Ставка на рынки с нулевым размером может быть рациональной Большие pivots компании (3D‑графика для PC, потом AI) - это ставки на “zero‑billion dollar markets”. То есть не про хайп, а про умение увидеть будущий сдвиг вычислительной парадигмы. 3️⃣ Программируемость = мультипликатор GeForce 256 была важна не только как ускорение рисования, а как шаг к программируемому ускорителю. Дальше из этого выросла CUDA и общие вычисления 4️⃣ Инженерная дисциплина под давлением решает История “у нас один шанс на tape‑out” и ускорение цикла разработки - это не романтика, а практическая управленческая инженерия: сокращать feedback loop любой ценой. 5️⃣ AI‑инфраструктура - это “система систем” DGX (системы) + Mellanox (сеть) = понимание, что для AI важны не только FLOPS, но и: память, интерконнект, сеть, софт‑стек, инструменты, поставки. Собственно Mellanox был куплен Nvvidia за $7 млрд в 2020 году, когда ребята поняли, что им этого не хватает. Для технических лидеров мне кажется полезным будет подумать над такими тезисами 1) Стратегия вычислений = стратегия бизнеса Если у вас AI‑фичи в roadmap - у вас появляется новый ресурс: GPU‑время/память/интерконнект, и этим нужно управлять как бюджетом и SLA. 2) Платформенная команда - это не роскошь Нужны люди/команда, которые делают “внутренний CUDA” вашей компании: - Шаблоны пайплайнов, - Инфраструктура обучения/инференса, - Наблюдаемость (стоимость, утилизация, узкие места), - Guardrails по качеству/безопасности. 3) Управляйте vendor lock‑in как риском, а не как идеологией CUDA‑экосистема реально мощная - и именно это даёт NVIDIA рычаг. - Оставляйте “точки выхода” (абстракции, ONNX/portable‑слои где уместно, контрактные тесты производительности), - Держите план B по инфраструктуре (облако/он‑прем/альтернативные ускорители), - Фиксируйте метрики стоимости/латентности как продуктовые KPI. 4) "Полный стек" важнее "самого быстрого GPU" - Покупка Mellanox и ставка на DGX - хороший сигнал: производительность AI‑системы часто упирается в сеть/IO/оркестрацию, а не в “ещё 10% TFLOPS”. 🧐 После просмотра можно пройтись по таком мини‑чеклист для команды 1. Посчитать стоимость 1 GPU‑часа (или inference‑1000 req) и сделать её видимой. 2. Ввести профилирование как обязательный шаг перед релизом ML‑фич. 3. Определить, где вам нужна "портируемость", а где можно идти в максимальную оптимизацию под конкретный стек. 4. Проверить узкие места: сеть, storage, батчинг, очереди. 5. Обновить hiring/skill‑matrix: нужен ли вам performance engineer / ML systems engineer? 6. Зафиксировать “exit strategy” от критических зависимостей (не завтра, но чтобы она была на бумаге). #Documentary #Infrastructure #AI #ML #Engineering #Software #Leadership #Startup #DistributedSystems

[1/2] Nvidia’s Explosive Rise from Zero to Trillions (Рубрика #Documentary) С большим интересом я посмотрел этот документальный фильм рассказывает впечатляющую историю превращения Nvidia из стартапа на грани банкротства в компанию стоимостью $3 триллиона . Фильм охватывает путь от основания в 1993 году до текущего доминирования в области AI . Мне было интересно посмотреть, а какие этапы проходила компания и какие выводы можно почерпнуть нам как инженерам и техническим руководителям Основание и первые годы Nvidia была основана тремя инженерами - Дженсеном Хуангом, Крисом Малачовски и Кёртисом Примом - которые познакомились работая в Sun Microsystems и LSI Logic . Легендарная встреча состоялась в ресторане Denny's в Сан-Хосе, где за чашками кофе они обсуждали будущую компанию день за днем . Их ставка была на 3D-графику для PC и видеоигр, хотя на тот момент они даже не видели персональный компьютер . Название Nvidia произошло от латинского слова "invidia" (зависть), а также от сокращения NV ("next version"), которое основатели использовали при сохранении файлов . С начальным капиталом всего $40,000 и последующим финансированием $20 млн от Sequoia Capital, они начали свой путь . Провал и чудесное спасение Первый продукт NV1 (1995) оказался катастрофой: из 250,000 чипов, отправленных партнёру Diamond Multimedia, вернулось 249,000 . Проблемы были в том, что чип использовал quadratic primitives вместо triangle primitives, которые стали стандартом Microsoft DirectX, плюс был слишком дорогим . После отмены контракта с Sega на NV2, у компании осталось финансирование только на один месяц зарплат . Riva 128 (август 1997) стал продуктом, спасшим Nvidia - за четыре месяца он продался тиражом в миллион единиц, в отличие от NV1, который продал едва тысячу . С тех пор в компании существует неофициальный девиз: "Мы всегда в 30 днях от банкротства". Интересно, что в моем первом компьютере был чип riva tnt2, то есть я познакомился с творчеством ребят еще до начала 21 века:) Прорыв и IPO GeForce 256 (1999) стал первым в мире GPU с программируемым ускорителем - это был прорыв в концепции ускоренных вычислений . В январе 1999 года Nvidia провела IPO, что дало компании больше капитала и публичности . Следующим большим шагом стал контракт с Microsoft на $200 млн на разработку чипов для оригинального Xbox . Поворот к AI Самое интересное решение было принято в середине 2000-х: релиз CUDA в 2006 году - платформы параллельных вычислений, которая позволила использовать GPU не только для графики . Профессор Стэнфорда Эндрю Нг вспоминает, что уже в 2008 году его студенты экспериментировали с CUDA для deep learning и получали ускорение в 10-100 раз . Это был огромный риск: в конце 2000-х никто не знал, станет ли AI прибыльным . Nvidia приняла решение о масштабной трансформации компании, добавляя затраты, нанимая людей и отвлекая внимание от основного бизнеса в gaming и компьютерной графике . Хуанг описал это как "wholesale pivot" - полную переориентацию всей компании . Интересно, что у меня был коллега в МФТИ, которого мы взяли пилить всякие веб-сайты, а он парарллельно занимался CUDA по научной траектории и в какой-то момент сказал нам ариведерчи и ушел заниматься CUDA фултайм. Дальше карта AI пошла хорошо - в 2012 году случился AlexNet и произошел старт “современного AI”. NVIDIA прямо отмечает, что прорыв AlexNet стал спусковым крючком эры modern AI, и GPU оказался в центре этой волны. А про инсайты и выводы из этой документалки мы поговорим в следующий раз. #Documentary #Infrastructure #AI #ML #Engineering #Software #Leadership #Startup #DistributedSystems

Giiker Decipher (Рубрика #ForKids) Я стал фанатом игрушек от компании Giiker - они очень приятные тактильно, а также в них просто интересно играть. Так на эту игрушку-дешифратор подсел мой пятилетний сын Кирилл, с которым мы перед сном теперь играм в загадывание кода, а потом разгадывание по очереди. Суть это игры в том, что у нас есть 4 слота, в которых загадан цветовой код. У нас есть 7 попыток на то, чтобы отгадать его. И загадывание и отгадывание в игре управляется оранжевой крутилкой, которую можно нажимать для того, чтобы установить код или проверить его. Собственно, есть опция играть вдвоем или одному против компьютера, а также можно играть в direct или non-direct версию (первая попроще). В direct версии мы выбираем зашифрованную последовательность и нажимаем проверить - дальше приходит ответ: - Если огонек под цветом не горит, то цвета нет - Если огонек горит белым, то цвет есть, но он расположен не в правильном месте - Если огонек горит зеленым, то значит мы угодали цвет этого квадратика Эта логика достаточно простая, но есть усложненная версия non-direct, которая посложнее и интереснее. В общем, как уже стало понятно, мне эта игрушка нравится и моему сыну тоже, поэтому я и вам могу ее рекомендовать. #Brain #Game #SelfDevelopment #Security

Borland: rise and fall of a software enmire - the delphi story (Рубрика #Software) Посмотрел на днях документальный фильм про компанию Borland, создавшая революционные инструменты для разработчиков (Turbo Pascal, Delphi). Я понмю, как писал свой бакалаврский диплом на Delphi 6 (клеточную модель мира для расчетов биогеоценоза + климата для предсказания климата). Это было где-то в 2006-2007 годах и уже тогда был виден упадок Delphi, хотя когда-то они были на коне и будущее выглядело перспективным. Кстати, после фильма я вспомнил, что читал на Хабре отличную статью "Как Borland «профукали все полимеры»". Ну а теперь рассмотрим ключевые вехи истории Borland 🚀 1983: Запуск Turbo Pascal Первый громкий успех Borland - выпуск Turbo Pascal, фактически первой удобной IDE на рынке (и дешевле на порядок IDE от конкурентов). Доступный и быстродействующий компилятор завоевал популярность среди программистов и образовательных учреждений, заложив основу будущего успеха компании. 🌟 1995: Появление Delphi В середине 90-х Borland представила среду визуальной разработки Delphi - флагманский продукт, совершивший прорыв в быстрой разработке под Windows. Delphi закрепила репутацию Borland как лидера инструментов для разработчиков. 👋 1995–1996: Уход ключевых фигур На пике успеха компанию покидают ее вдохновители. В 1995 году из-за разногласий с советом директоров уходит основатель и генеральный директор Филипп Кан. А в 1996-м Microsoft переманивает ведущего инженера Borland Андерса Хейлсберга, архитектора Turbo Pascal и Delphi. Потеря этих лидеров стала серьёзным ударом по стратегическому курсу и инновационному потенциалу компании. Кстати, Андерс Хейлсберг потом в Microsoft сделал C# и Typescript ⚠️ Стратегические просчёты Стремясь расти, Borland сделала ряд сомнительных ходов. Компания увлеклась расширением через покупки, не думая об интеграции продуктов: так, приобретение базы dBase при наличии собственной Paradox обернулось тем, что оба продукта потеряли позиции. Также Borland пыталась заняться офисными приложениями и другими "модными" направлениями по совету аналитиков, отвлекаясь от ядра своего бизнеса (инструментов разработки). Эти шаги ослабили фокус компании. 🔄 Смена курса и ребрендинг В конце 90-х, следуя конъюнктуре рынка, руководство объявило, что разработка инструментов больше не стратегический приоритет, и переименовало компанию в Inprise для имиджа корпоративного игрока. Этот резкий поворот едва не погубил Borland: разработчики восприняли его негативно, и финансовое положение ухудшилось. Лишь сохраняющаяся популярность продуктов Delphi (а позднее JBuilder) временно спасла ситуацию. Но в последующие годы Borland так и не смогла вернуть утраченные позиции, продала это направление, а потом прекратила своё самостоятельное существование. В итоге, история компании выглядит занимательно и из нее можно почерпнуть несколько мыслей для технических лидеров и компаний 🎯 Фокус на своём ядре История Borland показывает, насколько важно держаться своих сильных сторон. Компания добилась успеха, концентрируясь на инструментах для разработчиков, и начала терять позиции, как только отвлеклась на побочные рынки и тренды. 🤝 Обдуманные поглощения Расширение через покупки может обернуться провалом, если не продумана совместимость и стратегия. 🏃 Ценность команды и знаний Ключевые люди - носители экспертизы и духа компании. Уход Филиппа Кана и Андерса Хейлсберга оголил стратегические проблемы Borland. 🔀 Осторожно с резкой сменой курса Радикальные перемены в стратегии и бренде могут разом обесценить годы доверия. Ребрендинг Borland в Inprise и отказ от любимых разработчиками продуктов подорвали репутацию компании. 📣 Прислушиваться к сообществу, а не только к аналитикам Борьба за корпоративный сегмент выглядела перспективно на бумаге, но Borland игнорировала желания своей основной аудитории - разработчиков. Поэтому когда появились альтернативы (тот же C#) разработчики отвернулись от компании. #Engineering #Software #Management #Leadership #Architecture

Марко Спада в Большом Театре (Рубрика #Humor) Уже сложилась традиция, что каждый год я хожу с женой в Большой Театр зимой. Обычно это подарки на Новый год или мой День Рождения. Таким темпом я постепенно начинаю разбираться в балете, но у меня все равно остается вопрос - почему у девушек в балете платья, а у мужчин "термобелье":) #Culture

Профессор Илья Стребулаев о том, как заработать на своих идеях и ценить свои неудачи (Рубрика #Startup) Посмотрел крутое интервью Ильи Стребулаева, профессора из Стэнфорда и эксперта в области корпоративных финансов и венчурного капитала. Илья дал его Алексею Пивоварову, иноагенту и ведущему проекта "Редакция". Они поговорили про перенос логики венчурных инвесторов (как они думают о ставках, риске и качестве решений) на более широкий круг задач - от управления проектами до развития карьеры, что хорошо переносится на тему технического управления. Ниже мои инсайты 1️⃣ Консенсус - не всегда "здоровье команды", иногда это симптом риска - Если группа слишком быстро приходит к согласию, это может означать конформизм и отсутствие альтернатив. - Как применять: в архитектурных ревью и дизайн‑доках вводить явную норму: "минимум 2 альтернативы" и "1 назначенный оппонент". Это превращает «несогласие» из личного конфликта в часть процесса. 2️⃣ Очередность высказываний критична: "первым говорит авторитетный" → искажение распределения мнений. - Внешний конспект прямо указывает: когда первым выступает самый авторитетный участник, мнение остальных сдвигается. - Как применять: в обсуждениях инцидентов/пост‑мортемов и больших технических решений сначала собирать индивидуальные оценки (письменно), а уже потом обсуждать. 3️⃣ Слепое голосование/сбор мнений до обсуждения повышает честность сигнала - Предложение "использовать слепое голосование" дано как практический приём. - Как применять: для RFC/ADR: до синка просим всех выбрать вариант A/B/C и написать по 2 аргумента "за/против" в форме. На созвоне обсуждаем расхождения, а не "базовую позицию лидера". 4️⃣ Полезно начинать обсуждение с “джунов” (или “самых тихих”) - "Начинать с джунов" - это способ получить более разнообразную картину. - Как применять: в ревью требований: первым коротко выступает тот, у кого меньше иерархической власти. 5️⃣ Венчурные методы оценки проектов применимы не только инвесторам, но и тем, кто управляет командами/запускает проекты - Это ключевая рамка пересказа: подходы VC полезны для управленцев и инициаторов. - Как применять: относиться к крупным инициативам как к портфелю ставок: ограничивать размер ставки (time/budget), заранее определять критерии успеха/провала и "точки выхода" (kill criteria). 6️⃣ Неудачи - актив, если их превращать в данные, а не в стигму - Эта идея зафиксирована уже в названии ролика ("ценить свои неудачи"). - Как применять: стандартизировать пост‑мортемы: что предполагали, что наблюдали, что изменим. Полезный паттерн - хранить «реестр гипотез» и отмечать, какие из них были опровергнуты и почему (это снижает повторяемость ошибок). 7️⃣ Монетизация идей как инженерная задача - Тема "как заработать на своих идеях" заявлена в названии; её полезно читать как призыв думать про value‑delivery, а не только про "технологическую красоту". - Как применять: для каждой крупной фичи фиксировать: "кому больно", "какая метрика улучшится", "какая минимальная поставка (MVP) подтвердит ценность", "какая цена ошибки". Это дисциплинирует backlog и снимает иллюзию прогресса. Стратегические выводы и практики 1️⃣ Перестроить управление инициативами на "bets + checkpoints". Для каждой крупной инициативы заранее задавать: (а) ожидаемый выигрыш, (б) стоимость ошибки, (в) точки проверки, (г) критерии остановки. Это делает "ценность неудач" управляемой: проигрыш должен быть ограничен. 2️⃣ Метрики качества решений (а не только delivery): доля решений с зафиксированными альтернативами; среднее время до пересмотра плохого решения; количество повторяемых инцидент‑классов после пост‑мортемов. Эти метрики напрямую связаны с тезисами про групповую динамику и извлечение уроков. 3️⃣ Оргизменения: - Ввести норму "письменная позиция до созвона" (для решений выше порога); - Защищать несогласие (не как "оппозицию лидеру", а как "обязательный элемент качества"); - Обучить фасилитации: кто говорит первым, как фиксируем аргументы, как закрываем решение. #Engineering #Management #VC #Startup #Software #Leadership

T-Sync конференция - фото (Рубрика #Engineering) Сегодня рассматривал фотографии с конференции и понял, что она получилась масштабной. Плюс новый формат принес глоток свежего воздуха - Обычные конференции сконцентрированы на broadcast подходе к трансляции знаний - от спикера к остальным. И хоть они говорят про нетворк, но он сконцентрирован на сборе бесплатного стаффа со стендов - Наша конфа была сконцентрирована на вопросах и ответах - для получения знаний посетителям надо было ходить и задавать вопросы реальным инженерам, что делали представленные системы. Да, у нас были инженерные дискуссии и там сложность была в том, чтобы добыть наушники, которых всем не хватало. Плюс у нас еще был t-hack и другие интерактивные активности, что требовали вовлечения В итоге, формат нам понравился и мы будем его повторять в будущем. P.S. И немного фоток самого события для красочности

TypeScript Origins: The Documentary (Рубрика #Software) На днях я посмотрел документальный фильм TypeScript Origins от OfferZen. В нём выступают создатель TypeScript Андерс Хейлсберг и другие ключевые участники сообщества: от инженеров Microsoft до разработчиков JetBrains, Bloomberg, Deno и др. Фильм рассказывает, как и зачем в Microsoft создали TypeScript и как язык и его экосистема развивались с момента первого релиза. Ниже я расскажу про свои основные инсайты из этого фильма, а также поделюсь мыслями о том, что это значит для нас как инженеров и технических лидеров. 1️⃣ TypeScript родился из необходимости на больших проектах В начале 2010-х команда во главе с Андерсом Хейлсбергом увидела, что JavaScript плохо масштабируется в больших кодовых базах - не хватает типизации и инструментов для поддержки крупных приложений. В Microsoft запустили внутренний проект (кодовое имя Strata), чтобы "навести порядок" в мире JS, не ломая его основы. Один из героев фильма метко заметил: "Вопрос не в том, сломан ли JavaScript, а в том, достаточно ли он сломан". TypeScript стал ответом - надстройкой над JS, которая решает реальные боли разработчиков. 2️⃣ Ставка на совместимость и постепенное внедрение Создатели TypeScript с самого начала решили: любой код на JavaScript должен оставаться валидным кодом на TypeScript. Статическая типизация - опциональна. Такой подход позволил командам внедрять язык постепенно, без переписывания всего с нуля. Фильм подчёркивает, с каким пониманием авторы отнеслись к сообществу JavaScript - они максимально сохранили его привычки и свободу. Благодаря этому TypeScript легко "встраивался" в существующие проекты. 3️⃣ Открытость и сообщество сыграли решающую роль TypeScript был открыт миру (open source) с первого релиза в 2012 году, и это во многом предопределило его успех. В фильме показано, как вокруг языка сформировалось активное сообщество и экосистема: поддержку выразили разработчики инструментов (JetBrains, VS Code), крупные пользователи (например, инженеры Bloomberg) и даже создатели новых платформ вроде Deno. Изначально скепсиса хватало - даже Дэниел Розенвассер (менеджер команды TypeScript) признаётся, что поначалу боялся, "как бы Microsoft всё не загубила". Однако открытая разработка и вовлечение сообщества помогли этого избежать: внешние контрибьюторы улучшали язык, а компании охотно внедряли его у себя. 4️⃣ Внутренние препятствия и поддержка руководства Документальный фильм приоткрывает и закулисье создания языка внутри Microsoft. Продвижение новой технологии в корпорации оказалось непростым делом: команде TypeScript пришлось доказывать ценность своего подхода и конкурировать за ресурсы. Лишь благодаря поддержке дальновидных лидеров и энтузиазму самих разработчиков проект выжил и вырос. Для успеха понадобилось сочетание технического визионерства и умения "продать" идею внутри компании. 🧐 Что это означает для разработчиков и технических руководителей? - Решайте реальные проблемы. История TypeScript подчёркивает: инструмент выстреливает, когда снимает настоящую боль. - Внедряйте эволюционно, а не революционно. Нововведения лучше приживаются, если не требуют ломать всё сразу. - Сила open source и сообщества. Открытость к сообществу ускоряет развитие технологии. Если вы разрабатываете библиотеку или внутренний инструмент, подумайте об открытом коде и обратной связи от внешних разработчиков. - Поддерживайте культуру новаторства. Для технических руководителей урок в том, чтобы прислушиваться к инициативам снизу. TypeScript вырос из маленькой команды энтузиастов - дайте своим инженерам пространство экспериментировать и предлагать улучшения. P.S. Если интересно больше деталей и живых историй, то я рекомендую посмотреть TypeScript Origins целиком - там много интересных моментов и тонких моментов, которые не поместились в это саммари. #AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture #RnD

The rise of the professional vibe coder (Рубрика #Engineering) На днях у Ленни вышло интервью про вайб кодинг с Лазаром Йовановичем из Lovable (его должность буквально “Professional Vibe Coder”). И там отлично сформулировано то, что как использовать Lovable и не только для вайб инжиниринга и быстрой поставки фичей в свое приложение. Из интеррвью можно получить много инсайтов, среди которых следующие Что такое vibe engineering (по‑честному) - Это переход от "микроменеджмента синтаксиса" к управлению намерениями - Раньше: пишешь классы/циклы, гуглишь ошибки, дебажишь полдня - Теперь: описываешь что должно быть (UX, бизнес-логика, ограничения, edge cases) → AI строит решение → ты валидируешь как продакт и инженер одновременно Я прямо на system-design.space это все проходил и это действительно так и работает - за вечер и часть ночи я пересобрал сборку проекта, оптимизировав производительность + SEO, переехал на другой хостинг (как раз съехал с Lovable), добавил поиск по сайту. В общем, это очень вдохновляющий опыт - цикл обратной связи коротки и от идеи до результата проходят часы. Лазар формулирует работу в своем видео как формулировку "желания джинну" - Что за продукт/фича - Кто пользователь - Что считается “готовым” или критерии DoD (definition of done) - Ограничения (данные, доступы, SLA, безопасность) И у него в Lovable за 20–40 минут получается скелет: UI, API, модели, базовую логику. Это момент, когда из головы появляется "что-то кликабельное", и команда перестаёт спорить абстракциями. И я примерно так стартую проекты - с условного визуала. Но потом я иду в Codex и докручиваю то, что отличает демку от продакшена: проверки, обработка ошибок, миграции, тесты, логирование, права доступа, рефакторинг. Наверное, можно это делать и в Lovable, но мне удобнее делать это по другому. В итоге, получаются короткие итерации: собрал → кликнул → сломал → уточнил промпт → повторил. Время цикла - часы, не спринты. Главный инсайт из интервью относится к не-технарям Они могу быть реально быстрее инженеров, потому что их не засасывает в "а давай выберем библиотеку/идеальную архитектуру". Они держат в голове только одно: ценность для пользователя. Но я как технарь и руководитель добавлю: качество и ответственность никуда не делись - просто точка приложения усилий сместилась. И дальше все равно Если оцеивать, а что такой подход меняет для рынка и команд, то на ум приходит следующее - Умение писать бойлерплейт обесценилось. Ценится то, что раньше было "поверх кода": декомпозиция, архитектура, продуктовый вкус, ответственность за риск. - Роли продакт-менеджеров и инженеров размываются. Появляется гибрид: product engineer, который может придумать и сразу собрать продукт - Для MVP и внутренних тулов это вообще чит‑код: закрывать бэклог можно силами 1–2 людей, если у них сильный product sense + дисциплина. Но есть и тёмная сторона “вайба”: Если просто «навайбить» без рамок - получишь красивый интерфейс с дырявой безопасностью и техдолгом, который взорвётся через квартал. Поэтому мой rule of thumb: ✅ Вайб - для скорости и формы, ✅ Инженерия - для границ (security, доступы, тесты, наблюдаемость, данные), ✅ Ответственность - всегда на людях, не на модели. Короче: делать продукт стало проще, но делать его хорошо - всё ещё требует профессиональных навыков. Просто теперь эти навыки - это не набор синтаксических трюков, а способность быстро и точно "заказывать" систему и доводить её до надёжного состояния. #AI #VibeEngineering #Product #Software #Architecture #Lovable #Codex #Productivity #Management #Leadership

Бывший CEO GitHub стартанул новую компанию для создания новой платформы для разработчиков (Рубрика #Engineering) Интересная новость от Томаса, который недавно ушел из Microsoft (а точнее из GitHub), чтобы заняться своим стартапом. Он вышел из неизвестности с анонсом компании "EntireHQ", которая подняла $60 млн в сид раунде с оценкой в $300 млн на создание новой платформы с примерно таким видением - Git‑совместимая база данных, объединяющая код, намерение, ограничения и рассуждения в единую систему с контролем версий. - Универсальный семантический слой рассуждений, позволяющий координацию нескольких агентов через граф контекста. - AI‑native интерфейс, который заново изобретает жизненный цикл разработки ПО для сотрудничества "агент–человек" Это видение обусловлено тем, что за последние три месяца фундаментальная роль разработчика ПО была фактически "пересобрана". Невероятные улучшения в последних моделях от Anthropic, Google и OpenAI сделали кодинговых агентов настолько хорошими, что во многих ситуациях теперь проще написать промпт, чем вручную писать код. Терминал снова стал центром притяжения на наших компьютерах. Лучшие инженеры могут одновременно запускать десяток агентов. Ну и компания не просто анонсировала сид-раунд и видение - ребята уже выкатили продукт Checkpoints, который автоматически сохраняет контекст агента. С этим новым кубиком мы получаем автоматическое сохранение контекста агента как данных первого класса, с версионированием в Git. Когда вы коммитите код, сгенерированный агентом, Checkpoints сохраняет полную сессию вместе с коммитом: транскрипт, промпты, затронутые файлы, расход токенов, вызовы инструментов и многое другое. Ребята уже опубликовали этот продукт в виде open‑source CLI на GitHub. Будет очень интересно следить за начинаниями ребят - тем более Томас обещал, что они будут разрабатывать свой продукт в формате Open Source. #AI #Software #Engineering #Architecture #Agents #Software #ML #Leadership #Startup

Update: SDS (System-Design.Space) С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового: - Добавил уровень сложности для глав и разметил их - Добавил фильтрацию по типу материала и сложности - Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам) - Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами - Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность - Добавил части про безопасность и фронтовую архитектуру - Добавил кучу глав в разные части программы. В общем, мне очень нравится дорабатывать и расширять сайт. Если у вас есть идеи удушений или репорты о багах, то пишите в комменты и я их учту в планах разработки #SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

The Untold Story of Log4j and Log4Shell | Christian Grobmeier | GitHub (Рубрика #Security) С большим интересом посмотрел историю про один из самых крупных факапов в истории безопасности, которую рассказывал непосредственный участник событий - Кристиан Гробмайер, мейнтейнер Apache Log4j, участник Apache Software Foundation. Человек, который в декабре 2021 внезапно оказался ответственным за "половину интернета". Интересно, что я помню масштаб той истории и ее стремительное развитие - это было эпично. Но что же произошло? В 2021 в библиотеке Log4j нашли уязвимость максимального уровня 10 из 10 Log4Shell (CVE-2021-44228) - возможность удалённого выполнения кода через обычную строку логирования (${jndi:…}). Эксплуатация была элементарной, а Log4j был буквально везде: enterprise-системы, облака, гос-сервисы, игры. Например, в процессе работы над инцидентом Кристиана позвал его сын и показал, что даже его Minecraft сервер пал жертвой этой уязвимости ... А дальше был кризис - Несколько волонтёров, что поддерживали библиотеку на энтузиазме - Ноль сна и куча давления в стиле "чините быстрее" - Давление со стороны компаний и СМИ, - При этом мало поддержки и ноль вопросов о том, а как ребята себя чувствуют и нужна ли помощь В общем, этот инцидент показал не баг в одной библиотеке, а системную проблему всей open-source-экосистемы. Если говорить про инсайты в общем, то они примерно такие и актуальны до сих пор 1️⃣ Open source ≠ безопасно по умолчанию Открытый код не означает автоматически защищённый код. Безопасность - это люди, процессы и поддержка, а не лицензия. 2️⃣ Масштаб библиотеки = масштаб риска Маленькая зависимость → тысячи продуктов → глобальный инцидент. Большинство компаний даже не знали, что у них есть Log4j, пока не стало поздно. Отсюда резкий интерес к SBOM (Software Bill of Materials) и прозрачности цепочки поставок. 3️⃣ Самая опасная уязвимость - незнание Мейнтейнеры часто не security-эксперты. Без обучения secure coding разработчики часто становятся точками отказа 4️⃣ Один-два мейнтейнера - это single point of failure (если докапываться, то два - это уже не single) Критичные библиотеки не могут держаться на энтузиазме пары людей. Деньги важны, но ещё важнее - участие компаний-потребителей. 5️⃣ Культура важнее технологий Агрессия, давление и обвинения делают экосистему слабее. Поддержка и сотрудничество - наоборот. 🌝 Что это значит для инженеров - Минимизируйте зависимости. Каждая библиотека - потенциальная атака. - Автоматизируйте обновления и CVE-алерты (Dependabot, SCA). - Не доверяйте входным данным никогда, даже "внутренним". - Отключайте опасные фичи по умолчанию (типа jdni) - Используйте defense-in-depth. - Генерируйте SBOM - знайте, из чего вы собрали продукт. - Нашли проблему в OSS - помогите, а не просто «репортните и забудьте». 🔥 Что это значит для тимлидов и CTO - Безопасность зависимостей = бизнес-риск, а не "техническая деталь" - У вас должен быть ответственный за OSS-цепочку и реакцию на CVE - SBOM - must-have, а не nice-to-have - Закладывайте время инженеров на вклад в критичные open-source-проекты. - Инвестируйте в обучение secure development - Планируйте регулярные апдейты зависимостей как часть roadmap - Готовьтесь к 0-day заранее, а не в Slack-панике Итого, Log4Shell показал простую вещь - наш софт настолько безопасен, насколько безопасны его самые маленькие зависимости. А для того, чтобы они были лучше стоит не только использовать эти библиотеки, но и поддерживать их самим. #Security #Engineering #Software #Management #OpenSource

Liam Wong: TO:KY:00 (Рубрика #Culture) Прекрасная книга с фотографиями Лиама Вонга, который был арт-директором в Ubisoft, ездил по миру и в какой-то момент увлекся фотографией и стал профессионалом в ней. В этой книге представлена его серия робот о Токио, что предстает перед нами в антураже киберпанка Ридли Скота, что мы увидели в "Бегущем по лезвию". А сам бегущий был экранизацией книги "Мечтают ли андроиды об электроовцах" Филиппа Киндреда Дика, одного из моих любимых фантастов. В общем, я листал эту книгу Лиама с большим удовольствием, чего и вам рекомендую!

Interview with ‘Just use a VPS’ bro (OpenClaw version) (Рубрика #AI) Я давно так не смеялся, как с этого видео:) С учетом того, что я сам люблю возиться с Linux, то юмор попал в точку - раньше приходилось читать мануалы, а сейчас мне с этими настройками помогают всякие perplexity. В этом видео высмеивается стереотипный "сисадмина-параноик" и культура селфхостинга (self-hosting). Юмор строится на контрасте между простым желанием пользователя ("Я просто хочу запустить AI-агента") и безумно сложным, перегруженным инструктажем от "VPS-бро", для которого "просто" означает полноценную настройку Linux-сервера с нуля. В конце, когда пользователь отчаивается и просит сменить агента, что ему помогает, появляется новый "консультант", который начинает затирать про AWS EC2, Security Groups и Kubernetes. Шутка в том, что убегая от сложности Linux пользователь проваливается еще глубже в кроличью нору (прямо как Алиса). В общем, автор этого канала просто топ, рекомендую его всем знакомым айтишникам:) #Humor #Engineering #Software #AI #DevOps #DevEx

Путешествие в Лондон (Рубрика #Travel) Через пару недель мы с женой сгоняем на недельку в Лондон, где мы побываем впервые:) Когда я начинал учить английский в школе в Северодвинске и проговаривал "London is the capital of Great Britain" я и представить не мог, что когда-то поеду в этот самый London. Правда, сейчас путешествия уже стали рутиной, но я попросил жену добавить в нашу поездку посещение Блетчли-парка, где в период Второй мировой войны в Блетчли-парке располагалось главное шифровальное подразделение Великобритании, а сейчас там расположен Национальный музей компьютеров. Все остальные достопримечательности подбирала моя жена, которой я верю больше чем себе в вопросе планирования досуга:) А ближе к концу апреля мы поедем в Лондон уже с детишками, благо UK - это не Португалия, а значит дает нормальные визы (на полгода). В общем, я уже предвкушаю интересную поездку:) #Travel #Software #Engineering #History