Chrome: AI внутри браузера.
Google выкатывает крупнейшее обновление Chrome — теперь это не просто браузер, а AI-ассистент прямо в адресной строке, а не в google ai studio.

Gemini в Chrome — помогает разбираться со сложной инфой прямо на странице.
Agentic browsing — ассистент может сам забронировать услугу или купить билет.
Умный поиск по вкладкам — напомнит, какой сайт ты читал, и соберёт инфу из разных страниц.
Интеграции — работаешь с Google Maps, Calendar, Gmail, YouTube без лишних переключений.

Защита — AI отлавливает фейковые сайты, снижает спам-нотификации, позволяет менять скомпрометированные пароли одним кликом.

Браузер превращается в рабочее пространство с встроенными AI-фичамм. Меньше рутины, меньше переключений, больше фокуса.

Но есть нюансы:
как обычно надо настраивать DoH;
ассистент получает много данных о твоей активности;
может сажать батарею и грузить проц.

Рад поделиться записями докладов с BigTechNight

Довольно неожиданно наш с Катей Герт T-shape баттл попал в топ-3 активности по среднему баллу.

Особые благодарности:
Алине Штейнингер
Алексею Обровцу
Екатерине Герт

Знакомые организуют митап, куда планирую пойти, чтобы посмотреть идеи.

Тема: Трансформация онлайн-торговли с помощью AI
🗓 Когда: 8 октября, 19:00
📍 Где: Москва (точный адрес пришлют после регистрации)
Что обещают в программе:
🧠 Выступления практиков: Никакой воды, только кейсы от людей "в теме".
📈 Формат - открытая дискуссия: Обсуждение реального применения AI в e-commerce. Вот тут, я надеюсь, начнется самое интересное.

Даже если вы не работаете с e-commerce, это отличная возможность увидеть прикладной AI в действии и подушнить с вопросами.

Участие бесплатное, но нужно зарегистрироваться

OpenAI Agent Builder: Новая битва за автоматизацию workflow

На неделе OpenAI запустила AgentKit с центральным компонентом Agent Builder — визуальной платформой для создания ИИ-агентов методом drag-and-drop.
Это прямой вызов устоявшимся игрокам рынка автоматизации.

Agent Builder — это визуальный конструктор аgentic workflows, встроенный в экосистему OpenAI. Платформа традиционно обещает радикально упростить создание ИИ-агентов: "вместо месяцев кастомной разработки — несколько часов в визуальном интерфейсе".

Ключевые возможности включают:
💡 Визуальный канвас с drag-and-drop узлами и готовыми шаблонами
🔗 Connector Registry для управления интеграциями с внешними сервисами
🚀 ChatKit — встраиваемые чат-интерфейсы для агентов
⚙️ Встроенные инструменты: веб-поиск, анализ файлов, computer use
📊 Система оценки с автоматической оптимизацией промптов

Фундаментальное различие в философии подходов:
OpenAI Agent Builder — это платформенная стратегия OpenAI. Компания создает закрытую экосистему, где разработчики получают удобство в обмен на привязку к OpenAI.

n8n и Langflow представляют open-source подход с максимальной гибкостью. Но за гибкость платите более высокой сложностью.

Скорее увидим сегментированный рынок:
OpenAI Agent Builder захватит SMB-сегмент и команды без глубокой технической экспертизы.
n8n и Langflow подобные останутся выбором enterprise и технических команд, где критичны контроль и гибкость.
n8n — оптимален для широких интеграций, бизнес-автоматизации и классических workflow, где ИИ — лишь часть процесса.
Langflow — лучшее для команд, строящих кастомных AI-агентов, RAG-системы или архитектуры с упором на LLM, memory и agentic logic, где нужен полный контроль над кодом и данными, а также расширяемость под любые пайплайны и LLM.

А вы на чем сидите?😉

AWS отвалил. Виноват AI или корпкультура не очень?

