Дайджест событий в области искусственного интеллекта

Российские компании продолжают активно внедрять ИИ в разработку и бизнес-процессы, мировые игроки пересматривают стратегии, а аналитики фиксируют новые тренды. Собрали для вас главные новости за март в дайджесте.

В России:
☁️ В Университете «Иннополис» разработали систему бронирования облачных ресурсов для ИИ-экспериментов: сервис позволяет резервировать вычислительные мощности в один клик.
🤖 «Сбер» представил платформу GigaChat Enterprise: с помощью неё компании могут создавать собственных ИИ-агентов и адаптировать их под свои бизнес-задачи.
💻 «Альфа-Банк» переходит на вайбкодинг: разработка, в основе которой лежит собственная платформа AlfaGen, где основную часть кода пишет ИИ.
🧠 «МТС Web Services» запустил R&D-направление Physical AI: пилотные запуски ПО и платформы навыков для роботов на основе ИИ запланированы на вторую половину 2026 года.

В мире:
⚙️ Nvidia делает ставку на inference: на конференции GTC 2026 Дженсен Хуан заявил о смене стратегии, акцент смещается с обучения моделей на их использование в реальном времени.
🛠️ Tesla и xAI представили совместный проект Macrohard: ИИ-система для разработки ПО, объединяющая языковую модель Grok и ИИ-агента для управления компьютером.
🚫 OpenAI закрыла приложение для генерации видео Sora и отказалась от функции оплаты товаров через ChatGPT.

Аналитика:
📊 Исследование «Т-Технологий» выявило: 58% разработчиков используют ИИ для написания кода, но доверяют ему лишь 11%, а выпуск релизов ускорился не более чем на 5–10%.
🛡️ Эксперты Softline прогнозируют появление в компаниях новой должности: Chief AI Risk Officer (CAIRO) будет отвечать за безопасность и надежность систем искусственного интеллекта.

#дайджест

QA, разработка и DevOps: кто и как доставляет качественный код до пользователя

Тестирование — важнейший этап, позволяющий убедиться в качестве кода перед передачей заказчику. Однако между моментом, когда код успешно прошел все проверки, и его появлением в среде, доступной пользователю, существует еще один значимый этап. За его организацию и эффективность отвечает DevOps.

Для того чтобы код начал работать в реальной среде, необходима инфраструктура: серверы, операционные системы, веб-серверы, базы данных, среды исполнения. А сам процесс перемещения кода от репозитория до стенда требует последовательного выполнения множества операций — компиляции, проверки уязвимостей, упаковки, развертывания.

Так, основной зоной ответственности инженеров DevOps становятся:
👉 Конфигурация среды исполнения — подготовка серверов, установка и настройка всего необходимого ПО для работы приложения.
👉 Автоматизация доставки кода — создание пайплайнов, которые самостоятельно переносят код от разработчика до стенда без ручного вмешательства.

Это означает, что разработчики продолжают работать над кодом, не отвлекаясь на настройку серверов или ручное развертывание. QA получают актуальные версии на стендах без ожидания, пока коллеги развернут им правки. Они могут самостоятельно обновлять стенды или откатываться на предыдущие версии для сравнения или более тщательной проверки.

Как организован процесс доставки кода?
Разработчик фиксирует изменения в системе управления кодом. После этого автоматически запускается пайплайн — последовательность заданий, включающая проверку синтаксиса, статический анализ кода, юнит-тестирование, компиляцию, сборку Docker-образов, доставку на стенд и развертывание. Каждое следующее задание выполняется только при успешном прохождении предыдущего. Такой подход исключает попадание на стенд кода, не прошедшего базовые проверки.

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

Почему без DevOps качественный код может долго не доходить до заказчика
Без выстроенного процесса настройка серверов, установка ПО, компиляция и доставка кода ложатся на плечи разработчиков. Это отвлекает их от основной задачи, замедляет разработку и создает риски, связанные с человеческим фактором. Появление новых стендов требует повторения одних и тех же ручных операций, что увеличивает вероятность ошибок и затягивает сроки.

