Книжный куб

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 - это не Португалия, а значит дает нормальные визы (на полгода).

В общем, я уже предвкушаю интересную поездку:)

P.S.
Если кто 28 февраля будет в Лондоне и захочет пообщаться, то пишите в личку - мы выделили это воскресенье под встречи со своими знакомыми, кого сложно встретить в Москве:)

#Travel #Software #Engineering #History

[2/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI)

В этом посте мы закончим разбирать короткий trend-report Anthropic, который задает фокус того, что стоит делать в 2026 году нам как инженерам и руководителям, чтобы не отстать от стремительно меняющейся индустрии разработки софта.

3️⃣ Impact trends: What agents may change in 2026

Trend 6: Productivity gains reshape software development economics
Эффект - не только "быстрее", но "больше": растёт объём shipped-результата, появляется работа, которую раньше бы не делали (в отчёте ~27% AI-задач - “не сделали бы иначе”). TELUS, например, сделали 13k внутренних AI-решений и ускорили shipping кода на 30%, сэкономив 500k+ часов.
- Инженерам надо пересмотреть приоритеты - закрывать техдолг и “papercuts” становится выгодно.
• CTO стоит ожидать “взрыва output” и заранее ставить рамки качества, иначе скорость съест поддерживаемость.

Trend 7: Non-technical use cases expand across organizations
Неинженерные команды начинают автоматизировать процессы сами: меньше тикетов в разработку, больше локальных “мини-продуктов”. Zapier в отчёте - 89% adoption и 800+ внутренних агентов; у Anthropic юристы сократили маркетинг-ревью до 24 часов, причём self-service инструменты собрал юрист без опыта кодинга.
- Инженерам надо помогать через внутренние библиотеки/коннекторы/примеры, а не “делать за всех”.
- CTO пора строить governance для citizen devevelopers (что можно автоматизировать, где хранятся секреты, кто отвечает за поддержку).

Trend 8: Dual-use risk requires security-first architecture
Агентный кодинг усиливает и защиту, и атаки. Любой инженер может делать security-review с агентом - и любой атакующий тоже масштабирует свои попытки.
- Инженерам надо двигать практики безопасности: “least privilege” для инструментов агента, изоляция, журналирование, защита от инъекций/подмены контекста.
- CTO надо идти в security by design агентных систем (права, контуры, аудит, red teaming) до того, как агенты получат доступ к продовым данным/деплою.

Если свести отчёт к одному тезису: выиграют команды, которые научатся
- Ууправлять несколькими агентами
- Масштабировать контроль качества
- Безопасно расширить агентные инструменты за пределы инженерии

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

[1/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI)

Anthropic опубликовала любопытный отчёт о ключевых трендах "агентного кодинга" на 2026 год. Этот документ рисует картину того, что разработка всё больше опирается на AI-агентов, которые пишут код, пока люди задают им цели и контролируют результат. Они приводят статистику, что разработчики Anthropic используют AI в 60% задач, хотя полностью доверяют ему лишь 0–20% работы (это из их декабрьской статьи "How AI is transforming work at Anthropic", о которой я уже рассказывал). В новом документе они приводят кейсы и других компаний, который смогли добиться значимых результатов, но все-таки фокус на 8 тенденциях, что сгруппированы в три категории: foundation trends, capability trends, impact trends. Ну и ниже я расскажу про каждый из трендов, а также поделюсь мыслями, а что делать с ними инженерам и руководителям

1️⃣ Foundation trends: The tectonic shift

Trend 1: The software development lifecycle changes dramatically
SDLC остаётся, но цикл сжимается: агент пишет/дебажит/документирует, тесты и мониторинг быстрее замыкают фидбек (недели → часы).
- Инженерам стоит начать прокачивать «оркестрацию» (декомпозиция, постановка задач агенту, критерии приёмки, быстрый ревью).
• CTO стоит пересобрать процесс и метрики (меньше “время на задачу”, больше “качество+output”), и реально использовать “онбординг за часы” для динамического перераспределения людей по продуктам/проектам

2️⃣ Capability trends: What agents can do

Trend 2: Single agents evolve into coordinated teams
Один агент → команда агентов с ролями + оркестратор. Это про параллельную работу и синхронизацию в VCS. Пример из отчёта: multi-agent оркестрация дала Fountain 50% быстрее screening и сократила срок укомплектования нового центра до <72 часов.
- Инженерам надо научиться резать задачи так, чтобы их можно было делать параллельно (и собирать через PR/чеки).
- CTO стоит внедрять паттерны multi-agent (роли, протоколы, правила мержа/ревью для “агентских” изменений).

