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

Моему деду восемьдесят два. Инженер, пятьдесят лет стажа, из них последние пятнадцать — в почётной должности «внук, почини интернет». Excel он уважает, мессенджеры терпит, а важные электронные письма распечатывает и складывает в шкаф — «чтобы было». Прошлой зимой он посмотрел по телевизору сюжет про искусственный интеллект и спросил меня, правда ли, что «эта штука пишет документы». Я сказал: правда. Он сказал: покажи. Дальше начались три месяца полевого эксперимента, из которого я вынес больше, чем из иных рабочих проектов, — потому что смотреть, как с технологией разбирается человек без наших рефлексов, оказалось поучительнее любых статей про UX.

Первая попытка провалилась образцово. Я открыл ему чат — тогда это был ChatGPT через мой аккаунт, но с тем же успехом это мог быть GigaChat или что угодно ещё, — развернул экран и гордо сказал: пиши что хочешь. Дед посмотрел на пустое поле, потом на меня и задал вопрос, который я теперь считаю главным вопросом всей потребительской ИИ-индустрии: «А что писать-то?» Я ответил худшим из возможных способов: «Да что угодно!» Он пожал плечами, набрал двумя пальцами «здравствуйте» и получил в ответ три абзаца доброжелательной пустоты. На этом сеанс закончился. «Болтливая, — резюмировал он. — Как справочная, только справок не даёт».

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

Задача выглядела на полчаса: найти команде сервис для расшифровки созвонов с заказчиками. Требования скромные — русская речь, разделение по голосам, выгрузка текстом, вменяемая политика по данным. Единственное ограничение мне выставили сами коллеги: «только не по рекламе из телеги, найди по-человечески». По-человечески — это, видимо, по каталогам. Через неделю я вынырнул из этих каталогов с готовым решением, лёгкой контузией и наблюдениями, которыми хочу поделиться, потому что сам жанр «каталог ИИ-инструментов» оказался устроен куда занятнее, чем я думал.

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

Экономика жанра вообще главный ключ к его пониманию. Каталоги живут с размещений, подписок разработчиков и «фичеринга» — платного поднятия в выдаче. Это не делает их бесполезными, но означает простую вещь: порядок карточек отражает не качество сервисов, а структуру чьих-то маркетинговых бюджетов. У Futurepedia и Toolify та же модель, плюс вокруг каждого выросла ферма SEO-статей формата «15 лучших нейросетей для X в 2026 году», которые, по всем признакам, пишутся теми же нейросетями. Круг замкнулся: ИИ генерирует обзоры ИИ-сервисов, чтобы люди находили их через поиск, наполовину состоящий из таких же обзоров.

Redis долго был понятным выбором: BSD-лицензия, можно использовать почти где угодно. После смены лицензии в 2024 году всё стало сложнее: RSAL, SSPL, AGPLv3, Valkey, форки и вопросы к юристам.

В статье рассматриваю этот вопрос со стороны обычных продуктовых команд, а не облачных провайдеров. Если Redis у вас внутри как кеш, очередь или для сессий, что реально меняется, где начинаются риски и что сегодня разумнее выбрать - Redis 8, Valkey или другой Redis-compatible вариант.

Недавно я объяснял стажёру, как правильно формулировать запрос к языковой модели, и на середине фразы «сначала задай роль, потом контекст, потом формат ответа» поймал дежавю. Ровно этими же интонациями мне самому когда-то объясняли bash: сначала команда, потом ключи, потом аргументы, и не дай бог перепутать порядок. Прошло тринадцать лет, индустрия совершила несколько революций, а я снова диктую человеку синтаксис невидимого языка, у которого нет ни автодополнения, ни подсветки ошибок, ни даже гарантии, что вчерашняя команда сегодня сработает так же.

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

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

Графические интерфейсы победили командную строку не потому, что были мощнее. Они были заведомо слабее: любой GUI показывает лишь подмножество того, что умеет система. Победили они потому, что сделали возможности видимыми. Кнопка сообщает: меня можно нажать. Меню перечисляет всё, что здесь вообще бывает. Дон Норман называл это аффордансами — свойствами объекта, которые сами подсказывают способ обращения с собой. Дверная ручка-скоба говорит «тяни», пластина — «толкай», и когда дизайнер путает одно с другим, получается «дверь Нормана», об которую бьются поколения посетителей. Так вот, GUI — это система, целиком собранная из правильных дверных ручек. Порог входа упал на порядок, компьютеры ушли в массы, а командная строка осталась профессионалам — как более мощный инструмент для тех, кто готов платить за мощность обучением.

