Искусственный интеллект

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

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

ИИ помогает быстрее искать уязвимости, разбирать исправления и готовить эксплойты. Окно технологических работ от этого длиннее не становится. У команды по-прежнему есть проверка совместимости, согласования и системы, которые должны работать. Атакующему достаточно выбрать одну подходящую ошибку.

Чем больше находок, тем острее вопрос: что исправлять первым? За каждым обновлением стоят люди и время. Если обнаружение ускоряется, а устранение остаётся на прежнем уровне, растёт очередь открытых проблем.

Поэтому мы открываем cKEV Index — каталог приоритетных уязвимостей СайберОК на основе методики Urgent Patch Score (UPS). В нём собраны проблемы, требующие срочного внимания, и события, которые объясняют их приоритет: появление эксплойта, подтверждение атак и другие свидетельства. В открытой версии представлены стадии Urgent Patch и Emergency / IR с сокращённой историей событий.

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

Я сделал desktop приложение на Tauri, Rust, React и SQLite. Оно распознаёт речь, разделяет спикеров, анализирует тональность, эмоции и риски, а в конце локальная модель формирует резюме и рекомендации. Всё работает на компьютере, интернет нужен только для скачивания моделей.

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

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

Рассказываю, как мы создали систему Crop Control, которая доустанавливается на комбайн (даже если раньше на нём не было никакой автоматики) и позволяет мониторить качество и количество зерна прямо во время движения. Мониторинг количества нужен, чтобы понимать, сколько урожая собрано с конкретного поля: урожайность - одна из ключевых метрик оценки продуктивности уборочной кампании в целом. А мониторинг качества нужен для того, чтобы вовремя повлиять на собираемую продукцию, например скорректировать настройки комбайна, и не дать испортить уже намолоченное зерно.

Что значит основать свою компанию в 2024 году и развивать бизнес в 2026 году? На какие технологии делает ставки команда? Детали технологий и бизнеса в блоге CEO компании CoreInfra.

Вы могли слышать о некоторых из нас как об авторах проекта StatsHouse^[4], быть на наших выступлениях на HighLoad++ или работать вместе с нами в компаниях ВКонтакте, Яндекс или Транзас. Мы — инженерная команда, имеющая опыт создания технологических продуктов и запуска ML-сервисов, которыми пользуются миллионы людей.

В этом посте расскажу о главном нашем активе – команде и главных идеях компании.

Привет, Хабр. На связи Николай Карасов, ведущий разработчик отдела рекомендаций контентных сервисов в AI VK. Наша команда отвечает за рекомендации в Ленте ВКонтакте.

Перед нами стояла цель — развить внутри ВКонтакте новый пользовательский сценарий: человек приходит за контентом, видит у автора интересный ему товар и переходит к покупке прямо из социальной сети. Так в Ленте появился новый тип объекта — товарный пост. Первым партнёром в этом сценарии стал Ozon. Дальше речь пойдёт именно про товарные посты авторов в рамках реферальной программы Ozon, а не про любые публикации с товарами.

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

Когда у функции на базе языковой модели нет одного правильного ответа, привычные проверки по принципу «ожидание = фактический результат» перестают работать. Тестировщику приходится определить, какие свойства ответа действительно важны, как отделить допустимую вариативность от ошибки и построить понятный критерий pass/fail.

В этой статье на примере функции суммаризации обращений разберём, как сформировать контракт поведения, набор проверок и подход к регрессионному тестированию AI-фич.

В диспетчере задач напротив Archicad 26 стояло «Не отвечает». Процесс держал около 13% процессора и почти 4 ГБ памяти, каталог покрытий стен больше шести минут показывал «2D | Обработка элементов». Обычно в этот момент задачу снимают. Мы не стали: на 389-й секунде обработка ещё шла, к 452-й таблица была готова. Программа не зависла, она считала.

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

Дисклаймер: изначально это был комментарий на другую статью, но та статья оперативно улетела в черновики, а @0xKubik — в readonly (?!). Так что пишу тут, в надежде что однажды автор ответит тут, или свяжется иначе.

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

Первая версия получилась курсом по shell-скриптингу. А я не этого хотел: мне нужно было разобраться с Linux на практике, а не в теории по книге — права, службы, журналы, монтирование, сеть. На выходе же лежала полсотня заданий вида «напиши .sh, который…». Хотя каждое по отдельности выглядело нормально.

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

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

А администратор большую часть времени не автоматизирует. Он читает конфиг, смотрит, что запущено, и выясняет, почему оно работает не так, как написано в документации. Скрипты тоже пишет — но это следствие, а не основное занятие.

Я продуктовый дизайнер, больше шести лет делаю SaaS. Программировать умею, но фулстек-разработчиком себя не назову. Уже несколько месяцев я в одиночку делаю Котомку, планировщик жизни по методу PARA: сферы, проекты, задачи, календарь, привычки, финансы. Есть веб, мобильная версия, синхронизация между устройствами и с Google и Apple календарями. Почти весь код пишет Claude Code. Я ставлю задачи, проверяю результат и принимаю решения.

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

На практике мощный вычислительный кристалл может значительную часть времени ждать, пока память и интерфейсы доставят ему данные. За десять лет производительность вычислительных блоков GPU выросла намного быстрее пропускной способности памяти, а стоимость HBM остается высокой и в последние годы росла даже в пересчете на емкость и пропускную способность. Поэтому эффективность современной ИИ‑платформы определяется уже не отдельным чипом, а всей системой: памятью, межсоединениями, хост‑процессором, компилятором и программной средой.

Может ли Россия участвовать в этой гонке, не пытаясь полностью повторить NVIDIA? Какие направления выглядят реалистичнее универсального GPU и где в подобных системах может использоваться RISC‑V?

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

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