Trend 3: Long-running agents build complete systems
Агенты работают «долго»: часы → дни/недели. Могут тащить фичу/подсистему целиком, закрывать техдолг, делать “невыгодные руками” улучшения. Пример: Rakuten прогнали Claude Code по задаче в vLLM (12,5 млн строк) - 7 часов автономной работы и 99,9% точности.
- Инженерам пора начать мыслить чекпоинтами (контракты, тесты, инварианты) и строить ограждения, чтобы агент не «уехал».
- CTO стоит подготовить среду для длинных прогонов (sandbox, CI, лимиты, наблюдаемость) и выделить задачи “под агента” (миграции, рефакторинги, чистка бэклога).

Trend 4: Human oversight scales through intelligent collaboration
Ключ в том, чтобы масштабировать контроль. Агенты учатся звать человека, а не молча “дожимать”; AI проверяет AI (security/архитектура/качество), человек смотрит только «что важно».
- Инженерам надо собирать пайплайн “генерация → автопроверки → человек”.
- CTO стоит формализовать уровни риска и эскалации (что агент может сам, что только через человека), инвестировать в автоматизированный ревью/тестирование.

Trend 5: Agentic coding expands to new surfaces and users
Агентный кодинг выходит за IDE: больше языков (включая legacy типа COBOL/Fortran), больше ролей (ops, security, design, DS), больше интерфейсов для не-разработчиков.
- Инженерам пора готовиться к "коду от доменных экспертов" - нужны шаблоны, guardrails, API/платформа, чтобы это было безопасно. Тут можно вспомнить про условный Lovable и приложения, что продакты сгенерировали через него
- CTO надо сознательно открывать агентные инструменты другим отделам, но через песочницы, права доступа и наблюдаемость.

В продолжении я расскажу про последние три тренда из этого интересного отчета.

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

The history of C# and TypeScript with Anders Hejlsberg | GitHub (Рубрика #Software)

Интересное интервью Андерса Хейлсберга, создателя C#, Delphi, Turbo Pascal и ведущего архитектора TypeScript, которое он дал GitHub. Андреас разбирает, как создавались C# и TypeScript и какие компромиссы стояли за решениями и какие принципы помогают языкам и командам "жить долго".

Из получасовго интервью можно почерпнуть много интересного
1️⃣ Быстрый фидбек важнее почти всего
Короткий цикл «написал → сразу понял/проверил» определяет скорость и качество. Поэтому ценность TypeScript - не только в типах, но и в инструментах: подсказки, проверка, рефакторинг, быстрый компилятор.
2️⃣Масштаб требует жертвовать личным идеалом
Когда пользователей и сценариев много, побеждает прагматика: язык успешен, если вписывается в реальную работу команд, а не только в учебник.
3️⃣ Эволюция сильнее революции
TypeScript вырос как надстройка над JavaScript: улучшает поддерживаемость больших проектов, не заставляя «сжигать мосты» и менять экосистему.
4️⃣ Прозрачность ускоряет open source
Публичные PR/issue и обсуждения переводят приоритеты от "внутренних" к реальным потребностям, а решения становятся объяснимыми и проверяемыми.
5️⃣ Иногда нужен рывок в основании без ломки внешнего контракта
Переписывание критического компонента ради производительности имеет смысл, если пользователь не платит ценой совместимости.
6️⃣ Эпоха AI смещает роль инженера
Всё больше кода генерируется, а ценность инструментов - в точности: типы, проверки, тесты и рефакторинг как ограждения от правдоподобных ошибок.
7️⃣ "Память проекта" - это актив
История обсуждений и решений (почему сделали так, а не иначе) снижает повторение ошибок и облегчает онбординг.

Если эти lessons learned превратить в какие-то выводы, то они могу быть такими

Для инженеров
- Инвестируйте в быстрый цикл: локальные проверки, быстрые тесты, линтеры/типы, удобные IDE-инструменты.
- Пишите для "коллективного владения": читаемость, предсказуемость, простые правила важнее личной элегантности.
- Учитесь по контексту решений: обсуждения в issue/PR часто дают больше, чем абстрактные «best practices».
- При работе с AI-кодом усиливайте страховку: типизация + статанализ + тесты, иначе вы просто быстрее генерируете долг.

Для технических руководителей
- Ставьте скорость обратной связи в KPI инженерной системы: CI, тесты, статанализ, быстрые сборки. Медленный фидбек рождает процессы-«костыли».
- Держите баланс интересов: стандарты и совместимость важнее вкуса отдельных сильных инженеров.
- Внедряйте изменения через миграции и совместимость: постепенное улучшение обычно дешевле и надёжнее тотальной замены.
- Стройте институциональную память: ADR/решения, ссылки на обсуждения, понятные причины компромиссов - это снижает риски при росте и текучести.

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

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