Мы в Диасофт несколько лет назад начали строить Digital Q.DevOps — внутренний конвейер сборки, тестирования, доставки и развёртывания, — и сейчас через него проходит больше 2000 развёртываний в сутки. На прошлой неделе собрали внутренний митап с разработчиками, тестировщиками и DevOps-инженерами, чтобы честно разобрать, что в продукте получилось, что до сих пор болит, и куда мы движемся.

Делимся опытом автоматизации реферальной программы: как мы ушли от хаотичного сбора рекомендаций на вакансии и запустили собственный продукт для корпоративного портала — цифровой сервис «Рекомендовать кандидата». В результате увеличили конверсию закрытия вакансий по внутренним рекомендациям до 35%.

Узнайте, как получить бесплатные фото и подписку за 1 рубль!

Студийная фотосессия стоит 5–15 тысяч рублей за час — плюс макияж и обработка. Бесплатные ИИ-генераторы вроде бы решают проблему, но на деле лепят водяной знак на пол-лица, после пары генераций режут разрешение до 512×512 и требуют регистрацию с почтой и телефоном.

Новый сервис Фотостудия SpeShu.AI решает эти проблемы. Фотосессия по вашему фото через ИИ, по одному селфи, с оплатой в рублях. Причём фотосессии — лишь одна из частей сервиса. Вам доступны ещё 2 топовые функции!

Сколько раз вы слышали тезис о том, что в Java Reflection тормозит, и лучше его избегать. Насколько это правда?

В новом переводе от команды Spring АйО рассмотрим, почему производительность reflection-а имела проблемы.

Без сервисной системы не построить качественную техподдержку — это база. Но в промышленных компаниях обслуживание выходит далеко за рамки ИТ. Требуются ли в этом случае дополнительные системы? Не обязательно — и это доказывают пять крупных производственных компаний от Росводоканала до Щербинского лифтостроительного завода. 

Какие результаты они получили и как именно применяют service desk в промышленности — разбираем в статье.

Linux даёт мощные механизмы безопасности уровня ядра — seccomp, SELinux и AppArmor, — которые ограничивают возможности контейнеризированных рабочих нагрузок. Если коротко: seccomp фильтрует системные вызовы процесса, SELinux и AppArmor накладывают мандатные политики доступа к файлам, сети и возможностям. Каждый из них работает через профили, которые описывают разрешённое поведение, но писать, распространять и поддерживать такие профили вручную утомительно и легко ошибиться.

Security Profiles Operator (SPO) снимает эту боль: профилями безопасности можно управлять как пользовательскими ресурсами Kubernetes, записывать их с работающих нагрузок и декларативно привязывать к подам.

С выходом v1.0.0 Security Profiles Operator переводит все восемь своих API типа Custom Resource Definition (CRD, определение пользовательского ресурса Kubernetes) на версию v1. Это первый стабильный релиз проекта, подкреплённый сторонним аудитом безопасности, полным циклом работ по усилению защиты и путём миграции без простоя с любой предыдущей версии API.

Команда VK Cloud перевела статью о том, как проект Security Profiles Operator за шесть лет довёл свои API до версии v1, прошёл сторонний аудит безопасности и теперь влияет на развитие самого Kubernetes. Это будет полезно тем, кто отвечает за безопасность кластеров — DevOps- и SRE-инженерам, специалистам по ИБ и разработчикам, которые пишут профили seccomp, SELinux и AppArmor для контейнеров.

Термин «вайб-кодинг» появился в начале 2025 года как полушутка, а к середине 2026-го стал полноценной методологией: вы описываете задачу обычным языком, нейросеть для генерации кода выдаёт работающий результат, а дальше идут итерации — уточнить промпт, добавить деталей, попросить исправить баг. Заучивать синтаксис и часами читать документацию больше не обязательно: порог входа в разработку упал до умения внятно формулировать мысль.

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

Привет, Хабр! На связи Дмитрий Бондарев, я backend-разработчик Авито — занимаюсь проектами на стыке разработки и машинного обучения. В первой части этого материала мы обратились к истокам API и существующим ограничениям интерфейса в работе с агентами.

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

Однажды я попросил ChatGPT нарисовать организационную диаграмму. Знаете, что он сделал? Написал ASCII-арт :(, мило, но не то.

Я хотел настоящую диаграмму: с прямоугольниками, стрелками, цветами, зумом и возможностью подвигать элементы руками. То есть не картинку в ответе чата и не ASCII, а нормальный интерактивный canvas.

Можно было взять LangChain, MCP, готовый agent framework и спрятать всё за несколькими слоями абстракций. Но мне было интересно другое: что минимально нужно, чтобы LLM стала агентом, который не просто отвечает текстом, а меняет состояние внешнего мира?

В моём случае этим “внешним миром” стал Excalidraw canvas.

Я написал маленький агентный цикл с нуля. Важное уточнение: не весь проект, конечно, а именно ядро агента — около 100 строк. Вокруг него есть сервер, model layer, WebSocket, UI и куча мелких инженерных деталей. Но сама “агентность” живёт именно в этом цикле. Без LangChain, без MCP, без специальных библиотек для “агентности”.

Спойлер: агент не просто нарисовал оргчарт. В одном из прогонов он нарисовал его, потом посмотрел на результат, понял, что стрелки сделаны неправильно, удалил их, пересоздал с правильными привязками и только после этого сказал “готово”.

Всем привет! Мы — команда Облака Mail: редакторка Наташа, дизайнер Саша и исследовательница Лена.

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

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

После нагрузочного тестирования k6 формирует отчет с десятками метрик. Но сам по себе этот отчёт ещё не говорит, где находится проблема и действительно ли приложение стало работать хуже. Одни и те же значения могут указывать на разные причины: медленную базу данных, особенности работы Kubernetes, проблемы сети или обычный шум тестового стенда.

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

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

Как вам такая идея: может ли реальность содержать больше измерений, чем три пространственных направления, которые мы ощущаем каждый день? Это звучит как тот вид мысленного эксперимента, который больше подходит для научной фантастики. Однако в физике такая идея не заканчивается на спекуляциях. Напротив, она становится началом серьёзного исследования.

Физики задают сложные вопросы. Помогут ли дополнительные измерения решить существующую проблему? Можно ли их включить в математическую модель, которая и так уже довольно неплохо описывает природу? Позволяют ли они делать предсказания, которые можно проверить экспериментально? И, самое главное, существуют ли какие-либо наблюдения, которые в конечном итоге могли бы подтвердить — или опровергнуть — эту идею?

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

Статья про то, как AI-агенту дали знание о дизайн-системе, чтобы он перестал придумывать несуществующие компоненты и начал верстать из того, что реально есть в проекте.

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

Внутри: Figma MCP, свой DS MCP, React, Jetpack Compose и SwiftUI, поиск по компонентам, ChromaDB, RAG, embeddings, препроцессор для описания дизайн-системы, грабли с чтением файлов, шумом в контексте, устаревающим SKILL.md и честное сравнение подходов по tool calls, токенам и результату.

Заходите, читайте и рассказывайте, как вы решаете эту проблему у себя ❤️

ИИ задеплоит за тебя. А дежурить кто будет?

На днях в чате разработчиков мне написали: «Я описал Клоду проект с телефона, он собрал MVP и сам задеплоил на Firebase. В деплой я вообще не лез. Зачем теперь нужны сервисы деплоя?». Вопрос честный, и короткий ответ на него: незачем. Если ИИ развернул ваш проект и он работает, всё отлично, расходимся. Длинный ответ интереснее.

День первый: тут ИИ действительно победил

Признаю без оговорок: настройка сервера перестала быть проблемой. Любой ассистент напишет docker-compose, поднимет nginx, выпустит сертификат и объяснит каждую строчку. Гайды, по которым мы страдали вечерами, превратились в один промпт. Это прогресс.
Проблема в том, что настройка и была самой лёгкой частью. Она просто казалась сложной, потому что делалась один раз. А проект живёт месяцы.

День второй и все последующие

Что происходит с сервером дальше, из личного опыта за годы деплоев:

Сертификат истёк в пятницу вечером. Пользователи видят «соединение не защищено», вы узнаёте об этом в понедельник от клиента.

За одну ночь боты сделали 9999 попыток подобрать пароль к SSH. Сервер без защиты для интернета выглядит как открытая дверь, и в неё правда ломятся, обычно в первые же сутки.

Docker Hub перестал отвечать с российских IP. Деплой, который работал год, умер в момент пересборки образа. Кто не прописал зеркала реестра заранее, чинил это в панике на проде.

Диск кончился: каждая пересборка образа оставляет слои, за пару месяцев они съедают всё, и сервер встаёт с «no space left on device».

Я не пытался сделать «приватный мессенджер» и вообще не думал про слежку и прослушку.

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

Ниже — как так получилось, где у этой «невозможности» честные границы, и почему всё держится на одном-единственном решении.

Всем привет! На связи Максим Митрофанов, руководитель ML-команды Application Security в Positive Technologies.

Недавно мы выпустили нейросеть MOLOT и описали архитектуру решения в техрепорте на arXiv. Эта статья в каком-то смысле его TLDR в свободном изложении. Скажу сразу, наша модель — не LLM, хотя к трансформерам имеет самое прямое отношение. MOLOT построен на базе BERT-энкодера (не modern, не neo, а самого ванильного) и умеет обнаруживать вредоносный код по цепочкам вызовов не хуже Mythos от Anthropic (как минимум не боится промпт-инъекций).