Update: SDS (System-Design.Space)

С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового:
- Добавил уровень сложности для глав и разметил их
- Добавил фильтрацию по типу материала и сложности
- Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам)
- Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами
- Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность
- Добавил части про безопасность и фронтовую архитектуру
- Добавил кучу глав в разные части программы.

В общем, мне очень нравится дорабатывать и расширять сайт. Если у вас есть идеи улучшений или репорты о багах, то пишите в комменты и я их учту в планах разработки

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

Бывший 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

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

Профессор Илья Стребулаев о том, как заработать на своих идеях и ценить свои неудачи (Рубрика #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

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

[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