Масштабная конференция получилась:) С моего второго этажа отлично видны все остальные стенды - я решил отдохнуть немного, так как чуток осип полтора часа рассказыаать про исследование. А мне еще через полтора часа вести инженерную дискуссию про влияние AI на разработку:)

T-Sync Conf и итоги исследования AI4SDLC 2025 от Т-Банка (Рубрика #Engineering)

Сегодня я проведу весь день на конференции T-Sync, где нет докладов, а больше дискуссий и зон для общения. Собственно, у меня будет такая зона на втором этаже, где мы сможем поговрить про исследование AI4SDLC, которое мы стартанули в прошлом году опросом сообщества. Само исследование доступно на сайте ai4sdlc.tbank.ru при клике на вкладку "Исследование". Оно состоит из двух частей:

1️⃣ Раздел с мета-исследованием 2023–2025, где мы взяли порядка 50 отдельных исследований за последние годы и посмотрели на их результаты. Особенно интересно было смотреть на тренды серийных исследований, что проводятся ежегодно - по ним видно, как менялось отношение к AI в среде разработки, проникновение AI в разные сценарии, оценки его эффектов и так далее. Среди таких серийных исследований были исследования от: DORA, GitHub, Stack Overflow, JetBrains, Atlassian, McKinsey, Яков и Партнёры / Yandex, Express42, МФТИ. На сайте есть список серий, где можно посмотреть основные тренды каждой серии. Также есть таймлайн со всеми учтенными исследованиями + можно изучить краткое саммари по каждому из них

2️⃣ Раздел с результатами опроса, который мы проводили в конце прошлого года. Опрос получился объемным и я хотел бы поблагодарить всех поучавствовавших в нем. По результатам получилось примерно следующее: начали заполнять опрос порядка 1к человек и хорошо, что мы вопросы про использование и влияние AI вынесли в самое начало, так как до конца опроса дошли не все:) Если говорить, про профиль респондентов, то он получился такой:
- 50% разработчики, 17% технические руководители, 7% топ-менеджеры, 6% qa-инженеры, 4% AI/ML инженеры и так далее
- 24% работают в крупных компаниях (1к - 10к), 23% в очень крупных (10к+ сотрудников), 18% в средних (100 - 500 сотрудников), 16% в маленьких (10-100)
- основные представленные отрасли: финансы - 25%, технологии - 20%, розничная торговля и e-com - 15%, телеком - 7%, образование - 5%
- основные приложения/сервисы, над которыми работают респонденты распределились довольно равномерно: внутреннее/внешнее для пользователей - 45% vs 37% и b2c vs b2b - 34% vs 41%

Если говорить про executive summary результатов опроса, то они такие
- AI для генерации / автодополнения кода используют "часто/всегда" 58%; для code review 24%; для модернизации legacy 18% (при 42% "никогда").
- Производительность выросла у 64% (18% "значительно"); способность писать код улучшилась у 37%.
- Качество кода: улучшение 32%, ухудшение 14%, без изменений 42%.
- Доверие к AI-коду низкое: 49% не доверяют, 11% доверяют (остальные — нейтрально).
- Роль AI внутри компании выросла у 54%; прозрачность планов внедрения ощущают 50%, не ощущают 21%.
- "Системная готовность": commit→prod у заметной части измеряется неделями/месяцами; документация как источник правды работает плохо (около 39–42% не опираются на нее в критичных ситуациях).

И эти результаты хорошо откликаются в результатах мета-исследования
- Охват AI приближается к "почти у всех" (например, в сводках DORA к 2025 — около 90%); при этом личный эффект обычно сильнее командного.
- Узкие места переезжают в интеграцию, тестирование, ревью, релизы, коммуникации; в исследованиях регулярно всплывает тезис, что кодинг - лишь часть времени инженера (и что организационные барьеры съедают ощутимую долю недели).
- Качество и доверие - центральная проблема зрелости: "almost right" ответы создают новый долг проверки и дебага.
- Экспериментальные данные показывают: на сложных задачах эффект может быть нулевым или отрицательным; AI - усилитель системы, а не замена инженерии.
- Без guardrails (тесты, quality gates, small batch, ревью, наблюдаемость) "ускорение" легко превращается в "ускорение хаоса".

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

#AI #RnD #Software #Engineering #Management #Leadership #Metrics #Processes #Productivity

Почти интеллектуальные системы» (Smart (enough) systems) (Рубрика #Processes)

Нашел у себя на полке книгу про интеллектуальные системы, что вышла почти 20 лет назад. Когда-то давно я ее читал и в ней было много умных слов. А сейчас я ее открыл и понял, что если половину терминов оттуда заменять на модные сейчас слова типа "GenAI", "мультиагентные систем", "RAG" или "context engineering", то текст будет выглядеть как свежий архитектурный гайд по построению интеллектуальных систем. Дальше я решил понять, а что за авторы написали этот труд и оказалось, что там два автора
- Джеймс Тейлор - один из главных евангелистов decision management: работал в Fair Isaac (FICO), где развивал подход Enterprise Decision Management, а позже стал CEO Decision Management Solutions. Он много лет продвигает идею «делайте решения явными и управляемыми».
- Нил Рэйден - легенда BI/analytics: основатель Hired Brains, практик и аналитик, который умел объяснять, почему «данные есть, инсайты есть, а бизнес всё равно принимает решения “на глазок”».

Книга была хороша в свое время, так как в середине 2000‑х компании уже купили ERP/BPM/BI, построили витрины и дашборды… и внезапно обнаружили, что:
- Процессы автоматизировали, а решения внутри процессов - нет
- Аналитика живёт в презентациях и Excel, а не в runtime
- Правила размазаны по коду/табличкам/головам людей и меняются больно
Тейлор и Рэйден попали в нерв: они предложили смотреть на «решение» как на отдельный объект инженерии - как на сервис/компонент, который можно проектировать, тестировать, версионировать, мониторить и улучшать. Не «магический AI», а честная промышленная автоматизация скрытых решений.

Почему и сейчас книга актуальна - потому что многие используют buzzwords для описания желаемого результата вместо того, чтобы описать что именно они хотят. Условно "а тут у нас GenAI сделает все по красоте" или "наша multi-agent система выполнит эту работу сама" или просто "а тут справится AI". Для тех, кто немного понимает в технике такой подход кажется карго-культом. И тут полезно вспомнить про то, о чем рассказывала эта старая книга, а именно про то, что обычно болит в любой интеллектуальной системе:
- Где в продукте спрятаны решения и кто за них отвечает;
- Как отделять decision logic от process orchestration;
- Как сочетать “правила” и “модели” без религиозных войн;
- Как измерять качество решений (а не количество токенов);
- Как обеспечивать согласованность между каналами и командами;
- Как менять логику быстро, но безопасно (управление изменениями, контроль, обратная связь).

Когда читал эту книгу, то составил для себя минисловарик терминов из 2007 года и как они маппятся на термины из 2026 года
- Business rules engine → guardrails / policy engine / “промпт‑конституция”
- Predictive analytics model → ML‑модель / LLM‑модель / routing‑модель
- Decision service → AI‑оркестратор / агент с тулзами / микросервис решения
- Data & analytics → feature store + telemetry + (да‑да) RAG/векторная база
- Adaptive control → online‑эксперименты, bandits, self‑improving пайплайн
- “Make decisions explicit” → «вынесите это из кода/голов в явный артефакт + evals»

Забавно, что в 2007 году авторы специально добавили “(enough)” в название, чтобы отстроиться от тогдашнего "настоящего AI" - мол, нам не нужна эзотерика, нам нужна практическая автоматизация решений. В 2026 мы делаем наоборот: берём те же идеи, добавляем GPU, векторную БД и называем это GenAI.

Итого: технологии крутятся по кругу, а хорошая инженерия - нет. Если вы строите AI‑системы, то вам всё равно придётся:
- Делать решения явными
- Измерять их эффект
- Управлять изменениями
- Обеспечивать контроль и обратную связь

Просто вместо правил/скорингов иногда будет промпт/LLM. 🙂

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

Local-First Software: Taking Back Control of Our Data | a mini-doc (Рубрика #DistributedSystems)

Посмотрел интересный мини-документальный фильм, в котором засветились разные люди, но меня заинтересовал Мартин Клеппман, автор книги DDIA и один из апологетов подхода local-first. Собственно, этот подход предлагает альтернативу централизации хранения информации в облаке (и фиксации там источника истины). В local-first приложениях "истина" хранится на устройстве пользователя, работает без интернета и синхронизируется с облаком как с дополнительной копией.

Основные идеи концепции такие
1️⃣ Главная копия - у пользователя. Приложение читает/пишет локально → быстрый UX, офлайн по умолчанию. Облако нужно для синка между устройствами и бэкапа.
2️⃣ Cloud‑first ломается в быту. Например, пропал сигнал - пропал плейлист, хотя музыку «купили». И ещё хуже: сервис закрылся/выключил серверы - люди теряют доступ к своим данным.
3️⃣ Коллаборация возможна, но это сложно. Цель - как в лучших облачных продуктах (реал‑тайм, единые данные), но без постоянной связи с центральным сервером. Техники: CRDT, p2p/распределённая синхронизация, «слияние» изменений. Пока есть трудные кейсы и много инженерной работы.
4️⃣ Это уже движение. Сообщество растёт, появляются митапы/инструменты. Большинство «local‑first» продуктов пока гибридные (компромисс идеала и практики), но направление ясно: больше автономности и контроля пользователя.

Если прекладывать это на идеи для проектирования своих приложений и хочется попробовать двигаться в эту сторону, то можно сделать следующее
- Сделайте offline‑first базовым нефункциональным требованиям. Не «спиннер без сети», а работа с локальными данными + очередь/ретраи/идемпотентность (кстати, сейчас такой подход был бы актуален на случай блокирования мобильного интернета)
- Локальная БД + фоновый sync. SQLite/IndexedDB и слой репликации: журналы изменений, версии, мердж, лимиты/квоты, наблюдаемость синка.
- Конфликты - не баг, а сценарий. Опишите модель консистентности: last‑write‑wins, CRDT, явные конфликты в UI, правила домена.
- Контроль и долговечность данных. Экспорт, локальные бэкапы, миграции схем, E2E‑шифрование для синка/облака.
- Сдвиг сложности на клиент. Сервер может стать проще (координация/хранилище), но растут требования к тестированию офлайн/синка и к компетенциям в распределённых системах.

В общем. если подводить итог, то local-first пытается решить боли уехавших в облака приложений и ставших cloud-only, а список проблем большой: зависимость от сети, доверие и сохранность данных. Но надо отметить, что полный переход не обязателен, но уже сейчас можно внедрять элементы: локальное хранение, офлайн‑UX, безопасный sync и понятную модель конфликтов. Это даст продукту устойчивость и пользователю - ощущение контроля.

P.S.
Минидокументалка всего на 10 минут, поэтому ее вообще изян посмотреть почти как shorts:)

P.P.S.
Эта документалка тоже попала на сайт system-design.space, так как в ней очень интересно обсуждаются компромиссы при проектировании распределенных систем.

#DistributedSystems #Architecture #SystemDesign #Software #Databases

Official PyTorch Documentary: Powering the AI Revolution (Рубрика #AI)

Что-то я подсел в последнее время на документальные фильмы про технологии - очень интересно смотреть истории о том, как создавались техно-продукты, что сейчас являются де-факто стандартами индустрии. И это именно такой фильм про PyTorch с названием "Powering the AI Revolution", который вышел в 2024 году. Это фильм - ретроспектива от людей, которые строили PyTorch "изнутри": Soumith Chintala (со‑создатель PyTorch в Meta/FAIR), коллеги из Meta AI/FAIR (в т.ч. Yann LeCun) и партнёры по экосистеме. Основная мысль крутится вокруг того, как инструмент для быстрых экспериментов стал платформой, на которой учат и доставляют модели в прод.

Если говорить про основные вехи развития PyTorch (что хорошо освещается в фильме), то они такие
- Зарождение (2016). Выходцы из Torch7 (Lua) переносят идеи в Python и делают ключевую ставку на динамический граф (define‑by‑run / eager) + autograd «из коробки». Публичный релиз - осень 2016.
- Взлёт в ресёрче (2017). Минимальная «церемония», дебаг как в обычном Python, высокий темп релизов и рост комьюнити. Осенью 2017 с Microsoft запускают ONNX - стандарт переносимости моделей между фреймворками.
- Дорога в прод (2018). Объединение PyTorch и Caffe2. PyTorch 1.0 + TorchScript/JIT дают экспорт/оптимизацию для инференса и начинают закрывать разрыв между ноутбуком и сервисом.
- Массовое принятие (2019–2020): PyTorch догоняет/перегоняет TF по «весу» в академии и индустрии; усиливаются distributed‑возможности (torch.distributed и друзья). В 2020 OpenAI переводит стек на PyTorch ради скорости итераций; вокруг растёт «мидлварь» (Transformers, Lightning и т.п.), делая DL более инженерным.
- Нейтральность и устойчивость (2022). PyTorch Foundation под Linux Foundation, мультивендорное управление (облака, железо, платформы) - меньше рисков вендор‑локина, больше доверия рынка.
- Скорость без потери DX (2023). PyTorch 2.0 приносит torch.compile (Dynamo/Inductor) — компиляция, фьюзы, более агрессивные оптимизации, при этом код остаётся «питоничным».

Ключевые инсайты от создателей
- Конкуренция (TensorFlow) полезна: она заставила выбрать дифференциатор. PyTorch выиграл UX‑ом, а не лозунгами.
- Eager‑подход - продуктовая фича: меньше «магии графов», проще дебаг, быстрее цикл «гипотеза → код → метрика».
- Open source - это процесс: быстрые ревью/релизы, уважение к обратной связи, совместимость и прозрачность превращают библиотеку в стандарт.
- Побеждают экосистемы: training → export → serving → observability + интеграции с облаками и ускорителями. Один фреймворк не закрывает весь контур.
- Governance важно не меньше кода: нейтральная площадка и мультивендорность - условие долгой жизни платформы.

Уроки для разработчиков и техлидов
- DX - измеримая метрика: time‑to‑first‑result, скорость дебага, онбординг и число «переобучений» команды важнее синтетических бенчмарков. Кстати, про DX я много рассказываю и скоро опубликую целый динамический сайт, что посвящен именно этой теме
- Делайте путь из research в prod прямым: компиляция/экспорт/оптимизации должны быть частью дизайна, а не «потом допилим».
- Инвестируйте в компонуемость: стандарты (в духе ONNX), extension‑points, обратная совместимость, понятные контракты.
- Стройте платформу, а не зоопарк скриптов: пайплайны, репрод, трекинг экспериментов, тесты на деградации, понятные SLA.
- Организационный паттерн: дайте ресёрчу максимум свободы (eager, быстрые итерации), а платформенной команде - ответственность за «мост» в прод (compile/export/serving).
- Комьюнити (внутреннее или внешнее) - стратегический актив: доки, примеры, triage, RFC‑процессы и прозрачные решения масштабируют команду.
- Опирайтесь на облака/вендоров, но закладывайте переносимость: железо и провайдеры меняются быстрее ваших моделей.

Кстати, добавил этот фильм в список документалок на платформе system-design.space, так как тут очень интересно показаны вопросы дизайна платформы и миграции на нее с legacy систем

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

Troubleshooting Interview (Рубрика #Engineering)

Вчера впервые за полгода или даже больше провел интервью по траблшутингу для SRE-инженера. Когда-то я был лидером этой секции найма, много рассказывал про нее (на Devops Conf) и даже провел публичное интервью на Devoops Conf. Но потом я передал секцию другому лидеру, а сам остался в пуле интервьюеров и мне почти никогда не прилетал этот вид собеседований. Но на этой неделе он прилетел и я хотел отказаться - слишком я был перегружен другими делами и не хотелось тратить время на то, чтобы освежить воспоминания. Но я решил, что это отличный способ размять мозг и вспомнить былое - я вспомнил регламент, взял одну из задач, которую я добавлял в пул задач по траблшутингу на основе постмортема одной из моих команд и отправился проводить интервью. На самом интервью я вспомнил как это круто играть в DnD в роли гейм-мастера - мы "побеждали дракона" и "спасали принцессу" (нашу систему), а мне было очень интересно:) В итоге, я решил, что надо бы на сайт system-design.space добавить главы про troubleshooting - вопрос надежности спроектированного решения часто очень важен в рамках интервью по system design. В общем, я добавил главу про интервью в общем, а в главе про публичное интервью еще сделал визуализации архитектуры приложения и старта сбоя). Думаю, что на досуге возьму еще постмортемов и сделаю практических задач - а потом может с ними сделаю публичные моки интервью:)

