Обновить
255.95

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

Планирование, отслеживание и контроль

Сначала показывать
Порог рейтинга

AI-лоботомия отменяется

Представьте, что вы научили LLM всему, а потом поняли, что "всему" включает и рецепты сибирской язвы. Что делать? Простая фильтрация данных — дорого, ненадёжно и оставляет дыры. Пост-тренировочные методы "разучивания" (unlearning) слетают от простого fine-tuning. Новая статья от исследователей из Anthropic и Imperial College London предлагает элегантное решение — Selective GradienT Masking (SGTM).

Технические детали. Идея SGTM — не удалять знания, а локализовать их. Внутри модели создаётся "песочница" для нежелательных знаний (например, о биологии, как прокси для CBRN-угроз).

Как это работает:

  1. Разделение параметров: Нейроны MLP и головы внимания в каждом блоке трансформера делятся на две группы: 0_retain (для обычных знаний) и 0_forget (для опасных).

  2. Маскировка градиентов: Во время обучения, когда модель видит "опасный" пример, градиенты для 0_retain обнуляются. Обновляются только "опасные" параметры 0_forget. И наоборот, на обычных данных замораживаются 0_forget.

  3. Удаление: После обучения достаточно просто обнулить веса 0_forget. Опасные знания исчезают, а основная модель остаётся нетронутой и функциональной.

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

Практическое применение. Основной кейс — это удаление "dual-use" возможностей из моделей. Например, можно обучить модель на всей Википедии, а затем хирургически удалить только знания в области органической химии и вирусологии, оставив при этом общие научные знания. Это позволяет создавать мощные, но безопасные модели для широкого круга задач, не опасаясь, что их используют для создания оружия.

Насколько это эффективно? На мой взгляд, это один из самых перспективных подходов к AI Safety на сегодня.

• Плюсы: Это pre-training метод, что делает его фундаментально более надёжным. В статье показано, что SGTM в 7 раз устойчивее к попыткам восстановить знания через fine-tuning, чем другие методы. Это не "костыль", а часть архитектуры.

• Минусы: За всё надо платить. Метод добавляет около 6% вычислительной нагрузки на обучение. Кроме того, нужно заранее определить, какие именно знания мы хотим изолировать.

Вердикт: SGTM — это не панацея, но огромный шаг вперёд. Это переход от "лоботомии" модели к точечной "нейрохирургии". Для серьёзных систем, где цена ошибки высока, 6% оверхеда — смешная плата за такой уровень контроля. Скорее всего, скоро увидим эту технологию в основе всех крупных моделей от Anthropic, Google и других.

Исследование

Теги:
+3
Комментарии10

🎄Уважаемые Хабровцы, коллеги, друзья и партнеры! 🎉

В последние рабочие дни уходящего 2025 года команда SSP SOFT поздравляет вас с наступающим Новым 2026 годом и Рождеством!
Самое время подвести итоги, ощутить атмосферу праздника и с уверенностью посмотреть вперед.

🚀 Нашим заказчикам
Пусть 2026 год принесет устойчивый рост, новые рынки и технологические решения, которые действительно работают. Желаем, чтобы созданные вместе с SSP SOFT продукты были надежными, масштабируемыми и помогали бизнесу расти и развиваться дальше. Мы ценим доверие и рады быть вашим технологическим партнером 📈

💻 Компаниям, работающим с нами в формате аутсорсинга и Workforce-as-a-Service
Готовы направить к вам сильные, мотивированные команды и специалистов, которые быстро встраиваются в процессы, понимают задачи бизнеса и усиливают его изнутри. Пусть люди остаются вашим главным конкурентным преимуществом 💪

🤝 Нашим партнерам
Пусть проекты складываются, бюджеты сходятся, а наша совместная работа напоминает хорошо спроектированную систему — без лишней сложности и с понятным результатом. Спасибо за сотрудничество и совместное движение вперед 🚀

🏢 Немного о нас
В 2025 году для SSP SOFT мы переехали в новый офис в Москве — в самом центре города, рядом с Красной площадью — чтобы активнее развивать сотрудничество с федеральными компаниями.
📍Весь год у нас было много вакансий, в том числе в этот новый офис. Подробности о вакансиях на нашей странице ХХ.ру

