Представлен бесплатный открытый проект HeartMuLa, который генерирует музыку на уровне платных ИИ-студий. Это полноценная музыкальная «студия всё в одном»: можно создавать треки по описанию, делать песни в стиле любимых артистов и работать с готовым аудио.
Что умеет HeartMuLa:
пишет тексты песен через встроенный чат-бот;
генерирует треки с вокалом и текстом длиннее 4 минут;
можно загрузить любой аудиофайл, и ИИ перенесёт его вайб и стиль в новый трек;
работает даже на слабом железе: локальная версия требует всего ~3 ГБ видеопамяти;
простой и понятный интерфейс. Фактически: бесплатный аналог Suno, но без подписок, ограничений и облака;
можно ставить локально и делать музыку прямо на своём ПК.
Интуитивные управленческие решения и значение контекстного интеллекта для управленца
Приветствую!
Хочу поделиться с вами статьёй, которая стала для меня настольной. Её написала моя руководительница диплома из Высшей школы экономики, Светлана Жоржевна Гончарова. И что удивительно — материал не теряет актуальности, а, как это ни странно, становится лишь более востребованным.
За годы работы в аудите, консалтинге и разных компаниях я часто задумывался и наблюдал за тем, как принимаются управленческие, а нередко и ключевые для бизнеса решения. Мысли из этой статьи находят стопроцентный отклик в моём опыте. Моя практика постоянно подтверждала идеи, изложенные в ней, и мне захотелось поделиться ими с вами — вдруг и вам будет полезно!
Задавались ли вы когда-нибудь вопросом: что является продуктом управленца? Чем измеряется его эффективность? Один из основных вариантов ответа — в конце поста.
Сталкивались ли вы с такими ситуациями?
Постепенная эрозия рыночной доли компании. Например, на рынке ИТ при наличии благоприятных экономических обстоятельств бизнес теряет позиции, а причина неочевидна.
Ваши ИТ-продукты теряют конкурентоспособность. Успешные когда-то программные решения лишаются своего конкурентного преимущества (product edge).
Уходят самые ценные сотрудники. Наблюдается необъяснимый и неконтролируемый отток талантов, ключевых разработчиков, архитекторов.
Все ресурсы брошены на один «мега-ультра-проект» в ущерб остальным процессам и деятельности компании.
Вы заключаете «супер-контракт» на разработку, а через несколько лет понимаете, что попали в зависимость от партнёра. «Кабальные» условия долгосрочных соглашений становятся ясны лишь спустя годы, и разработка некогда рыночного B2C-продукта превращается в обслуживание одного B2B-клиента.
Знакомо, правда? Часто руководители принимают решения на основе интуиции, «чуйки» и веры в свою удачу, руководствуясь иными мотивами, выходящими за рамки данного поста. А вот своевременные решения, основанные на глубоком понимании контекста, людей, на качественно собранных и проанализированных данных, я, к сожалению, встречал гораздо реже.
Именно поэтому я полностью поддерживаю основную мысль статьи и даже предлагаю дополнить идеальный портрет современного управленца навыком «контекстного интеллекта» — умения «считывать» обстановку и принимать взвешенные решения.
Более того, я бы рекомендовал включать в контракты, договоры или должностные инструкции топ-менеджеров пунктоб обязательномвсестороннем изучении контекста, совокупности информации и мнений для принятия взвешенных управленческих решений.
Для справки: Contextual intelligence is the ability to understand the full situation (context)—including history, culture, environment, and human factors—to make wise decisions, adapt behavior, and act effectively, rather than just applying knowledge blindly. It bridges "knowing how" with "knowing what to do," blending technical skill with intuitive awareness of surrounding circumstances to achieve desired outcomes.
Сталкивались с подобными кейсами? Буду рад услышать ваше мнение в комментариях — делитесь мыслями и примерами!
И да, ответ на вопрос о том, что есть продукт управленца и чем он измеряется. Ответ предельно прост: своевременными, качественными и эффективными управленческими решениями. Продукт любого управленца, в первую очередь, — это управленческое решение.
Удачи в построении эффективных и устойчивых процессов.
Инструментальное средство PVS-Studio разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207—2024. Выявляет критические ошибки и может использоваться при разработке безопасного программного обеспечения по ГОСТ Р 56939—2024.
Я подготовил развёрнутый материал, посвящённый функциональным возможностям PVS-Studio на начало 2026 года с точки зрения перечисленных стандартов, приказа ФСТЭК №117, методического документа "Профиль защиты" и т. д.
Обзор PVS-Studio получился большой и явно не формата статьи для Хабра. Это вообще, скорее, мини-справочник на 66 страниц. В общем, я вас предупредил :) Тех, кто не испугался, а наоборот, заинтересовался, приглашаю познакомиться с материалом по ссылке:
как связаны между собой PVS-Studio и различные ГОСТы;
требования к статическим анализаторам кода и насколько им соответствует PVS-Studio;
разбор технологий анализа, реализованных в PVS-Studio;
примеры выявляемых критических ошибок и что это такое;
характеристики анализатора: языки, поддерживаемые операционные системы, скорость работы, форматы отчётов;
и т. д.
Если вас заинтересовали озвученные здесь темы или у вас появились вопросы, то напишите нам.
P.S. Команда PVS-Studio будет со стендом на ТБ Форум 2026 (18–20 февраля 2026, МВЦ "Крокус Экспо", павильон 2, зал 10). Я там тоже буду. Приходите задавать вопросы на тему публикации, стандартов и вообще.
Первая компания, где я работал, производила программное обеспечение и доставляла его на компакт-дисках. Курьеры-студенты периодически приезжали в офис, чтобы сдать выручку и получить очередную пачку дисков. Учёт велся в большом бумажном журнале. Постоянно возникала путаница: кто из курьеров сколько дисков взял и сколько денег должен.
Посмотрел я на это дело, открыл Эксель и набросал пару таблиц: журнал выдачи дисков и журнал расчётов. Получился инструмент, который сам считает, сколько дисков и денег на руках у каждого курьера. Задача была несложной, т.к. ещё в старших классах я где-то нашёл учебник по Экселю и прочёл от корки до корки. В итоге электронная таблица заменила бумажный журнал, а я прослыл в офисе главным автоматизатором.
Прошло четыре года, я уже пару лет как работал в другой компании. Раздаётся звонок. «Азат Лаисович, ваша таблица распухла и начала тормозить, можете помочь?» Я не поверил своим ушам. Они до сих пор её используют! Объяснил бывшим коллегам, как удалить исторические данные, таблица снова начала летать.
Умение пользоваться электронными таблицами — один из важнейших навыков. В личной жизни Эксель помогает настроить учёт коммуналки, запланировать путешествие и составить смету свадьбы. Стартапу или малому бизнесу электронные таблицы могут заменить дорогостоящие CRM и ERP. В большой компании Эксель позволяет выгрузить данные из сложной системы и быстро составить необходимый отчёт для аудита.
К сожалению, большинство людей осваивает Эксель методом тыка и продвигаются не дальше красивого раскрашивания ячеек. Хотите за пять минут делать работу, на которую ваши коллеги тратят часы — найдите учебник или курс по электронным таблицам.
Я публично веду исследование и собираю статистику причин провалов игровых проектов. Часто, как первичную точку для анализа того или иного игрового проекта я использую Google.
Однако, сегодня google меня немного удивил. На мой запрос: "What were the key issues with civilization vii game at the release"? Вот что сегодня, 20.01.2026 выдал Google:
AI Overview
Sid Meier's Civilization VII is scheduled for release on February 11, 2025 [1, 2]. As of today, January 20, 2026, the game has not been released, and therefore, it is impossible to identify key issues from its actual launch.
Однако, скорректировав запрос с уточнением "What were the key issues with civilization vii game at the release in 2025", я уже получил более разумный ответ:
AI Overview
Sid Meier's Civilization VII faced a rocky, "mixed" reception upon its February 2025 release, with many players describing it as unfinished and in a "rough" state. The launch was marked by complaints regarding fundamental gameplay changes, a poor user interface (UI), and missing quality-of-life features that left many long-term fans disappointed.
Обратил внимание, что часто от ИИ ожидают больше, чем он сейчас может дать. Тем более не стоит считать информацию формируемую генеративным AI полностью достоверной и не подлежащей проверке. Проводите кроссвалидацию с первоисточниками того, что вы получаете от генеративных нейросетей в форме утверждений.
В свете недавних обсуждений про тесты - пара слов про документацию. Я нашёл очень хорошую метафору: написание документации - это приём антибиотиков. Антибиотики спасли сотни миллионов жизней, может быть, больше миллиарда. Ценность открытия антибиотиков для человечества сложно переоценить.
Но внезапно бездумно пить антибиотики по каждому поводу и без - для организма совсем не полезно. В какой-то мере антибиотик является ядом: очень специальным, очень контролируемым, но совсем не витаминкой (хотя слишком много витаминов тоже не полезно).
С документацией дела обстоят ровно так же. Отсутствие документации не всегда == гибель проекта, но в большинстве случаев, если документации нет никакой, это довольно грустно и часто является очень существенной проблемой. С другой стороны, сама по себе документация - это накладные расходы, это не основной функционал, и она не приносит непосредственной пользы пользователю. Документацию надо поддерживать в актуальном состоянии, и чем её больше, тем это сложнее. И в этом смысле документация - это токсичный (если всё хорошо, легко токсичный) asset.
«Внезапно» не всегда документация так уж нужна. Предположим, у нас есть стандартное Spring Boot-приложение, сделанное через Spring Initializer, со, скажем, файлом build.gradle. В Gradle видна зависимость от Spring Data JDBC и от PostgreSQL базы, и в корне проекта лежит docker-compose.yaml, который стартует PostgreSQL. В src/main/resources лежит application.properties, где определены стандартные data source properties.
Вопрос - что стоит документировать в такой ситуации? Возможно, ничего. Ну, может быть, одну строку: «тут всё примерно как вы ожидаете от Spring Boot + Gradle + PostgreSQL», и, может быть, стоит на этом остановиться.
Более того, во всех случаях, когда я видел New Developer Onboarding документы на 5+ страниц, - это было признаком того, что у проекта есть проблемы того или иного сорта. Возвращаясь к метафоре с антибиотиками: если человек пьёт антибиотик каждые два месяца - с высокой вероятностью у него есть проблемы со здоровьем, которые непосредственно антибиотиком не лечатся, и надо смотреть на проблему комплексно.
Ещё раз повторю - документация - это хорошо, но чем её меньше, тем лучше. Если с проектом можно работать без документации - то это идеальный вариант, в реальной жизни, как правило, не случающийся. Чем больше документов, тем выше накладные расходы. Если архитектуру системы можно устроить так, чтобы сократить какой-то документ, то это, скорее всего, благое дело, и стоит подумать в эту сторону.
Как правило, хорошая причина для написания новых документов - это либо какое-то нестандартное решение, которое команда была вынуждена принять по какой-то причине, и тут причину и само решение стоит задокументировать. Либо это какая-то хитрая внешняя причина - например: как получить API-ключ, почему между вызовами API вдруг стоит Thread.sleep(18_500) или что-то такого же плана.
Красиво написанный, но длинный документ для какой-то области, где можно обойтись без него, - это, скорее всего, не полезный для организма проекта антибиотик, без которого можно было бы обойтись.
Записи с backend-митапа, который мы вместе с комьюнити «Live PHP» и «Пых» провели в конце прошлого года офисе Garage Eight
> NULL. Выбросить нельзя использовать Спикер: Владимир Романичев, CEO «Ветменеджер» Youtube | VK видео
> RabbitMQ: quorum queues и почему mirrored queues не работают Спикер: Виктор Михайлов, Backend Lead Garage Eight Youtube | VK видео
> Архитектура ИИ-сервиса для распознавания документов: путь от MVP до продакшена Спикер: Михаил Мироненко, Senior PHP Developer, 10+ лет в разработке Youtube | VK видео
Создатель инструмента для программирования Claude Code Борис Черный подробно рассказал о своем рабочем процессе.
Черный возглавляет Claude Code в Anthropic, и его подход радикально отличается от привычной линейной модели программирования. Вместо последовательной работы «написал — протестировал — исправил» он одновременно запускает несколько ИИ-агентов.
«Я запускаю пять Claude параллельно в терминале», — объясняет Черный. Он распределяет задачи между вкладками: один агент запускает тесты, другой занимается рефакторингом, третий пишет документацию. Дополнительно он использует ещё несколько сессий Claude в браузере, переключаясь между ними по мере необходимости.
Ключевой деталью стало и то, какую модель он выбирает. Вопреки стремлению индустрии к максимальной скорости, Черный предпочитает самую «тяжёлую» и медленную модель Anthropic — Opus 4.5. По его словам, она требует меньше контроля со стороны человека и лучше работает с инструментами, поэтому в итоге экономит время. «Даже если она медленнее, результат получается быстрее, потому что её не приходится постоянно поправлять», — отмечает Черный.
Чтобы решить проблему «забывчивости» ИИ, команда Claude Code использует простой, но эффективный прием. В каждом репозитории хранится файл CLAUDE.md, куда разработчики записывают все ошибки, которые агент допускал ранее. В следующий раз Claude учитывает эти правила. Таким образом, каждая ошибка превращается в постоянное ограничение, а ИИ со временем лучше адаптируется к конкретному проекту и стилю команды.
Компания Manus* (теперь являющаяся частью Meta*) представила новый инструмент Meeting Minutes, призванный решить проблему «мертвых» заметок. Новый инструмент не просто транскрибирует разговоры, но и превращает живые обсуждения в структурированные данные, позволяя мгновенно переходить от слов к созданию презентаций, веб-сайтов или постов в едином рабочем потоке.
Процесс записи встречи в Manus: простой интерфейс с кнопкой завершения и визуализацией голоса.
Как это работает: от голоса к действию
Основная идея Meeting Minutes — максимальная простота использования во время очных встреч. Процесс работы с инструментом состоит из трех интуитивных шагов:
Запись: Пользователь нажимает иконку записи в приложении, чтобы начать фиксацию разговора.
Транскрипция: Система автоматически переводит речь в текст в реальном времени.
Генерация: После нажатия кнопки «Finish» ИИ анализирует сказанное и генерирует структурированное саммари (резюме) встречи.
Ключевые возможности
Новая функция выделяется на фоне обычных диктофонов и сервисов транскрибации благодаря глубокой интеграции с рабочими процессами Manus:
Умное распознавание спикеров: Система умеет идентифицировать участников беседы. Если в разговоре упоминается имя коллеги (например, «Алексей подготовит отчет»), Manus автоматически распознает это и может назначить соответствующую задачу конкретному пользователю.
Бесшовное исполнение (End-to-End): Это главное отличие инструмента. Результат встречи — не просто текст, а база для действий. Пользователи могут сразу превратить заметки в готовые артефакты: сгенерировать слайды презентации, структуру веб-сайта или список задач, не выходя из контекста обсуждения.
Коллаборация: В созданную задачу можно приглашать других участников встречи для совместной работы над результатами, что превращает запись в единое пространство для командной работы.
Офлайн-надежность: Инструмент разработан с учетом нестабильного соединения. Запись продолжается даже при полной потере интернета. Сеть необходима только для инициации процесса и финального анализа данных в облаке.
Важные детали и ограничения
Несмотря на инновационность, у первой версии Meeting Minutes есть свои особенности, о которых стоит знать пользователям:
Фокус на очных встречах: Инструмент оптимизирован для живых разговоров в одной комнате и не предназначен для записи онлайн-звонков (Zoom, Google Meet).
Отсутствие паузы: В текущей версии нельзя поставить запись на паузу — сессию можно только завершить.
Монетизация: Сама запись голоса бесплатна, однако функции ИИ-анализа и генерации заметок расходуют кредиты пользователя.
Анализ: Плюсы, минусы и перспективы
Преимущества Manus делает шаг к закрытию разрыва между этапом обсуждения и этапом исполнения. В отличие от простых саммаризаторов, этот инструмент сразу интегрирует результаты встречи в производственную цепочку. Возможность работы без постоянного интернет-соединения делает его незаменимым для выездных встреч и командировок.
Недостатки Ограничение использования только оффлайн-встречами отсекает значительную часть сценариев удаленной работы. Отсутствие кнопки паузы может быть неудобным для длительных сессий с перерывами, а система кредитов за анализ потребует от активных пользователей внимательного контроля расходов.
Перспективы В контексте недавнего присоединения Manus* к Meta*, эта технология выглядит как фундамент для будущих интеграций. Можно ожидать появления подобных функций в WhatsApp* или умных очках Ray-Ban*. Фактически, это шаг в сторону «агентного» ИИ — помощника, который не просто пассивно слушает, но и активно помогает выполнять работу.
* Организация Meta, а также ее продукты Facebook и Instagram, признаны экстремистскими и запрещены на территории Российской Федерации.
Энтузиаст показал давно забытый секрет популярного офисного пакета Microsoft Office 97 — как открыть скрытые титры. Для этого нужно передвинуть окно программы в определённые места на экране, а затем ввести специальную фразу для Скрепыша: «This is not a contest». После этого появляется новое окно с яркой анимированной заставкой и титрами, которые длятся около трёх минут. Во время показа титров Скрепыш «рассказывает» о людях, которые создавали программу, добавляя шутливые реплики.
С новым рабочим годом, Хабр Мы в SSP SOFT опять расширяем команду и ждем ваши резюме
Кто мы? Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
В 2025 году SSP SOFT вошел в число лидеров найма ИТ-специалистов на российском рынке— за год мы наняли 179 сотрудников! И главное — в 2026 году найм продолжается.
У нас новый московский офис в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удаленку из любой точки России.
Открытые вакансии в SSP SOFT: это реальные проекты, дружная команда и атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем гуру, кто готов в новое профессиональное будущее вместе с нами.
Что вас ждет в SSP SOFT: ✅ Рост: Центр компетенций для максимального апгрейда скиллов. ✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис. ✅ Баланс: Работаем, чтобы жить, а не наоборот.
🎁 Приятные бонусы: ивенты для всей команды, ДМС для штата, обучение и бенефиты.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вакансию на Хабре».
Периодически наталкиваюсь на разработчиков, которые думают, что они незаменимы, потому что знают в каком-то месте кода прям всё на свете. И поэтому их-то точно никогда не уволят - слишком опасно и долго обучать новичка.
Но это, конечно, не так. За свою 20-летнюю карьеру видел пяток увольнений самых-пресамых незаменимых.
Во-первых, незаменимость часто преувеличивается (особенно с учетом ИИ, который и разберется, и нарисует, и расскажет всё, что важно знать). На практике обычно через 3-4 месяца уже никто и не вспоминает о Васе, который где-то там всё знал. А чаще скорее просто ругают его за странные решения, переписывая запутанные куски с нуля.
Во-вторых, даже если человек реально приносит огромную пользу и по-своему незаменим, то порой руководство просто поступает нелогично и увольняет всё равно. Иногда последствия бывают совсем неочевидны и отложены во времени (медленнее пилятся фичи, вылезают непонятные критические баги на проде), их никто никогда с Васей уже и не свяжет. Даже если объективное расследование бы показало, что денег в итоге потрачено больше. Короче, это или неправильная системная оценка или просто банальная глупость/лень менеджмента.
В-третьих, в кризисные времена сокращают целые направления, вместе с Васей и бизнесом, который Вася подпирал столько лет своим плечом, как заправский атлант. Причем, такие новости обычно приходя внезапно, как снег на голову. Типа, наш отдел закрывают с первого числа, сорян.
Короче, будьте бдительны. Нужно всегда быть готовым менять работу. Незаменимых не бывает.
Представлен открытый сервис SmartImage, который проверяет ресурсы в сети и ищет первоисточник картинки на базе нескольких алгоритмов поиска: SauceNao, IQDB, Ascii2D, trаce.mоe и других. Можно искать через перетаскивание и загрузку изображений, в текстовом поле, через буфер обмена, а также через командную строку.
Представьте, что есть некая суперспособность, позволяющая выполнять любую работу на 20% лучше и быстрее. И есть магические курсы, позволяющие обрести эту суперспособность. Доступ к курсам есть у каждого, но большинство людей либо ленятся их пройти, либо бросают на полпути. Зато те, кто дошёл до конца, всю оставшуюся жизнь пользуются указанной суперспособностью.
Когда я был в девятом классе, мне попался в руки клавиатурный тренажёр, обещавший за 100 уроков обучить слепому десятипальцевому методу набора текста. К тому моменту я уже довольно быстро печатал тремя-четырьмя пальцами и не понимал, зачем переучиваться на десять. Однако ради интереса установил программу и начал обучение. Чем дальше я продвигался, чем больше понимал, насколько новый метод эффективнее старого. За пару месяцев я освоил русский курс, а когда появился английский, прошёл и его.
С тех пор слепой набор ежедневно помогает мне в учёбе, программировании, руководстве. Он позволяет фокусироваться на задаче, а не на клавиатуре. Например, я на лету конспектирую встречи и записываю поставленные задачи.
Многие уверены, что и так набирают вслепую и не подсматривают на клавиши. Если вы тоже так считаете, пройдите простой тест. Попросите коллегу накрыть ваши руки листом A4 и попробуйте набрать без ошибок пару абзацев текста.
Впрочем, большинство людей всё равно продолжат набирать двумя-тремя пальцами. Поэтому мой совет школьникам и студентам: хотите получить фору перед сверстниками — найдите клавиатурный тренажёр.
Открытый проект Telegram AI Dating Agent (talk-to-girlfriend-ai) позволяет общаться второй половинке разработчика с ИИ-агентом на базе Claude через Telegram, потому что сам программист «не всегда может отвечать». Нейросеть умеет писать нужные публикации прямо в Telegram, ставит нужные реакты и даже считывать настроение. Когда наступает «код красный», то бот сигнализирует разработчику, что нужно ответить лично. Разработчик пояснил, что обучал нейросеть на материалах курсов по общению с девушками.
Представьте, что вы научили LLM всему, а потом поняли, что "всему" включает и рецепты сибирской язвы. Что делать? Простая фильтрация данных — дорого, ненадёжно и оставляет дыры. Пост-тренировочные методы "разучивания" (unlearning) слетают от простого fine-tuning. Новая статья от исследователей из Anthropic и Imperial College London предлагает элегантное решение — Selective GradienT Masking (SGTM).
Технические детали. Идея SGTM — не удалять знания, а локализовать их. Внутри модели создаётся "песочница" для нежелательных знаний (например, о биологии, как прокси для CBRN-угроз).
Как это работает:
Разделение параметров: Нейроны MLP и головы внимания в каждом блоке трансформера делятся на две группы: 0_retain (для обычных знаний) и 0_forget (для опасных).
Маскировка градиентов: Во время обучения, когда модель видит "опасный" пример, градиенты для 0_retain обнуляются. Обновляются только "опасные" параметры 0_forget. И наоборот, на обычных данных замораживаются 0_forget.
Удаление: После обучения достаточно просто обнулить веса 0_forget. Опасные знания исчезают, а основная модель остаётся нетронутой и функциональной.
Этот метод показал себя значительно лучше, чем простая фильтрация данных, особенно в условиях "шумных" меток, когда часть опасного контента случайно промаркирована как безопасная.
Практическое применение. Основной кейс — это удаление "dual-use" возможностей из моделей. Например, можно обучить модель на всей Википедии, а затем хирургически удалить только знания в области органической химии и вирусологии, оставив при этом общие научные знания. Это позволяет создавать мощные, но безопасные модели для широкого круга задач, не опасаясь, что их используют для создания оружия.
Насколько это эффективно? На мой взгляд, это один из самых перспективных подходов к AI Safety на сегодня.
• Плюсы: Это pre-training метод, что делает его фундаментально более надёжным. В статье показано, что SGTM в 7 раз устойчивее к попыткам восстановить знания через fine-tuning, чем другие методы. Это не "костыль", а часть архитектуры.
• Минусы: За всё надо платить. Метод добавляет около 6% вычислительной нагрузки на обучение. Кроме того, нужно заранее определить, какие именно знания мы хотим изолировать.
Вердикт: SGTM — это не панацея, но огромный шаг вперёд. Это переход от "лоботомии" модели к точечной "нейрохирургии". Для серьёзных систем, где цена ошибки высока, 6% оверхеда — смешная плата за такой уровень контроля. Скорее всего, скоро увидим эту технологию в основе всех крупных моделей от Anthropic, Google и других.
🎄Уважаемые Хабровцы, коллеги, друзья и партнеры! 🎉
В последние рабочие дни уходящего 2025 года команда SSP SOFT поздравляет вас с наступающим Новым 2026 годом и Рождеством! Самое время подвести итоги, ощутить атмосферу праздника и с уверенностью посмотреть вперед.
🚀 Нашим заказчикам Пусть 2026 год принесет устойчивый рост, новые рынки и технологические решения, которые действительно работают. Желаем, чтобы созданные вместе с SSP SOFT продукты были надежными, масштабируемыми и помогали бизнесу расти и развиваться дальше. Мы ценим доверие и рады быть вашим технологическим партнером 📈
💻 Компаниям, работающим с нами в формате аутсорсинга и Workforce-as-a-Service Готовы направить к вам сильные, мотивированные команды и специалистов, которые быстро встраиваются в процессы, понимают задачи бизнеса и усиливают его изнутри. Пусть люди остаются вашим главным конкурентным преимуществом 💪
🤝 Нашим партнерам Пусть проекты складываются, бюджеты сходятся, а наша совместная работа напоминает хорошо спроектированную систему — без лишней сложности и с понятным результатом. Спасибо за сотрудничество и совместное движение вперед 🚀
🏢 Немного о нас В 2025 году для SSP SOFT мы переехали в новый офис в Москве — в самом центре города, рядом с Красной площадью — чтобы активнее развивать сотрудничество с федеральными компаниями. 📍Весь год у нас было много вакансий, в том числе в этот новый офис. Подробности о вакансиях на нашей странице ХХ.ру
👏 Нашей команде Отдельная благодарность всем сотрудникам SSP SOFT за профессионализм, вовлеченность и ответственность. Пусть 2026 год принесет вам интересные задачи, развитие, баланс между работой и личной жизнью и уверенность в завтрашнем дне. Мы искренне рады работать вместе с вами 🤝
С нами — как дома!
🎄 С наилучшими пожеланиями в Новом году, Команда SSP SOFT 🌟ssp-soft.com 🌟
Представлен открытый удобный календарь на 2026 год, на котором все даты года отображаются на одной странице. Он автоматически поместится на одном листе бумаги любого размера. Для достижения наилучших результатов установите альбомную ориентацию при печати и отключите верхний и нижний колонтитулы.
Состоялся первый мажорный релиз открытого проекта для шифрования текста и файлов Stirlitz. Программа написана на языке С++ и распространяется под лицензией GPLv3. Приложение адаптировано для работы в операционных системах семейства Linux, Windows и Android. Для пользователей Arch Linux в AUR доступен сценарий сборки пакета. Для пользователей Windows доступен экспериментальный инсталлятор. Для пользователей Android доступен экспериментальный пакет в формате apk.
Основные возможности Stirlitz 1.0:
Шифрование текста и файлов для передачи через любые каналы публичной связи (мессенджеры, e‑mail сообщения и тому подобное). Шифрование осуществляется на базе публичных ключей (алгоритм Ed25519) и алгоритма шифрования AES256.
Шифрование файлов для локального хранения. Шифрование осуществляется через задание имени пользователя и пароля с использованием алгоритма AES256.
Создание шифрованных профилей для хранения ключей, используемых для обмена сообщениями через публичные каналы связи.
Создание одноразовых профилей: ключи хранятся в защищённой памяти, выделяемой с помощью библиотеки libgcrypt, и уничтожаются после выхода из профиля или закрытия программы.
Криптографические функции вынесены в отдельную библиотеку stirlitz, которая может быть собрана и использоваться полностью независимо.
Для библиотеки stirlitz доступна документация в формате html.
Неделю назад выступал с темой MCP сервера и как можно решить проблему с забиванием контекста как при старте диалога, так и при последующем общении через MCP сервера
Это больше походит на исследовательскую работу, а не на мой каждодневный сценарий использования. Мне было интересно, до скольки токенов можно сжать диалог без ухудшения качества
Вот, можете ознакомиться ⤵️⤵️⤵️
Давайте для начала о том, что такое MCP
MCP — протокол, который позволяет LLM подключаться к внешним сервисам: Notion, GitHub, Jira, Google Analytics, любой сервис с API. Один стандартный разъём вместо зоопарка интеграций — как USB для AI.
Протокол создали в Anthropic в ноябре 2024, в декабре 2025 передали в Linux Foundation с поддержкой OpenAI, Google, Microsoft и AWS. Де-факто стандарт индустрии. Вот тут есть каталог серверов, можете глянуть
Но у MCP есть две неочевидные проблемы, на которые я наткнулся после нескольких месяцев активного использования.
🛸 Проблема №1: Tools съедают контекст до старта
Предзагруженные MCP Tools занимают Context Window ещё до первого сообщения. Как системный промпт — уже там, когда вы только открыли чат.
Конкретные цифры из моих замеров:
Apify MCP — 7 инструментов, ~11.8k токенов
GitHub Official MCP — 40 инструментов, ~25-30k токенов
Несколько серверов вместе — легко съедают 40-70k токенов
При контексте в 200k это уже 20-35% бюджета — и вы ещё ничего не спросили.
🛸 Проблема №2: JSON забивает контекст в процессе
MCP-сервер — это переброска JSON-запросов между LLM и сервисом. Каждый вызов инструмента генерирует запрос и ответ, которые остаются в истории чата. Эти JSON часто громоздкие — особенно ответы с данными. Контекст забивается не на старте, а по ходу общения.
Почему это важно
Популярные модели имеют Context Window 128-200k токенов. Это весь бюджет чата: системные промпты, знания о вас, файлы, коннекторы. Что не влезает — забывается.
Хуже того: чем больше загружено в контекст, тем чаще модель теряет детали. В тестах на поиск 8 фактов GPT-5.1 падает с 65% до 30% при заполнении до 100k токенов. Даже более мощная GPT-5.2 проседает с 95% до 70%.
То есть проблема не только в лимите, но и в качестве работы модели при забитом контексте.
Решение для проблемы №1: Dynamic MCP
Docker Dynamic MCP — подключаем серверы не заранее, а динамически, во время разговора.
Например, вместо 40+ инструментов GitHub в контексте постоянно — лёгкий шлюз с базовыми командами:
mcp-find — найти сервер в каталоге
mcp-add — подключить к текущей сессии
mcp-exec — выполнить инструмент
mcp-remove — отключить сервер
Базовая нагрузка: ~4k токенов вместо 40-70k. Серверы подключаются по требованию и удаляются, когда больше не нужны. Работает с каталогом Docker MCP, где уже 300+ верифицированных серверов.
Нужно установить Desktop Client и в настройках Beta Features включить Enable Docker MCP Toolkit
Решение проблемы №2: запускать MCP сервера в SubAgents
SubAgents из Claude Code выполняют запрос в изолированном контексте, возвращая только результат.
Вся грязная работа — поиск серверов, подключение, вызовы инструментов, парсинг JSON-ответов — происходит в отдельном контексте подагента. В основной контекст попадает только чистый финальный ответ.
Claude Code (основной контекст)
│
▼ Запрос
┌─────────────┐
│ SubAgent │ ← вся работа с MCP
└─────────────┘
│
▼ Только результат
Claude Code (чистый контекст)
Итог: ~70k токенов экономии = 35% контекста свободно для реальной работы
Для полного описания всего этого нужна большая статья, так как без картинок и примеров суть идеи может быть непонятна
В Naumen распределенность — обычная история: офисы в разных городах, часть команд работает полностью удаленно. Отдел технического пресейла — один из таких кейсов. Его руководитель, Паша, работает удаленно, как и большая часть команды.
Несмотря на разницу во времени и расстояние, команде удается сохранять четкие процессы, регулярную синхронизацию и общее понимание происходящего.
Паша рассказал, как он управляет командой в таких условиях, какие инструменты и подходы работают, и что он считает самым важным в распределенной команде.
Чем занимается наша команда
Мы помогаем с технической стороны на продажах: участвуем в пилотах, проводим демонстрации, показываем, как наши продукты работают на реальных задачах заказчиков.
В команде 9 человек, почти все работают удаленно и живут в разных городах. Мы разделены на две группы по продуктам: Low Code и NoCode.
У каждой группы свой тимлид, который отвечает за операционку и распределение задач внутри команды. Я курирую все направление, слежу за тем, чтобы процессы работали, а команды были на связи.
Несмотря на удаленную работу, мы регулярно видимся на больших корпоративных мероприятиях. Это помогает поддерживать связь не только по задачам.
В чем была главная сложность
Самая заметная сложность — непрозрачная нагрузка. В основном мы взаимодействуем с менеджерами по продажам: изначально они писали напрямую сотрудникам моей команды. Задачи размазывались, терялись, пересекались.
В такой системе:
невозможно оценить загрузку;
нельзя планировать ресурс;
нет общей картины, кто чем занят.
Мне, как руководителю, это мешало выстраивать базовое управление. Без прозрачности все превращается в хаос. Мы решили, что пора менять подход.
Как мы выстроили систему
В 2022 году мы внедрили следующие изменения:
собрали таск-трекер на базе нашей платформы Naumen SMP;
сделали Telegram-бота и перевели всю коммуникацию с менеджерами туда.
Теперь процесс выглядит так:
Менеджер оставляет запрос в боте.
Тимлид ведет коммуникацию и ставит задачу на одного из сотрудников.
Сотрудник берет задачу в работу, оформляет результат, закрывает.
Мы ушли от личных сообщений и получили понятную нагрузку, удобный контроль и прогресс. Работать стало спокойнее.
Как поддерживаем связь внутри команды
Удаленной команде без постоянного взаимодействия довольно сложно работать. Поэтому у нас есть несколько форматов:
Дэйли внутри каждой группы — тимлид уточняет загрузку, корректирует задачи, если нужно.
Один-на-один со мной — каждый месяц встречаюсь с сотрудниками: обсуждаем годовые цели и путь к ним.
Есть еще «Флеймтайм» — раз в месяц любой может поделиться тем, что его особенно выбило из колеи. Это помогает выговориться и не держать напряжение внутри. Команда слушает и поддерживает.
Что важно в распределенной команде
Для меня как руководителя главное — правильный найм. Когда команда работает удаленно, ты не видишь человека каждый день, поэтому невозможно быть в курсе всего.
Важно, чтобы у человека был внутренний драйв, самостоятельность и вовлеченность. Такой сотрудник сам разбирается, держит фокус и включается в задачи.
Когда такие люди собираются в одной команде — неважно, где они территориально. Все и так работает.
SSP SOFT — последние вакансии в уходящем году: присоединяйтесь к команде 💻
Вот и настал момент последнего поста про вакансии в SSP SOFT в 2025 году! «Год прошел, как день вчерашний. Над Москвою в этот час. Бьют часы Кремлевской башни. Свой салют — двенадцать раз»...
А мы как раз переехали в новый московский офис в 2025 году у самой Красной площади! И там у нас есть открытые вакансии: реальные проекты, дружная команда и атмосфера, где работать — в удовольствие. Ищем гуру, кто готов в новое профессиональное будущее вместе с нами.
Что вас ждет в SSP SOFT: ✅ Вызовы: Амбициозные проекты, где не придется скучать. ✅ Поддержка: Наставник для каждого ньюби. ✅ Рост: Центр компетенций для максимального апгрейда скиллов. ✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис. ✅ Баланс: Работаем, чтобы жить, а не наоборот.
🎁 Приятные бонусы: выезды всей командой, ивенты, ДМС, обучение и бенефиты.
👉 Куранты скоро пробьют! Не теряйте время — ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, что увидели вакансию на Хабре.
Вебинар для разработчиков: Новое API и библиотека ParametricKit в nanoCAD BIM Строительство 25
Приглашаем на вебинар, посвященный работе с новой библиотекой ParametricKit — частью API для nanoCAD BIM Строительство 25. Обновленный API ускоряет разработку и поддержку библиотек благодаря поддержке C# и автоматизации типовых операций.
Ключевые темы:
Обзор API и возможностей библиотеки ParametricKit
C# как основной язык разработки библиотек
Автоматизация рутинных операций при разработке библиотек
Практические примеры работы с библиотекой ParametricKit
Требования к среде разработки
Дата: 24 декабря (среда), 11:00–12:00 (МСК) Участие: онлайн, бесплатно, по регистрации
Вебинар будет полезен BIM-разработчикам, программистам САПР, BIM-координаторам, технологическим компаниям в строительстве и дизайне.
Спикеры — эксперты «Нанософт»: Вадим Мелков, руководитель группы параметрических объектов Василий Кузьмин, программист отдела BIM-технологий
Вебинар для разработчиков: Новое API и библиотека ParametricKit в nanoCAD BIM Строительство 25
Приглашаем на вебинар, посвященный работе с новой библиотекой ParametricKit — частью API для nanoCAD BIM Строительство 25. Обновленный API ускоряет разработку и поддержку библиотек благодаря поддержке C# и автоматизации типовых операций.
Ключевые темы:
Обзор API и возможностей библиотеки ParametricKit
C# как основной язык разработки библиотек
Автоматизация рутинных операций при разработке библиотек
Практические примеры работы с библиотекой ParametricKit
Требования к среде разработки
Дата: 24 декабря (среда), 11:00–12:00 (МСК) Участие: онлайн, бесплатно, по регистрации
Вебинар будет полезен BIM-разработчикам, программистам САПР, BIM-координаторам, технологическим компаниям в строительстве и дизайне.
Спикеры — эксперты «Нанософт»: Вадим Мелков, руководитель группы разработки параметрических объектов Василий Кузьмин, программист отдела BIM-технологий
Как мы встречаем Новый год в SSP SOFT — и зачем вообще об этом писать на Хабре
В наших постах на Хабре мы часто пишем об открытых у нас вакансиях и упоминаем, что в SSP SOFT важны атмосфера в команде и баланс между работой и личной жизнью. Обычно такие формулировки воспринимаются как стандартный HR-шаблон — и мы понимаем скепсис читателей.
Поэтому иногда хочется рассазать, как это выглядит на практике.
В этом году новогоднюю вечеринку мы провели заранее — примерно за две недели до праздников. Формат получился нетипичный: фуршет, мастер-классы и… пижамная вечеринка. Без официоза, без пафоса, без «обязательного корпоратива по расписанию».
В SSP SOFT действительно бывают периоды высокой нагрузки — как и в любой ИТ-компании, работающей с заказной разработкой и сложными проектами. Именно поэтому мы сознательно относимся к нерабочим форматам общения как к части корпоративной культуры, а не как к разовой активности «для галочки».
В этот раз мы собрались в тёплом кругу, пообщались вне рабочих ролей и вместе поучаствовали в кулинарном мастер-классе с шеф-поварами — готовили обед для себя и коллег. Это был не тимбилдинг «по методичке», а живой вечер с разговорами, смехом и ощущением, что работа — не единственное, что нас объединяет.
Мы уже писали раньше и о летнем рок-концерте, и о других форматах встреч. Всё это — продолжение одного и того же подхода: работа важна, но жизнь не заканчивается задачами и дедлайнами.
Если вам близка идея работать в команде, где ценят профессионализм, но при этом помнят про человеческую сторону, — следите за нашими вакансиями на HeadHunter (загляните туда сейчас - есть открытые вакансии). Мы регулярно обновляем список открытых позиций и стараемся честно описывать, кого и зачем ищем. А откликаться можно напрямую в ЛС нашему HR Lead Алине. Не забудьте добавить сопроводительное письмо с ключевой фразой «Нашел(ла) вас на Хабре».
Иногда лучший способ рассказать о культуре компании — просто показать её без лишних слов. Желаем всем успешной карьеры в Новом году 🚀🎄)
Представлена открытая библиотека Telegram-ботов для разных задач Awesome Telegram. Там есть боты: поисковики, интеграторы с сотнями сервисов, для удаления ватермарок, загрузчики видео, аудио и картинок, генераторы картинок, стикеров, текстов, поздравлений. К каждому боту авторы приложили описание работы и инструкцию.
Я в создании продуктов и продуктовом дизайне уже больше 6 лет
Успел застать эру дизайна интерфейсов и в Photoshop, и в CorelDraw, проектировал UX в AdobeXD, а потом и Figma вышла
Поучаствовал в создании ~15 стартапов — и у нас чаще всего была 1 проблема — разработка.
Разработка стоила дорого во всех смыслах.
Это и прямые затраты — когда уже в процессе и каждый месяц уходят деньги на команду. И opportunity cost — когда идея даже не доходит до старта, потому что "где я возьму на разработчика".
Получается, чтобы создать продукт, у тебя было два пути: либо ты сам/кофаундер разработчик, либо у тебя есть деньги на разработку. Третьего не дано. Идеи без одного из этих условий оставались идеями ☕️
Что привнес вайбкодинг
Любые задачи Junior-уровня сейчас закрываются ИИшкой без проблем. С большими проектами сложнее — там пока люди не научились работать с большим контекстным окном. Но барьер входа упал радикально.
Например, в последнем батче YCombinator у большинства проектов почти весь код AI-сгенерирован. Это не плохо или хорошо, но вот как наблюдение
Что меняется
Время от идеи до работающего продукта сократилось в разы. ИИшка может собрать MVP за 2 дня, тогда как раньше даже простая разработка занимала недели или месяцы. Я до сих пор помню свои стартапы, где мы пилили функционал по 3-4 месяца — хотя сейчас я бы собрал это за несколько дней.
Теперь не нужна cost consuming команда, чтобы показать результат. Расходы из зарплатного фонда перетекают в расходы на подписки
Вайбкодинг резко удешевил и ускорил создание софта, поэтому венчур (и другие “money givers”) смещается от “дать денег, чтобы построили” к “дать денег, чтобы доказали спрос и масштабировали”
Как это влияет на мир
Количество созданных проектов увеличивается → конкуренция за пользователя растет → появляется больше нишевых решений
Раньше универсальный софт был следствием того, что разработка стоит дорого. Экономически выгоднее один продукт для всех. Сейчас за неделю можно создать 10 копий одного решения под разные рынки/ниши, и все они будут вполне рабочими
И получается, что самыми дорогими навыками теперь стали ⤵️
👨💻 Умение генерировать ценные идеи 👨💻 Продвигаться 👨💻 Выигрывать конкурентную борьбу за клиента
Почему вайбкодинг не спасет 95% проектов от провалов
Вайбкодинг убрал процесс, который и так не влиял на успешность продукта. Код сам по себе не делает продукт успешным — он просто был барьером на входе. Барьер сняли, но всё, что реально влияет на успех — все еще нужно уметь решать: понимание ЦА, работа с проблемой, умение донести продукт до людей, которым он нужен, и затем еще и масштабировать успех
Дальше — две долины (не той) смерти: — Problem-Solution Fit: Решаем ли мы важную проблему? — Product-Market Fit: Достаточно ли людей готовы за это платить?
Вероятность пройти оба — около 5%. У тех, кто не понимает, что нужно делать.
Потому что за "создать успешный продукт" спрятаны 4 огромных домена
Находить проблемы людей Не "мне кажется, это нужно", а реальные боли, за решение которых платят
Проектировать решение Так, чтобы оно действительно решало проблему. Не фичи ради фич
Продвигать через сотни конкурентов Кстати, отсутствие конкурентов — red flag. Либо ты дизраптор с миллионами на маркетинг, либо рынка просто нет
Выстроить прибыльную бизнес-модель Чтобы unit-экономика сходилась, а не "сначала наберём пользователей, потом разберёмся"
Каждый из этих пунктов — отдельная дисциплина. И вайбкодинг не помогает ни с одним из них
Итого
Вайбкодинг снижает ценность "уметь писать код". Но повышает ценность "уметь создавать продукты, которые покупают"
Технический барьер упал. Продуктовый — остался
Теперь просто больше людей могут быстрее создавать продукты, которые никому не нужны. Зато цикл обучения будет быстрее ☕️
Хорошая новость: если ты понимаешь продуктовую часть — у тебя огромное преимущество. Потому что большинство соревнуется в скорости разработки, а не в качестве идей.
«Джунов больше не нанимаем»: как ИИ‑агенты меняют разработку и роль инженера
ИИ-инструменты давно стали привычной частью рабочего стека разработчиков: автодополнение, генерация кода, помощь в тестах — всё это уже стандарт и даже набило оскомину. Но пока разработчики воспринимают ИИ как ассистента, они упускают начало нового этапа. На смену точечным ассистентам приходит агентный подход, когда автономные ИИ-агенты становятся полноценными участниками SDLC и работают не только с инженером, но и друг с другом.
Российские банки и крупные компании уже пробуют этот подход на практике: автоматизация тестов, аналитики, сопровождение фич в полуавтоматическом режиме. Но «волшебной кнопки 10x» всё ещё нет. Без продуманной интеграции и изменений в процессах ИИ легко превращается в красивую песочницу, которая не даёт реального ускорения.
На нашей конференции про ускорение разработки AI Boost выступил Александр Поломодов, технический директор Т-Банка. Он подробно рассказал, как команды переходят от простых ИИ-помощников к полноценным агентам, которые действительно влияют на скорость и качество разработки. Теперь запись доступна на YouTube — и это возможность взглянуть на внедрение ИИ-агентов глазами тех, кто делает это в проде, а не в демо-среде.
Вы узнаете:
Как сделать агентов рабочим инструментом: ключевой принцип — «проницаемость агента». Важно понимать, влияет ли он на время инженеров, какие метрики собирать и как интегрировать агентов в SDLC.
Почему миф «ускорим всё и снизим косты» не работает: ИИ ускоряет не всё. Реальные примеры показывают новые риски и необходимость перестройки процессов.
Как крупные команды строят агентную разработку: опыт Т-Банка — что автоматизировать первыми, какие роли и доступы давать агентам и как выглядит работа команды, когда агенты становятся её частью.
Как меняется роль инженера и тимлида: часть рутины уходит к агентам. Инженер всё чаще становится «лидом команды агентов», растут требования к middle/senior, а задачи джунов частично автоматизируются.
Как измерять эффективность ИИ-агентов: артефакты — не метрика. Важно смотреть на реальное влияние на скорость, избегать ложных показателей и встроить измерения в ежедневный процесс.
Какие навыки нужны уже сейчас: умение формулировать задачи как сценарии, проектировать роли агентов и отвечать за процессы, а не только за код.
Спикер:
Александр Поломодов — технический директор T‑Tech.
«Мы переходим от простых ИИ‑помощников к агентам, которые реально влияют на скорость и качество разработки. Но без правильных процессов и метрик это остаётся только красивой демо‑картинкой.»
Смотрите полную запись доклада на YouTube — особенно если вы:
руководите разработкой или продуктом и хотите понять, где агенты дадут реальную отдачу, а где нет;
отвечаете за инженерную культуру и планируете, как изменится роль разработчиков в ближайшие 2–3 года;
уже используете Copilot/Cursor и хотите перейти от «вайб‑кодинга» к системному использованию ИИ‑агентов в SDLC.
В этой подборке собрали три курса, которые будут полезны специалистам, стремящимся развиваться как руководители в своих направлениях.
«Lead DevOps» — 5 месяцев Научим быть «играющим тренером» — специалистом, который одинаково уверенно разбирается и в технологиях, и в менеджменте. После курса почувствуете, что к большой ответственности прилагается большая уверенность в своих силах.
«QA Lead» — 5 месяцев Курс поможет вырасти из QA-инженера в руководителя QA-команды. Разберём, как формировать сильную команду, управлять стратегией автоматизации и выстраивать эффективные QA/QC-процессы.
«Технический директор — СТО» — 4 месяца Программа для технических специалистов, которые хотят развиваться как руководители. Наставники и менторы — CTO из Яндекса и других крупных компаний.
Проект Open Scouts обеспечивает роботу целой команды ИИ-агентов для получения всевозможных сведений в сети. Сервис по расписанию мониторит сайты, соцсети и другие ресурсы и пересылает обновления на почту. ИИ-агенты могут следить за вакансиями, трендами, исследованиями или другими обновлениями данных в интернете по запросу.
ИИ в деле: как измерить реальную эффективность и избежать ошибок внедрения
В новом выпуске нашего подкаста мы углубились в процессы, которые стоят за стабильностью и инновациями в крупном финтехе.
Наш гость — Дмитрий Журавлёв, руководитель разработки отдела единой авторизации и Центра компетенции LLM. Мы разобрались, как управлять критически важными, но на первый взгляд, совершенно разными направлениями в одной IT-инфраструктуре.
Единая авторизация:
Стек и архитектура: почему при выборе open-source решения мы в итоге ушли от оригинальной реализации.
Решение проблем безопасности: как объединение десятков разрозненных систем входа в единый контур повышает безопасность и снижает когнитивную нагрузку на разработчиков.
Центр компетенции ИИ:
Практическое применение: кейсы автоматизации рутины в нетехнических отделах, генерация персонализированного контента под разные психотипы клиентов и, главное, реальное ускорение MVP-разработки.
Метрики и эффективность: как измерить реальный профит (ROI) от внедрения LLM и почему TTM (Time to Market) — главная метрика успеха в ИИ-проектах.
Границы применимости:
Большие кодовые базы: почему в больших legacy-проектах ИИ может не помогать, а мешать. Опасности AI-генерации кода без ревью и архитектурного контроля.
Будущее разработчика: станем ли мы "пилотами" ИИ? И почему именно эмпатия и архитектурное мышление остаются за человеком.
Со временем у каждого разработчика появляется свой набор маленьких правил, которые работают лучше любых инструкций. Матвей из команды разработки сервисов на базе SMP поделился пятью привычками, которые помогают ему держать код аккуратным и читаемым.
1. Давать осмысленные имена сразу же
Хорошие названия переменных, функций и классов экономят время всей команде: код проще читать, легче понимать и поддерживать. А еще чем меньше вопросов «что делает эта функция?» или «что содержит переменная?», тем лучше.
2. Декомпозировать код и избегать вложенности
if внутри if или for внутри for путают: каждое разветвление создает еще одну ветку, которую приходится держать в голове. Лучше разбить логику на небольшие части — код становится прозрачнее и надежнее.
как не надо:
функция заказать_пиццу(адрес):
если адрес_валиден(адрес):
если у_ресторана_ингредиенты():
если клиент_может_платить():
печать "Пицца заказана!"
иначе:
печать "Недостаточно денег"
иначе:
печать "Нет ингредиентов"
иначе:
печать "Адрес некорректный"
как надо:
функция заказать_пиццу(адрес):
если не адрес_валиден(адрес):
печать "Адрес некорректный"
вернуть
если не у_ресторана_ингредиенты():
печать "Нет ингредиентов"
вернуть
если не клиент_может_платить():
печать "Недостаточно денег"
вернуть
печать "Пицца заказана!"
3. Регулярно делать рефакторинг
Подходы и стандарты меняются, команда учится новому и растет, а код устаревает. Регулярный рефакторинг помогает поддерживать код актуальным и облегчает жизнь новым разработчикам, которые, возможно, уже пробовали новые подходы в работе.
4. Настроить линтер и форматер
Линтер — статический анализатор кода, который следит за определенным стилем написания кода. Так как у каждого из нас свой подход, нам нужен «инструмент-судья», который беспристрастно оценит оформление кода. Форматер помогает автоматически исправить код и привести его к единому виду.
5. Комментировать только неочевидную бизнес-логику
Комментарии полезны, если они объясняют то, что нельзя понять из кода. Например, когда понимаем, что участок кода содержит особенность бизнес-логики, которая еще не ясна новому сотруднику. Но важно помнить, что избыток пояснений превращает понятный код в мешанину из кода и комментариев. Принцип простой: объясняем редкие, действительно сложные места и не трогаем остальное.
Добавлять в рефакторинг улучшения Строго отделяйте рефакторинг т.е. преобразование кода из одной формы в другую с полным сохранением поведения от любых даже самых незначительных улучшений, оптимизаций, украшательства и тд и тп
Делать один огромный коммит Делайте много коммитов, каждый на свой шаг рефакторинга. Рефакторинг это как ходьба по заминированному лабиринту, нужно обязательно записывать все ходы и иногда отступать на шаг или N шагов назад и искать другой путь.
Рефакторить без промежуточных проверок Когда вдохновение несет и хочется "прибраться" и тут и там и везде и некогда останавливаться можно "пролететь поворот" и даже не один. Лучше всего делить рефакторинг на логические этапы. "Дешевые" по времени и ресурсу проверки можно и нужно запускать как можно чаще: компиляция, тесты, запуск приложение локально. Между крупными этапами желательно проводить регрессионное тестирование. И самое отличное поэтапный релиз рефакторинга, чтобы провести не только синтетические проверки, но самую важную "проверку продакшеном"
Затягивать и долго не релизить рефакторинг Топ выбрасываний рефакторинга на моей практике происходило из за желания довести его до окончательного окончания, всё всё исправить, привести в идеальную симметрию и тд и тп. Чем дольше человек очищает код, пока параллельно идут продуктовые спринты, тем больше он несет накладных расходов(мержить то надо) и тем больше падает вероятность успешной интеграции ветки рефакторинга с основной и его успешного релиза.
Не думать о запасном варианте Не смотря на все многоступенчатые системы проверки качества вашего кода всегда есть далеко не нулевая вероятность ошибки, особенно когда "наводишь порядок" в самом ключевом месте системы (а где еще как не в таких местах наводить порядок). В таких ситуация очень полезно оставлять запасной вариант, например флаг переключения на "абсолютно старый код", лучше всего налету без рестартов.
В своем канале о разработке в стартапах делюсь опытом и рассказываю еще больше удачных примеров и факапов. Буду рад видеть каждого! Заходите!
Представлен сервис LearnXinYMinutes, который поможет освоить базовые команды и понять, как они используются в работе в разных языках программирования, фреймворках и программных средах, включая IDE. Внутри есть 55 ссылок (от баша и C до YAML) для изучения с русским переводом.
Яндекс Практикум проводит опрос о найме IT и Digital специалистов на российском рынке. Этот опрос очень важен для рынка, и мы готовы поделиться отчетом по результатам опроса.
Опрос занимает 7-10 минут, в конце анкеты вас ждет бонус — бесплатный доступ к одному из курсов Яндекс Практикума (на ваш выбор).
Если вы нанимающий менеджер — тимлид, техлид, руководитель направления, перейдите по этой ссылке.
Зачем нужен опрос?
Нам важно узнать больше о найме IT и Digital специалистов сегодня с позиции рекрутеров и смежных ролей: какие инструменты помогают ускорить найм, что для вас важно в найме, какие проблемы есть на рынке труда сегодня.
Это безопасно?
Все данные анонимны и будут проанализированы только в обобщенном виде.
А можно ли узнать результаты?
При желании в конце анкеты вы можете оставить свой e-mail, мы пришлем вам обобщенные результаты исследования — это возможность узнать больше о рынке найма сегодня.
⚡️ITFB Group запускает KODA — платформу для объективной оценки эффективности разработки
Мы представили KODA — собственную платформу, которая показывает, как на самом деле работает команда разработки. Не по ощущениям и не по субъективным отчётам, а на основе данных из всех инструментов инженеров: репозиториев, таск-трекеров, CI/CD, баз знаний и систем тестирования.
🔥 За первые 3 квартала внутреннего использования мы увеличили производительность команд на 30%, сократили количество переделок на 35% и ускорили code review на 40%.
💻 KODA объединяет инженерные метрики, ИИ-модули и аналитику, чтобы дать руководителям полную картину разработки — прозрачную, измеримую и безопасную. Все данные остаются внутри компании.
Наталья Романова, директор по развитию ITFB Group: «Мы создавали KODA как инженеры для инженеров. Но в итоге получили инструмент, который одинаково важен и для бизнеса: он переводит работу разработки в язык цифр, прозрачности и управляемости».
📎 По оценкам Gartner, к 2027 году подобные системы станут стандартом для половины компаний мира. Российский рынок только начинает этот путь — и KODA становится одним из первых решений такого уровня.
Больше никаких мучений с Markdown — расширение Markdown Viewer превращает все файлы Markdown в Word-документы без боли и страданий. Захватывает инфографику: любые схемы, диаграммы, графики в чистые картинки. Берёт формулы из LaTeX и переносит их в Word нативно, а не в формате ужасных вставок. Переносит форматирование — подсвечивает код, сохраняет таблицы и списки, как в оригинале. Работает локально. Подходит для работы с GitHub: открывает документы и даёт перенести всё в Word.
Хотели ускорить разработку с ИИ, а получили сопротивление и хаос: как работать с командой
Сегодня ИИ стараются внедрить буквально в каждый этап разработки. Иногда это вдохновляет, но чаще вызывает закономерный скепсис и сопротивление — особенно у команд, которых бездумно заставляют использовать новые инструменты. Почему возникает это сопротивление и как его преодолеть?
Евгений Сатуров, CTO Mobile в Surf, провел 50+ сессий парного программирования, понаблюдал, как разработчики впервые работают с ИИ, и собрал 40 страниц выводов. А потом рассказал обо всем на конференции AI Boost. Теперь выступление есть на YouTube.
Вы узнаете:
Почему ИИ-кодинг — это отдельный навык, а не автоматическое ускорение разработки.
Какие 5 ключевых страхов чаще всего мешают командам (стоимость, недоверие, потеря контроля, замедление, отказ от результата).
Как ИИ подчеркивает слабые места постановки задач и почему качество промпта напрямую влияет на качество решения.
Чем различаются системные, таск- и мета-промпты, и зачем их понимать каждому разработчику.
Почему ИИ-агенты эффективнее на цельных задачах, чем на мелких правках.
Как руководителю внедрять ИИ так, чтобы это не было про «разбирайтесь сами».
Главные барьеры на пути внедрения — не технические, а человеческие. Все ошибки и проблемы проистекают из страхов и заблуждений разработчиков, а не из несовершенства ИИ.
Евгений Сатуров, CTO Mobile в Surf
В видео — много практики, наблюдений и реальных кейсов, как ИИ реально помогает командам — и какие ошибки лучше не повторять. Смотрите на YouTube.
