Управление разработкой *

Расскажем, как нам удалось повысить качество определения истинных секретов в результатах сканирования кода с 0.70 до 0.90 PR AUC с помощью LLM.

Хочу рассказать, почему растущие бизнес-требования к Time-to-Market, персонализации, 0 FTE in RUN заставили нас пойти на радикальный шаг — разработку собственной платформы управления архитектурой EA Tool. Это не история про замену одного софта на другой, а рассказ о том, как мы создаём «цифровую нервную систему» банка и как переход от изолированного рисования диаграмм (набивших оскомину «квадратиков со стрелками») к управлению цифровым двойником снова меняет нашу профессию.

Десятилетиями для нас, как и для многих на рынке, стандартом де-факто оставались такие вендорские решения, как Alfabet, iServer, Sparx EA и др. Это мощные, «классические» инструменты метамоделирования ИТ-ландшафта с широкой встроенной функциональностью, включающей аналитику текущего и целевого состояния ИТ-ландшафта, в которых годами работали сотни наших спецов. Но сейчас стало очевидно, что созданные десятки лет назад, такие инструменты имеют встроенные ограничения и начинают откровенно тормозить ИИ-революцию.

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

Всё это — девконтейнеры! Да, мы начинаем программировать прямо в контейнере. И всё это бесплатно и без необходимости развёртывания новых сущностей в вашей организации. О такой кнопке «сделать хорошо» мы и поговорим в этой статье по мотивам моего доклада для DevOps Conf. 

Coinbase уволили инженера за отказ пользоваться AI-инструментами. Prodoscore замерили 25 000 сотрудников - кто пользуется AI, тот на 19% продуктивнее. Каждый месяц разрыв растёт ещё на процент. Создатель Claude Code шипит 30 MR в день и не пишет ни строчки руками. Собрал данные - и понял, что «20 лет опыта» без AI уже мало.

Если у вас одна платформа, фронтенд работает стабильно и предсказуемо. Но стоит добавить десктоп, мобильное приложение, PWA — и простая логика превращается в гору if-ов.

Меня зовут Денис Кондратьев, я фронтенд-разработчик Точка Банк. В статье расскажу, как мы интегрировали наш мессенджер на четыре разные платформы (браузер, Electron, Capacitor, PWA) и сократили время адаптации новых фич в три раза.

Если тема управления задачами в Obsidian вам близка - заглядывайте в мой тг-канал, там я разбираю подобные вещи регулярно.

В очередной раз пытаемся понять: «есть ли место в нашей команде системному аналитику и нужен ли он нам вообще?»

← Часть первая

Я не помню ни дня, когда Azure не работал бы в стрессовых условиях.

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

Весной и летом 2024 года началась масштабная инициатива по увеличению количества VM, которое мог хостить каждый узел. С точки зрения бизнеса всё было понятно: повышение плотности уже имеющихся серверов гораздо дешевле, чем построение новых дата-центров. Развёртывания Azure на мощностях компании всегда были ограничены шестнадцатью VM на узел. До того года собственные коммерческие облака Microsoft работали максимум с 32 VM, и это всё равно крошечная доля от теоретически поддерживаемых гипервизором 1024 VM.

Цель заключалась в увеличении на 50%, до 48 VM на узел, с перспективой увеличения до 64 в будущем. То, что должно было стать задачей по повышению произвольных ограничений ПО, привело к росту вылетов и инцидентов на 50%. Проблемы масштабировались ровно пропорционально плотности.

Ранее, когда я ещё продолжал работать над планом переработки интерфейса гипервизора для нижней части стека узлов Azure, мы провели исследование с командой Core OS, отвечавшей за другую сторону Hypervisor API. Данные трассировки вызовов показывали, что агенты узлов вместе атаковали гипервизор через интерфейс пользовательского режима WMI, в пике достигая 10 тысяч вызовов в секунду. У команды Hyper-V не было информации о том, какие агенты отвечали за это и почему было необходимо столько вызовов. С нашей стороны тоже никто не мог дать определённого ответа. На этом этапе стало понятно, что проект портирования выгрузки Overlake не будет никогда завершён. Не только из-за описанных выше зависимостей, но и из-за самого динамического поведения стека.

Всем привет. Меня зовут Максим, я разработчик в одном из крупных финтехов России. У нас сейчас (наверно, как и у всех) интенсивно вводят ИИ-агенты для написания кода. Плюс необходимое соблюдение метрик по охвату и использованию данных агентов.