DevOps становится связующим звеном между разработкой, тестированием и эксплуатацией. Инженеры этого направления проектируют процессы, в рамках которых код проходит путь от репозитория до продуктивной среды с минимальным участием человека. Это позволяет разработчикам сосредоточиться на создании функциональности, QA — на обеспечении качества, а заказчикам — получать стабильно работающие обновления без задержек.

От срочных задач к прозрачной системе планирования: что такое бэклог

Задачи в проектах появляются постоянно: новые идеи, запросы пользователей, исправления ошибок, доработки проекта. Если не фиксировать их в одном месте и не расставлять приоритеты, команда работает в режиме постоянных срочных задач.

В Skillbox Media вышел материал с участием ведущего бизнес-аналитика Embedika, Эльвиры Иллензеер — о том, как навести порядок в бэклоге и выстроить прозрачную систему управления.

Разобрали на практике:
▫️ Как превратить бэклог из бесконечного списка задач в полезный инструмент, который помогает команде планировать работу и расставлять приоритеты;
▫️ Как работать с техническим долгом, чтобы он не тормозил развитие проекта;
▫️ Какие бывают виды бэклогов, чем они отличаются и для каких задач подходит каждый;
▫️ Почему бэклог нужен не только разработке, но и любым специалистам, которые работают с большим объемом задач.

🔗 Полная версия статьи доступна на сайте Skillbox Media

#сми_о_нас

Какие сложности встречаются в работе тестировщиков: 6 вызовов QA-команды

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

Собрали 6 ситуаций, с которыми регулярно сталкиваются тестировщики 👇

1️⃣ Изменение требований в процессе разработки
Одна из самых распространенных ситуаций — когда изначально описан только основной сценарий, а в ходе реализации появляются дополнительные условия и уточнения логики. В таких случаях QA необходимо пересматривать тестовые сценарии, уточнять требования и повторно проверять уже реализованную функциональность. В реальных проектах это неизбежно, поэтому важна своевременная синхронизация с аналитиками и разработчиками.

2️⃣ Сложность воспроизведения дефектов
Иногда пользователи или коллеги сообщают о проблеме, которую сложно воспроизвести. Часто такие ошибки возникают при определенных условиях:
🔷 использование конкретного браузера, устройства или операционной системы;
🔷 редкая последовательность действий;
🔷 высокая нагрузка на систему;
🔷 взаимодействие с внешними сервисами.
В подобных ситуациях тестировщик анализирует логи, проверяет различные сценарии и последовательно выявляет комбинацию условий, при которой возникает ошибка.

3️⃣ Дефекты, которые проявляются только в продакшене
Иногда система работает стабильно на тестовых стендах, но даёт сбой в рабочей среде. Причины могут быть разными: отличия в конфигурации среды, особенности реальных пользовательских данных, высокая нагрузка или поведение внешних сервисов. В таких ситуациях QA помогает проанализировать ситуацию и воспроизвести проблему в тестовой среде для ее дальнейшего устранения.

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

5️⃣ «Спорные» дефекты
Иногда сложно определить, является ли обнаруженное поведение системы дефектом или допустимой логикой. Такое случается, когда в требованиях отсутствует явное описание сценария, участники команды по-разному интерпретируют поведение системы или пользовательский сценарий не был учтен на этапе анализа. В таких случаях дефект обсуждают внутри команды — с аналитиками, разработчиками и, при необходимости, с заказчиком.

6️⃣ Большие цепочки зависимостей
В сложных системах одна функция может зависеть сразу от нескольких сервисов или модулей. Если на одном из этапов передачи и обработки данных возникает сбой, тестировщику необходимо определить точное место его возникновения. Это требует анализа логов, проверки API и взаимодействия с несколькими командами разработки.

Сложные ситуации позволяют раскрыть основную ценность тестирования. Задачи QA выходят за рамки поиска дефектов: это понимание поведения системы в реальных условиях и поддержка команды в поиске наиболее надежных решений.