Программирование *

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

Для этого мы сравнили два способа «подружить» ИИ‑агента с внутренними API — MCP и CLI + Skill. Взяли гипотезу из внешних исследований, собрали бенчмарк на 14 сценариях и двух моделях, прогнали больше 400 запросов на реальных внутренних инструментах. И в какой‑то момент всё, что работало, сломалось — и это оказалось самым интересным. Пришлось разбираться почему.

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

Сколько раз вы реально меняли базу под приложением? Generic Repository – первое, что тащат в проект, и последнее, в чём сомневаются, – держат ровно ради этого. У меня за карьеру смена базы случилась дважды, и оба раза репозиторий полетел в корзину вместе со всем слоем. Это лишь первое из трёх обещаний, которое он не сдержал, а по дороге тихо забрал доменную модель. Как именно – на реальном кейсе с Mongo, и чем мы его заменили.

Модель уверенно выдаёт прогноз, но насколько ему можно доверять на конкретном объекте? Конформные предсказания добавляют к результату интервал или набор классов с формальной гарантией покрытия — почти поверх любой ML‑модели и без предположений о распределении данных.

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

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

Начнём с самого простого. Кандидаты часто вообще не читают вакансию. Просто шлют сопроводительное письмо в стиле "Я готов работать", "." или "Я соответствую вакансии". Точка. Просто точка, Карл. Даже не три точки, чтобы была хоть какая-то интрига.

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

Например: "Классный у вас ИИ-агент. Я работал с LLM, посмотрел ваш продукт, идея огонь. Хочу поучаствовать, получить опыт и принести пользу - готов работать бесплатно за строчку в резюме". Всё. Такого кандидата уже хочется пригласить на интервью. Про "работать бесплатно за строчку в резюме" я, конечно, шучу. Но если человек хотя бы посмотрел продукт, это уже событие уровня "нашли воду на Марсе".

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

Реактивность лучше MobX, виртуализация рендеринга «из коробки», типизированные стили на TypeScript, локально-первая модель данных через CRDT — эти идеи Дмитрий Карловский (nin-jin) разрабатывает на своём фреймворке $mol и в проекте $hyoo.

За десять лет накопилось около сотни статей на Хабре и большая документация на mol.hyoo.ru, разбросанная по годам и площадкам — карта потерялась даже у тех, кто читал.

Этот каталог — навигатор по корпусу. 80+ материалов разложены по 12 темам:

с чего начать и для кого это вообще

история фреймворка от тизера 2016-го до обзора 2025-го

реактивность от первого «атома» 2014-го до свежего цикла 2026-го

архитектура: MAM, view.tree, виртуализация, CSS-in-TS

руководство по практике

утилиты: $mol_fetch, $mol_time, $mol_regexp, VaryPack, MarkedText

TypeScript-приёмы и принципы кода

$hyoo и Гипер База — распределённые данные на CRDT

сообщество, бенчмарки, аналитика проекта в цифрах

На каждый материал один абзац о сути и прямая ссылка на оригинал.

Полезно даже тем, кто не будет писать на $mol.

Часто можно услышать «ИИ-агент», но мало кто объясняет, что это такое, если разбирать на уровне кода. Спойлер: магии меньше, чем кажется — цикл, вызов моделей для истории сообщений. Соберём минимального агента на Python с нуля, чтобы увидеть механику своими глазами.

Привет, Хабр. Я Полина, продакт и главный редактор медиа-платформы «Своё Вино» от Россельхозбанка. Помните, не так давно мы говорили с вами о том, что общего у вина и ИТ? На платформе «Своё вино» мы с редакцией обычно говорим о терруарах, стилях и винтажах, но в этот раз попробуем применить ту же оптику к языкам программирования. Попробуем угадать язык по пяти строкам кода и заодно понять, по каким «ароматам» и «танинам» наш мозг так быстро их различает.

Почему, несмотря на накопленный опыт и современный инструментарий, число флаки‑тестов растёт год от года? Исследование BitRise 2025 года показало, что доля команд, которым приходится сталкиваться с флаки-тестами, выросла с 10% в 2022-м до 26% в 2025-м.

Нестабильные тесты сильно бьют по рабочим процессам: из опроса 1600 человек в 2023 году стало ясно, что флаки-тесты съедают 8% рабочего времени, почти столько же, сколько занимает наладка и поддержка тестовых сред. Но реальный вред флаков гораздо больше: они подрывают доверие к здоровым тестам и ставят под вопрос всю автоматизацию.

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

- Больше этапов в пайплайнах

- Более сложные рабочие процессы

- Больше сторонних зависимостей

Сложность среды, сторонние зависимости - всё это бьёт в первую очередь по E2E-тестам. Проблема в том, что компенсировать эти источники сложности может быть очень дорого. И именно об этом я хочу поговорить сегодня: насколько дорого обеспечить стабильность E2E-тестов?

