ИИ — помощник, или враг разработчика? Мысли на тему. Часть 2
Сейчас время нейросетей. Не надо излишне обольщаться на тему их возможностей — они владеют (по крайней мере пока), только той информацией, которая использовалась при обучении, плюс, имеют возможность «подглядывать» в поиск и различные внешние источники с помощью MCP-серверов. Всё.
Но даже это снова очень серьёзный рывок вперёд. Вместо необходимости искать и анализировать информацию из нескольких источников мы сразу получаем готовое решение. Да, ещё с погрешностями и необходимостью ручных правок и проверок, но это уже качественно другой уровень разработки.
Вместо ручного написания алгоритмов или их комбинирования из готовых частей на первое место выходит навык промптинга — умения сформулировать свой запрос в виде, достаточно полном и понятном для нейросети.
Меняется ли что-то для разработчиков? Безусловно. Снова. Нам снова надо менять свой подход к разработке. Так же, как мы меняли его 30 лет назад, 20, 10... И будем менять опять ещё лет через 10. Это естественный процесс.
Надо ли забывать синтаксис и особенности низкоуровневой разработки? Нет. Как минимум, ещё несколько лет необходимо будет выверять за LLM код так же, как мы выверяем его за новичками. Но, давайте будем честными, машинные коды и Ассемблер многие уже забыли, а то и не знали. А создавать программы им это не мешает. Так же как сейчас есть специалисты, активно использующие машинные коды и Ассемблер в работе.
Рынок не схлопнется. К нему добавится ещё один слой. Кто-то из разработчиков будет и дальше по старому писать код в областях, новых для ИИ, где у него нет наработанной «базы ответов». А кто-то переключится на написание промптов, в разы повысив скорость решения прикладных задач.
ИИ — помощник или враг разработчика? Мысли на тему. Часть 1
Привет, это снова Саша Кузнецов, ведущий инженер-программист в Контуре. 🙌
Я из тех «ископаемых», которые начинали программировать ещё во времена, когда в качестве IDE выступал обычный текстовый редактор, а для хранения информации о синтаксисе команд использовались собственные записи в тетради. Я в то время учился в школе и на уроках учитель давала нам информацию о синтаксисе команд с распечаток. Если в тетради была ошибка — ты делал ошибку в коде и не мог понять, что идёт не так. Роль интернета играла городская библиотека (в местной книг про IT практически не было), «пинг» до которой был несколько часов только на дорогу, а ещё — скорость работы «поисковой системы» по бумажным книгам оставляла желать лучшего.
Потом я поступил в университет и «произошла магия» — там были IDE с подсветкой синтаксиса команд, подсказками, появляющимися по нажатию F1, и более-менее вменяемыми сообщениями об ошибках.
Это было круто! Просто зная название команды можно было получить описание её синтаксиса, а не хранить в голове информацию обо всех возможных комбинациях! Реальный прирост производительности сейчас по памяти сложно замерить, но скорость непосредственно набора команд выросла в разы. С решением задач в целом ситуация улучшилась не сильно — основным источником информации оставались бумажные книги. Разве что «пинг» существенно сократился — читальный зал находился в том же корпусе, в котором шли занятия. По сути, в момент этого скачка необходимость знания точного синтаксиса команд заменилась на необходимость знать только название команды.
Потом магия произошла снова — на кафедре появился интернет и что-то похожее на поиск. Это был ещё далеко не современный интернет с мощными поисковыми системами, но и совсем древние его версии я не застал. Но, главное, уже можно было найти информацию за рамками того, что было включено в поиск разработчиками IDE, или лежало в читальном зале. Речь шла уже не о синтаксисе команд, а о способах решения задач. Но не всегда. Это было время, когда в интернете ещё надо было суметь найти готовый код для редких видов сортировки массива, а за написание алгоритма БПФ (Быстрого Преобразования Фурье) заказчики на фрилансерских форумах были готовы выложить $500. И, тем не менее, это снова был качественный скачок — можно было быстро найти информацию по конкретной проблеме, не перекапывая кучу книг, в которых, возможно, могло быть «что-то близкое по теме». Скорость решения задач снова выросла, и снова значительно. Всё больше и больше задач стало переходить в категорию шаблонных. На этом этапе на первое место начал выходить навык «гугления». Основы синтаксиса остались необходимой базой, но умение правильно забить вопрос в поисковую строку стал определять очень и очень многое.
Новый скачок произошёл с развитием разработческих форумов по типу Stack Overflow. С момента их основания огромное число пользователей задавало вопросы и получало на них ответы. Можно было не просто что-то найти, но дать описание проблемы и получить решение, часто с примерами рабочего кода. А ещё к этому моменту существенно выросли как возможности поисковых систем, так и объём проиндексированной информации в них. Плюс, достаточно много книг перевели в цифровой формат. В результате стало возможным указывать не конкретное название нужного алгоритма или ключевые слова, а давать описание проблемы и получать подборку страниц с нужными ответами. В том числе на Stack Overflow и другие похожие форумы.
Теперь можно было нормально искать решение более-менее широко известных проблем по их примерному описанию и сразу получать примеры рабочего кода. Существенный рывок, значительно сокративший время на простые, рутинные задачи, и, одновременно, подаривший куче студентов возможность гуглить практически готовые лабораторные работы.
Фактически, именно в этот момент программирование стало общедоступным. А на первое место вышел навык комбинирования — умения собрать решение из похожих кусков кода, найденных в интернете.
26 марта эксперты AXENIX проведут вебинар, посвященный современной фронтенд архитектуре и гибким подходам к разработке.
🔘Разберем реализацию подхода Server Driven UI и рассмотрим, как эффективно интегрировать в него ИИ-агентов. 🔘Поговорим о долгосрочном здоровье проекта и преимуществах изоляции бизнес-логики от фреймворков на примере Feature-Sliced Design (FSD) и реальном опыте перехода на Effector. 🔘Проведем анализ гибридных решений: как из единой кодовой базы собирать и облачный сервис, и десктопное Electron-приложение с офлайн-режимом, преодолевая ограничения браузерной среды.
Участие в вебинаре бесплатное, необходимо только зарегистрироваться по этой сcылке и подключиться к нам 26 марта в 18:00.
Привет, Хабр. Делимся подборкой бесплатных уроков, которые пройдут в Отус в рамках набора на курсы. Опытные практики проведут занятия онлайн — на них вы сможете узнать больше о формате обучения и задать вопросы. Выбирайте тему и присоединяйтесь, чтобы пробустить свою карьеру.
СЕО Stripe Патрик Коллисон в подкасте TBPN рассказал, что программное обеспечение вообще‑то не должно производиться «впрок» и продаваться бесконечно. По его мнению, его стоит создавать по запросу — прямо в момент использования.
«Софт должен быть как пицца: его нужно готовить здесь и сейчас, в момент заказа», — объяснил Коллисон. До сих пор, по его словам, экономика ПО строилась по модели фиксированных затрат на разработку с последующей почти бесконечной монетизацией.
Но когда появляются издержки на работу ИИ-моделей и кастомную генерацию под конкретный запрос, всё меняется. Коллисон назвал это «не-валрасовским» режимом софта — то есть рынком, который уже не живёт по старым экономическим правилам. Эта аналогия отражает общий вопрос в индустрии: заменит ли ИИ традиционное ПО или будет всего лишь его дополнять.
17 марта вебинар про сокращение техдолга и уязвимостей в AI-разработке
Искусственный интеллект — это не только про скорость разработки и генерации кода, это еще про баги, уязвимости и технический долг. На вебинаре на примере LLM и VS Code будем разбираться, как встроить большую языковую модель в разработку так, чтобы результат был предсказуемый и безопасный. Настроим IDE под ваш стиль, включим защитные ограничения от небезопасных действий и мониторинг качества и безопасности кода с помощью SonarQube.
Если тезисно, то вебинар ответит на три вопроса:
как быстро запустить и контролировать генерацию кода с LLM в VS Code в enterprise-подходе;
как при работе с LLM выстроить правила, ограничения и стандарты: стиль, безопасность, предсказуемость результата;
как настроить ранний контроль качества и безопасности через SonarQube и использовать MCP-серверы для более качественного кода.
Ждем всех, кто внедряет LLM в ежедневную разработку, отвечает за стандарты и качество кода, выстраивает безопасные практики разработки, оценивает риски использования LLM или отвечает за управляемость и предсказуемость разработки.
📅 Когда? Вторник, 17 марта, в 11:00 мск.
📍Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы экспертам в прямом эфире.
Кстати, это третий вебинар цикла «Сценарии применения AI в корпоративной среде», который начался в феврале. Записи первого и второго вебинара есть на сайте.
Разговоры вокруг отечественного связного 💬 Макс не унимаются с момента его официального выхода. Блогеры по всему миру "изучают" безопасность приложения, выискивая, куда он "ходит" и какую "секретную" информацию передает. В основном, все инфоповоды крутятся вокруг изучения манифеста приложения и его разрешений в системе, не углубляясь в изучение сетевых пакетов, исходники и декомпилляцию. А я как раз тот ленивый инфобезник, который еще ни разу не высказался относительно данного вопроса, поэтому исправляюсь.
В прошлую пятницу на весь 🇷🇺 российский интернет прогремела новость: все фото из ваших чатов в Макс может увидеть любой человек по ссылке.
Когда в личный чат или в папку «Избранное» в мессенджере загружается изображение, для него генерируется статичная гиперссылка. Ее можно найти в коде страницы в веб-версии Max. Эта ссылка открывается с других браузеров и устройств без авторизации в мессенджере - обнаружили пользователи. Более того, фото по ссылке останется в открытом доступе, даже если его удалить из переписки в Max.
На лицо классический IDOR. Но если мы проанализируем ссылки на фотографии, которые генерирует Макс, мы обнаружим, что изображения по ним действительно доступны без авторизации. Часть адреса у разных изображений совпадает, однако они содержат различающиеся подстроки длиной не менее 21 символа (минимум 16^21 комбинаций), а значит получить доступ к таким изображениям простым перебором адресов невозможно. Более того, EDR и WAF вас уже на 1000 запросе за несколько секунд обнаружат и отправят отдыхать минут на 5. Ну а про хранение файлов "закон Яровой" никто не отменял.
А знаете, где еще применяется такая технология? В недавно (октябрь 2024 года) заблокированном мессенджере Discord. Все медиа файлы из приложения можно открыть в исходном качестве по прямой ссылке без регистрации и смс (именно поэтому его многие использовали как файлообменник, а платформа ограничивала размер передаваемого файла 8 мегабайтами). И, о новость, если потом данный файл удалить, он все равно остается доступным по прямой ссылке (см. прилагаемое видео).
Возвращаясь к Максу, не могу не обратить внимание, что его разработчиком является крупнейший IT-гигант Mail.ru. Я лично принимал участие в тестировании его на безопасность в период 2020-2021 годах и могу с уверенностью сказать, что там более чем секьюрно. Кроме того, опыт в обеспечении безопасности ВК, ОК и других массовых продуктов у них уже в генах.
Более того, у Макса есть Bug Bounty программа от Bi.Zone и за некоторые уязвимости там выплачивают до 10 миллионов рублей:
Получение доступа к приватной переписке определенных пользователей - 10 000 000 ₽ Получение доступа к местоположению определенных пользователей в реальном времени - 4 000 000 ₽ Получение доступа к телефонной книге определенных пользователей - 2 000 000 ₽
За год существования программы, было реально найдено 13 багов, за которые суммарно выплатили 873 тысячи. При указанной выборке я могу сделать вывод, что Макс достаточно безопасен, раз никто пока не смог сорвать джек-пот.
Поэтому, не верьте всему тому, что пишут в интернете: делите все минимум на 10. Ну и конечно, что попадает в интернет - остается в интернете, поэтому не забывайте про цифровую гигиену.
Команда разработчиков языка программирования Python визуализировала изменение кодовой базы интерпретатора CPython в привязке к основным событиям, произошедшим за 36 лет существования проекта. За последние 10 лет объём кода на языках Python и Си в CPython практически удвоился. Для подсчёта числа строк кода использовалась утилита cloc.
Разработка: Оркестровка агентов по ролевым кластерам (MSF)
Современная разработка всё чаще превращается в ансамбль агентов. ИИ‑системы становятся не просто инструментами, а полноценными участниками команд. Но как их организовать, чтобы они не превратились в хаотичный «зоопарк»?
Microsoft Solutions Framework (MSF) когда‑то предложил модель ролевых кластеров для проектных команд. Идея проста: каждая роль отвечает за свою часть жизненного цикла, а вместе они образуют сбалансированную спираль. Если перенести это на мир ИИ‑агентов, мы получаем оркестровку по ролевым кластерам.
🧩 Смешанная модель
Люди: держат контекст, принимают стратегические решения, задают намерения и проверяют ценность.
Агенты: берут на себя рутинные задачи, прозванивают целостность, генерируют код и тесты, моделируют сценарии.
Оркестровка по MSF: роли распределяются так, чтобы каждый виток спирали был сбалансирован — часть работы делает человек, часть агент.
🎭 Пример
Архитектор‑человек задаёт CASE‑скелет.
Vibe‑агент генерирует код по его намерению.
Тестировщик‑агент прогоняет сценарии.
Координатор‑человек принимает решение: «идём дальше» или «возвращаемся».
Бизнес‑агент симулирует нагрузку, а живой менеджер проверяет, совпадает ли это с реальными целями.
🔧 Пример: смешанная команда разработки по MSF
Ситуация: корпорация запускает новый сервис аналитики.
Роли и участники
Архитектор‑человек: задаёт CASE‑скелет, фиксирует блоки и связи.
Vibe‑агент: генерирует код по намерению архитектора.
Тестировщик‑агент: прогоняет юнит‑тесты и нагрузочные сценарии.
Координатор‑человек: принимает решение о переходе к следующему витку спирали.
Архитектор формулирует задачу: «Нужен модуль аналитики с API для отчётов».
Vibe‑агент генерирует код, интегрируя новый модуль в систему.
Тестировщик‑агент прогоняет тесты, выявляет узкие места.
Координатор‑человек решает: «фиксируем итерацию» или «возвращаемся».
Бизнес‑агент симулирует нагрузку: «При 10k запросов в минуту система держится».
Команда делает следующий виток спирали — добавляет новые функции.
Заключение
Это не «ИИ вместо людей» и не «люди без ИИ». Это ансамбль, где роли распределены между живыми и искусственными участниками. И именно такая смешанная команда даёт максимальную плотность: люди держат смысл, агенты — скорость и прозрачность.
CASE + Vibe + MSF + ИИ: Думаю, Будущая архитектура разработки
Олдфаги помнят CASE(Computer-Aided Software Engineering)-системы из 90-х — это была первая великая попытка «запрограммировать программирование». Тогда нам тоже обещали мир без кода. Не взлетело, потому что инструменты были кривые, а сложность систем росла быстрее, чем наши навыки моделирования. Сегодняшний ИИ — это CASE-система, которая наконец-то заработала.
Современная индустрия разработки ПО переживает переломный момент. С одной стороны — классические методологии, которые дают строгую архитектуру и прозрачные схемы. С другой — «вайб-кодинг», когда разработчик накидывает идеи в поток, а ИИ тут же генерирует код. Между ними — пропасть: Case методологии слишком формальные, вайб-кодинг слишком хаотичен.
Но если соединить CASE + Vibe, через ИИ и дополнить принципами MSF (Microsoft Solutions Framework), мы получаем новую парадигму — инженерию намерения.
CASE: скелет
CASE-модели позволяют фиксировать архитектуру системы: связи, блоки, уровни. Проблема в том, что переход от схемы к живому коду всегда был мучительным. Программисты ненавидели CASE за «рисование картинок», которые потом приходилось вручную превращать в тысячи строк.
Vibe Coding: энергия
Вайб-кодинг — это поток идей. Разработчик формулирует намерение, ИИ тут же выдаёт код. Это быстро и драйвово, но хаотично. Без структуры такие системы рассыпаются при первой нагрузке.
MSF: спираль
Microsoft Solutions Framework изначально создавался как гибкая методология управления проектами. Его спиральная модель идеально ложится на задачу балансировки изменений: каждый виток фиксирует достигнутое, проверяет целостность и готовит систему к следующему шагу.
ИИ: мост
ИИ становится универсальным переводчиком. Он умеет:
превращать вайб в CASE-модель;
разворачивать CASE в рабочий код;
делать обратный ход — извлекать архитектуру из существующего кода;
проверять целостность пирамиды при каждом изменении.
Что это даёт
Привязка к структуре: уникальный код перестаёт быть хаотичным, потому что у него есть CASE‑скелет.
Двухсторонняя верификация: можно не только генерировать код из схемы, но и извлекать схему из кода.
Спиральная разработка: каждый виток добавляет плотность — вайб даёт энергию, CASE фиксирует, ИИ проверяет.
Блочная архитектура: вместо переплавки всего кода можно пересобирать подсистемы как Лего, сохраняя пирамиду целостности.
Прогон стратегий: структура позволяет моделировать изменения и балансировать нагрузки до внедрения.
Эффект для индустрии
Для программистов: исчезает «тайное знание», код становится прозрачным и управляемым.
Для корпораций: хаос уходит, появляется возможность прогнозировать реструктуризации и управлять динамикой изменений.
Для поля: это новый уровень плотности — разработка превращается в управление реальностью через блочные пирамиды.
Заключение
CASE + Vibe + MSF + ИИ — это не просто очередная методология. Это живая архитектура, где код перестаёт быть бетоном и становится кристаллом: он держит форму, но готов перетекать в новую, когда меняется намерение.
Эта структура позволяет не только писать программы, но и прокатывать стратегии, балансировать нагрузки и управлять корпоративной эволюцией.
И именно к этому программистам и корпорациям придётся готовиться. Потому что хаос больше не будет оправданием. CASE + Vibe + MSF + ИИ превращают хаос в прозрачную пирамиду, где каждая ошибка становится видимой, а каждое верное решение — мгновенно масштабируется.
Эра «писать код руками» заканчивается. Наступает эра «инженерии намерения». И вопрос теперь не в том, «заменит ли ИИ программистов», а в том, кто сумеет стать архитектором этой новой реальности — а кто останется в прошлом.
GitHub визуализировали в цифровой город в проекте gitcity. В рамках проекта представлен сайт, на котором можно летать по «городу», где каждое здание это аккаунт разработчиков. Высота небоскребов = количеству коммитов. Летая по городу, можно искать интересные и популярные аккаунты, либо находить что-то новое и недооцененное.
С таким вопросом разработчиков периодически сталкиваюсь. Добавлю контекста. Работаю AppSec инженером в финтехе. Когда нахожу уязвимости — сообщаю разработчикам. Среди прочего - доношу мысль: если в данном случае можно смягчить потеницальные последствия угрозы через WAF — это не значит, что уязвимость не нужно исправлять в приложении. Нередко разработчики спорят. Примерный диалог:
— Ну, есть же WAF — на нём и делайте фикс, зачем нам-то в код лезть? WAF — он же для того и нужен, чтоб уязвимости устранять. — WAF — не панацея: на нём мы сделаем правило. Но это не значит, что в самом приложении не нужно устранять. — Почему? — Например, потому, что практически любой WAF можно обойти. — А зачем покупаете WAF, который можно обойти?
Отвечаю так: потому что WAF пишут такие же разработчики, как Вы, и они тоже иногда ошибаются (как и все люди). Некоторые особо настырные разработчики желают доказательств, что WAF можно обойти. В целом я солидарен, что практика "а ты докажи" в управлении уязвимостями - не очень хороша. Но, если есть под рукой на что можно быстро сослаться - можно это сделать. Я ссылаюсь на эту статью. В моей практике были случаи, когда WAF из-за сбоя переставал применять правила на несколько дней. Т.е. трафик через него шёл, сервис за WAF продолжал быть доступным. Но, правила на WAF не работали — будто их и нет.
Эта история в очередной раз показывает: насколько бывают различны в оценке ситуации разработчики и "безопасники". Более интересный вариант — когда разработчики считают, что только они могут решать: что является уязвимостью, а что — нет (подробнее об этом я писал в статье "Как я зарегистрировал CVE и разозлил вендора").
Там описал утилиту sumr, которая саммаризирует файлы проекта через LLM и выдаёт дерево с однострочными описаниями. Коротко: запускаешь sumr в корне — и она выдает структуру папок и файлов с кратким описанием каждого элемента. Это помогает AI-агенту быстро понять, что где находится, без необходимости читать весь код.
Что добавил с тех пор:
Теперь инструмент держит кэш у себя и не трогает ваш проект.
Добавил watch mode. Достаточно запустить sumr watch или sumr watch --detach на папке с проектом — и утилита начинает следить за изменениями. Появился новый файл или изменился существующий — саммари обновляется автоматически. Не нужно каждый раз вручную перезапускать. Запустил один раз в фоне и забыл.
Ещё добавил два флага: -p для указания конкретной папки и -d для ограничения глубины дерева, как tree -L. Их можно комбинировать:
sumr -p ./src # начать с конкретной папки
sumr -d 2 # показать только 2 уровня глубины (как tree -L 2)
sumr -p ./src -d 1 # папки верхнего уровня с саммари
После запуска watch в инструкцию CLAUDE.md добавил рекомендацию:
* Всегда начинай ЛЮБУЮ задачу с команды 'sumr -p ./... -d ...' для получения общей структуры проекта и понимания, где что находится.
Вот примеры использования команды sumr:
sumr -p ./src # начать с конкретной папки
sumr -d 2 # показать только 2 уровня глубины (как tree -L 2)
sumr -p ./src -d 1 # папки верхнего уровня с саммари
И это действительно работает на моих проектах - буквально 1 read корня - 2 read подпапки - старт выполнения задачи :)
В октябре 2025 года в сети распространился ролик,в котором девушка расплачивается улыбкой, используя ... фотографию своего знакомого. Комментаторы, как обычно, разделились на 2 лагеря: на обывателей, которые чихвостят "систему", и технических специалистов, утверждающих, что это фейк. Ну а мы давайте теоретически разберемся, что это и как такое в принципе возможно.
«Оплата улыбкой» — это сервис Сбербанка, который позволяет оплачивать покупки на кассах в магазинах с помощью биометрии. Проект был запущен летом 2023 года как альтернатива ушедшим с рынка платежным сервисам... Для оплаты нужно посмотреть в камеру, которая распознает изображение лица и сопоставляет его с уникальным номером, привязанным к биометрическим данным. Этот номер также привязан к счету карты. Если данные совпадают, оплата проходит. (с) РБК
Вообще, распознавание лиц в биометрических системах обычно работает как конвейер из нескольких шагов. Верхнеуровнево порядок следующий:
Набор камер получает кадр лица
Алгоритм находит лицо на изображении (рамку вокруг лица)
Система ищет ключевые точки (глаза, нос, уголки рта) и “выравнивает” лицо
Нейросеть преобразует лицо в вектор признаков (эмбеддинг) — набор чисел, который компактно описывает уникальные черты
Дальше считается “близость” двух векторов, например, косинусное сходство или евклидова дистанция: если сходство выше порога, то доступ/оплата разрешена.
Системы безопасности в таких устройствах настроены на защиту от подстановки фотографий, масок, а также добавляют проверки на "человечность". Так, системы анализируют блики и глубину, микродвижения, отражения от ИК-камера (кожа и материалы отражают по-разному); определяют объемность и т.д. Поэтому, в профессиональных системах биометрии обычно используется нескольких камер: • обычная RGB: получение изображения лица • ИК: даёт надёжную проверку "человечности" • глубина (3D/ToF): уверенное отделение “лица” от плоской подделки.
Возвращаясь к видео: если мы внимательно изучим аппаратную часть представленного PoS-терминала (можем даже сходить в ближайший магазин и физически его потрогать), то обнаружим только 1 обычную RGB камеру для селфи. В таких обстоятельствах программно-аппаратный комплекс не может провести дополнительные вышеуказанные проверки и надеется только на изображение. В таких обстоятельствах, как показывает международная практика, система может верифицировать злоумышленника по чужой фотографии, видео или даже маске.
При изложенных обстоятельствах, я бы предположил, что видео более похоже на правду, чем на фейк и не рекомендовал бы пользоваться функцией "Оплатить улыбкой" пока все терминалы оплаты не будут оснащены современным техническим оборудованием.
Корректные ссылки из приложения. Раньше ссылки на статью или каталог копировались как https://app.gram.ax/repo-name.... Теперь приложение подставляет домен вашей компании (где развернут веб-редактор), поэтому ссылки ведут в приложение в вашем контуре.
Фильтр по файламв поиске. Добавили режимы «Без вложений», «С вложениями» и «Только во вложениях», чтобы искать не только по тексту статей, но и по содержимому PDF и DOCX-файлов.
Другие улучшения:
Автоматическое решение конфликтов в комментариях. Если несколько пользователей одновременно отвечают или редактируют один и тот же комментарий, изменения корректно объединяются и не ломают комментарии. В связи с этим в «Проверить на ошибки» появился пункт «Комментарии» — он показывает статьи с комментариями, которые не привязаны ни к одному блоку.
Улучшения поиска:
Поиск стал быстрее. Ускорили примерно в 2 раза и оптимизировали индексацию.
Обязательные слова в запросе. Добавили оператор +: поставьте его перед словом или фразой, и они точно будут учитываться в результатах.
Окно поиска по статье сохраняет состояние. При переходе между статьями окно закрывается, но при повторном открытии сохраняется введенный текст (пока приложение открыто).
ИИ-поиск стал точнее. Мы улучшили RAG, поэтому ответы в поиске стали более релевантными и полезными. Подробнее — в статье на Хабре.
Инлайн-тулбар в комментариях, сниппетах и шаблонах. Теперь над полем ввода комментария доступно базовое форматирование: жирный, курсив, код и вставка ссылок. А в редакторе сниппетов и шаблонах появился полный набор инструментов, включая редактирование таблиц.
Превью Excel-файлов. Теперь Excel-файлы можно открыть в режиме предпросмотра: при клике отображается превью в модальном окне.
Быстрая публикация. Список изменений загружается в 3 раза быстрее.
Автоматическое обновление ссылок при редактировании. Если вы меняете текст ссылки и он совпадает с ее адресом, адрес тоже обновится. Если текст и адрес разные — ссылка не меняется.
Сохранение позиции прокрутки между статьями. Если вы перешли в другую статью и вернулись назад, статья откроется там, где вы остановились, а не в начале.
Версия приложения в деталях ошибки. Это помогает быстрее понять, на какой версии возникла проблема и быстрее ее воспроизвести.
Исправление уязвимостей. Теперь перед выпуском новых версий мы автоматически проверяем используемые библиотеки на известные уязвимости.
Как перенести AI-платформу из‑за рубежа в Россию и не переписать код: кейс Worken AI
👨💻 Что за компания
Worken AI — разработчик одноименной платформы, на которой пользователи создают или выбирают готового виртуального сотрудника — Виртса. Такой сотрудник становится частью отдела продаж, поддержки или HR: он отвечает на заявки, обрабатывает заказы или поддерживает в адаптации новых членов команды.
Изначально проект строился на зарубежном облаке с прицелом на глобальный рынок, используя cloud native подход: сервисы платформы работают в Docker-контейнерах, а базы данных и хранилища — на управляемых облачных сервисах.
🚀 Задача
Когда пришли первые российские клиенты с повышенными требованиями к 152-ФЗ и локализации персональных данных, встал вопрос: как быстро и безболезненно развернуть локальный контур в России, не переписывая архитектуру? Задача звучала так:
поднять backend-сервисы и вспомогательные компоненты платформы в Docker-контейнерах, оркестрируемых Kubernetes;
отдельно разместить frontend-часть (веб-интерфейс) платформы;
подключить управляемую СУБД для транзакционных данных и векторного поиска по базам знаний клиентов;
организовать объектное хранилище для документов и других файлов, на основе которых строятся векторные представления (Vector Store) пользователей Worken AI.
Разработчику было критично, чтобы облако одновременно соответствовало требованиям 152-ФЗ и предлагало современный стек managed-сервисов и AI-инструментов.
☁️ Что сделали
Сохранив cloud native подход, Worken AI развернул российский контур платформы на управляемых сервисах платформы Cloud.ru Evolution. Основные backend-сервисы и API-шлюзы разработчик вынес в кластеры Evolution Managed Kubernetes. Для хранения данных пользователей и векторных представлений документов Worken AI использует Evolution Managed PostgreSQL, управляя только схемой базы и запросами приложения. Файлы баз знаний, вложения и резервные копии размещаются в S3-совместимом объектном хранилище. Автоматизации на базе n8n и ряд вспомогательных сервисов разработчик развернул на бесплатных виртуальных машинах. Отдельные контейнерные приложения, которым не нужен полноценный Kubernetes-кластер, запущены в Evolution Container Apps.
🦾 Что получили в итоге
Все ключевые сервисы российского контура платформы Worken AI работают в российском облаке: входящие запросы пользователей проходят через frontend- и backend-сервисы, обращаются к управляемой базе данных и объектному хранилищу, а затем — к выбранным AI-моделям.
В планах сделать работу с моделями еще проще и ускорить вывод новых сценариев в продакшен. Это возможно в цифровой среде AI Factory, где строится единый контур: готовые LLM с OpenAI-совместимым API, сервисы для инференса и дообучения собственных моделей, управляемые Kubernetes-кластеры, объектное хранилище и управляемые СУБД.
Благодаря этому Worken AI может развивать Виртсов одновременно для глобального рынка и российских заказчиков на привычном cloud native стеке, удерживая данные и модели в инфраструктуре, соответствующей требованиям 152-ФЗ и уровню защищенности УЗ-1.
Смертельный марш: почему ваш проект обречен и как в этом выжить
Если вы работаете в разработке, то рано или поздно вы оказываетесь в ситуации, когда дедлайн был вчера, бюджет сократили до стоимости обеда, а команда напоминает выживших после кораблекрушения. Эдвард Йордан в своей классической книге назвал это «Смертельный марш. Выживание в безнадежных проектах» (Death March).
Самое важное, что нужно понять: это не досадный сбой менеджмента. Это — стандартная, осознанная и часто эффективная (с точки зрения бизнеса) модель работы.
Генезис катастрофы: Политика, политика и еще раз политика
Йордан честен: большинство безнадежных проектов рождаются не из-за технических сложностей. Они рождаются из-за того, что кто-то наверху играет в свои игры. Маркетологи наобещали невозможное, чтобы закрыть сделку; менеджеры побоялись сказать «нет» вице-президенту; а высшее руководство живет в мире, где девять женщин могут родить ребенка за один месяц.
В этой среде вы — не просто разработчик, а участник социальной драмы. Вы знаете, что проект обречен. Вы знаете, что обещания руководства — пустой звук. Вы принимаете эти правила игры не из наивности, а потому что это текущая реальность, в которой нужно как-то функционировать.
Классификация неизбежного: В каком аду вы находитесь?
Йордан делит безнадежные проекты на четыре типа. Понимание того, где вы, определяет вашу стратегию поведения:
«Невыполнимая миссия» (Mission Impossible): Шансы на успех — 1 к 10, но команда верит, что они избранные. Это чистый адреналин. Если получится — вы станете легендами компании. Если нет — вы хотя бы попробовали прыгнуть выше головы.
«Камикадзе» (Kamikaze): Здесь нет веры в успех. Есть только осознание финала. Но проект дает доступ к технологиям, которые сделают ваше резюме золотым. Вы идете на дно вместе с кораблем, но с полными карманами ценного опыта и крутым стеком в портфолио.
«Отвратительные» (Ugly): Самый грязный вариант. Вы — просто «сжигаемый ресурс». Менеджеру нужно дотянуть до конца квартала, получить бонус и уволиться, оставив после себя выжженную землю и дергающихся от каждого уведомления сотрудников. Здесь нет места героизму, только эксплуатация.
«Самоубийственные» (Suicidal): Проект мертв, смысла нет, прогресса нет. Все сидят и ждут, когда здание наконец рухнет, просто потому что страшно или лень увольняться. Это чистая стагнация.
Принцип «Сортировки» (Triage)
Термин заимствован из военной медицины. Когда раненых слишком много, врач не спасает всех — он выбирает, на кого тратить ресурсы. В «Смертельном марше» происходит то же самое.
Вы понимаете, что 80% функционала, о котором мечтает заказчик, никогда не будет реализовано. Профессионализм здесь заключается в том, чтобы сосредоточиться на тех 20%, которые позволят системе выдать хоть какой-то результат в день релиза. Всё остальное — белый шум и декорации. Вы просто игнорируете второстепенные задачи, не тратя на них ни капли энергии, даже если менеджер бьется в истерике.
Эстетика процесса
Безнадежный проект — это странное место. Когда результат предопределен (провалом), у вас исчезает страх перед этим самым провалом. Вы становитесь свободны. Вы можете писать код так, как считаете нужным, не оглядываясь на KPI и бесконечные совещания о «светлом будущем».
Смертельный марш — это не про успех продукта. Это про вашу личную устойчивость в условиях тотального хаоса. Пока вы сохраняете дистанцию и понимаете, что это просто роль в плохой пьесе, вы остаетесь профессионалом.
P.S. Циатата:
Когда я впервые услышал эти истории [о неразумном корпоративном поведении], я пришел в недоумение, однако после тщательного анализа я разработал сложную теорию, объясняющую такое странное поведение. Она заключается в следующем: люди - это идиоты.
Включая меня. Идиоты все, не только люди с низкими интеллектуальными показателями. Единственная разница между нами заключается в том, что мы идиоты по отношению к различным вещам в различное время. Неважно, насколько вы остроумны и находчивы, все равно большую часть дня вы проводите как идиот.
В минувшею пятницу, 26 февраля, на площадке Кибердома прошла премьера фильма «Как получить доступ ко всему: реверс-инжиниринг».
Исходя из описания под трейлером, этот
Документальный фильм расскажет, как люди учатся вскрывать сущность комплексных технологических систем. Разбирая устройство или технологию по частям, мы получаем доступ к их структуре и замыслу создателей. Эксперты в области обсудят реверс-инжиниринг в СССР и России – от промышленности после Первой мировой до искусственного интеллекта и «киберпанка», который ждет нас в ближайшем будущем.
Я, к сожалению, на премьеру попасть не смог по причине конфликта в графике. Поэтому, чтобы "изучить материалы по теме" мне пришлось посмотреть фильм в четверг, то есть за день до его официальной премьеры! Enumeration is the key (c) OffSec, и если хорошенько прошерстить интернет, то можно найти и посмотреть документалку без регистрации и СМС на официальном портале PREMIER: Как получить доступ ко всему: реверс-инжиниринг.
Естественно, не буду спойлерить детали, однако скажу, что фильм снят очень качественно, а в создании участвовали эксперты из Positive Technologies, «Лаборатории Касперского», Т-Банка, «Иви», SR Space, Музея криптографии, «Росатома», Elverils, интернет-проекта «Я помню» и другие неравнодушные люди и организации. Как посмотрите, приглашаю вас в комментарии, чтобы обсудить увиденное и высказать свои мысли по поводу фильма!
Как перестать быть центром всех решений и не потерять контроль :)
Когда команда растет, руководитель постепенно становится обязательной точкой во многих процессах. Кажется, все логично, ведь так быстрее и надежнее. Проблема становится заметной, когда появляется вопрос: что будет, если руководитель на время выпадет из работы?
С этим столкнулась Катя, руководитель операционного отдела. Консультации, планирование дежурств и часть сложных решений постоянно замыкались на ней. Это замедляло работу, снижало самостоятельность команды и создавало риски на случай ее отсутствия.
Попросили Катю рассказать, как она пересобрала процессы так, чтобы решения не требовали ее обязательного участия, а система оставалась управляемой и прозрачной.
1️⃣ Что происходит, когда процессы держатся на одном человеке
Я пришла в Naumen в 2015 году. В 2020 у меня появилась первая команда из трех аналитиков. Через год — уже две команды. Сейчас это три команды: три тимлида, два техлида и двадцать аналитиков.
У нас закрывались задачи, клиенты получали ответы. Но по факту консультации, планирование дежурств и нестандартные решения замыкались на мне. И чем больше становилась команда, тем сильнее росла эта зависимость.
2️⃣ Три страха, которые мешают передавать процессы
Когда я решила что-то менять, сначала пришлось разобраться со своими страхами:
Я стану не нужна
Перегружу команду
Команда что-то сделает не так
Самым тяжелым оказался последний страх. Руководителю трудно осознать, что кто‑то может принять решение иначе. Но иначе не значит хуже.
А еще я поняла: если процесс живет только при моем участии — это слабое место, а не моя ценность.
3️⃣ Как мы перестроили систему консультаций
Раньше все было просто: любой сложный вопрос — ко мне. Я объясняла одно и то же разным людям, и это отнимало все больше времени.
Поэтому мы разложили консультации на типы: технические, процессные, бизнесовые. Дальше я посмотрела на реальную экспертизу внутри команды и распределила роли.
Опытные аналитики по каждой заявке
Скриптолог дня для базовых техвопросов
Техлиды для сложных техвопросов
Третья линия как финальная инстанция
В этой схеме больше нет обязательного шага «спросить у Кати» :)
Важно, что я не просто объявила новые правила. Я объяснила команде, зачем им это,и дала возможность сказать, если что‑то не работает.
В результате консультации ускорились, экспертиза выросла, а я перестала быть узким горлышком.
4️⃣ Как мы перестали тратить часы на планирование дежурств
Каждую пятницу я собирала пожелания в чате и сорок минут составляла график, учитывая личные обстоятельства и роли. Когда меня заменяли, на это уходило по два-четыре часа.
Теперь оставила себе только рамки: сколько слотов нужно закрыть и какие роли должны быть в дежурствах. Все остальное передала команде.
Мы сделали общую таблицу, где каждый выбирает удобные слоты. Если остается неудобное время, люди договариваются между собой. Через несколько минут после сообщения в пятницу график уже заполнен.
Я больше не держу в голове десятки нюансов — команда решает их самостоятельно.
5️⃣ Как быть с кризисными ситуациями
Передавая процессы команде, важно понимать: это не означает, что руководитель больше не нужен. В кризисной ситуации именно руководитель остается тем, кто подключается, принимает решения и берет на себя ответственность. Но разница в том, что кризис перестает быть повседневностью.
У нас был показательный случай: у команды одновременно отсутствовали тимлид и техлид. Младший аналитик пришел ко мне и сказал, что сам проведет встречу по планированию, потому что понимает, что процесс не должен останавливаться.
В этот момент я поняла, что эта система — уже часть нашей культуры, и она работает. Команда не ждет указаний — каждый понимает, что он часть процесса и может на него влиять.
Я не считаю этот подход универсальным. Но если есть процесс, который держится только на вас, это повод задать вопрос: это стратегическое решение или просто привычка?