👏 Нашей команде
Отдельная благодарность всем сотрудникам SSP SOFT за профессионализм, вовлеченность и ответственность. Пусть 2026 год принесет вам интересные задачи, развитие, баланс между работой и личной жизнью и уверенность в завтрашнем дне.
Мы искренне рады работать вместе с вами 🤝 

С нами — как дома!

🎄 С наилучшими пожеланиями в Новом году,
Команда SSP SOFT
🌟ssp-soft.com 🌟

Теги:
+8
Комментарии2

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

Теги:
0
Комментарии0

Состоялся первый мажорный релиз открытого проекта для шифрования текста и файлов Stirlitz. Программа написана на языке С++ и распространяется под лицензией GPLv3. Приложение адаптировано для работы в операционных системах семейства Linux, Windows и Android. Для пользователей Arch Linux в AUR доступен сценарий сборки пакета. Для пользователей Windows доступен экспериментальный инсталлятор. Для пользователей Android доступен экспериментальный пакет в формате apk.

Основные возможности Stirlitz 1.0:

  • Шифрование текста и файлов для передачи через любые каналы публичной связи (мессенджеры, e‑mail сообщения и тому подобное). Шифрование осуществляется на базе публичных ключей (алгоритм Ed25519) и алгоритма шифрования AES256.

  • Шифрование файлов для локального хранения. Шифрование осуществляется через задание имени пользователя и пароля с использованием алгоритма AES256.

  • Создание шифрованных профилей для хранения ключей, используемых для обмена сообщениями через публичные каналы связи.

  • Создание одноразовых профилей: ключи хранятся в защищённой памяти, выделяемой с помощью библиотеки libgcrypt, и уничтожаются после выхода из профиля или закрытия программы.

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

  • Для библиотеки stirlitz доступна документация в формате html.

Теги:
+2
Комментарии4

Главная причина купить очки дополненной реальности — играть на работе, пока коллеги думают, что ты пытаешься успеть всё к дедлайну.

Теги:
+9
Комментарии1

Неделю назад выступал с темой MCP сервера и как можно решить проблему с забиванием контекста как при старте диалога, так и при последующем общении через MCP сервера

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

Вот, можете ознакомиться ⤵️⤵️⤵️

Давайте для начала о том, что такое MCP

MCP — протокол, который позволяет LLM подключаться к внешним сервисам: Notion, GitHub, Jira, Google Analytics, любой сервис с API. Один стандартный разъём вместо зоопарка интеграций — как USB для AI.

Протокол создали в Anthropic в ноябре 2024, в декабре 2025 передали в Linux Foundation с поддержкой OpenAI, Google, Microsoft и AWS. Де-факто стандарт индустрии. Вот тут есть каталог серверов, можете глянуть

Я уже писал про MCP ранее, тоже можете глянуть

--------------

Но у 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% контекста свободно для реальной работы

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

Теги:
+5
Комментарии0

В Naumen распределенность — обычная история: офисы в разных городах, часть команд работает полностью удаленно. Отдел технического пресейла — один из таких кейсов. Его руководитель, Паша, работает удаленно, как и большая часть команды.

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

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

Чем занимается наша команда

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

В команде 9 человек, почти все работают удаленно и живут в разных городах. Мы разделены на две группы по продуктам: Low Code и NoCode.

У каждой группы свой тимлид, который отвечает за операционку и распределение задач внутри команды. Я курирую все направление, слежу за тем, чтобы процессы работали, а команды были на связи.

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

В чем была главная сложность

Самая заметная сложность — непрозрачная нагрузка. В основном мы взаимодействуем с менеджерами по продажам: изначально они писали напрямую сотрудникам моей команды. Задачи размазывались, терялись, пересекались.

В такой системе:

  • невозможно оценить загрузку;

  • нельзя планировать ресурс;

  • нет общей картины, кто чем занят.

Мне, как руководителю, это мешало выстраивать базовое управление. Без прозрачности все превращается в хаос. Мы решили, что пора менять подход.

Как мы выстроили систему

В 2022 году мы внедрили следующие изменения:

  • собрали таск-трекер на базе нашей платформы Naumen SMP;

  • сделали Telegram-бота и перевели всю коммуникацию с менеджерами туда.

