Книжный куб

[2/2] The Technological Republic: Hard Power, Soft Belief, and the Future of the West (Технологическая республика. Жесткая сила, мягкая вера и будущее Запада) (Рубрика #Economics) Продолжая рассказ про книгу, расскажу про основные идеи подробнее 1. Кремниевая долина потеряла ориентир общественного блага. Авторы начинают с резкой критики современной Силиконовой долины, утверждая, что за последние десятилетия технократическая элита изменила своим бывшим идеалам. Вместо решения больших задач человечества или укрепления национального процветания, лучшие инженерные умы занялись обслуживанием тривиальных потребностей рынка. Авторы говорят, что IT-гиганты ныне тратят колоссальные ресурсы не на прорывные инновации ради общего блага, а на приложения для комфорта избалованных потребителей. Забавно, что не требуется даже думать, чтобы можно было назвать конкретные компании, которые критикуют авторы. 2. Урок истории: союз технологий и государства творил великие дела. В противопоставление нынешней ситуации авторы приводят золотой век техно-прорывов XX века, когда наука, бизнес и государство в США действовали заодно (Манхэттенский проект, проект Apollo с высадкой человека на Луну). Эти программы объединили тысячи лучших учёных и инженеров, были щедро профинансированы государством и привели к колоссальным достижениям, изменившим ход истории. Авторы подчёркивают, что ранние инновации Кремниевой долины рождались похожим образом. Контраст с сегодняшним днем разителен: вместо “больших замыслов” - культура стартапов, устремленных к быстрому IPO; вместо сотрудничества с государством - гордое противопоставление ему или бегство от регулирования. Кстати, современный проект "Stargate" в этом плане выделяется (см. документалку, о которой я уже рассказывал) 3. “Мягкая вера” Запада: утрата общих убеждений и целей. Важнейшее понятие, которое вводят Карп и Замиска, - это кризис веры и идейной воли на Западе, то, что они называют "soft belief". С их точки зрения, у западных элит (политиков, академиков, гендиректоров) притупилась способность формулировать настоящие убеждения и отстаивать их публично. В публичной сфере царит дух самосохранения и страха кого-либо обидеть, из-за чего лидеры предпочитают говорить ни о чем, прятаться за корпоративными лозунгами, лишь бы избежать шквала критики в соцсетях. Этот интеллектуальный релятивизм ведет к тому, что компании, реально определяющие будущее (бигтехи), хранят многозначительное молчание о том, куда движется мир. Авторы доходят до идеи о “распаде национальной идентичности”, которая когда-то сплачивала изобретателей и инженеров вокруг общей цели, а теперь растворилась в космополитичном мире потребительства 4. Необходим пересмотр либерального консенсуса. Вследствие вышеописанного авторы считают, что сложившийся после Холодной войны либеральный консенсус – вера в автоматическое торжество свободного рынка, глобализации и толерантности - нуждается в переосмыслении. Карп и Замиска вовсе не призывают отказаться от демократических свобод, но считают, что Западу пора избавиться от наивности и вернуть стратегическое мышление времен противостояния с тоталитаризмом. Видно, что авторы противопоставляют себя Китаю и другим автократиям. 5. Технологическая республика: как технологии могут спасти, а не убить демократию. Центральный образ книги - “технологическая республика” и аллюзия на платоновскую «Республику» (не случайна). Речь о политическом порядке, крайне необходимом сегодня Америке и всему Западу, понимаемому как сообщество технологически и морально развитых демократий под лидерством США. По замыслу авторов, такая республика смогла бы противостоять вызовам XXI века, опираясь одновременно на “жесткую силу” (военную и технологическую мощь) и “мягкую веру” (убежденность, ценности и интеллектуальную смелость). По сути, “технологическая республика” - это призыв к возрождению просвещенного патриотизма среди технарей, ученых, предпринимателей. Их книга - это манифест уверенности в том, что Запад еще способен обновиться и победить, если обретет волю и смысл. #History #Economics #Future

[1/2] The Technological Republic: Hard Power, Soft Belief, and the Future of the West (Технологическая республика. Жесткая сила, мягкая вера и будущее Запада) (Рубрика #Economics) Прочитал интересную книгу Александра Карпа и Николаса Замиски из компании Palantir о будущем Запада. Чтобы понять контекст книги, необходимо знать о Palantir Technologies - компании, которую Александр Карп (со-автор книги) основал в 2003 году совместно с Питером Тилем и несколькими выпускниками Стэнфорда. Название Palantir заимствовано из Толкеина: палантиры - это “видящие камни”, позволяющие наблюдать на расстоянии (компания специализируется на анализе больших данных и разведывательной аналитике для спецслужб). Palantir с самого начала создавалась при активном участии ЦРУ и других разведывательных ведомств США, которые стали ее первыми клиентами. Сейчас капитализация компании составляет 420+ миллиардов долларов. В политическом плане Карп сам определял себя как прогрессивного социалиста, который всю жизнь голосовал за демократов и жертвовал крупные суммы в их поддержку. При этом он стал сооснователем компании, тесно связанной с военными и спецслужбами США, и убежденным сторонником укрепления обороноспособности Запада. Это своеобразное сочетание убеждений - делает Карпа фигурой нетипичной для Кремниевой долины. Карп открыто заявляет, что деятельность Palantir - это проект в защиту демократии, а усиление военного потенциала США и союзников он видит средством обеспечения свободы. Если говорить про основные идеи книги, то их можно суммировать до следующих 1. Кремниевая долина потеряла ориентир общественного блага 2. Урок истории: союз технологий и государства творил великие дела (Манхэттенский проект и проект Apollo) 3. “Мягкая вера” Запада: утрата общих убеждений и целей 4. Необходим пересмотр либерального консенсуса: веры в автоматическое торжество свободного рынка, глобализации и толерантности 5. Технологическая республика: как технологии могут спасти, а не убить демократию Продолжение будет здесь. #History #Economics #Future

[3/3] Future of Work with AI Agents: Auditing Automation and Augmentation Potential across the U.S. Workforce (Рубрика #AI) Заканчивая рассказ (1 и 2) про исследование, поделюсь финальными мыслями. Исследование также выявило важную тенденцию: по мере внедрения AI-агентов меняется набор ключевых навыков, востребованных у человека. Человеку будущего потребуется меньше узкоаналитических умений, но больше социальных и управленческих компетенций. Ведь аналитическую работу заберет на себя ИИ. Отдельно авторы обсудили ограничения своего исследования: - Авторы подчеркивают, что их результаты - это “срез” начала 2025 года, и прямолинейно проецировать их на далекое будущее нельзя без учета развития технологий. В частности, база WORKBank охватывает существующие задачи из O*NET; но в будущем появятся новые виды задач и профессий по мере интеграции AI, которые сейчас просто не учтены - Респонденты могли не до конца представлять возможности новейших AI-систем (авторы отмечают, что многие люди пока мало знают о границах и потенциале ИИ), что могло повлиять на их ответы - Опрос охватил 104 компьютеризированные профессии - это широкий спектр, но не все профессии экономики; исключены, например, рабочие специальности, где ИИ-агенты пока не применяются. Авторы прогнозируют, что ландшафт предпочтений и возможностей будет смещаться: по их словам, «AI Agent WORKBank отражает текущее состояние генеративного ИИ в начале 2025 года, и по мере эволюции технологий картина выполнимых и желанных для агентов задач будет меняться. Будущие итерации этого аудита необходимы для отслеживания долгосрочных трендов». Также исследователи дают несколько предсказаний и рекомендаций 1. Они ожидают снижения спроса на чисто аналитические, монотонно-информационные навыки (там, где ИИ уже доказал эффективность) и увеличения роли навыков, требующих взаимодействия между людьми. Этот прогноз подкрепляется их находкой о смещении высокооплачиваемых навыков и фактически рисует образ рынка труда, где в цене будут социальный интеллект, умение управлять и обучать, а не только умение работать с информацией 2. Авторы призывают к активным мерам по переподготовке работников. Поскольку AI-агенты способны изменить структуру спроса на навыки, важно уже сейчас разрабатывать программы рескиллинга и апскиллинга - переобучения сотрудников под новые компетенции 3. Исследование указывает на необходимость более человеко-ориентированной стратегии внедрения ИИ. Организациям и разработчикам рекомендуется учитывать желания работников при решении, что автоматизировать - то есть AI-системы будущего должны разрабатываться в тандеме с пользователями, чтобы они вызывали доверие, принимались сотрудниками и повышали эффективность без негативных социальных последствий 4. Бриньолфссон подчеркивает, что особое внимание следует уделить зонам “R&D Opportunity” - тем задачам, которые люди хотят автоматизировать, но техника пока не умеет. Повышение интенсивности исследований именно в этих областях позволит создать AI-инструменты, приносящие максимальную пользу и востребованные на рабочих местах, тем самым лучше подготовив экономику к будущему В целом, авторы видят будущее труда не как полную роботизацию, а как эволюцию ролей, где человек и умные агенты работают совместно, и призывают управлять этой эволюцией ответственно, исходя из потребностей людей. P.S. Выводы авторов про совместную работу напоминают идеи из whitepaper "Rethinking Software Engineering in the Foundation Model Era: From Task-Driven AI Copilots to Goal-Driven AI Pair Programmers", про который я рассказывал раньше. #AI #Economics #ML #Work

[2/3] Future of Work with AI Agents: Auditing Automation and Augmentation Potential across the U.S. Workforce (Рубрика #AI) Продолжая рассказ про исследование, поделюсь найденными результатами. Положительное отношение к автоматизации рутины Вопреки распространенным страхам, значительная доля работников хочет передать ИИ рутинные и низкоценные задачи. По опросу, для 46,1% всех рассматриваемых задач респонденты дали позитивную оценку возможности автоматизации (выше нейтральной на 5-балльной шкале). Причем перед ответом людей просили задуматься о риске потери работы и о том, нравится ли им выполняемая задача - но даже с учетом этого почти половина задач желанна для автоматизации по следующим причинам - Освободить время для более важной работы" (отметили ~69% сторонников автоматизации) - Избавиться от рутины (~47%) - Улучшить качества результата с помощью ИИ (~46%) - Избежать стресса (~25%) Опасения и зоны неприятия Вместе с тем, опрос подтвердил наличие серьезных опасений работников относительно ИИ. Наиболее распространены - Недоверие к качеству решений AI (упомянули ~45% – сомнения в точности, надежности алгоритмов) - Страх потери работы (23%) - Отсутствие человеческого подхода (16%) Эти страхи особенно сильны в творческих и гуманитарных сферах: например, в секторе «Искусство, дизайн, медиа» лишь 17% задач получили позитивную оценку автоматизации Четыре зоны соответствия желаний и возможностей Сопоставив желание работников с оценками экспертов, авторы разделили все задачи на 4 категории 1. "Зеленый свет" - задачи, которые люди готовы отдать ИИ и для которых уже есть технические возможности. Такие задачи - первые кандидаты на внедрение AI, обещающие наибольший выигрыш в продуктивности. 2. "Красный свет" - задачи, которые ИИ умеет выполнять, но люди не хотят автоматизировать. Здесь потенциальное внедрение ИИ может встретить сопротивление или иметь негативные соц. последствия, поэтому требуется осторожность 3. Зона R&D - задачи, которые работники очень хотели бы автоматизировать, но нынешние AI-модели с ними не справляются. Эти направления – перспективные цели для дальнейших разработок ИИ, чтобы удовлетворить явный запрос пользователей 4. "Низкий приоритет" - задачи с низким желанием автоматизации и низкой реализуемостью ИИ; ими можно пренебречь в ближайшей перспективе. Анализ показал значительные несоответствия: порядка 41% задач попали либо в «красную» зону, либо в «низкий приоритет», то есть значительная часть текущих усилий по внедрению AI либо направлена не туда, где этого хотят люди, либо пытается автоматизировать то, что пока не по силам технологиям. Например, оказалось, что стартапы из акселератора Y Combinator часто нацелены на задачи из «красной» или малоприоритетной зон, тогда как многие желанные для людей области (зелёная зона и R&D) остаются недоинвестированными. Этот вывод подчеркивает разрыв между интересами разработчиков/инвесторов и потребностями работников, а также указывает, куда стоит перенаправить усилия - на задачи зоны “Green Light” и R&D, где запрос высок, а технологий пока не хватает. Предпочтение сотрудничества, а не полной замены Большинство работников предпочитают не полную автоматизацию, а партнерство с ИИ. По введенной шкале участия человека (HAS) наиболее распространенный идеал - уровень H3 (равноправное партнерство): в среднем 45,2% опрошенных хотели бы работать в тандеме с AI-агентом как с равным “напарником”. Еще ~35,6% предпочитают модель H4 – то есть ИИ как ассистент под контролем человека (человек принимает ключевые решения). Таким образом, совокупно ~80% респондентов выступают за сохранение существенной роли человека при внедрении ИИ. Лишь малая доля работников (около 19%) готовы к почти полной автономии AI (уровни H1–H2) либо, наоборот, к совсем минимальному его использованию (H5). Это свидетельствует о ясном нежелании полностью передавать работу машинам: люди хотят, чтобы контроль и критические решения оставались за ними. Окончание в следующем посте. #AI #Economics #ML #Work

[1/3] Future of Work with AI Agents: Auditing Automation and Augmentation Potential across the U.S. Workforce (Рубрика #AI) Прочитал свежее и интересное исследование про будущее работы с учетом появления AI агентов (июнь 2025 года). Данное исследование проведено группой ученых Стэнфордского университета - в частности, исследователями из Института человеко-ориентированного ИИ (HAI) и Лаборатории цифровой экономики Стэнфорда. В состав авторов входят молодые исследователи (Йидзя Шао, Хумишка Зоуп, Ючэн Цзян, Цзясин Пэй, Дэвид Нгуен) под руководством признанных экспертов: профессор компьютерных наук Дии Йэн (Diyi Yang) и экономист Эрик Бриньолфссон (Erik Brynjolfsson). У Эрика есть научно-популярная книга “Machine, Platform, Crowd” 2017 года, о которой я уже рассказывал. Также я недавно разбирал похожую статью от Erik Brynjolfsson, Bharat Chandar и Ruyu Chen про трудоустройство "Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence". И теперь, когда ясно, что исследование от уважаемых людей, стоит рассказать в чем основная мысль авторов. Они хотели понять, а чего именно хотят сами работники от внедрения ИИ на рабочих местах, и насколько современные возможности AI-агентов соответствуют этим желаниям. Это желание напомнило мне whitepaper "What Do Developers Want From AI?" от ребят из Google, который я разбирал раньше. Но в этом исследовании вопрос поставлен примерно так: какие задачи своей работы люди хотели бы автоматизировать с помощью AI-агентов или, наоборот, предпочли бы оставить под человеческим контролем, и совпадает ли это с тем, что текущие технологии вообще способны автоматизировать. Плюс исследователей интересовало то, как интеграция AI-агентов может повлиять на структуру навыков и ролей в будущем. Для ответа на этот вопрос авторы разработали отдельную методологию, завязанную на опросы работников и экспертов. Они опросили 1 500 сотрудников из 104 различных профессий по всей США. Вопросы касались конкретных рабочих задач (взятых из официальной базы задач O*NET Министерства труда США), которые каждый респондент реально выполняет на своей работе. Работников просили указать, хотят ли они, чтобы AI-агент полностью автоматизировал выполнение каждой такой задачи, лишь помогал (дополнял человека) или же предпочли бы не использовать ИИ для данной задачи вовсе. Для более глубоких ответов использовались аудио-интервью (голосовые комментарии) и 5-балльная шкала Human Agency Scale (HAS), отражающая уровень участия человека - от H1 (полностью автономный ИИ, без участия человека) до H5 (полностью ручное выполнение, ИИ только как инструмент). Этот новый показатель HAS позволил количественно оценить предпочтительную степень участия человека в разных заданиях, а не только бинарно "автоматизировать или нет". Отдельно авторы опросили 52 экспертов по ИИ (разработчиков AI-агентов) для оценки текущей технической реализуемости автоматизации тех же задач. Эксперты оценивали, насколько современные системы ИИ (на начало 2025 г.) способны выполнять каждую из 844 рассмотренных рабочих задач. Такой двойной сбор данных - от работников и от экспертов - лег в основу базы WORKBank (AI Agent Worker Outlook & Readiness Knowledge Bank). WORKBank объединил предпочтения работников и оценки возможностей ИИ по широкому спектру задач (844 задачи, 104 профессий). Используя собранные данные, исследователи построили "ландшафт желаний vs. возможностей", распределив задачи по четырем зонам в зависимости от того, хотят ли люди их автоматизации и может ли ИИ их выполнить (вспоминается тост "Так выпьем же за то, чтобы наши желания совпадали с нашими возможностями"). Также была проанализирована текстовая расшифровка аудиоответов работников (тематика опасений и надежд) с помощью тематического моделирования, и выполнено сопоставление задач с требуемыми навыками и уровнем заработной платы, чтобы выявить смещение значимости навыков в связи с ИИ. Продолжение с разбором результатов исследования в следующем посте. #AI #Economics #ML #Work

Yandex Neuro Scale (Рубрика #AI) Дошел сегодня на конференцию Yandex Cloud, где на keynote докладе анонсировали много нового: новую зону доступности, новые AI инструменты внутри Яндекс Облака, новую AI студию для создания агентов и т.д. А сейчас я зашел послушать про работу AI агентов в разработке софта от Жени Колесникова (через недельку просто я сам буду выступать на похожую тему). Думаю, что потом напишу пост про выступления, что мне понравились на этой конфе. #AI #Cloud #Engineering #Software

[2/2] How tech companies measure the impact of AI on software development (Рубрика #AI) Продолжая пост про измерение влияние AI на разработку хочется поделиться примером из Dropbox, где ~90% инженеров регулярно пользуются AI-помощниками (по индустрии ~50%). Там измеряют активных пользователей, CSAT, экономию времени и расходы на ИИ, а затем накладывают эти данные на core-метрики: change fail percentage (CFR), throughput и др. (заметим, что CFR и throughput - это контр-балансирующие метрики). В итоге AI-пользователи доставляют на ~20% больше кода в неделю, при этом качество не падает (сбоев даже меньше). Это признак того, что массовое внедрение ИИ реально повышает эффективность, а не просто активность. Компании также сравнивают показатели у тех, кто пользуется ИИ, и тех, кто нет, и наблюдают изменения со временем. Такой анализ возможен только при наличии базовых данных до внедрения ИИ, но он ценен: так можно проверять гипотезы о влиянии ИИ на реальных цифрах. Важно не упирать только на скорость, забивая на качество - важно, чтобы рост частоты релизов/PR не сопровождался увеличением багов или откатов. Для выявления скрытого негативного эффекта (ухудшение maintainability, недовольство команды) проводите регулярные опросы Developer Experience. Из размышлений авторов вытекают практические рекомендации: 1.Сформулируйте ключевые метрики продуктивности (качество и скорость) и зафиксируйте базовый уровень до внедрения ИИ. Без этого непонятно, улучшает ли ИИ то, что нужно. 2. Отслеживайте использование ИИ, но не путайте активность с результатом. Важно не количество сгенерированного кода, а влияние на качество, скорость и комфорт работы 3. Балансируйте скорость и надёжность. Ускорение работы не должно приводить к росту брака - следите сразу за метриками скорости и качества 4. Учитывайте опыт команды. Наряду с логами и другими системными метриками регулярно собирайте обратную связь разработчиков (опросы DevEx, CSAT) - так вы не пропустите проблемы, незаметные в одних только цифрах. 5. Не карайте метриками. Донесите, что показатели ИИ нужны для улучшения процессов, а не для оценки персонала. Иначе подорвёте доверие и получите искажённые данные. 6. Культивируйте эксперименты. Пробуйте разные инструменты на небольших проектах, сравнивайте, где эффект максимален. Поощряйте обмен знаниями – обсуждайте удачные и провальные кейсы, делитесь находками и предупреждайте об ограничениях инструментов 7. Держите в фокусе ROI и риски. Отслеживайте, где ИИ даёт наибольший эффект и оправдывает вложения. Ограничьте применение ИИ в критичных зонах (данные пользователей, безопасность) до появления уверенности и нужных контролей #AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops

[1/2] How tech companies measure the impact of AI on software development (Рубрика #AI) Интересный пост от Гергели Ороша, автора подписки "The Pragmatic Engineer", и Лаура Тахо, CTO платформы DX, которая занимается измерением эффективности продуктивности. Они вместе были в подкасте "Measuring the impact of AI on software engineering", который я уже разбирал. У DX есть свой фреймворк для измерения продуктивности и недавно появился фреймвор для измерения влияния AI. В подкасте Research Insights мы их разбирали с Женей Сергеевым, engineering director из Flo Health - "DX Core 4" - "Measuring AI Code Assistants and Agents" Если возвращаться к этой статье, то интересны примеры конкретных метрик из 18 компаний, которые Лаура привела в качестве примеров. Из них видно, что ИИ-инструменты уже широко распространились: ими пользуются ~85% разработчиков. Но измерить их эффект непросто - 60% техлидов признаются, что у них нет понятных метрик пользы ИИ. В новостях упрощают: звучат заявления вроде «ИИ пишет N% кода». Однако строки кода - плохая метрика продуктивности: исходный код - скорее бремя, а не ценность. В итоге, Лаура предлагает ориетироваться на базовые метрики продуктивности: качество, надёжность, скорость, удовлетворённость инженеров. Многие компании продолжают измерять те же показатели, что и до ИИ (частота сбоев, скорость выпуска, время цикла, DevEx), а также оценивают насколько AI помогает их улучшать. Если эти базовые метрики не определены и нет консенсуса, а что считать продуктивностью, то оценка ИИ сведётся к пустым метрикам типа «количество кода» или процент принятых подсказок. Кромое стандартных показателей появляются и специфичные для AI метрики и они разбиваются на три категории (подробности в статье "Measuring AI Code Assistants and Agents"): 1. Уровень использования (usage) 2. Влияние на работу (сэкономленные часы) 3. Экономическое влияние (cost & benefits) Продолжение в следующем посте. #AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops

Unpacking нового роутера (Рубрика #Hardware) Недавно решил сменить роутер дома, так как прошлый не дотягивал до дальней комнаты. Решил прикупить роутер с 4 ядрами, достаточным количеством оперативы, а также слотом под флешку, чтобы расширять их. После раздумий я купил TP-Link AX80v1, особенно когда под него появилась прошивка под openwrt. А потом я его начал распаковывать и настраивать, что привело к распаковке до уровня платы и подключению через uart для накатки новой прошивки. Внутри роутер выглядит тоже отлично, примерно как и снаружи. Зато теперь у меня есть неплохой роутер со всеми нужными для меня возможностями (правда я узнал, что под перепрошивку можно купить роутер помощнее и даже подешевле). #Hardware #Software

AI agents in 2025: Expectations vs. reality (Рубрика #AI) Когда изучал информацию про успехи AI Agents наткнулся на статью полугодовой давности от IBM. В марте 2024 года IBM собрали четверых экспертов, чтобы обсудить с ними насколько реальна революция AI агентов. Среди экспертов были - Maryam Ashoori, PhD: Director of Product Management, IBM® watsonx.ai™  - Marina Danilevsky: Senior Research Scientist, Language Technologies  - Vyoma Gajjar: AI Technical Solutions Architect  - Chris Hay: Distinguished Engineer  Их позиции в этой статье выглядели примерно так 1. Ашоори: Сегодняшние «агенты» - это LLM с базовым планированием и function calling. Настоящий агент должен автономно рассуждать и планировать. 2. Данилевски (самая скептичная): «Я до сих пор не понимаю, чем это отличается от обычной оркестрации. Вы просто переименовали оркестрацию в агенты, потому что это модное слово». Данилевски опирается на опыт программирования - оркестрация существует давно. Ашоори разделяет текущие возможности и теоретический потенциал. 3. Хэй (самый оптимистичный): Технологический фундамент уже готов: -- Лучшие, быстрые, компактные модели -- Chain-of-thought training -- Расширенные контекстные окна -- Function calling На чем основано: Хэй анализирует техническое развитие моделей за 12-18 месяцев и видит качественный скачок в возможностях. 4. Гаджар: «Мы видим ранние проблески, но для сложных решений нужны прорывы в контекстном мышлении и edge cases». Среди экспертов разгорелись споры по следующим темам 1. Оркестрация vs единый агент Хэй: Будет маятниковое движение - сначала multi-agent системы с оркестратором, потом переход к «богоподобным» единым агентам, затем снова к коллаборации. - Ашоори: Это архитектурное решение, зависит от use case. Не всегда нужен мета-оркестратор. 2. Enterprise readiness - Хэй: «Большинство организаций не готовы к агентам. Интересная работа будет в экспозиции API ваших enterprise-систем». На чем основано: Понимание текущего состояния enterprise-архитектур и требований интеграции. 3. Проблемы безопасности - Ашоори: «Что, если агент подключится к датасету и удалит кучу чувствительных записей?» - Данилевски: «Технология не думает. Она не может быть ответственной. Масштаб риска выше - технология может сделать больше за меньшее время незаметно». - Гаджар предлагает в качестве решений: строгое тестирование в sandbox, механизмы rollback, audit logs. 4. Human-in-the-loop vs замещение - Данилевски: Агенты будут аугментировать людей - «человек должен постоянно присутствовать и принимать финальные решения». - Хэй: «Есть реальный риск, что при неправильной реализации люди будут дополнять AI, а не наоборот». На чем основаны прогнозы экспертов - Технический анализ: Хэй смотрит на прогресс в модельных capabilities - Практический опыт: Данилевски основывается на опыте с текущими системами - Enterprise research: Ашоори опирается на исследования поведения разработчиков - Архитектурное понимание: Гаджар анализирует требования к production-системам Выводы для инженеров - Текущие «агенты» - это upgraded LLM с function calling. До настоящей автономии еще далеко, но базовые кейсы уже работают. - Ценность будет у тех, кто организует свои данные для агентных workflow. Проблема не в моделях, а в enterprise-readiness. - Transparency, traceability, rollback mechanisms - это не опция, а must-have. Один неконтролируемый агент может удалить критические данные. - «Не становитесь молотком в поисках гвоздей» - сначала определите ROI, потом внедряйте агенты. Главное предсказание авторов в том, что 2025 действительно станет годом экспериментов с агентами, но революцию стоит ожидать позже. Готовьте почву сейчас, но держите ожидания реалистичными. Пока кажется, что он сбывается:) #AI #Software #Architecture #Agents #Leadership #ML #SystemDesign

Rethinking Software Engineering in the Foundation Model Era: From Task-Driven AI Copilots to Goal-Driven AI Pair Programmers (Рубрика #AI) Прочитал интересный и короткий whitepaper про изменения в разработке софта, готовясь к выступлению "AI в SDLC: от ассистентов к агентам". Если кратко, то это статья далекого 2024 года (а для AI прошлогодняя статья - это реально далеко), в которой авторы A. E. Hassan, G.A. Oliva, D. Lin, B. Chen, Z. M. Jiang предлагают уйти от task‑driven copilot‑инструментов к goal‑driven AI‑напарнику, который понимает цели разработки, помогает с архитектурой, кодом и проверкой результата. Если присмотреться, то ключевые моменты такие - Goal‑driven AI pair programmer, где ИИ не автодополнение, а партнёр по достижению цели (фичи, баг-фикса, миграции) - Инженерный процесс EDD (evaluation‑driven delivery), который аналогичен TDD (test-driven development), но фокус на постоянной проверке прогресса к цели на основе evals - В основе мультиагентная схема из четырех агентов: -- Агент целей - помогает выяснить цели инженера, общаясь с ним и собирая информацию (работает как аналитик) -- Агент архитектуры - умеет дизайнить под выясненные требования, знает архитектурные паттерны и может использовать ATAM (architecture tradeoff analysis method) или его аналоги -- Агент кода - рабочая лошадка, что умеет писать хороший код (и не только добавлять, но и рефакторить и удалять мертвый код) -- Goal delivery агент - агент, что отвечает за интеграцию работы всех остальных агентов для доведения проекта до успешного завершения. Он отслеживает выполнение конечных требований: превращение требований в тесты, актуальность тестов при изменении требований, и финальное прохождение всех тестов. Этот агент, помимо прочего, накопливает историю выполненных целей и прогресса, что затем может использоваться для наставничества: по мере работы он отмечает, какие навыки приобретает человек, где делает ошибки (связано с задачей обучения разработчика, см. Challenge 4). (Проще говоря, агент контролирует, чтобы всё задуманное действительно реализовано и проверено тестами, и фиксирует уроки для будущего). Для успешной работы такой системы есть следующие вызовы -Выравнивание целей человека и ИИ (минимум уточняющих вопросов, максимум понимания контекста) - тут мы видим пресловутый вопрос alignment - Общение на естественном языке вместо “промпт‑инжиниринга” (лучшие промпты машины пишут сами себе) - Доступные и умные code‑LLM (качество понимания проекта при умеренных ресурсах) - Роль ИИ‑наставника: адаптивное обучение разработчика “в паре” (AI не только исполнитель, но и ментор для инженера) В своем исследовании авторы опираются на следующие факты - Накопленный опыт использования GitHub Copilot и аналогов в индустрии, включая выявленные проблемы взаимодействия человека с AI - Предыдущие попытки автоматизировать разработку с помощью мультиагентных систем (ChatDev, MetaGPT, Devin и др.) - Проверенные временем методологии разработки (TDD, парное программирование) - Фундаментальные теории из образования (эффект наставничества по Блуму) и психологии (Theory of Mind) для обоснования социально-обучающего аспекта ИИ Статья была опубликована как препринт на arXiv в апреле 2024 года и сразу привлекла внимание в сообществе. Google Scholar индексирует эту работу; уже в 2024–2025 годах появились ссылки на нее в ряде новых исследований. Стоит отметить, что сами авторы продолжили развивать эту тему: в октябре 2024 они выпустили расширенный препринт “Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap”, фактически развивающий идеи этой статьи. В нем они ввели терминологию “Software Engineering 3.0” и более подробно описали план исследований на ближайшие годы. Если вам нравится эта тема и интересно общее состояние дел о том, как AI влияет на инженерную культуру, то предлагаю пройти опрос от Т-Банка на эту тему. О чем этот опрос и почему его результаты будут интересными я уже рассказывал раньше. #AI #Software #Architecture #Agents #Leadership #ML #SystemDesign

Спектакль «Учёная семейка и роботы» (Рубрика #Kids) Ученая семейка рассказывала про роботов. Нащшим малышам выдали дипломы повышения квалификации по итогам часового представления:) А если серьезно, то были опыты с жидким азотом, рассказ о том, как работают гидроэлектростанции, конвейер и роботы. Теоретическая часть была хорошо сдобрена юмором - детишки смеялись и с большим интересом генерировали ответы на вопросы актеров. #ForKids #ForParents

Обложка книги "Большая энергетика. Что почем и как с этим жить" и несколько иллюстраций

Большая энергетика. Что почем и как с этим жить (Рубрика #Economics) Прочитал уже вторую книгу Андрея Косько, популяризатора науки, который в своей первой книге "Да будет свет... и тепло! Сколько стоит энергия" уже обращался к теме энергетики. Я про нее уже рассказывал, но если кратко, то там он на пальцах объяснял, что такое энергия и откуда она берется, отвечал на вопросы вроде «Когда закончится нефть?» и «Пересядем ли мы на автомобили с солнечными панелями?» - опираясь на основы физики, экономики и политики. Во второй книге "Большая энергетика" 2022 года Андрей продолжает эту тему на более глобальном уровне, но как и первое издание, она написана для широкой аудитории и не требует специальных знаний выше школьного курса. Правда, теперь автор смещает фокус с бытовых аспектов к "большой энергетике" - мировой энергетической системе, рынкам и геополитике. Это логичное развитие: получив в первой книге базовое понимание об энергии, читатель во второй погружается в сложные вопросы международной энергетики и получает ответы на вопросы вида - Что нас ждет с изменением климата? - Почему во всем мире так активно внедряется электротранспорт? - Что вызывает ценовые шоки на нефтяных и газовых рынках и управляет динамикой поставок углеводородов? Андрей подкрепляет выводы официальными документами, статистикой и реальными примерами. Книга охватывает технические, экономические, торговые и политические аспекты производства, транспортировки и потребления энергоносителей. Благодаря такому комплексному подходу читатель получает целостное представление о том, как устроена большая энергетика - от скважины и электростанции до розетки в доме, и какие силы движут этой системой. Эта тема особо важна сегодня: мир переживает сложный этап в энергетике, когда традиционный рынок углеводородов становится все более непредсказуемым из-за геополитических и экономических потрясений, а параллельно набирают вес новые факторы, такие как глобальная электрификация и стремительный рост спроса на электроэнергию со стороны IT и искусственного интеллекта. Структура книги Книга логично поделена на четыре части, каждая из которых отвечает на конкретный блок вопросов Часть I: «Статистика. Что и сколько?» - здесь собраны данные о ключевых энергетических ресурсах: нефть, природный газ (включая сжиженный - СПГ), уголь, электроэнергию и их роль в мировом энергобалансе. Часть II: «Торговля. Кто и кому?» - посвящена глобальному энергетическому рынку. Обсуждается, что такое рынок энергоносителей и как энергоресурсы превращаются в товар. Часть III: «Экология. Что делать?» - сфокусирована на климате и экологии. Здесь автор разбирает проблему глобального потепления, парникового эффекта и их прямую связь с энергетикой. Часть IV: «Политика. Как с этим жить?» - заключительная часть об энергетической политике и безопасности. Косько описывает понятие энергетической безопасности и вспоминает энергетические кризисы прошлого, чтобы показать их уроки. Даётся обзор деятельности международных энергетических организаций и анализируются региональные стратегии. Хотя книга вышла в 2022 году, её содержание остается весьма актуальным на конец 2025 года. За последние годы энергетический ландшафт претерпел резкие изменения, но описанные Косько тренды только усилились. Рынок углеводородов по-прежнему лихорадит: после волатильности 2022–2023 гг. цены на нефть и газ то взлетают, то падают, реагируя на геополитику, санкции и решения ОПЕК. Электротранспорт продолжает набирать популярность по всему миру, выполняя прогнозы книги. Одновременно искусственный интеллект и цифровая экономика предъявляют новый запрос на электроэнергию: мощности дата-центров и суперкомпьютеров для ИИ растут экспоненциально. По оценкам, уже сейчас 5–15% потребления энергии дата-центров приходится на задачи ИИ, а к 2030 году эта доля может возрасти до 35–50%. Вопросы экологии тоже никуда не делись: 2023–2025 годы принесли рекордные природные аномалии, подчёркивая срочность борьбы с изменением климата – тем самым поддерживая важность обсуждения климатической повестки, рассмотренной в книге. #Engineering #History

Angular: The Documentary | An origin story (Рубрика #Engineering) Посмотрел интересный документальный фильм про создание и развитие фронтового фреймворка Angular. Этот фильм интересно посмотреть даже если вам не интересна история фронтовых фреймворков (кстати, про react тоже есть документалка и я уже про нее рассказывал). Фильм рассказывает как Angular родился как внутренний эксперимент в Google, который поначалу отмахнули большие команды (Gmail и Maps), а затем стал массовым фреймворком и прошёл через болезненную «вторую жизнь» (Angular 2+). А теперь чуть 1. Как Angular появился внутри Google (локальная инициатива) Старт проекту дала команда, работавшая над Google Feedback. Она утонула в 17 000 строк фронтенда и низкой тестопригодности. Тогда Ми́шко Хевери предложил дерзкий ход: переписать всё за две недели своим хобби‑проектом (GetAngular/AngularJS). Вышло за три, но код сжался до ~1 500 строк, и это стало моментом истины — менеджмент увидел в подходе ценность и дал зелёный свет на развитие. В общем, видно, что Angular родился не как глобальная инциатива "сверху-вниз", а скорее как локальная инженерная идея, доказавшаяся прототипом лечение реальной боли команды. 2. Борьба за ресурсы и «нет» по дороге На старте AngularJS не получал аппрув от флагманов внутри Google - многие говорили что-то в стиле "хорошая игрушка, удачи". Поддержка пришла после демонстрации драматической экономии сложности/кода и скорости разработки. Сначала - маленькая команда, много скепсиса, мало ресурсов; дальше - органический рост вокруг первых успешных внедрений. Итого, в большой компании лучше один раз радикально показать ценность на рабочем кейсе, чем долго убеждать словами. 3. Как в Angular появился Dart и почему далее произошёл «раскол» AngularJS и Angular Следующей развилкой стала производительность, статанализ и tree‑shaking. Внутри Google к этому моменту крепки были позиции Dart (с его dart2js и агрессивным tree‑shaking), а команда Angular экспериментировала между JS, AtScript и Dart. В итоге Google и Microsoft сошлись на TypeScript: ключевые идеи AtScript попали в TS 1.5, а Angular 2 строили уже на TypeScript, параллельно поддерживая AngularDart для крупных внутренних продуктов (Ads/AdSense). Это и закрепило исторический «раскол»: AngularJS (1.x) и Angular (2+) — два разных мира. В итоге, видно, что Dart повлиял на выделение дополнительных ресурсов, архитектуру фреймворка и компиляцию (статичность, AOT, tree‑shaking), но "языковая ставка" в открытой экосистеме ушла в сторону TypeScript. 4. Большие миграции У Angular было две ключевые миграции: - Архитектурный разрыв AngularJS → Angular (2+) - без обратной совместимости. Перепроектирование ради мобильности, модульности, типизации и будущей компиляции. Это самая болезненная точка истории. - Смена движка рендера на Ivy (Angular 9) - уже внутренняя замена View Engine на новый компилятор/рендерер, специально спроектированный под мелкогранулярный tree‑shaking и меньшие бандлы. Переход стал дефолтом в v9 и принёс ощутимую экономию размера без переписывания приложений с нуля. Обе миграции были болезненны, но кажется, что необходимы. 5. Как Angular чувствует себя сейчас и планы Angular снова на подъёме: зрелая реактивность (Signals), сильный SSR/гидрация, фокус на DX и производительности, аккуратные мажоры без «лома мира». А Google планирует переносить фичи Wiz (внутреннего фреймворка внутри Google) в публичный Angular. Акутальная дорожная карта есть на angular.dev/roadmap. В общем, документалка показалась мне интересной как техническому руководителю и инженеру - из этой истории можно извлечь много полезных уроков о том, как создавать и развивать крупные проекты. #Software #SoftwareDevelopment #Architecture #Engineering #Management #OpenSource

🧠 Как устроен наш ИИ-агент для разработчиков Мы в Т запустили агентский режим для разработки. Теперь агент не просто подсказывает части кода, а выполняет последовательность действий по заданию инженеров и помогает им сфокусироваться на сложных и креативных задачах. 🔥 Скоро откроем предзапись, чтобы любой желающий мог попробовать ИИ-агента в деле. Подробнее — на сайте. #AI4SDLC

Мы рассказали чуть подробнее о том, как работает наш агентский режим для разработчиков

AI в SDLC: от ассистентов к агентам 3 октября на конференции AI Boost я буду выступать с таким докладом. Саму конференцию про реальное ускорение разработки с помощью AI организовали ребята из Surf и где-то месяц назад они предложили мне выступить с продолжением моего доклада "Интегрируем AI в процессы разработки в большой компании", который я рассказывал летом на CTO Conf. В новом докладе я планирую поговорить про переход от режима AI-«ассистентов» (GitHub Copilot, Cursor и др.) к агентному подходу - когда автономные ИИ-агенты становятся полноценными участниками SDLC и взаимодействуют между собой. Будут затронуты следующе темы 1. Почему про это так много говорят - экономические предпосылки и эффект на workforce 2. Почему для эффективности AI-агентов критически важны чёткая постановка задач и знание контекста проекта 3. Как роль инженера смещается в сторону тимлида команды AI-агентов и какие для этого требуются навыки и образ мышления 4. Как мы дошли до жизни такой и какие агентские инструменты появились или засияли в 2025 году (Claude Code, OpenAI Codex, ...) 5. Как мы создали свой агентский режим для разработки и как он себя показывает на наших сценариях 6. Как это связано с модным "вайб-кодингом", где новым многообещающим языком программирования видят ... английский Если вам нравится эта тема, то покупайте билеты на конференцию и приходите слушать и задавать вопросы. А если вам интересно общее состояние дел о том, как AI влияет на инженерную культуру, то предлагаю пройти опрос от Т-Банка на эту тему. О чем этот опрос и почему его результаты будут интересными я уже рассказывал раньше. #AI #Engineering #Software #Management #ML #DevEx

Библиотеки Прикольно, что в парке на Ходынке сделали библиотеку. Правда, я в нее хожу со своими книгами:) Но сама идея - топ. Правда, я все равно предпочитаю читать книги, гуляя по парку, а не сидя в библиотеке. Вот дочитываю книгу Гергели Ороша, про котрую писал уже раньше

Как измерять продуктивность инженеров на разных уровнях (Рубрика #DevEx) Появилась запись выступления Станислава Моисеева, директора R&D‑центра Т‑Банка с Big Tech Night. В этом докладе Стас делает обзор лучших практик последних лет и связывает их с волной GenAI‑инструментов. За 5 лет ландшафт сильно изменился: ковид → удалёнка → внедрение AI. Компании инвестируют в ИИ‑инструменты для разработки, но без измерений сложно доказать ROI. Доклад показывает, какие метрики и на каком уровне отвечают на вопрос «что реально ускоряет поставку ценности», и упоминает методологию индустриального опроса 2025 для оценки влияния GenAI на разработку. Если говорить про уровни, то они такие IC (индивидуальные контрибьюторы) -> команды -> компании -> индустрия целиком. И работает это так - IC (индивидуальный инженер): следить стоит не за «строками кода», а за временем потока (сколько часов без переключений), cycle time своего PR, долей переделок/rollback’ов, качеством ревью. Это помогает видеть, как инструменты (IDE‑плагины, ассистенты, автотесты) влияют на вашу личную скорость и аккуратность. Осмысленный набор метрик хорошо описывается рамкой SPACE (удовлетворённость, performance, activity, communication, efficiency). - Команда: классический набор DORA (частота деплоев, lead time for changes, доля неудачных изменений, MTTR) + операционные метрики потока: WIP, размер PR, доля «ожидания» vs «работы», стабильность спринтов. Эти показатели коррелируют с предсказуемостью поставки и качеством. - Компания: здесь важны сквозные метрики: cost‑per‑change, time‑to‑value, скорость онбординга, покрытие автотестами критичных путей, утилизация платных AI‑мощностей на разработку vs «игрушки», экономия инженерных часов от ассистентов. Цель - связать инженерные метрики с P&L: сколько стоил прирост скорости и как он отразился на бизнесе. - Индустрия: бенчмарки и сравнительные опросы. В докладе заявлен подход к индустриальному исследованию 2025 года по влиянию GenAI — чтобы компании могли соотнести свои практики с «средней температурой по цеху» и отделить хайп от эффекта (я уже рассказывал про это исследование раньше) Если говорить про то, на что обратить внимание при использовании метрик, то - Не стоит использовать анти‑метрики: «строки кода», «количество задач», «скорость закрытия багов» без контекста. Они легко геймитсятся и толкают к плохим решениям. - Не используйте метрики без обратной связи: любой график должен вести к конкретному решению процесса или инструмента. - Не мерьте температуру «среднюю по больнице»: сравнивайте себя со своей историей (тренды), а не с соседним отделом с другим контекстом или на другой архитектуре. #Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership