AI и Platform Engineering (Рубрика #AI)

Интересное выступление Игоря Маслова, VP of Coretech & Data в Т-Банке, на открытии конференции Platform Engineering Night, про которую я уже рассказывал. Игорь открывал конференцию и рассказал о том, как AI влияет на работу инженеров и развитие инженерных платформ. Основные мысли выступления примерно следующие

1. AI как усилитель существующих платформ
Сейчас нужно "обмазывать" существующие инженерные сценарии AI - от создания пайплайнов до анализа телеметрии. В этом разрезе интересно глянуть whitepaper Google "Measuring Developer Goals", чтобы посмоттреть какие основные сценарии выделяет Google (я рассказывал о нем раньше), а также девятый выпуск "Research Insights Made Simple", в котором мы с коллегой Колей Бушковым разбирали whitepaper "What Do Developers Want From AI?" от ребят из Google
2. Когнитивная нагрузка и потеря навыков
Игорь отмечает, что активное использование AI приводит к потере низкоуровневых навыков, но считает это нормальной эволюцией - условно, мало кто пишет на ассемблере и большая часть инженеров его уже не понимает и это никого не смущает. Примерно также мы будем писать код с ассистентами на условной Java и часть людей без ассистентов его уже не смогут написать/прочитать:)
3. Режим "копайлота" как базовый уровень
Ответственность за финальный результат остаётся за человеком, что минимизирует риски "галлюцинаций" AI-моделей. Anthropic реализует эту философию в Claude, где модель действует как ассистент, а не замена разработчика. Такой подход особенно важен в критически важных системах, таких как финансы или здравоохранение, где ошибки AI недопустимы
4. Будущее: AI как платформенная инженерия
В долгосрочной перспективе AI может стать основным интерфейсом для управления инженерными процессами, устраняя необходимость в традиционных инструментах. Это направление напоминает эволюцию Kubernetes, который стал стандартом для оркестрации контейнеров, но для AI аналогичный "момент" ещё не наступил
5. Vibe Coding и персонализированный софт
Генерация кода под конкретные бизнес-кейсы или индивидуальные потребности пользователей — ключевой тренд. Однако, как предупреждает Игорь, подобные системы требуют тщательной валидации, чтобы избежать проблем с поддерживаемостью кода
6. Разгрузка разработчиков от рутины
80% экспериментальной работы можно автоматизировать, освободив время для более важных задач. OpenAI's Code Interpreter позволяет итеративно решать сложные задачи программирования и анализа данных.
7. ML-платформы: гибкость и готовность к изменениям
Инвестиции в ML-платформы оправданы, но требуют готовности к технологическим сдвигам. Например, переход от традиционных нейросетей к трансформерам в 2020-х потребовал полного пересмотра инфраструктуры у большого количества компаний. Спикер подчёркивает, что платформы должны сохранять модульность, чтобы адаптироваться к новым алгоритмам и аппаратным решениям
8. Отсутствие "момента Kubernetes" в AI
Пока нет универсального стандарта для AI-платформ, и стоит дождаться его появления. Каждая компания развивает свои подходы: OpenAI с Agents SDK, Anthropic с фокусом на безопасность, Google с комплексными AI решениями.
9. Высокорискованная природа current AI R&D
Современные AI-решения требуют больших ресурсов и подходят в основном крупным компаниям. Это подтверждается масштабными инвестициями OpenAI, Google и Microsoft в платформенные решения.
10. Постепенный подход к внедрению
Рекомендация: начинать с улучшения инструментов, но пока воздержаться от сложных low-code процессов. Anthropic следует схожей философии, предоставляя мощные модели с акцентом на контролируемое внедрение.

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

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

