Несколько месяцев назад в публичном пространстве появилась история, которую в engineering-сообществе стали называть поучительной. Команда AWS использовала внутренний AI-инструмент Kira для ускорения работы. Kira предложила джуниорам сценарий: переразверни продакшн-слой. Инженеры согласились. Следующие шесть часов весь AWS не работал. После разбора полётов компания объявила новое правило: финальный апрув на изменения, предложенные агентом, должен давать сениор-инженер.

На первый взгляд, решение логичное. На второй, уже менее. Если агент генерирует изменения в темпе, к которому люди не привыкли, один сениор превращается в бутылочное горлышко для бесконечного потока PR. Это не решение проблемы. Это антипаттерн, оформленный как процесс.

История AWS точно формулирует главный вызов 2025-2026 годов: AI научился быстро писать код, но индустрия пока не научилась с такой же скоростью его доставлять, проверять и принимать решения о нём. Данные, собранные в рамках масштабного исследования State of AI4SDLC, это подтверждают.

У разработчиков есть крепкое убеждение: стать тимлидом значит навсегда потеряться в созвонах, потерять хард-скилы и оказаться в ловушке из которой не выбраться. В конце 2024 года на Хабре набрала больше 200 плюсов статья с говорящим названием «Не надо быть тимлидом». Она начала просачиваться в чатики, каналы и умы людей. И закрепила страх: тимлидство карьерный тупик.

Евгений Антонов, ведущий технический менеджер в Yandex Infrastructure и автор телеграм-канала «Тимлид Очевидность», с этим категорически не согласен. 18 лет в IT, последние 10 в менеджменте, плюс 5 лет консалтинга с десятками тимлидов в клиентах. Достаточно, чтобы смотреть на карьерные страхи без паники. Доклад на Saint TeamLead Conf 2025 в Петербурге он посвятил разбору этого популярного тезиса.

Спойлер: тимлид это не тупик. Это развилка.

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

О четвёртой промышленной революции говорили так долго, что к разговорам успели привыкнуть. А она тем временем уже разворачивается прямо в редакторах кода. Все прошлые промышленные революции ускоряли физический труд. Эта впервые взялась за труд когнитивный: за проектирование, написание кода, ревью, отладку, за всё, чем инженер занят каждый день. Куда это приведёт, честно не знает пока никто. Понятно при этом одно: разбираться придётся всем, и разбираться всерьёз. Под этот сдвиг команда Saint HighLoad++ пересобрала всю программу. И вместе с этим появилась новая логика, по которой всё устроено.

На «Ура, мы запустили процесс!» работа не заканчивается. Здесь как с деревьями: мало посадить, важно присматривать и ухаживать, иначе процесс зачахнет и не даст ожидаемых плодов. В этой статье по мотивам выступления с TeamLeadConf Александр Бондаренко из Garage Eight поделится своим опытом, как сделать так, чтобы процессы жили и приносили результаты. Передаём ему слово.

IT-индустрия вышла в новую фазу: мы научились быстро писать код, масштабировать системы и внедрять новые технологии почти без трения. Но столкнулись с новым вызовом: проблем не стало меньше — они стали сложнее.

Команда «Онтико» решила не делать вид, что это просто «ещё один виток роста», и в 2026 году меняет сам формат IT-конференций! GolangConf 2026 — это уже не про «послушать доклады», которые кто-то просЛушал, а кто-то просРушал :) Мы будем разбираться с тем, что реально болит у команд прямо сейчас.

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

Поэтому в 2026 году AiConf пройдёт в формате «конференция развития». Это значит больше интерактивных форматов и нетворкинга, чтобы участники были не пассивными слушателями, а активными создателями решений, знаний, новых контактов и инсайтов.

На любой DevOps-конференции рано или поздно возникает один и тот же момент. Слушаешь про архитектуру, пайплайны, масштабирование, observability — всё звучит разумно и красиво. А потом в голове появляется простой вопрос: «Окей, а чем вы это всё делаете?». То есть буквально: какие инструменты стоят под капотом, как они внедрялись, где с ними было больно и где они действительно экономят время команде.

Именно для таких бесед на DevOpsConf 2026 будет отдельное пространство — продуктовая аллея!