А в итоге разобрала файлы проектов Claude Design по кусочкам, потратила месяц на отладку и сделала плагин, который переносит готовый проект из Claude Design прямо в Figma — с редактируемыми слоями, auto‑layout, текстами и данными.

Днём я пишу код в Claude Code, вечером хожу в зал: у меня пауэрлифтинг, тренировки тяжёлые, часа по два. Тренера я сделал для себя. Хотелось, чтобы тот же Claude, в котором я работаю, вёл и мои тренировки.

Так появился claude-gym-coach, open-source тренер по силовым внутри Claude Code. Один раз рассказываете ему, кто вы и чего хотите, и дальше он ведёт сам: составляет программу под ваш зал, перед каждой тренировкой расписывает веса по вашей истории, после тренировки записывает то, что вы скажете в телефон, и раз в блок разбирает, что сработало. Если раньше был дневник, его можно перенести, и новые тренировки тренер строит от него. Отдельное приложение и отдельная подписка не нужны: всё работает внутри Claude Code, на той подписке Claude, которая у вас и так есть.

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

Веб-агент сообщил «готово» — а сделал ли? На живых сайтах это не проверить: контент меняется, а судить приходится либо по словам самого агента, либо через LLM-судью, который тоже ошибается. Мы выпускаем WebPageBench — открытый бенчмарк из 152 задач на шести имитациях популярных российских сервисов (от покупок на маркетплейсах до бронирования билетов на поезд). В комплекте локальная среда, в которой любой агент запускается одной командой, и публичный рейтинг, в котором представлено 24 связки «модель + обвязка», а по результатом которого видно, что агенты зачастую сильно завышают свои результаты.

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

Большой проект иногда начинается с простого любопытства: что получится, если доверить ИИ разработку настоящего приложения? Проверять гипотезу хотелось на полезной задаче — создать собственную программу удалённого доступа. Эксперимент казался коротким, пока первая версия не зашла в тупик, а за ней не обнаружились вопросы архитектуры, сетей и безопасности.

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

ИИ тебя заменит! Слышали? Я часто, и мне захотелось разобраться в теме и понять для себя, как разработка будет жить в условиях всеобщего ИИ, когда любой встречный-поперечный может с помощью AI сделать генерацию сайта, бота или использовать нейросеть для генерации приложений. И вроде бы, действительно, программист больше не нужен, но ведь мы интуитивно понимаем, что не всё так просто.

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

Предположим, вам нужно заселиться в один из двух небоскребов на 99 этаж. Оба небоскреба имеют 100 этажей, основание, у них одинаковая площадь квартир и общедомового пространства, у каждого встроена противопожарная безопасность, но в обоих случаях она еще ни разу не запускалась. Но есть и различия: первое здание прошло полную приемку в органах гос-пожар-тех-потреб надзора, его проектировали и строили люди по всем современным нормам. Второе здание было построено ИИ без привлечения специалистов-людей. Для второго здания гос-пожар-тех-потреб надзор НЕ участвовал во вводе строения в эксплуатацию.

Какое здание вы бы предпочли на ближайшие 5–10 лет? Почему-то мне кажется, что первое.

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

Так уж вышло, что иногда я балуюсь таро. Обычно, делаю расклады знакомым, но недавно подруга сказала, что вместо таро использует… ИИ. И нет, не как объективного эксперта, который рассудит в сложном вопросе, а именно как таролога.

Вот уж не думала, что именно эту, так сказать, «профессию» нейронки так лихо заменят. Мне стало интересно, как умудрились автоматизировать магию и работает ли это вообще.

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

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

Мы пишем инструкции и скиллы для ИИ-агентов, просим их проверять свою работу, запускаем отдельных агентов на код-ревью. Для важных изменений добавляем ещё одного проверяющего. Каждый такой запуск требует времени и токенов.

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

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

Такие автоматические проверки в этой статье я называю guardrails: они задают условия, которым должно соответствовать изменение кода перед принятием. Если проверка обнаруживает нарушение, изменение требует исправления.

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

Статья рассчитана на Go-разработчиков, знакомых с тестами, контекстами, каналами и CI. Исходники, конфигурации и команды воспроизведения лежат в репозитории с примерами. Весь вывод команд получен на Go 1.27.1 и golangci-lint 2.13.2. Версии зафиксированы, чтобы у вас получился тот же вывод, что в статье.

Когда мы обсуждаем агентов для программирования, разговор быстро сводится к моделям. Какая модель Claude лучше пишет код, а какая версия GPT увереннее чинит ошибки, как Gemini работает с большим репозиторием. Но между моделью и рабочим деревом Git находится ещё один слой, от которого зависит, что агент вообще сможет сделать.

Этот слой — программная обвязка вокруг модели, которую принято называть harness. Он организует цикл работы агента: передаёт запрос модели, выполняет вызванные ею инструменты и возвращает результаты для следующего шага. Здесь же собирается контекст, применяются правки и сохраняются сессии. Модель может предложить правильное изменение, но не суметь применить его через неудобный инструмент редактирования. Может найти проблему, но потерять нужную информацию после сжатия контекста. Или потратить несколько ходов на задачу, которую подходящий инструмент выполнил бы за один вызов.

Интересный проект, который изменил традиционное устройство моделей — Pi. Это терминальный агент, который строит свой harness с нуля, а не надстраивается над готовым. Его автор, Mario Zechner, сознательно ограничил набор встроенных механизмов работы. Вместо попытки заранее предусмотреть все сценарии Pi предлагает основной инструментарий, который можно приспособить под себя. Oh My Pi вырос из этой основы, но выбрал другое направление: собрать больше решений в одном готовом агенте.

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