#Architecture #SRE #Engineering #Software #Management #Career #Devops #Interview #SystemDesign

The Future of General AI Agents: The Story of Manus AI - SuperAI Singapore 2025 (Рубрика #AI)

Глянул старенькое видео Tao Cheung, co‑founder Manus AI, где он делился тем, какой путь прошла компания. Конечно там нет последнего этапа - acquistion компании запрещенной в России Meta (так как видео уже больше полугода). По-факту, Тао рассказывает как продукт прошел от браузерного расширения, эксперимент с AI-браузером, а дальше к облачному агенту, которые делает вещи, а не только отвечает на вопросы. В этом выступлении мало слов про технику и много про то, как сделать AI полезным в реальных сценариях.

Основные моменты из этого 24-минутного видео такие

1️⃣ General AI agent = мозг + руки
Ключевая метафора: одной генерации текста недостаточно. Агенту нужны “руки” - способность выполнять действия (инструменты/интеграции/исполнение задач), иначе это остаётся умным помощником в чате. Кстати, название стартапа с латинского переводится как рука (кисть).

2️⃣ Путь: расширение → AI‑браузер → облачные задачи
Команда начинала с расширения браузера как способа "встроить AI туда, где пользователь уже работает". Дальше был заход в "AI‑браузер", над которым команда работала 7-месяцев, но он оказался неудобен и ломал привычный флоу (надо было сидеть и ждать пока агент в браузере работает и не мешать ему). Этот опыт подтолкнул к идее облачного выполнения задач, когда агент делает работу в фоне и отдаёт готовый результат.

3️⃣ AI должен жить в рабочем контексте, а не в отдельной вкладке
Расширение как wedge‑продукт - это ставка на "AI в потоке работы" (браузер/страницы/контент), а не отдельный чат, куда нужно каждый раз перетаскивать контекст. Ребята вдохновлялись тем, как работает Cursor (IDE для разработчиков)

4️⃣ Самые частые юзкейсы (и почему это важно)
В Q&A Тао рассказал про три основных сценария: сбор/исследование информации, создание слайдов, сборка сайтов. Это хороший маркер того, где агенты дают ценность уже сейчас:
- много рутины,
- много “склеивания” источников/артефактов,
- понятный результат (“готовый deck / страница / отчёт”).([SuperAI Singapore][4])

Для инженеров можно почерпнуть следующие мысли

1) Парадигма меняется: вы строите не “чат”, а систему выполнения задач
Агент — это мини‑distributed system: планирование → шаги → инструменты → промежуточные состояния → финальный артефакт → логирование. Даже если “мозг” - LLM, инженерная часть - это оркестрация и контроль.
2) Архитектурный паттерн: sandbox + коннекторы
У Manus явно просматривается модель:
- облачный sandbox/браузер для изоляции и повторяемости
- плюс локальный коннектор/расширение там, где важны авторизованные сессии и “доверенный” контекст (логины, IP, вкладки)
Для ваших внутренних агентов это переводится в: где исполнять (локально/в облаке), с какими правами (least privilege), как аудитить (лог действий)
3) “Контекст‑инжиниринг” важнее “промпт‑инжиниринга”
Если агент собирает слайды/страницы/отчёты, решает не красота промпта, а:
- какие источники подключены,
- какие форматы входов/выходов стандартизованы,
- как агент получает обратную связь и исправляет.