В этой статье речь пойдёт не просто об очередном алгоритме, а о том, как можно обойти классический бинарный поиск. Казалось бы, что может быть эффективнее старого доброго деления массива пополам для нахождения значения в отсортированных данных? Однако можно пойти дальше. В этой статье будет рассказываться о самодельном алгоритме «SIMD Quad» - квадратичном поиске.

Идея возникла из необходимости быстро искать 16-битные целые числа в массивах размером до 4096 элементов — именно такие структуры лежат в основе популярного формата Roaring Bitmap. Вместо того чтобы на каждом шаге сравнивать искомый элемент только с одной серединой интервала, авторский алгоритм использует две ключевые аппаратные особенности современных процессоров. Во-первых, это SIMD-инструкции, позволяющие за раз сравнить до 16 элементов. Во-вторых, это распараллеливание работы с памятью, которое даёт возможность безболезненно делить массив не на две, а сразу на четыре части. Так родился гибрид, который сначала выполняет учетверённый поиск по блокам, а затем находит нужный элемент с помощью векторных инструкций. Давайте разберёмся, как это работает и почему такой подход действительно позволяет превзойти бинарный поиск.

Привет, Хабр! Меня зовут Андрей Серебрянский. Раньше я строил платформы потоковой обработки данных в банках, а теперь вместе с командой разрабатываю YDB Topics и YMQ. После своих докладов на конференциях мы с коллегами по индустрии часто обсуждаем брокеры сообщений. И меня, как разработчика таких решений, огорчает упрощённый подход: «RabbitMQ не нужен, всё можно собрать на Kafka».

Вспоминая известную шутку: да, с помощью буханки бородинского и двух спиц можно собрать модель троллейбуса. Но зачем? Да, я люблю Kafka и с удовольствием про неё рассказываю на Хабре и Хайлоаде. Но, кроме Kafka и RabbitMQ, есть и третий класс брокеров сообщений: SQS-совместимые очереди в облачных платформах (и не только), которые для многих продакшн-задач подходят лучше, чем Kafka.

Опытные разработчики, проводя system design interview, любят спрашивать друг друга о разнице между брокерами сообщений. А мне каждый раз хочется ответить: «Зависит от контекста». В статье под катом я начну с такого контекста: напомню, для чего изначально создавались SQS, RabbitMQ, Kafka. После этого расскажу про принцип «простой API, умный сервер» и про задачи, которые в эпоху микросервисов решаются с помощью брокеров. А в завершение — про реализацию SQS, над которой сейчас работаю: Yandex Message Queue.

Полное руководство по аппаратному мультиколору для тех, кто не знает, что это такое и зачем он нужен.

Преимущества и недостатки, прототип игры, перспективы

Если у вас российский номер, my.telegram.org с VPN выдаёт ERROR при создании приложения, а без VPN вообще не открывается. Антифрод сверяет страну номера и страну IP - и они не сходятся. Разбираю, почему обход через VPN - тупик, при чём тут DNS, и как получить api_id и api_hash одной строкой в файле hosts за 5 минут, без покупки номеров телефона других стран.

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

# Как мы четыре раза неправильно диагностировали зависание на джобе 281 339

