Слово «вайбкодинг» в ИТ-среде вызывает неоднозначную реакцию: разработчики морщатся, бизнес интересуется, а все остальные делают вид, что давно разобрались. Ни лагерь хейтеров, ни лагерь евангелистов не дают честного ответа. Разбираемся: почему разработчики правы в своих опасениях, почему бизнес всё равно идёт в эту сторону — и что со всем этим делать.
Полгода поиска. Сотня отказов. И в итоге — либо берёте «почти подходящего», либо проект стартует без нужного человека. Знакомо? Проблема в том, что вы ищете одного человека там, где нужна комбинация навыков. В 2026 году роль «Senior Backend» больше не описывает реальную работу — она описывает несбыточную мечту работодателя. Пора собирать команды иначе.
Открываете список задач перед планированием спринта. Прокручиваете. Прокручиваете ещё. Где-то на третьем экране перестаёте понимать, что тут вообще происходит. Половина задач без автора, часть не трогали с прошлого года, несколько штук явно дублируют друг друга — но удалить страшно, вдруг важное. Разбираемся почему так происходит и что с этим делать.
Петров уволился, ноутбук исчез. На складе соседнего офиса нашли 12 нераспакованных ноутбуков. При инвентаризации обнаружили сервер, о котором никто не знал. Знакомо? Разбираем, почему Excel и 1С не справляются с учётом оборудования при росте компании и как выглядит нормальный процесс — с пошаговым планом перехода.
Проблема большинства команд не в том, что они работают медленно. Проблема в том, что они толком не понимают, где именно теряют время, сколько стоит каждая ошибка и насколько тяжёлым стал сам процесс поставки изменений. Именно здесь и полезны DORA-метрики. Разберём, что они измеряют, где их чаще всего трактуют неправильно и как применять их без KPI-магии.
Ещё три года назад ИИ в ITSM представлялся как просто чат-бот на входе, который пытается угадать категорию тикета. Сегодня уже другой разговор: ведущие платформы встраивают AI не как надстройку над тикет-системой, а как архитектурный слой, который участвует в маршрутизации, предсказывает инциденты до их возникновения, автономно закрывает типовые обращения и генерирует постмортемы. Рынок уже видит пользу — по данным Forrester, компании, внедрившие предиктивные ITSM-практики, восстанавливаются после инцидентов вдвое быстрее тех, кто полагается на ручную обработку.
Рынок ITSM на это отреагировал по-разному — теперь при выборе инструментов фокус может быть не на том, какие ИИ-фичи есть у вендора, а насколько эта AI-инфраструктура управляема. В этом материале обозреваем мировых ITSM вендоров и их подходов к реализации ИИ.
Представьте: команда из 80 человек несколько лет живёт в Jira. Доски, спринты, кастомные поля, автоматизации на Groovy, сотни вложений, тысячи ссылок, разлетевшихся по корпоративным вики и письмам.
И вот в один прекрасный день приходит задача: «Переезжаем». Дедлайн — три месяца. При этом на старте никто не знает, что в системе накопилось за годы: десятки автоматизаций, половина из которых создавалась под задачи, которых уже нет.
Сможет ли российский продукт стать полноценной заменой Jira для команд разработки? Обсуждают команды SimpleOne и iiii-tech.
В поддержке запрос бизнеса очень прикладной: быстрее отвечать, делать меньше ошибок, выполнять SLA, выдерживать рост обращений при расширении каналов — почта, порталы, телефония. Компаниям нужно масштабировать сервис, сохраняя при этом стабильное качество. В статье о том, как они это делают.
Три пары функций. В каждой одна написана человеком, другая — ИИ. Сможете отличить? Мы не смогли. И наш ИИ-ревьюер тоже. Разбираем, почему синтетика проверяет синтетику — и что с этим делать.
Антон проработал в компании три года — хороший разработчик, знал кодовую базу лучше всех, онбордил новичков, вкладывал душу. В пятницу он написал в личку тимлиду: «Нам надо поговорить», а в понедельник уже с заявлением.
Тимлид был искренне удивлён: «Я не видел никаких признаков!». А было ли тимлиду, где на них посмотреть?
Задачи закрываются, метрики зелёные. Потом приходит момент, когда нужно тронуть модуль, который написал ИИ три месяца назад — и выясняется, что никто не понимает, что там происходит. Разбираем, почему ИИ-долг опаснее обычного техдолга и что с этим делать.
О том, как одна базовая задумка – сделать разработку управляемой, пережила эпоху тяжелых каскадных проектов, DevOps, CI/CD, и подошла к 2026 году уже в совсем зрелом виде.
Разработчик приходит к руководству и говорит: «Нам нужен рефакторинг». Руководство слышит: «Мы хотим потратить деньги и ничего не выпустить». Дальше — тишина, новый спринт с новыми фичами и ещё один слой технического долга сверху.
ИТ-директор знает, что сервер загружен на 90% и скоро встанет. Бухгалтер знает, что этот же сервер уже три года как самортизирован и формально не существует. Закупщик знает, что на прошлой неделе купил сорок новых ноутбуков — и понятия не имеет, что на складе лежат ещё два десятка. Все трое работают в одной компании, но живут в разных реальностях.
Цена этого разрыва — потерянное оборудование, раздутые бюджеты и простои, которых можно было избежать.
Представьте: у компании 300 подразделений по всей стране или пять производственных площадок от Москвы до Дальнего Востока. Как узнать, сколько реально ноутбуков в омском филиале, где они находятся и в каком статусе принтер, купленный два года назад: используется, неисправен, в ремонте или уже подлежит списанию? Если данные приходят через мессенджеры или эксельные файлы, присланные раз в квартал — вы уже в зоне риска.
Однажды утром вы открываете задачу и понимаете: единственный человек, который знал, как это работает, вчера уволился. Знания ушли вместе с ним.
Разберем, почему попытки оцифровать интеллект через нормо-часы и коммиты ведут к деградации продукта, и как на самом деле устроена невидимая зона создания ИТ-решений, где ценность рождается из исследования и анализа, а не из скорости стука по клавишам.
Внедрили таск-трекер для ускорения — а команда стала тратить 40 минут в день на костыли. Рассказываю, как за полтора года у нас накопилось 11 обходных путей, почему онбординг новичков растянулся до трёх недель и что мы с этим сделали. Внутри — чек-лист «тормозит ли вас ваш инструмент» и пошаговый план действий.
Как бесконтрольное использование ИИ для генерации кода превращает сеньоров в уборщиков чужого кода: разбираем метрики, которые выявляют проблему, и три практики, позволяющие встроить управление ИИ-долгом в процесс разработки.