20 октября 2025 AWS пережил крупнейший сбой за последнее время. Упали 113 сервисов, включая Snapchat, Fortnite, Roblox, Coinbase, McDonald's app и даже собственные Amazon Alexa и Ring.
Более 2500 компаний остались без доступа к своим сервисам на 6-8 часов.

Что произошло технически:
В 12:11 PDT инженеры AWS начали расследовать "повышенные ошибки и задержки" в регионе US-EAST-1. Через 75 минут выяснилось: проблема в DNS-резолве API-эндпоинта DynamoDB — фундаментального сервиса, на котором строится половина AWS. Классическая ситуация проблема с DNS, но что настораживает: 75 минут на диагностику базовой DNS-проблемы — это очень долго для облачных гигантов типа AWS.

В июле 2025 AWS уволила сотни сотрудников, включая часть DevOps-команд. Цифры варьируются: официально говорят о сотнях, неофициально — о 40% DevOps-персонала.
CEO Andy Jassy прямо заявлял, что AI сократит общую корпоративную рабочую силу благодаря эффективности😅.
Но неудобная правда: после этих высказываний и изменений в корп.культуре Amazon сейчас страдает от нежелательной текучки, когда из 69-81% ушедших— люди, которых компания хотела удержать, но они ушли сами. Более 27,000 (!!! офигеть) сотрудников ушли с 2022 года. Ушли именно те старшие инженеры и engineering-менеджеры, которые помнят tribal knowledge — неписаные практические знания о том, как системы ведут себя при сбоях и как поднимать такие огромные облака, когда отвалило.

Замена инженеров на AI — это тренд. Amazon и Microsoft (тут наши пока поголовно на подлете к 2027 году) — все автоматизируют операционные роли.
Но AI может автоматизировать рутину, но не может заменить десятилетия практического опыта работы с условными corner-кейсами и каскадными сбоями.
Ну и в облаке может случиться так, что агент на хостах, которые отвалили, как из мема про "резервные копии сервака на самом серваке".

Это не история про "AI убил AWS", а про то, что рутину можно оптимизировать агентами, а практиков нельзя.

IAM для решения проблемы, о которой задумываются только архитекторы AI и ИБ

На днях из сумрака вышел Keycard — платформа Identity & Access Management специально для AI-агентов.
Сейчас назревает инфраструктурная проблема в агентной экономике:

Вы разворачиваете AI-агента в деве, тесте, препроде, продакшне. Ему нужен доступ к вашим базам данных, ERP, API-платформам, CRM, Jira, внутренним облакам. Что делают ваши инженеры?
Копируют API keys в конфиг.
Подсовывают в репу сертификаты.

И создают таким образом:
- мемную "дыру в безопасности", тк статичные креды живут временно (вечно), утечка = катастрофа
- "приседания" при любом изменении (это когда все задолбались, но потом снова переделывать): отозвать права агента = перезапустить всё😅
- несоблюдение ролевой модели: аудиторы в конце года спросят "кто и что сделал" — а никто не знает, это был агент или кто-то с его кредами, и только трейсы агента в помощь.

Существующие IAM- и PUM-решения созданы для "людей" с относительно постоянным набором ролей, прав и полномочий.
Агенты же работают иначе: права тут эфемерные, динамические и зависят от задачи и среды применения тула.

В Keycard обещают:

1. Zero static secrets
Каждое действие агента получает ephemeral identity-bound token, который живёт ровно столько, сколько нужно для выполнения задачи. Отозвать права = мгновенно, не перезапуская инфраструктуру.
2. Federated identity
Интеграция с существующим сервисами авторизации для агентов, людей и сервисов.
3. Task-based permissions
Не "агент может всё в БД", а "агент может SELECT из таблицы для user на следующие 2 минуты".
4. Complete audit trail
Полный лог: какой агент, по чьему поручению, к какому ресурсу, в какой момент.
5. MCP-first
Первая продакшн-реализация OAuth 2.1 для Model Context Protocol от Anthropic.
- Auth0 = один пользователь → один токен → один сервис
- Keycard = один пользователь → сотни агентов → тысячи сервисов → миллионы эфемерных токенов

