Софт

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

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

В 2026 году эту проблему сформулировал Томас Домке, бывший CEO GitHub и основатель Entire. Она звучит так: «Узкое место при выпуске кода — это ревью кода, созданного агентами». Мы в «Первой Форме» к похожему выводу пришли через собственную практику. У нас ИИ-агенты работают внутри управляемого конвейера: задача получает проверяемые критерии, агенты действуют по ролям, результаты фиксируются в артефактах, а человек сохраняет за собой продуктовые решения, финальное ревью и мёрж. Расскажем подробнее.

98% успешных проверок в дашборде выглядят прекрасно. Ровно до момента, когда доходит: недостающие 2% это одна пара нод, один протокол, и так каждый день. Обновили CNI или ядро, и между двумя конкретными нодами начал теряться UDP, а агрегат всё ещё зелёный.

kconmon‑ng ставит агента на каждую ноду и гоняет TCP, UDP, ICMP, DNS и HTTP‑пробы между всеми парами каждые 5 секунд, а при сбое сам снимает MTR‑трейс, пока проблема ещё жива.

К версии 2.0.0 у проекта выросла веб‑консоль: матрица N×N, расследование с ранжированием причин без ML, машина времени для разбора ночных инцидентов и алертинг, который сводит правила в настоящий PrometheusRule. Под капотом всё тот же Prometheus.

И она потрясающая, но я несколько выбился из сил, поэтому, как говорится, простите за неровный почерк :) Напоминаю контекст: f4 — эксперимент по переписыванию Far на go, чтобы сразу и кроссплатформенно и асинхронно. И красиво.

С красоты и начнём. На днях во фреймворк консольных интерфейсов vtui, который пишется под f4, добавлена поддержка Auto layout. Можно делать диалоги как у Apple! А чтобы это смотрелось красиво, предусмотрены две стратегии хинтинга: байткод, по аналогии с тем, как это сделано для рендеринга шрифтов у TrueType, и эвристики, как у FreeType. Для этого потребовалось портировать на go быструю считалку cassowary (пользуйтесь! там и wasm есть), а потом изобрести дискретный cossowary специально под консоль — задаем стандарты интерфейсов, люблю такое! И заодно — новая, уже полностью своя цветовая тема, не пытающаяся повторять что-то из Far, Turbo Vision или Monokai.

Привет, Хабр! Представьте ситуацию в интернет-магазине. Клиент звонит и пишет в поддержку, так как получил поврежденный заказ. При этом он уже откладывал повторную покупку из-за долгой доставки в прошлый раз и не дописал отзыв, который хотел оставить неделю назад. Человек на грани ухода к конкурентам. Что увидит типичный оператор поддержки? Да просто текущее обращение. Он оформит возврат, закроет тикет — и на этом как бы все. Остальные сигналы останутся незамеченными им. В противовес ему, агентная система видит всю картину, ловит паттерны и закрывает боли клиента: оформляет возврат, предлагает промокод на следующую покупку, устраняет причину недовольства. Это рабочая модель, которую уже описывают аналитики McKinsey в свежем отчете о перестройке клиентского опыта в эпоху агентского ИИ.

Последние пару лет компании в основном просто добавляли генеративный ИИ поверх старых процессов. Да, чат-боты стали вежливее и быстрее, но логика принятия решений при этом у них не изменилась. Клиент как сталкивался с разрозненными сценариями на разных этапах пути, так и сталкивается. Агентский ИИ меняет эту логику. Вместо заранее прописанных сценариев он в моменте принимает решение на основе реального контекста. Что это значит на практике, через какие этапы проходят компании и какой результат получают на выходе?

Минуло четыре года, когда после массового исхода Avaya, Genesys, Cisco и Verint российские контакт-центры начали разворачиваться с западного стека на отечественные платформы. 

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

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

17 лет с покупки первого айфона я складывал музыку в одну медиатеку. Она начиналась с mp3-шек на жёстком диске, пережила переезд в стриминг (через iTunes Match) и росла до марта 2026-го. Плейлисты «Deepden», “Kizaru”, “повтор” — собранные под себя, годами.