Harnessing the Universal Geometry of Embeddings (Рубрика #Security)

Буквально на днях я выступал на PHDays, рассказывая про надежность и безопасность как фундаментальную часть наших систем, отмечая новые риски от AI. Вроде модель угроз была мне относительно понятна, но вчера читая канал Сергея Николенко Sinекура (@sinecor), наткнулся на рассказ про whitepaper "Harnessing the Universal Geometry of Embeddings", в котором авторы буквально разработали метод vec2vec для трансформации векторов из одного пространства представлений (embeddings) в другое. Сергей дальше в своем посте объясняет последствия

Ничего вроде бы сверхгениального в самом методе нету, но качество результата поразительное: на рис. 3 показано, как пять почти ортогональных друг другу векторов превратились в векторы со скалярными произведениями от 0.8 до 0.95.

На практике это очень много чего значит, и в основном не очень хорошее. Получается, что базы данных, которые содержат векторные представления, надо защищать так же тщательно, как исходный текст (чего никто сейчас, насколько я понимаю, не делает). В одном эксперименте они взяли эмбеддинги корпоративных email'ов Enron, перевели их в пространство известной модели (рис. 4) и смогли извлечь чувствительную информацию (имена, даты, суммы) из 80% документов.

В общем, еще один интересный вектор атаки, только уже не на базы с оригинальными данными, а на векторные базы с embeddings. Может у меня дойдут руки и я почитаю этот whitepaper в ближайшее время:)

P.S.
Я подписался на канал Сергея Николенко после того, как написал отзыв на книгу "Глубокое обучение. Погружение в мир нейросетей" 2018 года, соавтором который был Сергей. Суть в том, что один из подписчиков канала сказал, что у автора есть прикольный tg-канал, я проверил - канал оказался действительно интересным и теперь я его иногда почитываю. Спасибо за эту рекомендацию!

#Security #AI #Software #Engineering #Database #Data

Microsoft Build 2025 | Satya Nadella Opening Keynote (Рубрика #AI)

На прошлой неделе Сатья Наделла, CEO Microsoft, открывал большую конференцию MS Build интересным keynote докладом, в котором подключались гости в виде Сэма Альтмана, Илона Маска и других. И вот ключевые моменты, что были в его выступлении

1. GitHub Copilot как автономный агент
GitHub Copilot эволюционировал в полноценного агентного помощника, способного самостоятельно выполнять задачи разработки: от добавления новых функций и исправления ошибок до рефакторинга и генерации документации. Он использует Model Context Protocol (MCP) для взаимодействия с внешними данными и инструментами, а также поддерживает мультимодальные входные данные, включая скриншоты и макеты.
2. Azure AI Foundry: более 1900 моделей и мультиагентная оркестрация
Платформа Azure AI Foundry расширена до поддержки более 1900 моделей, включая интеграцию с Grok 3 от xAI. Она предоставляет инструменты для создания и управления мультиагентными системами, позволяя разработчикам строить сложные ИИ-приложения с высокой степенью кастомизации.
3. NLWeb: открытый протокол для агентного веба
Представлен NLWeb — открытый протокол, позволяющий внедрять ИИ-интерфейсы на веб-сайты с минимальным кодом. Он поддерживает подключение к различным LLM и использует MCP для взаимодействия с контентом сайта, открывая путь к созданию "агентного интернета".
4. Windows AI Foundry: локальная разработка ИИ на Windows
Новая платформа Windows AI Foundry предоставляет инструменты для локальной разработки, оптимизации и развертывания ИИ-моделей на Windows и macOS. Она поддерживает интеграцию с MCP и обеспечивает доступ к системным функциям, таким как файловая система и WSL.
5. Copilot Studio и настройка агентов
Copilot Studio теперь позволяет создавать и настраивать ИИ-агентов, используя внутренние данные компании. Это включает в себя настройку поведения агентов, их взаимодействие с другими системами и поддержку мультиагентных сценариев.
6. Интеграция моделей Grok от xAI в Azure
Microsoft объявила о партнерстве с xAI, предоставляя доступ к моделям Grok 3 и Grok 3 mini через Azure AI Foundry. Это расширяет выбор LLM для разработчиков и снижает зависимость от OpenAI. Именно на этой новости подключался Илон:)
7. Открытие исходного кода Windows Subsystem for Linux (WSL)
Microsoft открыла исходный код ключевых компонентов WSL, включая wsl.exe и wslg.exe, под лицензией MIT. Это шаг к большей прозрачности и вовлечению сообщества в развитие инструмента.
8. MCP как стандарт взаимодействия
MCP становится ключевым стандартом для взаимодействия ИИ-моделей с внешними данными и инструментами. Он обеспечивает унифицированный способ подключения моделей к различным источникам данных и системам, включая Windows и Azure.
9. Microsoft Discovery: платформа для научных исследований
Представлена платформа Microsoft Discovery, использующая специализированных ИИ-агентов для управления научными исследованиями — от генерации гипотез до анализа результатов. Она предназначена для ускорения научных открытий и повышения эффективности исследований. Интересно, что у Google и OpenAI уже были такие платформы
10. Фокус на мультиагентных системах и их оркестрации
Microsoft делает акцент на разработке мультиагентных систем, где агенты могут взаимодействовать друг с другом для выполнения сложных задач. Copilot Studio и Azure AI Agents Service предоставляют инструменты для создания таких систем с возможностью делегирования задач между агентами.