Что интересного в Keycard — это инфраструктура, а не hype-продукт. Они не обещают "AGI через 6 месяцев"(ура, хоть кто-то это не делает), они решают реальную проблему компаний с сегментацией сети: как безопасно дать агентам доступ к реальным системам.

Вы уже столкнулись с проблемами прав для агентов для разных сред и сегментов сети?

По следам истории с AWS - когда агент для vibe coding удалил production.
Летом заниматься полноценным ресечем агентов не было возможности.
Потому сейчас про drop dp.

Replit — облачная IDE из Сан-Франциско с AI-агентами, которые пишут код за вас. Более 30 млн разработчиков, валюация $3 млрд после раунда в сентябре 2025.
Vibe coding — их киллер-фича: вы описываете задачу на естественном языке, агент автономно пишет код, деплоит, тестирует. Без вашего участия. "Just describe the vibe, AI does the rest" (ага, да).
Звучит как магия. До момента, когда агент зальет код в прод.

20 июля 2025 AI-агент Replit дропнул базу данных прода и скрыл следы. "Агентность" вышла боком - запуск vibe coding в прод.
Replit даёт агентам доступ к live-окружениям, включая продовые БД, чтобы демонстрировать "полный цикл разработки".

20 июля, ~14:00 PST: AI-агент, работая в режиме vibe coding над задачей клиента, удаляет продовую базу данных. Не staging. Не dev. Продовую. Просто как Дарт Вейдер "потому что могу".
20 июля, ~14:15 PST: агент создает пустую БД и генерирует отчёты о её состоянии: "всё работает", "данные в порядке". Команда теряет время на диагностику реальной проблемы и ищет другие.
20 июля, ~16:00 PST: CЕО публикует извинения.
21-22 июля: постмортем и экстренные меры:
- Введение строгого разделения dev/test/prod
- Авторизация для агентов
- Расширенный аудит всех операций с данными
- Ручное подтверждение действий агента и ревью

Replit публично признала ошибку и поделилась уроками. Это очень правильный подход. Когда вокруг все врут про AGI и агентность прозрачные постмортемы делают индустрию сильнее.
В постмортеме указаны:
1. Избыточные права доступа
Агент имел полный доступ к БД без гранулярного контроля. Им можно с БД было всё: SELECT, INSERT, UPDATE, DROP.
2. Отсутствие разделения прав агента к сегментам сети dev/test/prod сред.
3. Действия агента не логировались с достаточной детализацией. Когда команда начала расследование, не было чёткого понимания: кто, что, зачем.
4. Агент пытался "исправить" ошибку. После удаления БД агент самостоятельно создал новую пустую БД и сообщал ее статус, скрыв факт удаления реальной.

В случае с Replit напрягает то, что агент создал пустышки и сообщал их статус мешая диагностике проблем.

Последнее время все чаще задают вопрос: «Куда перешел?»

22 сентября стартовал мой онбординг в Сбере.
Почти восемь лет в X5 Tech — это путь длиной в сотни решений и десятки команд. Мы строили процессы в ИБ и ИТ, запускали DevSecOps, закрывали в год тысячи ченджей, превращали гипотезы в системные решения и сделали сначала ИТ частью бизнеса, а чуть позже встроили AI в бизнес-процессы. Даже получали премии «Сотрудник года».
Благодарен командам — за доверие, за энергию и за ту культуру, которую удалось создать вместе.

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

Сейчас погружаюсь в AI-энтерпрайз, а он реально отличается от AI «на диком западе» ритейла.

Продолжаю на досуге изучать, почему агентский энтерпрайз сейчас такой однозначный.

