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

Большая энергетика. Что почем и как с этим жить (Рубрика #Economics)

Прочитал уже вторую книгу Андрея Косько, популяризатора науки, который в своей первой книге "Да будет свет... и тепло! Сколько стоит энергия" уже обращался к теме энергетики. Я про нее уже рассказывал, но если кратко, то там он на пальцах объяснял, что такое энергия и откуда она берется, отвечал на вопросы вроде «Когда закончится нефть?» и «Пересядем ли мы на автомобили с солнечными панелями?» - опираясь на основы физики, экономики и политики. Во второй книге "Большая энергетика" 2022 года Андрей продолжает эту тему на более глобальном уровне, но как и первое издание, она написана для широкой аудитории и не требует специальных знаний выше школьного курса. Правда, теперь автор смещает фокус с бытовых аспектов к "большой энергетике" - мировой энергетической системе, рынкам и геополитике. Это логичное развитие: получив в первой книге базовое понимание об энергии, читатель во второй погружается в сложные вопросы международной энергетики и получает ответы на вопросы вида
- Что нас ждет с изменением климата?
- Почему во всем мире так активно внедряется электротранспорт?
- Что вызывает ценовые шоки на нефтяных и газовых рынках и управляет динамикой поставок углеводородов?

Андрей подкрепляет выводы официальными документами, статистикой и реальными примерами. Книга охватывает технические, экономические, торговые и политические аспекты производства, транспортировки и потребления энергоносителей. Благодаря такому комплексному подходу читатель получает целостное представление о том, как устроена большая энергетика - от скважины и электростанции до розетки в доме, и какие силы движут этой системой. Эта тема особо важна сегодня: мир переживает сложный этап в энергетике, когда традиционный рынок углеводородов становится все более непредсказуемым из-за геополитических и экономических потрясений, а параллельно набирают вес новые факторы, такие как глобальная электрификация и стремительный рост спроса на электроэнергию со стороны IT и искусственного интеллекта.

Структура книги

Книга логично поделена на четыре части, каждая из которых отвечает на конкретный блок вопросов
Часть I: «Статистика. Что и сколько?» - здесь собраны данные о ключевых энергетических ресурсах: нефть, природный газ (включая сжиженный - СПГ), уголь, электроэнергию и их роль в мировом энергобалансе.
Часть II: «Торговля. Кто и кому?» - посвящена глобальному энергетическому рынку. Обсуждается, что такое рынок энергоносителей и как энергоресурсы превращаются в товар.
Часть III: «Экология. Что делать?» - сфокусирована на климате и экологии. Здесь автор разбирает проблему глобального потепления, парникового эффекта и их прямую связь с энергетикой.
Часть IV: «Политика. Как с этим жить?» - заключительная часть об энергетической политике и безопасности. Косько описывает понятие энергетической безопасности и вспоминает энергетические кризисы прошлого, чтобы показать их уроки. Даётся обзор деятельности международных энергетических организаций и анализируются региональные стратегии.

Хотя книга вышла в 2022 году, её содержание остается весьма актуальным на конец 2025 года. За последние годы энергетический ландшафт претерпел резкие изменения, но описанные Косько тренды только усилились. Рынок углеводородов по-прежнему лихорадит: после волатильности 2022–2023 гг. цены на нефть и газ то взлетают, то падают, реагируя на геополитику, санкции и решения ОПЕК. Электротранспорт продолжает набирать популярность по всему миру, выполняя прогнозы книги. Одновременно искусственный интеллект и цифровая экономика предъявляют новый запрос на электроэнергию: мощности дата-центров и суперкомпьютеров для ИИ растут экспоненциально. По оценкам, уже сейчас 5–15% потребления энергии дата-центров приходится на задачи ИИ, а к 2030 году эта доля может возрасти до 35–50%. Вопросы экологии тоже никуда не делись: 2023–2025 годы принесли рекордные природные аномалии, подчёркивая срочность борьбы с изменением климата – тем самым поддерживая важность обсуждения климатической повестки, рассмотренной в книге.

#Engineering #History

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

AI agents in 2025: Expectations vs. reality (Рубрика #AI)

Когда изучал информацию про успехи AI Agents наткнулся на статью полугодовой давности от IBM. В марте 2025 года 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

[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