Но никто не задумывается о состоянии души разработчика при KPI обязательного использования ИИ.

От вайбкодинга к профессиональной ИИ‑разработке на примере LanChess: 3300 промптов, 832 коммита, 100 тыс. строк кода и путь от POC к продакшен‑сервису.

Поздний вечер, я смотрю в терминал. Celery worker на восьмиядерном сервере перемалывает 67 партий блица на Lichess одного из пользователей. Через минуту этот человек получит персонализированную аналитику и упражнения от сервиса, аналогов которого в России найти пока не удалось. Я же сижу и думаю, стоит ли выводить этот сервис из закрытого режима по инвайтам.

Менее чем за 3 месяца я написал 100 тыс. строк кода и ни одной — своими руками. Мне пришлось стать оператором персональных данных. РКН порекомендовал мне убрать авторизацию от Google. А ВК не давал мне подключить свою авторизацию, пока я не стал самозанятым.

Зато теперь у меня есть свой сервис, на примере которого без всяких NDA я могу открыто рассказывать о том, чем отличается вайбкодинг от профессиональной ИИ‑разработки. Могу смело поделиться статистикой продуктивности. Могу, не таясь, рассказать о сложностях, ошибках и успехах, с которыми сталкиваются инженеры, использующие самые современные инструменты искусственного интеллекта для разработки программного обеспечения. С помощью ИИ я работал над разными проектами за последние годы. Но только о своём я могу рассказать всё.

Это материал по мотивам выпуска подкаста Podcast++ от Онтико и Ви.Tech. В центре разговора - Ольга Ортега, директор по данным и аналитике в Ви.Tech - IT-дочке ВсеИнструменты.ру, и Иван Лукьянов, коуч и ментор директоров и фаундеров крупных компаний. Говорили о жизнестойкости лидера: не как о красивом слове из популярной психологии, а как о практическом навыке, который проверяется не на конференциях, а в моменты, когда все идет не так.

С жизнестойкостью есть известная проблема. О ней легко говорить общими словами: держаться, не сдаваться, мыслить позитивно, искать возможности. Но как только разговор упирается в увольнения, кассовые разрывы, выгорание, потерю почвы под ногами и месяцы турбулентности, все общие слова быстро перестают помогать. Приходится разбирать тему по частям: что именно держит человека, где заканчивается оптимизм и начинается самообман, почему одной дисциплины мало и можно ли вообще эту штуку в себе натренировать.

Проектный шестиугольник, документация проектов, внутрянка проектных команд, фреймворки обратной связи, система обучения в проектной команде и всё самое интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Из этой серии статей вы узнаете о, вероятно, самой глупом, легко предотвратимом и дорогом провале 21-го века, из-за которого Microsoft чуть не потеряла своего самого крупного клиента (OpenAI) и доверие правительства США.

Скучным утром понедельника 1 мая 2023 я впервые вышёл на работу в Azure Core в качестве сениор-сотрудника команды Overlake R&D, разработавшей карту выгрузки и сетевой ускоритель Azure Boost.

Azure не был для меня чем-то новым: наверно, это самая длительная моя подписка на облачный сервис, который был запущен в феврале 2010 года под названием Windows Azure.

Не был я и новичком в Microsoft: с 1 января 2013 года я был частью команды разработчиков Windows, а позже помогал выполнять миграцию SharePoint Online в Azure; в дальнейшем я присоединился к команде Core OS в качестве разработчика ядра. В ней я помогал совершенствовать ядро, участвовал в разработке и реализации платформы Container, поддерживающей Docker, Azure Kubernetes, Azure Container Instances, Azure App Services и Windows Sandbox. Выпуск всех этих технологий привёл к получению множества патентов.

Кроме того, я участвовал в мозговом штурме при создании прототипов карт Overlake в 2020-2021 годах, в составлении драфта предложения коммуникационного протокола и сетевого стека Host OS <-> Accelerator Card ещё на том этапе, когда у нас было лишь последовательное соединение отладчика. Также меня привлекали в качестве специалиста по Core OS, и я помогал разработчикам Azure Core диагностировать глубокие проблемы операционной системы.

В 2023 году я вернулся в Azure сразу в должности специалиста, поскольку уже внёс свой вклад в разработку некоторых из технологий, лежащих в основе Azure, и будучи её пользователем в глобальных масштабах больше десятка лет, как снаружи, так и внутри Microsoft.