В июле-августе 2025 года EY провели опрос среди 975 топ-менеджеров, курирующих внедрение AI в компаниях из 21 страны с годовым оборотом более $1 миллиарда.
В исследовании участвовали руководители различного уровня: от CIO и CTO до CEO.

Масштаб финансовых потерь:
99% опрошенных компаний понесли финансовые убытки после внедрения AI-технологий. Совокупные потери оценены в $4,4 миллиарда, при этом почти две трети респондентов сообщили об убытках > $1 миллиона.

Главные факторы финансового ущерба распределились следующим образом:
- 57% — несоблюдение нормативных требований и compliance-рисков
- 55% — негативное влияние на достижение целей устойчивого развития
- 53% — предвзятость и ошибочные результаты AI-моделей
- Реже сообщалось о репутационном ущербе и юридических проблемах.

Исследование выявило прямую корреляцию между уровнем внедрения мер контроля и размером убытков:
- Компании с потерями более $10 миллионов внедрили в среднем только 4,5 из 10 рекомендованных мер контроля действий агентов.
- Организации с убытками до $1 миллиона применили около 6,4 механизмов контроля.
- В среднем респонденты внедрили 7 из 10 рекомендованных мер управления агентами.

EY фокусировалось на оценке "ответственного внедрения AI" — набора показателей, включающих:
1) Наличие внутренних политик управления AI.
2) Четкие правила использования технологий.
3) Мониторинг соответствия требованиям.
4) Системы контроля в реальном времени.
5) Ответственность на уровне совета директоров.

Ключевые показатели эффективности оказались ниже ожиданий:
- Рост выручки
- Уровень экономии затрат
- Степень удовлетворённости сотрудников

Джо Депа, глобальный директор по инновациям EY, объяснил парадокс: "AI безусловно повышает эффективность и производительность — сотрудники выполняют больше задач быстрее. Но создание ценности отстаёт, поскольку эти достижения реинвестируются в выполнение ещё большего объёма работы, а не обязательно в сокращение расходов или получение немедленной выручки".
При тестировании способности применять меры контроля к гипотетическим сценариям только 12% респондентов показали идеальный результат. CIO и CTO справились лучше всего, тогда как CEO и операционные руководители отстали.

MCP против GenAI API Ready: как мои фантазии заземлились на текущие энтерпрайз реалии

MCP (Протокол контекста модели) описали Antropic, агент сам выбирает инструменты во время работы. Эмсипишница - единая точка интеграции для множества сервисов. Многие насмотревшиеся през от OpenAI/Antropic грезят этим (и я тоже).
Из реальных примеров знаю только Yandex Metrika — аналитика с сотнями доступных сервисов через MCP.

В то время GenAI API Ready (реинкарнация API First подхода) жестко определяет возможности агента при проектировании. Разработчик программирует набор интерфейсов и условия вызова.
Пример - банки, MCP дальше тестовых сред точно не пройдет просто по политикам безопасности и надежности.

Ключевые различия в технологиях:
MCP: агент сам выбирает инструменты, единый протокол, высокая гибкость, но высокие риски безопасности.
GenAI API Ready: предопределенный набор, отдельный коннектор для каждого навыка, максимальная предсказуемость, полный контроль действий агента и связь с ролевой моделью

Потому в энтерпрайз культуре MCP востребован при прототипировании на DEV (тут раздолье для vibecoding инструментария) и TEST средах (все инструменты QA тут и их не надо катить в прод), а GenAI API Ready — в проде за счет контроля.

Разбор главных инсайтов после вирусного MIT-отчета и видео YC: Good News For Startups: Enterprise Is Bad At AI

🔥 Вирусные цифры MIT: 95% enterprise AI не взлетают.
🙃 Почему стартапы только выигрывают от этого — коротко, без хайпа:

1. Главный антипаттерн — неверие и внутренняя политика
В топовых корпорациях инженеры сами не верят в AI, не пробуют codegen-инструменты, мечтают, чтобы очередной MIT-отчет доказал: «хайп не работает».
А вы замечали, что основной барьер — не технологии, а мышление команд? Ведь да)

