Kurgan-Telecom Ru | Информационные технологии

Меня зовут Петрищева Евгения, я отвечаю в SM Lab за оценку и развитие сотрудников.

Последние несколько лет внесли коррективы во все сферы работы организаций и корпоративное обучение (L&D) не стало исключением. Ключевые вызовы сотрудников L&D: какие навыки понадобятся команде в ближайшие два года, как успеть развить их раньше, чем они станут дефицитом, и как ещё более точно рассчитать вложения на обучение персонала.

В этой статье хочу собрать самые интересные наблюдения, которые мне встретились. Поговорим о мировых трендах развития сотрудников, а также IT-специалистов исходя из исследования Future of Job Survey и мнений визионеров. А также обсудим российские тенденции в обучении и развитии сотрудников как в IT, так и в других отраслях. В конце расскажу, как эти тенденции отражаются в наших программах развития в SM Lab.

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

Все мы иногда меняем работу. Я вот тоже недавно решил. Походил по собеседованиям и удивился. Спрашивать стали больше, шире, детальнее.

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

Хочу в этой статье немного порассуждать про то, что изменилось с экспертизой в LLM сфере за последние годы и что теперь нужно знать современному LLM инженеру. Опираюсь на свой личный опыт и общение с людьми из сферы из наших и зарубежных компаний.

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

1. ИИ уже перешёл от личного использования к командному и сквозному внедрению.

2. Глубина внедрения ИИ зависит от размера компании и роли сотрудника.

3. Применение ИИ вышло за пределы генерации кода.

4. Чем выше инженерная зрелость, тем глубже внедрение ИИ и заметнее результат.

5. ИИ скорее убыстряет процесс разработки, чем пишет качественный код.

Мы проанализировали все заполненные анкеты — их оказалось 317. Под катом расскажем, насколько наши гипотезы подтвердились или опроверглись вашими ответами и попутно опишем пару-тройку других интересных корреляций. Например, мы поняли, что размер компании часто не помогает, а, наоборот, мешает внедрить ИИ по сквозному принципу — «крупняки» делают это на 35% реже, чем небольшие компании. Но обо всём по порядку.

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

Embedded Swift быстро развивается. После наших обновлений об улучшениях Embedded Swift в Swift 6.3 в конце прошлого года, этот пост описывает ряд дополнительных улучшений, сделанных в предстоящем выпуске Swift 6.4. Вы можете опробовать их уже сегодня, используя снапшот разработки Swift.

Улучшения языка

Embedded Swift продолжает расширять свое подмножество языка, включая все больше аспектов «полного» Swift, что упрощает обеспечение совместимости существующих кодовых баз Swift с Embedded Swift. Многие из этих функций имеют динамический аспект, что означает их влияние на производительность во время выполнения (например, из-за косвенных вызовов) и размер кода (из-за необходимости дополнительных метаданных). Однако это влияние проявляется только там, где эти динамические функции языка действительно используются: код, критически важный к размеру и производительности, может избегать их, например, включив предупреждения в группе диагностики PerformanceHints.

Обобщенная поддержка экзистенциальных (any) типов

“Мы не пишем ТЗ, - гордо сказал мне руководитель агентства. - Мы работаем только по Agile”. Хочется порассуждать на тему того, нужно ли в 2026 году писать техническое задание на разработку информационного продукта и в каком виде. Или это все замшелые водопадные технологии, которые уже давно прогрессивным разработчикам и вайбкодерам никуда не уперлись.

Вообще, сам термин “техническое задание” для разработки в последнее время стал встречаться реже - и в обсуждениях и в профильных статьях. Чаще его заменяют словом “требования” (reqirements) или Product vision и это действительно ближе к истине - в таком документе мы фиксируем требования заказчика и видение того, каким должен быть создаваемый продукт, что он должен уметь и как выглядеть. Вне зависимости от подхода к разработке такой документ на старте проекта должен быть обязательно, и при этом быть хорошо проработанным - хотя бы для создания MVP. Потому что и у заказчика проекта и у его разработчика перед глазами должен быть так сказать единый “образ победы” - того продукта, который они совместными усилиями делают. Без такого документа вы не сможете ни бюджет спрогнозировать даже примерно, ни сроки готовности, да и функционал самого продукта может в итоге оказаться совсем не таким, как его представлял себе заказчик. Сколько раз приходилось наблюдать ситуацию, когда не только отдельные фичи, но даже использованные в постановке задачи термины понимались сторонами по-разному, что приводило к спорам на приемке очередного этапа работ. Поэтому кстати, считаю раздел с терминами обязательным и всегда включаю его в свою документацию - чтобы у всех было единое понимание того, что такое “Заказ”, из чего состоит “Заявка”, кто такой “Администратор” и т.п.

Последние годы я работал разработчиком в области машинного обучения, компьютерного зрения и 3D-реконструкции. Писал и видел множество вариантов организации вычислений и обработки потока данных. Но в них мне не хватало системы и организованности, прозрачности и гибкости. Поэтому я набрался решимости и воплотил самые мои смелые — и, как оказалось, вполне рабочие — идеи в новом фреймворке, который я назвал ICO.

Суббота, клиент вернулся из отпуска, открыл свой сайт и написал мне: «сайт лежит, вижу только белый экран, что случилось?». Код ответа при этом 200, мониторинг зелёный, хостинг жив, база данных на месте.

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

В этом кейсе я расскажу, через какую уязвимость всё это залезло на сервер, почему легли сразу три сайта на одном аккаунте (включая наш свежесозданный, который мы отдали пару дней назад), как выглядели восемь с лишним тысяч подложенных файлов.htaccess и закладка, обёрнутая вокруг настоящего движка сайта.