Так как я был вернувшимся сотрудником, то пропустил обучение для новичков и получил приглашение Global Security на полдень для получения своего бейджа, но мой будущий менеджер спросил, смогу ли я прийти раньше, потому что тем утром у команды должно было состояться ежемесячное совещание по планированию.

Дефекты — неизбежная часть разработки, но если они живут своей жизнью в чатах и трекерах, релизы превращаются в лотерею. В этой статье рассказываю, как выстроить системное управление дефектами: от жизненного цикла и сортировки до метрик вроде MTTR и SLA. Вы узнаете, чем серьёзность отличается от приоритета, почему «не воспроизводится» — это красный флаг для команды, и как метаданные дефекта экономят часы разработчиков.

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

Скачиваний и отзывов у приложения было немного, но я сам продолжаю им пользоваться почти каждый день. В результате накопилось несколько мелких, но неприятных «щелчков» в UX: не хватает языков, неудобен плеер, нет понятного индикатора записи и тому подобное. Решил: раз я использую этот инструмент сам, почему бы не довести его до того вида, который будет удобен именно для меня. Тем более некоторые мои друзья так же начали его использовать и стали делиться обратной связью.

Меня зовут Андрей Трегубов, я руковожу группой DevOps в Ви.Tech, IT‑дочке ВсеИнструменты.ру. Недавно мы записали подкаст с Александром Крыловым, директором по развитию продукта «Штурвал», и обсудили, где у DevOps заканчивается роль «ребят, которые иногда помогают разработке» и начинается сервисная модель с понятным входом, приоритетами и правилами игры. В этой статье я собрал из нашего разговора самое практичное: когда DevOps уже пора выстраивать как сервис, почему на росте перестает работать героизм, как не утонуть в поддержке, что делать с зоопарком технологий и где в этой истории нужны Enabling Team, безопасность и ИИ.

Можно долго спорить о терминах, но на практике все очень приземленно. Есть команда, к ней приходят с запросами, она что‑то делает, где‑то автоматизирует, где‑то чинит, где‑то вытаскивает всех из пожара. И какое‑то время это даже выглядит нормально. Проблема в том, что «нормально» и «масштабируется» далеко не одно и то же.

На днях прислали в рабочую почту очередное ТЗ в Word на разработку, для комментирования и оценки реализации. При том что у нас есть корпоративный Confluence - мощнейшая система, как раз предназначенная для коллективной работы.

Почему многие до сих пор продолжают изначально использовать Word как основу для обмена информацией?

Я работаю с Claude каждый день, по многу часов. За это время я автоматизировал кучу рутины — от утренних брифингов до генерации коммерческих предложений. Не теоретически. Реально.

Но давайте сразу расставим точки. Claude не заменяет мне голову. Он — напарник. Second brain. Тот, кто собирает информацию, готовит черновик, вытаскивает контекст из прошлых переписок. А решения принимаю я. Всегда. Это не «AI сделал за меня работу» — это «AI подготовил мне почву, чтобы я работал быстрее и не тратил мозг на рутину».

Большинство статей про AI-автоматизацию подают это иначе: «подключил ChatGPT к Zapier — теперь у меня автоматические письма!» На практике это шаблон с пятью переменными, который ломается на шестом письме, потому что AI не помнит контекста и каждый диалог начинает с чистого листа.

Я решил собрать 10 задач, которые раньше делал руками, а теперь — нет. В каждой из них Claude работает как copilot: предлагает, готовит, собирает. А финальное слово — за мной. На примере Claude Cowork — агентного десктоп-приложения от Anthropic, которое вышло в январе 2026.

В командной работе есть парадокс, который раздражает сильнее, чем чужие ошибки. Ты объясняешь, и объясняешь все верно, но твой собеседник тебя не понимает, хоть ты тресни. Не его, разумеется. По столу например :)

Эта ситуация, в общем-то, не редкая и встречается почти повсеместно. Я собрала небольшой гайд по ясной коммуникации в работе про то, как этого избежать.

Один AI-агент на базе Claude Sonnet закрывает 100% моих DevSecOps-задач. Без фреймворков, без оркестраторов, без векторных баз. Только LLM, операционная система и markdown-файлы. Рассказываю архитектуру, которая за этим стоит.