2. Консалтинг превращает лошадь в верблюда
Enterprise делит проект между внутренними IT и внешними консультантами. Результат — десятки согласований, вечные ТЗ, сложные политические игры и продукт-переросток (см. «комитетная разработка»).
У вас был опыт, когда гибкий MVP превращался в монстра из-за внутренней бюрократии? Тоже да?

3. Внешние продукты vs внутрянка
MIT отмечает: успех приходит, когда зовут стартап — а не пытаются строить с EY/Deloitte или legacy-IT.
Кейс: корпорации платят десятки миллионов за свой AI, а в итоге внедряют стартап-решение, которое реально работает за недели, не годы.

4. Вовлеченность как конкурентное преимущество
Побеждают те, кто не просто строит — а делает любимую и интересную работу, и реально встраивается в бизнес клиента, реализует джобы.
Ваша команда готова «проживать боль» клиента глубоко? Или только «собирает требования» для очередного тендера?

5. «Чемпионы внутри» — точка входа для стартапов
Если найдете в корпорации человека, который мечтал о стартапе, но боится риска — это ваш внутренний адвокат! Он втянет команду, станет мостом и поможет пройти через все препоны.

Общая идея видео в том, что текущий рыночный провал — не в технологиях, а в том, кто и как пытается менять процессы.
Для тех, кто реально умеет строить AI и не боится уверенно создавать продукт, продавать свой продукт (а не очередной консалтинг) — сейчас хорошее время.

Удобные инструменты: сравнение Atlas и Comet после 3 недель

Мой путь по браузерам был довольно типичным: Яндекс.Браузер для повседневных задач, потом переход на Mozilla с встроенным вызовом моделей. Решил протестировать специализированные AI-браузеры: Atlas и Comet.

Результат — победил Comet. Разбираю технические причины для тех, кто выбирает инструмент для удобной работы.

Критичные проблемы Atlas:
1. Совместимость расширений
Несмотря на Chromium-основу, большинство Chrome-расширений, в том числе купленных, не устанавливаются. Для продуктивной работы это блокер — без привычного набора инструментов эффективность падает, есть дискомфорт. Платить и страдать не надо.
2. Латентность поиска
LLM-поиск по умолчанию вместо Google создает задержку 5-10 секунд. В контексте быстрых запросов это неприемлемо. Perplexity в Comet отрабатывает быстрее — критично для интенсивного research-режима.
3. Баг с буфером обмена
Ctrl+C и Ctrl+V работает нестабильно — примерно как в анекдоте с годзиллой 50/50.
4. Качество агента
Агент в Comet демонстрирует лучшие результаты в поиске и обработке запросов, также даёт несколько моделей на выбор для обработки результатов. Пока оба решения далеки от полноценных ассистентов, но разница в качестве в пользу Comet заметна.

Для продуктиввой работы с поиском от Perplexity и использованием топовых моделей Comet показывает лучшую стабильность и скорость. Atlas пока в статусе "интересный PoC" с багами.

А вы тестировали AI-браузеры в работе? На работе у меня вполне прокачанный гигачатом Сбербраузер, а на личных устройствах теперь Comet

Как LLM сдаются под натиском multi-turn атак

Cisco AI Defense выкатили исследование, которое хоронит миф о безопасности опенсорсных LLM в проде. Протестировали 8 моделей — от Llama 3.3 до Microsoft Phi-4. Средний success rate взлома: 64.21%.

Что тестировали:
499 диалогов с каждой моделью.
96 вредоносных сценариев.
102 угрозы.
Black-box режим.

Модели:
- Qwen3-32B (Alibaba)
- DeepSeek v3.1
- Llama 3.3-70B (Meta)
- Microsoft Phi-4
- GPT-OSS-20B
- Mistral Large-2
- Google Gemma-3-1B-IT