Привет, Хабр! Я — Владимир Балун, и это — вторая часть материала о пакете с отпугивающим названием «unsafe» в Go и том, чем он может быть реально полезен. В первой части мы рассмотрели его содержимое, особенности и нюансы, оптимизации кода с использованием unsafe — все это вы можете освежить в памяти по ссылке.

Сегодня перейдем непосредственно к той самой «магии»: трюки, хаки, советы и лучшие практики с моей стороны.

В стандартной библиотеке Go есть пакет с отпугивающим названием «unsafe». Но он может быть реально полезен! Сегодня поговорим о том, как использовать его надежно и эффективно.

Привет, Хабр! Я — Владимир Балун, основатель balun.courses и it-interview.io. Эта статья будет для удобства разделена на две части. Из них вы узнаете, как можно создавать срезы без дорогостоящей инициализации, научитесь избавляться от Bound Checks и конвертировать строки в срезы и обратно без лишних копирований и аллокаций памяти. 

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

Кажется, мы все немного устали. Устали от унаследованного кода без владельца. От инфраструктуры, которая «как-то работает». От ИИ, который внедряют быстрее, чем понимают. От регуляторики, написанной на инопланетном языке. От SLO, которым вроде бы можно верить — но лучше бы перепроверить.

И на фоне всего этого — привычный формат конференции: два дня докладов, блокнот заметок, лёгкая эйфория… а через неделю всё растворяется в задачах.

Команда DevOpsConf в этом году честно признала: формат «послушал — вдохновился — пошёл применять» больше не тянет. Индустрия изменилась. И мероприятия тоже должны. Поэтому DevOpsConf 2026 проходит в новом формате — «конференция развития».

Расписание уже готово — можно изучить программу и собрать свой маршрут по стримам на официальном сайте. Давайте посмотрим, что получилось!

Привет, Хабр! Это вторая часть статьи по мотивам доклада реверс-инженера Дмитрия Ильина для прикладной конференции по Data Sience Ai Conf 2025. Дмитрий рассказал о своём проекте OpenIPC, где IPC — это аббревиатура от IP-камера. Изначально он задумывался как специализированный дистрибутив Linux для IP-камер, но со временем превратился в большое комьюнити любителей опенсорса, каждый из которых является носителем уникального кусочка знаний.

В предыдущем материале мы разбирали вопросы видеоаналитики, сравнивали Cloud AI протв Edge AI и изучали, что есть интересного кроме GPU. Освежить материал в памяти можно по ссылке. Сегодня поговорим о многокамерных массивах (Multi Camera Array), мультисенсоры и разберём конкретные кейсы.

Привет, Хабр! Эта статья написана по мотивам доклада реверс-инженера Дмитрия Ильина для прикладной конференции по Data Sience Ai Conf 2025. В нём Дмитрий рассказывает о своём многолетнем хобби, которое родилось на стыке реверс-инжиниринга, софта и железа. Это проект OpenIPC, где IPC — это аббревиатура от IP-камера. Изначально он задумывался как специализированный дистрибутив Linux для IP-камер, но со временем превратился в большое комьюнити любителей опенсорса, каждый из которых является носителем уникального кусочка знаний.

Это будет материал из двух частей. В первой Дмитрий объясняет, как работать с видеоаналитикой, какие есть проблемы  в области Computer Vision и какие нестандартные решения можно найти сегодня.

В этом обзоре мы собрали ключевые идеи и практические инсайты из серии подкастов, записанных на конференции Industrial++.

Привет, Хабр! Пока рынок обсуждает новые модели и копайлоты, промышленный IT живёт в другой реальности: там AI должен снижать простои, повышать безопасность и приносить измеримый экономический эффект.

Партнёры из «Сферы» как никто другой знают изнанку промышленного IT. Компания разрабатывает инструменты для организации и автоматизации процессов производства на всех этапах жизненного цикла ИТ-продукта. А делать востребованные решения без тесного общения с рынком невозможно. Поэтому в этих подкастах ведущие и гости честно рассказывают, как выбирают сценарии применения ИИ, считают эффективность, встраивают решения в производственные контуры и работают с сопротивлением изменениям.