Теперь процесс выглядит так:

  1. Менеджер оставляет запрос в боте.

  2. Тимлид ведет коммуникацию и ставит задачу на одного из сотрудников.

  3. Сотрудник берет задачу в работу, оформляет результат, закрывает.

Мы ушли от личных сообщений и получили понятную нагрузку, удобный контроль и прогресс. Работать стало спокойнее.

Как поддерживаем связь внутри команды

Удаленной команде без постоянного взаимодействия довольно сложно работать. Поэтому у нас есть несколько форматов:

Еженедельная общекомандная встреча — обсуждаем новости компании, нестандартные кейсы, делимся опытом.

Дэйли внутри каждой группы — тимлид уточняет загрузку, корректирует задачи, если нужно.

Один-на-один со мной — каждый месяц встречаюсь с сотрудниками: обсуждаем годовые цели и путь к ним.

Есть еще «Флеймтайм» — раз в месяц любой может поделиться тем, что его особенно выбило из колеи. Это помогает выговориться и не держать напряжение внутри. Команда слушает и поддерживает.

Что важно в распределенной команде

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

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

Когда такие люди собираются в одной команде — неважно, где они территориально. Все и так работает.

Теги:
0
Комментарии0

SSP SOFT — последние вакансии в уходящем году: присоединяйтесь к команде 💻

Вот и настал момент последнего поста про вакансии в SSP SOFT в 2025 году!
«Год прошел, как день вчерашний. Над Москвою в этот час. Бьют часы Кремлевской башни. Свой салют — двенадцать раз»...

А мы как раз переехали в новый московский офис в 2025 году у самой Красной площади! И там у нас есть открытые вакансии: реальные проекты, дружная команда и атмосфера, где работать — в удовольствие. Ищем гуру, кто готов в новое профессиональное будущее вместе с нами.

📢 Мы ищем прямо сейчас:

1️⃣ Fullstack QA (Java)
2️⃣ Бизнес-аналитика (Senior)
3️⃣ С# Разработчика (интеграции с Lekton)
Подробности о вакансиях на нашей странице ХХ.ру

Что вас ждет в SSP SOFT:
✅ Вызовы: Амбициозные проекты, где не придется скучать.
✅ Поддержка: Наставник для каждого ньюби.
✅ Рост: Центр компетенций для максимального апгрейда скиллов.
✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис.
✅ Баланс: Работаем, чтобы жить, а не наоборот.

🎁 Приятные бонусы: выезды всей командой, ивенты, ДМС, обучение и бенефиты.

👉 Куранты скоро пробьют! Не теряйте время — ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, что увидели вакансию на Хабре.

Желаем всем успешной карьеры в Новом году 🚀🎄)

Теги:
0
Комментарии0

Вебинар для разработчиков: Новое API и библиотека ParametricKit в nanoCAD BIM Строительство 25

Приглашаем на вебинар, посвященный работе с новой библиотекой ParametricKit — частью API для nanoCAD BIM Строительство 25. Обновленный API ускоряет разработку и поддержку библиотек благодаря поддержке C# и автоматизации типовых операций.

Ключевые темы:

  1. Обзор API и возможностей библиотеки ParametricKit

  2. C# как основной язык разработки библиотек

  3. Автоматизация рутинных операций при разработке библиотек

  4. Практические примеры работы с библиотекой ParametricKit

  5. Требования к среде разработки

Дата: 24 декабря (среда), 11:00–12:00 (МСК)
Участие: онлайн, бесплатно, по регистрации

Вебинар будет полезен BIM-разработчикам, программистам САПР, BIM-координаторам, технологическим компаниям в строительстве и дизайне.

Спикеры — эксперты «Нанософт»:
Вадим Мелков, руководитель группы параметрических объектов
Василий Кузьмин, программист отдела BIM-технологий

Успейте зарегистрироваться! Количество мест ограничено.

Теги:
0
Комментарии0

Вебинар для разработчиков: Новое API и библиотека ParametricKit в nanoCAD BIM Строительство 25