А вот что это значит для технических руководителей

1) Выбирать нужно сценарии для автоматизации, а не “намазывать AI” ровным слоем
Самые “быстрые победы” - процессы с чётким Definition of Done и низким blast radius:
- подготовка отчёта/ресёрча,
- генерация презентации из RFC/PRD,
- сборка лендинга/демо‑страницы,
- автоматизация повторяемых web‑операций
2) KPI для агента = скорость × качество × цена
Вводите метрики, например
- % задач “сдано без переделок”,
- среднее время до результата,
- стоимость (деньги/кредиты/токены),
- количество вмешательств человека
3) Управление рисками: доступы, аудит, остановка
Если агент “кликает и логинится”, вам нужны политики:
- кто может подключать какие интеграции,
- где хранятся секреты,
- как выглядит audit trail,
- как быстро “остановить выполнение”

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

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

[2/2] Achieving Productivity Gains with AI-based IDE features: A Journey at Google∗ (Рубрика #Whitepaper)

В продолжении разбора обсудим на подход с оценкой изменения продуктивности в реальном использовании. Для этого они проанализировали показатели работы инженеров (подробнее про подход Google можно прочитать в whitepaper "Enabling the Study of Software Development Behavior With Cross-Tool Logs", который я уже разбирал). Измеряли, сколько Change Lists (CL, завершённых кодовых изменений) сдаёт разработчик в месяц, сколько времени он активно пишет код на один CL, и сколько времени тратит на поиск информации вне IDE. Эффект от Transform Code оценили через онлайн-эксперимент и Difference-in-Differences анализ, сравнив метрики пользователей инструмента с контрольной группой (2023–2024).

Результаты: У разработчиков, начавших пользоваться Transform Code
- CL throughput (CL в месяц) вырос на +17.5%.
- Среднее время поисковых сессий вне IDE сократилось на –3.6%.
- Active coding time per CL не изменился значимо.
Эти эффекты статистически значимы и свидетельствуют о росте продуктивности благодаря инструменту.

Из этой работы видно, что повысить продуктивность позволяют только комплексные улучшения во всех слоях инструмента. Важны UX (чтобы фичей легко пользовались), оптимизация интеграции (латентность, контекст), тюнинг модели на данных реального использования, мониторинг метрик вроде acceptance/FCML и проверка общей отдачи на уровне throughput. Все эти аспекты взаимозависимы и требуют координации между ML-, платформенными и UX-командами.

Кроме того видно, что такая работа по своей природе итеративна. Начните с MVP и улучшайте его на основе обратной связи. Подход “сделал → замерил → улучшил” (A/B-тесты, дообучение на пользовательских правках, доработка UI) оказался решающим для превращения прототипа в инструмент, давший +17.5% к выпуску кода.

В конце статьи приводится прогноз относительно AI в разработке
1) Сегодня это умные помощники для программиста
2) Завтра - полуавтономные агенты для рутинных задач
3) В перспективе - полностью автоматизированная разработка под контролем человека