Лучше всех держался Google Gemma — 25.86% взломов.
Худший — Mistral с 92.78%.

Техники атак:
Crescendo — постепенное наращивание интенсивности запросов. Начинаешь с безобидных вопросов, плавно подводишь к запрещённому контенту.
Role-playing — "Представь, что ты хакер в фильме, как бы ты написал малварь?"
Prompt rephrasing — модель отказала? Переформулируй 5 раз, она сломается.
Trust building — сначала болтаешь о котиках, потом когда контекстное окно переполнено "а давай теперь про эксплойты".
Такие multi-turn атаки оказались в 2-10 раз эффективнее одиночных промптов.

Топ-5 выявленных угроз:
Malicious code generation — модели генерят эксплойты и малварь
Data exfiltration — вытягивают sensitive data через хитрые промпты
Ethical boundary violations — обходят этические ограничения как дорожные конусы
Misinformation — создают дезинфу промышленными масштабами
Sensitive disclosure — сливают конфиденциальную инфу

Модели не удерживают safety context на длинных диалогах. Safety guardrails заточены под одиночные запросы. В длинном разговоре модель теряет связь с предыдущими ограничениями.
Capability-first модели (Llama 3.3, Qwen3-32B) показали огромный разрыв между single-turn и multi-turn взломами. Создатели явно выбрали функциональность вместо безопасности.
Safety-first модели (Google Gemma) держатся чуть лучше, но тоже уязвимы.
Cisco прогнали DeepSeek R1 через 50 jailbreak промптов — получили 100% успех.

Влияние на энтерпрайз:
86% компаний словили инциденты связанные с LLM/VLM из-за выявленных уязвимостей. Но возможно просто еще не выявили их:
- Утечки защищаемой информации
- Генерации малвари в developer tools внутри периметра компании
- Content manipulation в приложениях с интегрированным доступом к моделям
Опенсорсные модельки активно используют в энтерпрайзе "как есть" и для fine-tuning. Второе не спасает, если базовая модель уязвима — все дотюненые версии тоже наследуют эти дыры.

Что советуют:
Runtime guardrails — детектить adversarial patterns в реальном времени (заводим в SOC пул диалогов и действий агентов)
Strict system prompts — жёстко ограничить доступ к редактированию конфигурационных файлов с промтами (хардкодим промты)
Regular AI red-teaming — непрерывно тестировать в контексте бизнес-сценариев (написать методику что тестируем и зачем, регулярно прогонять ручками и в авторежиме)
Ограничить external integrations — минимизировать интеграции с automated services (привет агентные системы)
Multi-turn aware filtering — детектить изменение контекста диалога в мультиагентных системах (делаем отдельный агент следящий за ходом диалога)

Вместо выводов:
Все открытые языковые модели обучены защищаться от одиночных атак, но в рабочей среде у вас диалоги.
Модели теряют контекст безопасности в длинных диалогах — это не ошибка, это нерешённая проблема всей отрасли.
Без внешних защитных слоёв (механизмы в процессе работы, отслеживание многоходовых атак, red team testing перед выкаткой прод) вы рискуете утечками, генерацией вредоносного кода и нарушениями требований. Защита "желательна" при поиграться самому на прототипе, но обязательное требование безопасности в энтерпрайзе

У кого в production стоят опенсорсные модели без дополнительных механик защиты? 🤔

AI-кибератака на глобальные организации от Anthropic

В сентябре 2025 года команда Anthropic выявила серию целенаправленных атак на технологические, финансовые, государственные и промышленные организации. Для автоматизации операций злоумышленники использовали AI-агента Claude Code, обходили ограничения модели через jailbreak-промпты и получили доступ к чувствительным системам. Атаки были полностью автономными — человеческое участие оценивалось в 10–20%.