Потом сверху решили, что оплачивать Apple Music в России никак нельзя. Я закинул 2000 ₽ на счёт Apple, чтобы не умерла синхронизация с iCloud, остальные подписки отменил — с мыслью, что за год решения, как обойти ограничения, найдутся. Так и жил без подписки: медиатека на месте, слушать нельзя. В августе 2026-го понадобился особенный трек, которого не было в Я.Музыке (худший сервис — и, к сожалению, ровно потому, что соблюдает законы РФ). Завёл американский аккаунт — тем более после покупки MacBook Air в американском сторе подарили три месяца халявы. Регистрируюсь, соглашаюсь на триал, открываю «Музыку».

Пусто.

10 532 трека — как оказалось позже — канули в лету. Переживал я даже не из‑за конкретных треков, а из‑за плейлистов: там собирались подборки под каждое настроение. Собирать их заново — ни в Я.Музыке, ни где‑то ещё — у меня не было ни желания, ни времени.

6 453 трека и все плейлисты вернулись на место. Ниже — как именно.

TL;DR. Финансовая модель в таблице разваливается при смене периода расчёта. Я честно старался, был аккуратен как мог, но период в модели хранится в геометрии листа: колонка — это месяц, а формулы адресуют ячейки по абсолютным координатам. На Хабре на эту боль есть два описанных ответа, оба уходят от таблиц: перенести логику в OLAP-куб с семантическим слоем или написать модель на Python. Здесь описан третий: оставить табличный интерфейс, но вынести диапазон и период в параметры модели, а адресацию перевести с координат ячеек на имена строк и колонок. Перевод модели из 10 листов с месяцев на кварталы стоит тогда 2 действия вместо 460–3060 — расчёт по шагам приведён в тексте.

У меня был iPhone и ноутбук на Windows, а хранилище Obsidian лежало в iCloud. Работаешь себе, всё нормально, и в какой-то момент заметка, которую ты правил, превращается в 10 копий с номерами в именах. Что-то потыкал, вроде исправилось. Несколько дней тишина, потом то же самое. А когда я наконец заглянул в служебную папку, там лежали сотни копий одного файла workspace.json: он размножался активнее всего, просто на глаза не попадался.

Кончилось тем, что я перешёл на технику Apple целиком. Я и так к этому шёл, но история с копиями решение заметно ускорила.

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

У меня всегда крутится несколько Claude Code. Вчера заметил странное: два агента, работавшие над одной проблемой, сами обменялись сообщениями через сокет uds:/tmp/cc-socks/769334.sock. Раньше такого не было.

Оказалось, в 2.1.224 появился cross-session SendMessage: разные сессии находят друг друга через ListAgents и пишут друг другу напрямую. А в 2.1.225 это заработало и между машинами при включённом remote control. Сейчас 90 процентов работы у меня делает один универсальный агент с огромным контекстом — и вот теперь наконец можно собрать поверх нескольких полноценных Claude Code отдельного координатора.

Всю свою сознательную жизнь я «учил» немецкий: в школе, универе, на внутренних курсах IT-компании и самостоятельно. Слово «учил» я поставил в кавычки, потому что на самом деле я ничего никогда нигде не учил, ну разве что зазубрил немецкий алфавит в школе. Всё как-то училось само, слова запоминались после нескольких повторений, грамматика – после нескольких упражнений. Слава Богу, память всегда была хорошая. Но во-первых, если в будущем эти слова и грамматика не использовались, всё это вскорости выветривалось из головы, а во-вторых, так это не работает со сложными темами. Такими, как, например, склонение немецких прилагательных.

Тем, кто учит английский, повезло: прилагательные там не склоняются вовсе, но в немецком (как и в русском) всё совсем не так:

Оба числа - про одно и то же испытание двигателя ПД-8. Разница в том, где оно проходило.

Испытания двигателя ПД-8 в АО «ОДК-Сатурн». Натурный эксперимент: оценочно 1,1 млрд рублей и около года с учётом изготовления опытных образцов, монтажа и подготовки к испытаниям. То же самое на комплексных инженерных моделях: 8 миллионов рублей и два месяца. Плюс к этому в цифре удалось оптимизировать конструкцию двигателя и поднять его характеристики.

Разница в 137 раз по деньгам и в шесть раз по срокам - это не эффект удачно купленного софта. Это эффект того, что гипотезу проверили до того, как она превратилась в металл. И дальше я хочу объяснить, почему такая разница возникает закономерно, а не как счастливое исключение.