Интересно, что после этого нас порадовал и Google со своей презентацией достижений народного хозяйства на Google I/O 2025

#AI #Software #Engineering

State of platform engineering in the age of AI (Рубрика #AI)

Интересный отчет конца 2024 года, который подготовлен компанией Red Hat совместно с исследовательским агентством Illuminas. Red Hat — мировой лидер в области корпоративных open source-решений, активно развивает платформенную инженерию и внедрение ИИ в инфраструктуру предприятий. Illuminas — опытная исследовательская компания, специализирующаяся на IT и B2B-рынках. Этот отчет построен на опросе 1000 инженеров платформ и IT-руководителей из США, Великобритании и стран Азиатско-Тихоокеанского региона.

Методология исследования была следующей
- Это был онлайн-опрос на 20 минут, где было 1000 респондентов (поровну инженеров и руководителей)
- 35% участников представляло средние компании, а 65% — крупные
- Участвовали сотрудники компаний из отраслей: IT, финансы, ритейл, здравоохранение, профессиональные сервисы
- География опроса: США, Великобритания, англоязычные страны APAC

Ключевые идеи и выводы опроса следующие
1. Платформенная инженерия становится стратегической
62% компаний уже имеют выделенные команды платформенной инженерии. Платформенная инженерия — это не просто автоматизация инфраструктуры, а стратегический инструмент для ускорения инноваций и внедрения ИИ.
2. Влияние искусственного интеллекта
76% организаций уже используют генеративный ИИ для задач разработки (документация, генерация кода, подсказки). 45% считают ИИ центральным элементом своей платформенной стратегии.
3. Модель зрелости платформенной инженерии
Red Hat выделяет 4 уровня зрелости:
- Exploring - исследование
- Emerging - начало внедрения
- Established - устоявшаяся практика
- Advanced - продвинутый уровень
Компании с высокой зрелостью достигают на 41% лучших результатов (по продуктивности, инновациям, безопасности).
4. Основные драйверы внедрения
- Безопасность
- Улучшение взаимодействия между командами
- Автоматизация и ускорение процессов
5. Эволюция инвестиций
- На ранних этапах — фокус на модернизации инфраструктуры (55%)
- На продвинутых этапах — автоматизация (85%), безопасность (59%), инструменты для разработчиков (55%)
6. Проблемы и вызовы
На всех уровнях зрелости сохраняются сложности с интеграцией рабочих процессов и рисками безопасности (по 37%).
- На ранних этапах — нехватка навыков и бюджета (40%)
- На продвинутых этапах — несовместимость инструментов, нестабильность платформ, дефицит знаний (около 30%)
7. Метрики успеха
Зрелые компании отслеживают больше показателей (в среднем 7), включая продуктивность, безопасность, производительность приложений, удовлетворённость разработчиков. На ранних этапах чаще фокус на снижении затрат.

Если подводить итоги отчета, то можно заключить, что
- Платформенная инженерия становится отдельной профессией, требующей новых навыков и командной структуры.
- Компании и вендоры должны интегрировать ИИ в платформенные решения, а не рассматривать ИИ как отдельный инструмент.
- Стандартизация архитектур и best practices ускоряет внедрение и снижает риски.
- Безопасность и автоматизация — ключевые приоритеты для будущего развития.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

Code of Leadership #39 - Interview with Denis Pakhomov about social platforms (Рубрика #Management)

В очередном выпуске подкаста ко мне пришел интересный гость, Денис Пахомов, который является техническим руководителем в управлении разработки социальных платформ. Возглавляет 14 команд, которые разрабатывают социальную платформу и два продукта на её основе: Пульс и Линк. Команды e2e делают бэкэнд сервисы, мобильные SDK и продуктовые интеграции в клиентские поверхности. Собственно, с Денисом мы поговорили про его путь в IT, а также про развитие социальных сервисов внутри Т.

За час мы обсудили следующие темы
- Знакомство с гостем, обсуждение его биография и старта карьеры
- Переезд в Москву и работа в Сбербанке
- Переход в Тинькофф: работа над маркетинговыми проектами
- Проблемы, новый модуль и его задачи
- Рост команды и управленческие изменения
- Переключение на развитие соцплатформ и объединение команд
- Архитектурные процессы и формирование продукта
- Интеграция решений, внутренняя соцсеть и гибридизация мобильных и веб-платформ
- Культура, структура команд и видение социальных механик
- Роль менеджера, вызовы и советы по развитию

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

[2/2] ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (ATDD. Разработка программного обеспечения через приемочные тесты) (Рубрика #Engineering)

Продолжая рассказ о книге, расскажу про ключевые принципы ATDD, изложенные в ней

1. Коллаборативная спецификация требований. ATDD базируется на совместной работе бизнес-заказчиков, разработчиков и тестировщиков для формулирования тестируемых требований. Цикл состоит из четырех стадий:
- Discuss - обсуждение пользовательских историй
- Distill - выделение критериев приемки
- Develop - разработка
- Demo - демонстрация прототипа
Этот подход гарантирует, что все члены команды имеют одинаковое понимание целей.
2. Примеры как основа коммуникации. В ATDD команда использует конкретные примеры для описания поведения системы вместо абстрактных требований. Эти примеры служат живой документацией и должны быть написаны на языке бизнеса, понятном всем участникам процесса.
3. Автоматизация как буквальная интерпретация. Приемочные тесты должны автоматизироваться таким образом, чтобы они буквально отражали описанные примеры. Это означает, что автоматизированные тесты становятся исполняемой документацией, которая всегда актуальна и может служить регрессионным тестированием.
4. Тестирование до написания кода. Подобно TDD, в ATDD тесты создаются до написания продуктивного кода. Это помогает фокусироваться на том, что действительно нужно пользователю, и избегать оверинжиниринга.
5. Формат Given-When-Then. Для описания сценариев часто используется формат Gherkin с конструкциями Given-When-Then. Given описывает начальные условия, When — действия пользователя, Then — ожидаемые результаты. Этот формат делает тесты читаемыми как для технических, так и для нетехнических участников команды.
6. Фокус на бизнес-ценности. В отличие от unit-тестов, приемочные тесты проверяют функциональность с точки зрения пользователя и бизнес-ценности. Они отвечают на вопрос "работает ли система так, как ожидает заказчик", а не "работает ли конкретный метод правильно".
7. Интеграция с процессом разработки. ATDD не заменяет другие практики тестирования, а дополняет их. Он прекрасно сочетается с TDD на уровне модульных тестов, создавая многоуровневую систему обеспечения качества.
8. Постоянная обратная связь. Автоматизированные приемочные тесты обеспечивают постоянную обратную связь о состоянии системы.
9. Чистота и поддерживаемость тестов. Приемочные тесты должны быть написаны чисто и поддерживаемо. Они являются долгосрочными активами проекта и требуют такого же внимания к качеству кода, как и продакшен код. Рефакторинг тестов — неотъемлемая часть процесса.
10. Демонстрация как валидация. Финальная стадия цикла ATDD — демонстрация работающей функциональности заинтересованным сторонам. Это не только показывает результат, но и позволяет получить обратную связь для дальнейших итераций. Демо служит точкой валидации того, что построено именно то, что требовалось.

В итоге, книга ок с точки зрения базы, но требуется обновление в части
- Использования LLM для генерации тестов (подробнее в "Acceptance Test Generation with Large Language Models: An Industrial Case Study")
- Использовании актуального стека (например, Playwright или Cypress).
- Интеграции в процессы CI/CD

P.S.
Книга отправляется в booksharing уголок, что расположен в нашем московском офисе на 7 этаже (надеюсь, что она найдет себе новых читателей).

#QA #DevOps #Process #Software #Engineering #AI