Анализируй и проектируй
ИИ ускоряет выполнение отдельных задач, но управление растущим числом процессов и проектов остаётся на человеке. На примере своих экспериментов покажу путь от одного агента к AI-организации и объясню, зачем над несколькими направлениями может понадобиться AI-холдинг.
Есть особый жанр разочарования, знакомый каждому, кто занимался поиском всерьёз: читаешь статью, где новый метод обходит старый на несколько пунктов, воспроизводишь всё у себя и видишь совсем другую картину. С ColBERT и MUVERA у меня вышло именно так: на обычных текстах обещанного прироста почти не было, зато по дороге выяснилось, где эти методы действительно работают, а где нет.
Добраться до них пришлось почти случайно. Мне попалась статья о MUVERA, реализация которой уже появилась в экосистеме Qdrant. С Qdrant я работаю давно и как раз готовил по нему практический курс, поэтому решил разобраться и с этой частью поиска, тем более что рассказывать о механизме, который сам ни разу не запускал, было бы странно. Первым делом я просто проверил всё на практике.
Дальше началась история о том, почему результаты оказались совсем не такими, как я ожидал. По дороге не обошлось без собственных ошибок, и каждая из них, как ни странно, постепенно приближала к ответу. А сам ответ оказался заметно скучнее, чем хотелось бы, но от этого, пожалуй, только полезнее.
В статье расскажу про то как боролся с переместившимся клубком запутанных сущностей. Также поделюсь идеями и новостями по прототипу.
Вам в наследство досталось руководство пользователя МИС на 1160 страниц в формате .docx, тысячи повторяющихся скриншотов, процесс обновления вызывает глубокую грусть. Что с этим «добром» делать?
В этой статье я расскажу о своём проекте по переводу такой документации на рельсы docs-as-code: переосмысление структуры, укрощение размера скриншотов, борьба с кириллицей в Asciidoctor, настройка автоматической сборки HTML и PDF через GitLab CI/CD.
Долгое время мне казалось, что сильное дизайн‑решение должно говорить само за себя. Если сценарий логичный, интерфейс понятный, состояния продуманы, а решение опирается на исследования — зачем дополнительно его «продавать»? Но когда я оказалась в продуктовой команде, а не на проектах фриланса, оказалось, что качество самого макета — только часть задачи.
Вторая часть — объяснить команде, почему решение выглядит именно так, какую проблему оно решает и что произойдёт, если сделать иначе.
И для меня здесь есть несколько важных выводов.
Агент пишет патч, пишет для него тесты, выполняет их и сообщает об успехе. Дифф выглядит здраво. Итак, у нас есть реализация, файл с тестом, и проверка пройдена (зелёная).
Реализация может согласовываться с тестами, поскольку там содержатся одинаковые ошибки. Если агент недопонял требования, когда писал код, то такое непонимание может сохраниться и на этапе чтения кода в стремлении получить ожидаемый результат. Чем больше тестовый набор, тем сложнее будет устранить такую ошибку. Позже вы исправите реализацию, и тесты начнут ругаться.
Окончить бакалавриат, стать ведущим ТИМ-специалистом и получить две награды «САПР-Перспектива – 2026» за учебные проекты – все это Нина Гагулина успела в 2026 году. Ее карьера началась с победы в конкурсе на знание nanoCAD, а сегодня она уже помогает проектным организациям осваивать российское ПО. Поговорили с Ниной о том, как по обмерам и фотографиям создать информационную модель дома XIX века, разработать купольную систему собора и заинтересовать работодателя своим портфолио.
– Нина, этим летом вы получили диплом бакалавра и стали ведущим специалистом. Чем занимаетесь сейчас?
– Я окончила Санкт-Петербургский государственный архитектурно-строительный университет по направлению «Строительство», профиль «Промышленное и гражданское строительство». Выпускалась на кафедре организации строительства. Сейчас продолжаю обучение в магистратуре СПбГАСУ по программе «Программирование и ТИМ-технологии в строительстве». Занятия проходят по вечерам, поэтому их удобно совмещать с работой. Кроме того, участвую в научно-исследовательской работе Центра региональных проблем экономики качества Института проблем региональной экономики Российской академии наук.
Параллельно с учебой развиваюсь и в профессиональной сфере. Начинала карьеру специалистом САПР, а летом 2026 года стала ведущим ТИМ-специалистом по архитектурным и конструктивным решениям. Сейчас много общаюсь с представителями проектных организаций и институтов: провожу обучения, помогаю разобраться в программах и осваивать инструменты информационного моделирования...
Когда мы просим Claude Code, Codex или Cursor «починить воот эту функцию», то сначала надо понять, где этот код вообще находится. В каком файле? В какой функции? Как она называется и кто её вызывает? Через какие еще системы пролетают байтики наших данных?
За последние полвека для этой задачи придумали огромное количество инструментов: grep, текстовые индексы, полнотекстовый поиск, ctags, LSP, AST, анализ потоков данных, графы, поиск по смыслу и многое другое. Самое забавное, что весь зоопарк с нами и почти ничего из этого не умерло.
В 2026 году поиск по коду в лучших кодинговых агентах по-прежнему состоит из алгоритмов и технологий, которым пять, десять, тридцать, а иногда и больше пятидесяти лет (grep вышел в 1973 году!). И в этой огромной статье я расскажу об эволюции этих технологий, истории и философии их создания, решаемых проблемах и способе работы.
Погнали!
Двести миллионов лет динозавры удерживали вершину пищевой цепи. Они были совершенны для своего времени, пока резкая смена среды обитания и последовавший за ней пищевой дефицит не поставили точку в их истории. В схожей ситуации оказались и популярные таск-трекеры. Превратившись за два десятилетия из стройных и шустрых помощников в прожорливых Jiraзавров, они стали потреблять неприлично большие объёмы рабочего времени. В новой среде асинхронной и многопоточной разработки сам факт их выживания зависит от того, смогут ли они оставаться востребованными утилитами, или их место займут более совершенные системы, построенные на иной архитектуре.
Когда ИТ-директор в 2019 году выбирал промышленную систему, у него был короткий путь: открыть отчёт Gartner, Forrester или IDC, посмотреть, кто в правом верхнем углу, и вести переговоры с тремя вендорами, а не с тридцатью. Квадрант не заменял пробное внедрение, но экономил месяцы на составлении длинного списка. В 2022 году западные агентства ушли, а российские продукты в их отчётах и раньше встречались единично.
Потребность никуда не делась. За четыре года её начали закрывать десятки локальных рейтингов: отраслевые, редакционные, вендорские, от СМИ и от ассоциаций. У каждого своя методика, свой набор категорий, свой способ попасть в список. Сравнить два рейтинга между собой нельзя, а понять, почему продукт в одном списке первый, а в другом отсутствует, нельзя тем более. Рынку нужна не ещё одна таблица, а понятный способ считать.
Мы в АНО «Цифровые платформы» в сентябре в тестовом режиме запустили Призму: квадрант российского ПО по каждой из 441 категории каталога, 9842 позиции, пересчёт раз в квартал. Эта статья не отчёт о продукте. Это попытка разобрать задачу «как построить квадрант в условиях, когда ни вендоры, ни заказчики пока не умеют описывать внедрения» и предложить рынку подход, который можно критиковать, дополнять и забирать себе.
Можно ли описать архитектуру на Python, а получить работающий каркас сервиса на Go, C++, Rust или TypeScript? Причём так, чтобы схема не становилась отдельной документацией, которую все забывают обновлять.
В статье покажу, как из одного описания получить граф и код, зачем нужны разные уровни детализации и как попробовать новую логику рядом с работающей.
Думал, что автоматизирую линейную цепочку: RSS → сайт издателя → URL → отчёт. RSS оказался простой частью. Сложнее стало доказать, что найденный URL — действительно нужная публикация и уже может считаться результатом. Началась история вообще с того, что клиенты уже платили, пока я продолжал искать их проблему на кастдевах.
Сейчас у меня регулярно занимаются четыре ученика. Для четырёх человек CRM звучит как избыточное решение. Но проблема оказалась не в числе контактов: один диалог жил в Telegram, другой — в WhatsApp, ещё два канала были VK и MAX. Перед уроком я вручную вспоминал, где написать ученику, отправлял напоминание и искал ссылку на встречу.
Я собрал рабочее место на базе Chatwoot и дописал небольшой сервис, который связывает календарь с конкретным диалогом. Ниже — как устроена эта цепочка, почему в событии хранится именно номер диалога, а не номер контакта, и какую гарантию доставки в действительности даёт SQLite.
В 1998 году 20-летний студент из Великих Лук отправил в Microsoft письмо с идеей push-индексации сайтов. Ему ответили вежливым отказом. Потом были Яндекс, частные инвесторы, отказ в визе и неслучившийся Grabit. Спустя 28 лет автор нашёл тот самый конверт из Редмонда — и понял, что идея опередила время.
Один ключ на все события заказа — и кажется, что порядок гарантирован. А потом клиенту приходит «Ваш заказ собран» раньше, чем «Оплата получена», витрина откатывает статус назад, а после планового перезапуска одно событие пропадает навсегда.
В статье разбираем три таких инцидента из одной системы на transactional outbox, PostgreSQL и Kafka 4.2. Попробуйте сами определить, где сломалось: в источнике, в relay, в продюсере или у потребителя.
В первой части материала мы разобрали, что необходимо контролировать в корпоративном хранилище данных - от инфраструктуры и ETL/ELT-процессов до Data Quality и выполнения запросов:
Мониторинг и логирование DWH, часть 1: уровни контроля, метрики и типовые проблемы
Во второй части перейдем к конкретным инструментам: Prometheus, Grafana, Zabbix, ELK Stack, OpenSearch, Loki. Разберем, как они устроены, какие задачи решают, чем отличаются друг от друга и на что обратить внимание при выборе стека для мониторинга и логирования DWH.
Выложу здесь в одну статью серию постов из моего ТГ канала про то, как в этом году прошёл DotNext.
25 и 26 сентября в Москве прошла очередная конференция DotNext. Вернулся и делюсь впечатлениями. Я уже писал, какие доклады хочу посетить, однако, по ходу несколько раз передумал. На этот раз решил посетить несколько воркшопов, т.к. они не записываются на видео, а доклады можно посмотреть в записи позже. Воркшоп отличается от доклада тем, что на нём разбирается конкретный практический пример, а аудитория активно участвует, задавая вопросы или предлагая решения. Раньше они меня пугали своей продолжительностью. Доклады длятся по часу, а воркшоп – это обычно от полутора часов и дольше. ИЧСХ, в начале каждого воркшопа любой докладчик считает своим долгом упомянуть, что времени у нас очень мало 😉. Хочу признать, что я много потерял, не посещая воркшопы раньше. Это отличный опыт практики и командной работы.
Первым был воркшоп от Андрея Цветцих (они с братом Денисом завсегдатаи различных конференций) «Паттерны асинхронного взаимодействия в распределенных системах». Мы разбирали пример реализации сервиса уведомлений (например, по e-mail) о событиях. Как настроить передачу информации в сервис рассылки? Какие данные передавать? Как реализовать гарантии доставки и избежать отправки дублирующих сообщений? Возможно ли реализовать доставку «exactly-once»? Интересно, что здесь нет единственно верного решения. Каждое решение – компромисс со своими плюсами и минусами.
Создать отверстие, подобрать комплектующие, расположить элементы в пространстве и разместить готовую проходку в проекте – все эти задачи можно решить в nanoCAD BIM ОПС 25.1. Разбираем, как сформировать кабельную проходку с собственной 3D-графикой, проверить ее расположение и автоматически получить спецификацию отверстий.
С чего начать создание кабельной проходки
Для работы понадобятся три таблицы базы данных из категории «Проходки»: «Отверстия», «Комплектующие проходок» и «Сборки проходок» (рис. 1). Дополнительные элементы доступны в таблице «Материалы» категории «Материалы и комплектации». Каждая таблица отвечает за свою часть работы: геометрию отверстия, состав комплектующих или объединение элементов в готовую сборку.
Сегодня кодинг-агенты неплохо справляются не только с небольшими правками, но и с достаточно крупными инженерными задачами: могут написать код, тесты для нескольких модулей и подготовить запрос на слияние (pull request).
Но есть другая проблема: между этапами создания ПО работу по-прежнему выполняют люди. Аналитик вместе с агентом подготавливает список требований и передаёт разработчику, тот дополняет требования ограничениями и ставит новую задачу кодинг-агенту, и так далее. Получается интересная ситуация: агент может выполнить большую часть работы внутри этапа, но сам процесс всё ещё держится на человеке.
Мы — команда международных расчётов для корпоративных клиентов в Сбере. И для нас следующим практическим шагом развития ИИ-разработки стало устранение именно этого разрыва. На более широком уровне вопрос перехода организации к единому управляемому процессу поднят в руководстве AI-Disrupt PDLC. Сам документ значительно шире, а для статьи нам важен обозначенный в нём образ целевого процесса: человек задаёт цель и принимает решения, агент выполняет работу, а среда обеспечивает контекст, правила, проверки и историю выполнения.
В этой статье разберём, как мы попробовали реализовать этот подход в нашем решении — оркестраторе HG SDLC (Human Guided SDLC). Расскажем, почему разрозненные сессии с агентом не дают масштаба и что становится связующим звеном между этапами разработки. Разберём, что из себя представляет оркестратор на практике, результаты за первые месяцы работы и куда планируем развиваться дальше.
В феврале 28 дней, в марте 31, продавайте одинаково каждый день — и рост на 11% появится сам, без новых клиентов.
В статье разбираю базу, как календарь и сезонность ломают отчёты: три вопроса перед сравнением периодов, SQL-запросы для среднего за день и скользящего среднего, ловушки сравнения год к году.