Изучаю шину CAN J1939 через написание самописных утилит. Целенаправленно отключал датчик наддува для проверки своих программ.

И здесь случай: Идёт выпуск машин на маршрут. На одном из автобусов АКПП не включается выше второй передачи. Сканера нет читать нечем. Но есть C, Linux, CANable, map_id_j1939, viz_j1939.

В 2024 году я завела базу знаний в Obsidian, а потом полтора года её пересобирала... Ставила и выкидывала плагины, пробовала чужие методики, бросала, опять возвращалась и около полугода назад база наконец перестала разваливаться.

В статье представлена архитектура базы слоями, выживших плагины, переезд синхронизации с Google Drive на CouchDB на своём VPS и грабли, с которыми я столкнулась.

Крупный промышленный холдинг разослал по рынку анкету: больше 130 критериев к «умной таблице», которая должна заменить у него Excel. Мы её заполнили, защитили перед архитектором и службой безопасности, подали коммерческое предложение — и не получили даже отказа. Просто тишина. Разбор этого случая — ниже, и он объясняет, почему так заканчивается почти всегда.

Разберем также других кандидатов — что с ними не так и почему они безнадежны.

В моём хранилище 801 заметка. Когда я открывал Obsidian, меня встречала пустая вкладка - не главная страница, не список последнего, просто пустота, из которой надо было куда-то попасть.

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

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

База e-mail адресов в Excel и задача сделать рассылку писем. Сервиса рассылок нет, надстройки ставить нельзя из-за корпоративных ограничений. Как сделать полуавтоматическую рассылку без установки стороннего софта имея только Excel и корпоративный Outlook?

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

Если у вас есть похожие задачи, вы сможете их решить после прочтения статьи.

Моя знакомая занимается довольно простым бизнесом: собирает всякие косметические штуки крафтовых российских марок и продаёт в магазинчике в центре города. По ощущению — девчачий бизнес, который никогда не должен был прозвучать на Хабре. А он и не прозвучит, тут и своих когтеточек хватает :-) Дело в том, что я эту девушку встретила на ЦИПРе — она слушала деловую программу трека по управлению персоналом с помощью ИИ. После форума мы поехали в её магазинчик и тут... я офигела. Для меня, айтишника с админским опытом, было удивлением увидеть полностью автоматизированную начинку этого микробизнеса: CRM, управление логистикой, камеры и безопасность, всякие наклеечно-ценниковые принтеры... Автоматизировано всё и досконально. А самое интересное, что малый (не микро!) бизнес уже довольно активно погрузился в эту тему и научился отличать инвестиции от издержек. Расскажу-ка я о своих наблюдениях в этой сфере. 

Планерка. Руководитель озвучивает: «За прошедший месяц мы закрыли 4200 заявок. На 300 больше, чем в предыдущем». 

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

Узнайте, какую правду может рассказать аналитика в сервис деске, кроме «сколько заявок закрыли», с помощью допнастроек и без cведения данных из множества систем.

Всем привет! Меня зовут Григорий, и недавно при разработке своего микросервисного приложения я нашёл уязвимость — сообщения, пересылаемые между сервисами, имели высокий риск быть необработанными. Решением стал паттерны Outbox и Inbox. Однако, когда я стал их реализовывать во всех приложениях, то понял, что просто копирую и вставляю код. Чтобы это исправить, я решил написать свой стартер.

Со временем у меня появилось несколько серверов: VPS, домашний NAS и ещё пара машин под разные задачи. Для подключения я использовал PuTTY. Он работает, но управлять несколькими серверами в нём неудобно. Сессии хранятся в реестре Windows, список хостов плоский, вкладок нет. Чтобы открыть два сервера, нужны два отдельных окна.

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

Мне не хотелось регистрироваться и загружать список своих серверов в облако ради обычного SSH‑подключения. Поэтому я начал делать собственный клиент - LucidSSH. Это не попытка собрать ещё один комбайн для системных администраторов. Мне нужен был простой локальный SSH‑клиент с несколькими дополнительными функциями: защитой от опасных команд и понятными объяснениями ошибок.

Я не занимаюсь администрированием каждый день. Поэтому делал программу прежде всего для таких же пользователей, как я: тех, кто впервые настраивает VPS, NAS, Raspberry Pi или небольшой домашний сервер. Разрабатываю LucidSSH в свободное от основной работы время.