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

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

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

"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