Несколько месяцев назад я писал, [как мы четыре раза неправильно чинили мерцание](https://habr.com/ru/articles/1042962/) при рендеринге 4,4 миллиона полигонов. Тогда казалось, что это рекорд: месяц блужданий, четыре отброшенных подхода, решение на неделю. Эта история хуже. Баг пережил четыре диагноза подряд, два из которых мы успели «подтвердить числами», получил по дороге три работающих фикса от несуществующих причин - и в итоге оказался файлом, который лежал на рабочем столе.

Напомню контекст: мы небольшой командой пишем на Rust + Vulkan редактор топологий интегральных схем + верификатор (DRC/LVS/Antenna/PEX) с прицелом на российский рынок. Команда - три человека, я в роли CTO направляю архитектуру и принимаю основные решения. В том числе неверные, о которых ниже. Тестовый основной дизайн всё тот же - Caravel SkyWater SKY130: 4,4 миллиона полигонов, 1014 уникальных ячеек, 22 уровня иерархии, 278 МБ GDS (недавно воспользовались прекрасным проектом [TinyTapeout]( https://github.com/TinyTapeout/) - для прогона на различных gds)

К моменту этой истории мы только что закончили перф-кампанию по паразитной экстракции (PEX). Если коротко: чтобы посчитать ёмкости, нужно сначала собрать цепи - обойти иерархию чипа BFS-ом от каждого "сида" (точки на цепи устройства) и выяснить, какие фигуры электрически связаны. На Caravel это 537 748 сидов. Кампания ужала полный холодный прогон с 962 секунд до 70: пространственный грид вместо квадратичного перебора пар, параллельные трейсы на 14 потоках, кеш результата. Все гейты бит-идентичности зелёные, CLI летает.

1С 7.7 сегодня живет в странном статусе: платформа давно не новая, типовые решения на ней уступили место 1С 8, но в реальном бизнесе старые базы продолжают работать. Часто это сильно доработанные конфигурации, которые годами закрывали конкретные процессы компании, и переписать их «на восьмерку» быстро не получается. С нейросетями похожая история: для 1С 8 примеров, обсуждений и готовых фрагментов заметно больше, а код под 7.7 они пишут менее уверенно. Синтаксис вроде знакомый, но объектная модель, запросы, периодические реквизиты и старые приемы работы отличаются. Поэтому использовать нейросеть для 7.7 можно, но не как автопилот, а как помощника, которому обязательно нужны реальные файлы, описание метаданных и проверка человеком.

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

У меня была как раз такая задача: внешняя обработка для 1С 7.7 загружала XML-файлы универсального передаточного документа в документ «Приходная накладная». Нужно было доработать ее под реальные файлы поставщиков.

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

В какой-то момент я стал для себя и своих коллег собирать статьи на habr про агентную разработку, которые с моей точки зрения были бы нам полезны. С 27.04.2026 начал это делать каждый день: просматривать все статьи в хабах ИИ, Java, Python, аналитики и тестировании. Решил сделать статью с этой подборкой, может кому будет интересно. В этой подборке только дата статьи, название и ссылка. Понял, что нужно хотя бы комментарий писать, почему я ее сохранил. Для новых статей исправлюсь. Буду благодарен, если в комментариях напишите ссылку и на другие статьи про агентную разработку, которые считаете полезными.

Приветствую читатель!

Для тех кто со мной впервые вот оглавление:

Часть 1

Часть 2

Часть 3

Код лежит тут

Подразумевается что читатель знаком с архитектурой аллокатора из части 3 и понимает алгоритм неявного списка свободных блоков который был освещен в части 1

Аллокатор работает стабильно, все тесты зеленые, включая тесты на стабильность. И следующим шагом логично бы реализовать перегрузки new и delete для abi, но вот незадача: там есть версии принимающие дополнительный аргумент, а именно выравнивание. Эту фичу я реализовать как раз забыл. В архитектуре которая рассматривается в предыдущей статье это оказалось простой, но интересной задачей. Ее мы и обсудим ниже.

Решение потребовало реализации функции mem_malloc_aligned которая выделит бОльший кусок памяти с учетом запрошенного выравнивания что бы мы там точно нашли правильно выровненный адрес.

Но что если адрес указателя из mem_malloc_aligned не совпадает с адресом указателя который вернул mem_malloc? Что делать в mem_free? Что делать в mem_realloc? Как мне работать с указателем перед которым не хедера?

Для начала я решил применить технику добавления смещения перед payload выровненного блока вместо хедера, смещения до payload изначального блока у которого есть хедер и футер.

Но как мне отличить offset от header? Я решил добавить magic number в хедер и футер увеличив тем самым размер оверхеда в 2 раза и раз уж от него считалось внутреннее выравнивание блоков памяти в аллокаторе и минимальный размер блока, то теперь минимальный размер блока стал 32 байта, а с оверхедом все 64. Теперь можно просто проверять magic number и если он не совпадает, то интерпретировать число на месте хедера как смещение до payload блока который вернул mem_malloc и далее получив на него указатель работать с блоком стандартным образом.

Китайские модели дешевле западных в разы, и регулярно всплывает вопрос: можно ли просто пересесть на Qwen и не платить за Claude с GPT? Я взял одну реальную задачу — разбор pprof-профиля Go-сервиса с фиксами по файлам — и прогнал её через три модели сразу: Codex (GPT-5.5), Claude Opus 4.8 и Qwen 3.7 Max. Свёл качество (по 10 критериям) с реальной ценой за токены и разбираю, где Qwen работает наравне с дорогими конкурентами, где отстаёт по глубине, где выдал прямо небезопасный совет, и кому он в итоге подойдёт. Спойлер: дело не в «IQ модели», а в том, что одиночная модель — хоть дорогая, хоть дешёвая — слепа к своим ошибкам.

90% code coverage выглядит как повод выдохнуть — до первого бага, который спокойно проходит сквозь все тесты и добирается до прода. В статье разберём, почему покрытие строк создаёт ложное чувство надёжности, чем branch coverage полезнее и как мутационное тестирование показывает реальные дыры в тестовом наборе.

Недавно попалось на глаза одно очень интересное видео с динамическими шкалами по популярности разных языков программирования по годам (вроде как, начиная с 1980х). Удивительно, сколько всего и как много придумало человечество. И как быстро меняются тренды, а еще - сколько всего уникального уходит в тень истории. Вот был такой Лисп. Принято считать, что Лисп - это что-то из учебников по истории программирования. Где-то между перфокартами и первыми компиляторами. Условный артефакт. Язык, которым пользовались бородатые профессора, пока не пришел Python и не навел порядок.

Только вот Python тоже унаследовал из Лиспа некоторую часть. Но не все. Самое радикальное так и не забрал.