Приглашаем на вебинар, посвященный работе с новой библиотекой ParametricKit — частью API для nanoCAD BIM Строительство 25. Обновленный API ускоряет разработку и поддержку библиотек благодаря поддержке C# и автоматизации типовых операций.

Ключевые темы:

  1. Обзор API и возможностей библиотеки ParametricKit

  2. C# как основной язык разработки библиотек

  3. Автоматизация рутинных операций при разработке библиотек

  4. Практические примеры работы с библиотекой ParametricKit

  5. Требования к среде разработки

Дата: 24 декабря (среда), 11:00–12:00 (МСК)
Участие: онлайн, бесплатно, по регистрации

Вебинар будет полезен BIM-разработчикам, программистам САПР, BIM-координаторам, технологическим компаниям в строительстве и дизайне.

Спикеры — эксперты «Нанософт»:
Вадим Мелков, руководитель группы разработки параметрических объектов
Василий Кузьмин, программист отдела BIM-технологий

Успейте зарегистрироваться! Количество мест ограничено.

Теги:
0
Комментарии0

Как мы встречаем Новый год в SSP SOFT — и зачем вообще об этом писать на Хабре

В наших постах на Хабре мы часто пишем об открытых у нас вакансиях и упоминаем, что в SSP SOFT важны атмосфера в команде и баланс между работой и личной жизнью. Обычно такие формулировки воспринимаются как стандартный HR-шаблон — и мы понимаем скепсис читателей.

Поэтому иногда хочется рассазать, как это выглядит на практике.

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

В SSP SOFT действительно бывают периоды высокой нагрузки — как и в любой ИТ-компании, работающей с заказной разработкой и сложными проектами. Именно поэтому мы сознательно относимся к нерабочим форматам общения как к части корпоративной культуры, а не как к разовой активности «для галочки».

В этот раз мы собрались в тёплом кругу, пообщались вне рабочих ролей и вместе поучаствовали в кулинарном мастер-классе с шеф-поварами — готовили обед для себя и коллег. Это был не тимбилдинг «по методичке», а живой вечер с разговорами, смехом и ощущением, что работа — не единственное, что нас объединяет.

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

Если вам близка идея работать в команде, где ценят профессионализм, но при этом помнят про человеческую сторону, — следите за нашими вакансиями на HeadHunter (загляните туда сейчас - есть открытые вакансии). Мы регулярно обновляем список открытых позиций и стараемся честно описывать, кого и зачем ищем. А откликаться можно напрямую в ЛС нашему HR Lead Алине. Не забудьте добавить сопроводительное письмо с ключевой фразой «Нашел(ла) вас на Хабре».

Иногда лучший способ рассказать о культуре компании — просто показать её без лишних слов. Желаем всем успешной карьеры в Новом году 🚀🎄)

Теги:
+2
Комментарии0

Представлена открытая библиотека Telegram-ботов для разных задач Awesome Telegram. Там есть боты: поисковики, интеграторы с сотнями сервисов, для удаления ватермарок, загрузчики видео, аудио и картинок, генераторы картинок, стикеров, текстов, поздравлений. К каждому боту авторы приложили описание работы и инструкцию.

Теги:
0
Комментарии2

Про вайбкодинг

Я в создании продуктов и продуктовом дизайне уже больше 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 огромных домена

  1. Находить проблемы людей
    Не "мне кажется, это нужно", а реальные боли, за решение которых платят

  2. Проектировать решение
    Так, чтобы оно действительно решало проблему. Не фичи ради фич

  3. Продвигать через сотни конкурентов
    Кстати, отсутствие конкурентов — red flag. Либо ты дизраптор с миллионами на маркетинг, либо рынка просто нет

  4. Выстроить прибыльную бизнес-модель
    Чтобы unit-экономика сходилась, а не "сначала наберём пользователей, потом разберёмся"

Каждый из этих пунктов — отдельная дисциплина. И вайбкодинг не помогает ни с одним из них

Итого

Вайбкодинг снижает ценность "уметь писать код". Но повышает ценность "уметь создавать продукты, которые покупают"

Технический барьер упал. Продуктовый — остался

Теперь просто больше людей могут быстрее создавать продукты, которые никому не нужны. Зато цикл обучения будет быстрее ☕️