В Istio всё начинается с маленькой «удобной» идеи — прокси рядом с каждым подом. А заканчивается тем, что XDS разносит по кластеру тонны Listener’ов, Route’ов и Cluster’ов, дублируя конфиги для сервисов, которые вы даже не трогаете. Память тает, GC злится, а апдейты сервисов превращаются в шторм.

В статье пойдет речь о том, как мы в проде с 20K+ подов «урезали аппетит» сайдкаров на гигабайты. Обсудим, где работает жёсткое ограничение видимости, когда спасает Ambient Mesh, зачем нужен ленивый XDS и почему «волшебной кнопки» нет — но есть комбинации, дающие двузначную экономию. Эта статья написана по мотивам моего доклада для конференции Saint HighLoad++.

Когда твой тестовый стенд разбросан по этажам, IP-адреса живут своей жизнью, а нужное устройство стабильно «гуляет» между кабинетами — это не инфраструктура, это квест. Три года назад я подключался к железкам по SSH и даже не знал, где они физически находятся. Сегодня всё иначе: у нас универсальная тестовая лаборатория, собранная как из конструктора LEGO — аккуратная, управляемая, с централизованной сетью, удалённым регулированием питания и мониторингом.

Этот текст — про то, как из хаоса родился порядок. Как вместо десятков разрозненных девайсов появилась стойка, где каждый винт, кабель и IP на своём месте. И как одна инженерная идея может превратиться в систему, которая экономит часы, нервы и делает работу с тестами наконец-то предсказуемой. Эта статья написана по мотивам моего доклада для конференции Highload++.

Если бы кто-то создал кнопку «Сделать безопасно», то заработал бы миллиарды. Но увы — такой не существует, приходится всё делать вручную.

Привет, Хабр! Меня зовут Анна Лучник. Последние два десятилетия я реализую сложные и безопасные ИТ-проекты.

В этой статье расскажу:

От каких угроз может защитить внедрение Service Mesh в теории и на практике.

Какие конфигурации и решения обесценивают включение mTLS, на какие конфигурации стоит обратить внимание, чтобы всё корректно работало.

Поговорим о том, чем mTLS отличается от обычного TLS.

К каким сбоям и проблемам может привести режим strict mTLS. И что делать, чтобы безопасность на стала причиной того, что у нас ничего не работает. 

Как объединить по сети вычислители? Что происходит при компиляции кода для железа под капотом и какие есть нюансы при работе с AI в пространстве ядра? ИИ с ноги ворвался во все сферы разработки, работы — вагон и маленькая тележка. Но на чём и как она должна ехать? У каждой программы есть свои требования, универсальных советов нет.

О новых решениях можно будет узнать на конференции OS DevConf 25 — там будет целый трек, посвящённый железу для AI. Пул экспертов соберётся, чтобы показать, как устроен современный стек ИИ — от базового железа для инференса до системных рантаймов и объединения ферм GPU, чтобы обучить большие языковые модели. Участники не просто узнают об инструментах, но и ознакомятся с методиками, как программировать это железо до уровня «можно использовать в Pythorch».

Мы в Смартомато — супер продуктовые ребята. Со временем у нас скопились недовольство по поводу работы с Golang, захотелось залезть в технические дебри. Произошла гиперкомпенсация и мы придумали препроцессинг в Go. Да, несмотря на то, что этот язык официально не поддерживает препроцессоры —  мы всё равно сделали. А сейчас делимся результатами этой работы с вами.

Эта статья по мотивам моего доклада на Golang Conf X 2025 о болях шаблонного кода и вариантах их решения с помощью препроцессинга на базе стандартного тулчейна Go. В тексте не будет сравнения с препроцессорами в других языках и морально-этической оценки решения.

Условия работы в IT-отрасли становятся всё более непростыми из-за санкций, сокращения бюджетов и прочих факторов. Рынок технологических продуктов в России откровенно штормит, он переживает сложный и важный этап. Растёт спрос на локальные, контролируемые и легко интегрируемые решения, и вместе с этим появляется всё больше зрелых продуктовых команд, способных не просто писать код, а создавать полноценные B2B и B2C-продукты.

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