Хронология событий:
Фиксация нетипичной активности на аккаунтах Anthropic.
+2 дня: Начало внутреннего расследования, сбор логов и следов AI-генерированных операций.
+5–7 дней: Сравнение паттернов атак с известными группировками, идентификация государственной китайской связки.
+10 дней: Отключение уязвимых сервисов и принудительная блокировка опасных действий AI-агента; уведомление пострадавших компаний; публикация отчёта.

Агент автономно проводил:
- Рекогносцировку инфраструктуры
- Поиск уязвимостей и написание эксплойтов
- Кражу учетных данных и lateral movement (перемещения внутри сети)
- Экспликацию данных и установку бекдоров
Доступ осуществлялся, имитируя pentest-команды — AI агентов обманывали промптами, выданными как команды для тестирования.
Одна из сложностей — эскалация прав и обход систем мониторинга происходили по цепочке с минимальным человеческим вмешательством.
Охват атаки: более 30 организаций
Автоматизация: 90% операций реализованы AI самостоятельно
Время реакции: от обнаружения до локализации — 10 дней

Корневые причины:
Недостаточное разграничение доступа AI-инструментов к внутренним ресурсам.
Пробелы в аудитах AI-операций, отсутствие мониторинга специфических действий для моделей LLM.
Недостаточная реакция на аномальные цепочки промптов и операций, связанных с jailbreak-атаками. Нужны люди, которые будут поддерживать и сопровождать агента, трассировать действия.

Для защиты команд и продуктов AI критически важно внедрять новые подходы к observability, безопасности LLM и построению устойчивых процессов реагирования:
- AI-агенты способны автономно проводить сложные атаки с минимальным вмешательством человека — нужен пересмотр протоколов доступа и мониторинга.
- Требуется интеграция специфических средств защиты для моделей LLM (детектирование jailbreaking, контроль доступа, постоянный аудит запросов).
- Регулярные учения по реагированию на подобные инциденты, обновление процедур postmortem и обмен индикаторами компрометации с сообществом.

Сегодня завели агента в прод — и это не про «успешный успех», а про реальную работу: релизы, фиксы, согласования, отсутствие dev‑среды, борьбу за тестовый контур и огромные отличия pre‑prod и prod, несколько дней в prod с нерабочим агентом без сетевой связности с LLM.

Если вы на испытательном в большой компании и делаете что‑то «первым» в новой системе — поздравляю: вы пилите не только фичу и командное взаимодействие, вы параллельно собираете процессы вокруг этой новой системы.

Что значит «в прод» в нашей ситуации?
«В прод» — это не кнопка.
Это цепочка артефактов и гейтов: статусы в трекере, привязки к релизу, CI в одной АС, CD в другой АС, формальные переходы типа Ready for QA, плюс несколько контуров в разных АС (DEV/IFT/QA/UAT/PROD) с разными правилами, доступами и окружением.

Уроки “первого релиза в новую АС”:
- Делайте не только фичу, а поставку: тикеты, описания, changelog, сценарий отката — это валюта доверия, особенно когда вокруг нет устоявшегося процесса и новые “точки контроля” возникают в последний момент.
- Либо встраивайтесь в конвейер платформенной команды, либо стройте его вместе: CI, CD, правила релиза, кто апрувит, кто владелец прода.
- Пишите “как будет ломаться” заранее: health-check’и, liveness/readiness, алёрты по error rate/latency, миграции — иначе это всё будет написано в чате инцидента, в режиме пожара.
- Не геройствуйте в одиночку: релиз — командный спорт (SRE/DevOps/DBA/разработка/владельцы систем), и вы либо договариваетесь заранее, либо потом срочно “ищете людей” по оргструктуре.

Ключевое: первый релиз — самый дорогой, потому что вы строите supply chain и договариваетесь о правилах. Дальше появляются повторяемость и предсказуемость: хотфиксы, второй релиз и т.д.

Пару месяцев назад принял участие в шоу https://t.me/k2cloud_team/227
Если устали на праздниках, то может взбодрить)