Хорошая новость: если ты понимаешь продуктовую часть — у тебя огромное преимущество. Потому что большинство соревнуется в скорости разработки, а не в качестве идей.

Теги:
-13
Комментарии62

Ближайшие события

«Джунов больше не нанимаем»: как ИИ‑агенты меняют разработку и роль инженера

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

Российские банки и крупные компании уже пробуют этот подход на практике: автоматизация тестов, аналитики, сопровождение фич в полуавтоматическом режиме. Но «волшебной кнопки 10x» всё ещё нет. Без продуманной интеграции и изменений в процессах ИИ легко превращается в красивую песочницу, которая не даёт реального ускорения.

На нашей конференции про ускорение разработки AI Boost выступил Александр Поломодов, технический директор Т-Банка. Он подробно рассказал, как команды переходят от простых ИИ-помощников к полноценным агентам, которые действительно влияют на скорость и качество разработки. Теперь запись доступна на YouTube — и это возможность взглянуть на внедрение ИИ-агентов глазами тех, кто делает это в проде, а не в демо-среде.

Вы узнаете:

  • Как сделать агентов рабочим инструментом: ключевой принцип — «проницаемость агента». Важно понимать, влияет ли он на время инженеров, какие метрики собирать и как интегрировать агентов в SDLC.

  • Почему миф «ускорим всё и снизим косты» не работает: ИИ ускоряет не всё. Реальные примеры показывают новые риски и необходимость перестройки процессов.

  • Как крупные команды строят агентную разработку: опыт Т-Банка — что автоматизировать первыми, какие роли и доступы давать агентам и как выглядит работа команды, когда агенты становятся её частью.

  • Как меняется роль инженера и тимлида: часть рутины уходит к агентам. Инженер всё чаще становится «лидом команды агентов», растут требования к middle/senior, а задачи джунов частично автоматизируются.

  • Как измерять эффективность ИИ-агентов: артефакты — не метрика. Важно смотреть на реальное влияние на скорость, избегать ложных показателей и встроить измерения в ежедневный процесс.

  • Какие навыки нужны уже сейчас: умение формулировать задачи как сценарии, проектировать роли агентов и отвечать за процессы, а не только за код.

Спикер:

Александр Поломодов — технический директор T‑Tech.

«Мы переходим от простых ИИ‑помощников к агентам, которые реально влияют на скорость и качество разработки. Но без правильных процессов и метрик это остаётся только красивой демо‑картинкой.»

Смотрите полную запись доклада на YouTube — особенно если вы:

  • руководите разработкой или продуктом и хотите понять, где агенты дадут реальную отдачу, а где нет;

  • отвечаете за инженерную культуру и планируете, как изменится роль разработчиков в ближайшие 2–3 года;

  • уже используете Copilot/Cursor и хотите перейти от «вайб‑кодинга» к системному использованию ИИ‑агентов в SDLC.

Теги:
-4
Комментарии2

Запуски 2025: менеджмент в ИТ

В этой подборке собрали три курса, которые будут полезны специалистам, стремящимся развиваться как руководители в своих направлениях.

«Lead DevOps» — 5 месяцев
Научим быть «играющим тренером» — специалистом, который одинаково уверенно разбирается и в технологиях, и в менеджменте. После курса почувствуете, что к большой ответственности прилагается большая уверенность в своих силах.

«QA Lead» — 5 месяцев
Курс поможет вырасти из QA-инженера в руководителя QA-команды. Разберём, как формировать сильную команду, управлять стратегией автоматизации и выстраивать эффективные QA/QC-процессы.

«Технический директор — СТО» — 4 месяца
Программа для технических специалистов, которые хотят развиваться как руководители. Наставники и менторы — CTO из Яндекса и других крупных компаний.

Теги:
0
Комментарии0

Проект Open Scouts обеспечивает роботу целой команды ИИ-агентов для получения всевозможных сведений в сети. Сервис по расписанию мониторит сайты, соцсети и другие ресурсы и пересылает обновления на почту. ИИ-агенты могут следить за вакансиями, трендами, исследованиями или другими обновлениями данных в интернете по запросу.

Теги:
0
Комментарии1

ИИ в деле: как измерить реальную эффективность и избежать ошибок внедрения

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