А ещё честно расскажу, где мы сами ошиблись. Одна ошибка стоила ещё десяти часов спама в Google уже после того, как мы решили, что всё закончилось.

В конце — 5 способов за 5 минут проверить ваш собственный сайт.

Где команда получила ускорение почти в 9 раз, почему на другом сценарии выиграла всего 11 часов и зачем считать настройку агента частью тестирования

Я тимлид, пятнадцать лет в разработке. Последний год мой пет‑проект пишут ИИ‑агенты, а я читаю их отчёты о том, как всё прекрасно работает. Что отчёты и реальность живут отдельно друг от друга, я знал и раньше, у меня команда из живых людей. Неожиданным оказалось другое: лекарство подошло то же самое. Дальше будет устав судьи, настоящие вердикты, сторожевые тесты и грабли, которые я собрал по дороге. Всё из живого репозитория.

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

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

В прошлый раз мы пробежались по предметной области, добыли данные и вывели их на экран. В принципе, этого достаточно для выполнения моего ежедневного ритуала, но в быту я использую более навороченную версию скрипта. Её стоит рассмотреть, чтобы закончить вводный курс по Thuja и поговорить об особенностях консольных графических интерфейсов. Слишком уж многое здесь можно и нужно делать не так, как в больших фреймворках.

В этом материале я попробую максимально просто показать что такое ключевая ставка, о которой многие говорят и почему она сейчас еще большая, хотя 14% это намного меньше, чем 21%, которые были в начале 2025 года.

Итак, сегодня 14% ключевая ставка, ее постепенно снижают, а это значит что кредиты постепенно должны становиться дешевле, а депозиты менее доходными, в целом и происходит. Однако я еще предлагаю посмотреть в сторону инфляции, которая также влияет на эту ключевую ставку.

Мы построили систему, которая умеет честно останавливаться, когда не может довести гипотезу до конца.

Слепой отбор координаты в пространстве представлений SU(3)×SU(2)×U(1), группа гейтов на аномалии/унитарность/UV-завершение, и правило «нельзя ранжировать меньше пяти механистически разных гипотез». По пути — не только результаты, но и честные признания: семь «исследовательских кандидатов» оказались вручную закодированы, а не выбраны вслепую (поймали аудитом кода); клетка с представлением размерности 1518 упёрлась в UV-стену и получила BLOCKED вместо выдуманного числа; найден баг, который ложно добавлял канал распада по совпадению подстроки.

Два кандидата дошли до настоящих d=7 операторов и первой условной зоны исключения по данным CMS. Для одного из них не хватает ровно одной вещи — специалиста, который умеет собирать UFO-модели для цветовых секстетов.

Архитектура при этом не заточена под физику частиц — на ней же стоят глобальный фит нейтринных экспериментов (DayaBay, KATRIN, T2K) и модуль аэроупругости с реальными данными DLR.

Подробности, формулы и вся цепочка проверок — в статье.

Знакомая ситуация: продукт написан за выходные, гипотеза подтвердилась, кто‑то уже платит. Приходит дизайнер и просит файл.

Файла нет. 

Есть интерфейс, который существует только в виде кода. Кнопка там называется.btn‑primary,.btn‑add и.button‑save — три класса, одна кнопка, паддинги отличаются на пиксель. Серый цвет записан тремя способами, и один из них, судя по всему, опечатка. Отдать это дизайнеру нельзя. Нарисовать заново — значит выбросить полгода работы и начать спорить про радиусы. 

Мне стало интересно, что тут реально может AI. Не «сделай красиво», а честный замер: я собрал маленькое демо, намеренно заложил в него шестнадцать несогласованностей, записал их в отдельный файл и спрятал. Потом запустил на этом коде свежую сессию Claude Code, которая файла с ответами не видела.

В статье — что из этого вышло, с цифрами и с местами, где всё сломалось.

Полноценный зонтичный мониторинг, по ощущениям, сегодня есть у считанных единиц: я бы оценил долю таких компаний примерно в 1–2%. И обычно путь к внедрению у всех выглядит примерно одинаково: что‑нибудь падает, ЦОД останавливается, бизнес несет многомиллионные убытки, после чего собственник логично задает вопрос: «Что нужно сделать, чтобы это больше не повторилось?» Так и возникает тема с внедрением мониторинга.

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

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

Представьте фрагмент книги о полнотекстовом поиске. В базе данных хранятся персонажи Disney. Автор объясняет: если искать слово «мышь», система вернет запись «Микки Маус», потому что только она содержит это слово.

На английском пример работает. В оригинале запрос mouse совпадает со словом Mouse в имени Mickey Mouse. В русском переводе связь исчезает. В «Микки Маусе» нет слова «мышь», поэтому обещанного результата читатель не получит.

Такая ошибка выглядит забавно, пока пример остается на странице. Если человек повторяет его во время обучения, он видит другое поведение системы и начинает искать проблему в коде, настройках базы или собственном понимании темы. Один маленький переводческий промах ломает весь учебный эпизод.

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

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

У Jira есть REST API, есть JQL, есть маркетплейс с дашбордами. Но как только метрики становятся чуть сложнее, чем «сколько задач закрыто за спринт», всё это упирается в потолок:

Абсолютные импорты без расширений в ESM-монорепозитории.
Настраиваем Vite, TypeScript и автоимпорты в IDE (VSCode) с помощью “subpath imports”.

Разрешаем конфликты настроек без костылей.

Добавляем приоритет автоимпорта папок в качестве модулей, при наличии “index.ts”.

Настраиваем Vite и TypeScript на работу с исходниками компилируемой библиотеки в dev-режиме.