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

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

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