Наш гость — Дмитрий Журавлёв, руководитель разработки отдела единой авторизации и Центра компетенции LLM. Мы разобрались, как управлять критически важными, но на первый взгляд, совершенно разными направлениями в одной IT-инфраструктуре.

Единая авторизация:

  • Стек и архитектура: почему при выборе open-source решения мы в итоге ушли от оригинальной реализации.

  • Решение проблем безопасности: как объединение десятков разрозненных систем входа в единый контур повышает безопасность и снижает когнитивную нагрузку на разработчиков.

Центр компетенции ИИ:

  • Практическое применение: кейсы автоматизации рутины в нетехнических отделах, генерация персонализированного контента под разные психотипы клиентов и, главное, реальное ускорение MVP-разработки.

  • Метрики и эффективность: как измерить реальный профит (ROI) от внедрения LLM и почему TTM (Time to Market) — главная метрика успеха в ИИ-проектах.

Границы применимости:

  • Большие кодовые базы: почему в больших legacy-проектах ИИ может не помогать, а мешать. Опасности AI-генерации кода без ревью и архитектурного контроля.

  • Будущее разработчика: станем ли мы "пилотами" ИИ? И почему именно эмпатия и архитектурное мышление остаются за человеком.

Наш подкаст доступен на всех удобных платформах:

Youtube | Apple Podcast | Яндекс Музыка | Spotify | VK Музыка

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии0

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

1. Давать осмысленные имена сразу же

Хорошие названия переменных, функций и классов экономят время всей команде: код проще читать, легче понимать и поддерживать. А еще чем меньше вопросов «что делает эта функция?» или «что содержит переменная?», тем лучше.

2. Декомпозировать код и избегать вложенности

if внутри if или for внутри for путают: каждое разветвление создает еще одну ветку, которую приходится держать в голове. Лучше разбить логику на небольшие части — код становится прозрачнее и надежнее.

как не надо:

функция заказать_пиццу(адрес):
  если адрес_валиден(адрес):
    если у_ресторана_ингредиенты():
      если клиент_может_платить():
        печать "Пицца заказана!"
      иначе:
        печать "Недостаточно денег"
    иначе:
      печать "Нет ингредиентов"
  иначе:
    печать "Адрес некорректный"

как надо:

функция заказать_пиццу(адрес):
  если не адрес_валиден(адрес):
    печать "Адрес некорректный"
    вернуть
  
  если не у_ресторана_ингредиенты():
    печать "Нет ингредиентов"
    вернуть
  
  если не клиент_может_платить():
    печать "Недостаточно денег"
    вернуть
  
  печать "Пицца заказана!"

3. Регулярно делать рефакторинг

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

4. Настроить линтер и форматер

Линтер — статический анализатор кода, который следит за определенным стилем написания кода. Так как у каждого из нас свой подход, нам нужен «инструмент-судья», который беспристрастно оценит оформление кода. Форматер помогает автоматически исправить код и привести его к единому виду. 

5. Комментировать только неочевидную бизнес-логику

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

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии3

5 Ошибок Рефакторинга

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

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

  3. Рефакторить без промежуточных проверок
    Когда вдохновение несет и хочется "прибраться" и тут и там и везде и некогда останавливаться можно "пролететь поворот" и даже не один. Лучше всего делить рефакторинг на логические этапы. "Дешевые" по времени и ресурсу проверки можно и нужно запускать как можно чаще: компиляция, тесты, запуск приложение локально. Между крупными этапами желательно проводить регрессионное тестирование. И самое отличное поэтапный релиз рефакторинга, чтобы провести не только синтетические проверки, но самую важную "проверку продакшеном"

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

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

    В своем канале о разработке в стартапах делюсь опытом и рассказываю еще больше удачных примеров и факапов. Буду рад видеть каждого! Заходите!

    Всем удачного рефакторинга!

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Представлен сервис LearnXinYMinutes, который поможет освоить базовые команды и понять, как они используются в работе в разных языках программирования, фреймворках и программных средах, включая IDE. Внутри есть 55 ссылок (от баша и C до YAML) для изучения с русским переводом.

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии2
1
23 ...

Вклад авторов