Мне кажется, что часть людей вне корпораций уже живет в "завтра" по этой классификации. Но в любом случае конечная цель в том, чтобы ИИ ускорял весь цикл от идеи до продукта.

#Engineering #AI #ML #Software #Bigtech #Productivity #Management #Leadership #Processes #Architecture

[1/2] Achieving Productivity Gains with AI-based IDE features: A Journey at Google∗ (Рубрика #Whitepaper)

Прочитал ночью свежую статью (27 января 2026 года) от Google про их опыт к внедрению двух AI-функций в своей внутренней IDE: стандартного code completion и более интересной трансформации кода (где выделяешь код и дальше пишешь промпт о том, как поменять). Эти фичи были призваны ускорить работу разработчиков, но по пути инженерам пришлось решить проблемы с задержкой, UX и качеством подсказок, опираясь на эксперименты и данные. По-факту, ребята посмотрели на процесс продуктово - построили воронку и оценили потери на каждом шаге из-за разных факторов: неуверенности модели, задержек, нерелевантных рекомендаций или низкого вовлечения пользователей. Это позволило системно бороться с этими факторами, понимая на какие из них стоит сделать больший упор.

Дальше рассмотрим оба сценария

1️⃣ AI-автодополнение кода
В основе автодополнения - трансформер, обученный предсказывать код сразу за курсором (fill-in-the-middle), причем модель дообучена на реальных историях правок Google-разработчиков (приближая ее к живым сценариям). Для ускорения отклика и повышения качества применяются адаптивное кэширование (повторно использует недавние подсказки, устраняя лаг при быстром наборе), спекулятивное декодирование (параллельный запуск небольшой модели-прогнозера для снижения латентности) и другие оптимизации latency. Кроме того, модель получает расширенный контекст - фрагменты кода из открытых файлов вместе с их окружением (релевантные части, ближайшие к месту редактирования).

Совсетно все эти приседания дали следующие эффекты:
- Адаптивный кэш дал ~35% кеш-хитов и снизил медианную задержку на 9% (p90 –2%), а acceptance rate подсказок вырос на ~17%, увеличив долю кода, генерируемого ML, на 41%
- Добавление контекста дало еще +5% к принятию и +11% к FCML (хоть задержка выросла, медиана +46%)

Совокупно acceptance rate достиг ~45%, а ~28,7% всего кода теперь генерируется моделью (до 70,6%, если исключить copy-paste). В среднем принятый фрагмент подсказки составляет ~62 символа.

2️⃣ Transform Code (авто-правки по описанию)
Этот инструмент позволяет по запросу разработчика отредактировать выделенный код согласно текстовой инструкции (например, “замени X на Y”). Под капотом – модель Gemini, дообученная на внутреннем коде; она получает контекст файла с выделенным фрагментом и текст запроса, а выдает изменения в формате диффа. Основные сложности внедрения - как подсказать пользователю воспользоваться функцией (discoverability), как удобно отобразить крупные правки и как обеспечить высокое качество предложений даже на незавершённом коде.

Google решил эти проблемы несколькими улучшениями:
- Кнопка при выделении (+40% запросов, +64% новых пользователей).
- Упрощенный дифф (ревью быстрее на 7%, acceptance +2.2%, до +4.5% на крупных изменениях).
- Дообучение на правках (acceptance вырос ~55% → 63%).

Transform Code уже приносит пользу: ~68% предложенных правок принимаются разработчиками, а средний отклик < 1 с.

В продолжении я расскажу про то, как ребята оценивали изменения продуктивности от этих инструментов (это интересно).

#Engineering #AI #ML #Software #Bigtech #Productivity #Management #Leadership #Processes #Architecture