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

В ML легко перепутать аккуратное число с честной вероятностью: модель выдаёт predict_proba = 0.9, и кажется, что событие произойдёт в 90% случаев. Но это не всегда так.

В статье разбираем, почему выход модели может быть просто внутренней оценкой уверенности, чем калибровка отличается от AUC, как увидеть смещение через reliability diagram и Brier score — и когда вероятности нужно обязательно калибровать, прежде чем использовать их в бизнес‑решениях.

Существует множество известных RAG-фреймворков, проверенных на многочисленных бенчмарках, так что точность работы системы в наших реалиях не такая большая проблема. Однако, для любого, кто сталкивался с прикладной интеграцией RAG в рабочие пайплайны, не секрет, что рано или поздно сталкиваешься с постобработкой форматов, отличных от текста. Комбинируешь OCR, парсеры, ридеры…

RAG-Anything устраняет ненужные телодвижения.

С помощью RAG Anything возможно обрабатывать подавляющее большинство ходовых форматов файлов(PDF, DOC, PPTX, XLS, JPG, BMP, GIF и др. )

В этой статье мы разберем механизм работы фреймворка и на примере посмотрим, как он работает.

TL;DR: ИИ не заменяет инженерный контроль, но меняет базовую планку разработки. С ним проще удерживать скоуп, тесты, техническое качество и в режиме дедлайна. Главный риск — потерять ownership, поэтому уровень автономности должен зависеть от проекта, стадии и зрелости инженерного процесса.

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

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

Пятница, 23:47. PagerDuty: “Платёж AmEx, провайдер вернул 5xx три раза подряд, билеты не зарезервированы.” Открываю логи – действительно три ответа провайдера 5xx, ни одной успешной транзакции по нашей базе. Закрываю как временный сбой на стороне провайдера, пишу короткую сводку в дежурный чат и иду досматривать. Через 40 минут второй алерт – уже от ночной поддержки: клиент прислал скрин выписки, 3 списания подряд за одну бронь. У клиента рейс через 6 часов, ему нужна действующая бронь и подтверждение, что он завтра нормально улетит, а не тикет в поддержку.

Мы делали B2B-платформу для деловых поездок: бронь авиа, отели, трансфер, страховка, в финале – оплата корпоративной картой через платежный шлюз. С этой ночи началась история, которая закончилась переписыванием всего платёжного слоя нашего booking-сервиса. По дороге мы поймали 5 граблей.

В прошлой статье я разбирал паттерны и необходимость компромиссов в реальной разработке, и там была одна мысль которую я намеренно оставил в стороне. Паттерны редко живут в одиночку, и любая реальная система это не один паттерн, а несколько, склеенных, скрученые, слепленных, и местами прибитых сбоку гвоздями, и каждый из них закрывает только часть проблемы. Менеджер ресурсов это, наверное, самый показательный пример такой склейки, потому что снаружи он обычно выглядит как пару строчек видаLoadTexture("bark.dds"), а внутри это кэш, политика дефолтов, механика восстановления после сбоя и ещё полдюжины вещей, каждая из которых прошла через пот, кровь и пиксели и осталась в архитектуре этой системы.

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

Понятие "определенная форма" тем не менее тоже звучит абстрактно, поэтому люди предпочитают использовать "текстуру", "меш", "звук" и т.д. Но одну и ту же текстуру wall.dds, которую можно загрузить в DXT5 со сжатием, sRGB и mip-фильтром box, а можно без сжатия, в линейном пространстве и с другим фильтром. Формально у нас был один файл на диске, но с точки зрения ресурсного менеджера теперь это два разных "ресурса", потому что их параметры различаются. Подмена одного ресурса другим в рантайме может сломать игру, потому что игра ожидает определенных данных для шейдера, которая изменилась после фильтра или определённую раскладку мипов, которой может не оказаться.

Более явный пример для шейдеров будет, когда lighting.fx, скомпилированный с дефайном SIMPLE_BUMP_MAPPING, и lighting.fx, скомпилированный с PARALLAX_BUMP_MAPPING, физически выглядят в исходниках как один файл, но дают два разных пайплайна, со своими константными буферами и со своими ожиданиями к набору текстур, а если ресурсный менеджер этого не понимает, то он либо начнёт раздавать второй вариант, когда просят первый.

С мешами история та же самая, и ship.mesh, загруженный в менеджере ресурсов, и тот же ship.mesh, лежащий в GPU это два разных объекта, у которых даже время жизни и поведение при потере устройства будут отличаться, не говоря уже о том, что первый мы можем менять, а в второй нет.

15-й выпуск IT-новостей от OpenIDE!

Вредоносная версия плагина провисела в VS Code Marketplace 18 минут и этого хватило, чтобы слить конфиги Claude Code, ключи AWS и 3800 репозиториев GitHub. 

Параллельно двое братьев удалили 96 правительственных баз данных за ~1 час после увольнения по Teams, а Bolt вообще уволил весь HR-отдел.

Есть такие анти‑паттерны, которые выглядят нормально и даже проходят код‑ревью, но тихо убивают производительность в горячих местах: 

- Конкатенация строк в циклах

- String.format() в горячем коде

- Автобоксинг 

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

Если вы пишете на Java и у вас всё вроде работает, но под нагрузкой сервисы начинают задыхаться, в новом переводе от команды Spring АйО рассмотрим конкретные паттерны, на которые стоит посмотреть.

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

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

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

Гоняю Codex CLI каждый день параллельно с Claude Code. За январь-май 2026 OpenAI выкатил столько релизов, что я честно сбился со счёта — GPT-5.3-Codex, GPT-5.4, GPT-5.5, Desktop app, Codex в ChatGPT mobile, Browser Use, Computer Use на macOS, стабильные hooks, plugin marketplace, /goal, Windows sandbox, Chrome extension. Это дайджест по реальному changelog с моим ранжированием — что зашло, что нет, и одна важная инверсия популярного мнения. Топ-1: GPT-5.5 — на голову выше 5.4, честно говоря, удивлён, что не назвали GPT-6. Топ-2: наблюдаемость субагентов через spawn — раньше я вручную копировал промпты, чтобы видеть, что делает дочерний агент. Теперь кликаю в карточку и вижу всё. Тотально поменяло работу команды. Что не зашло: автоматизации глючат, скорость уступает Opus 4.7, у Codex два режима запуска агентов и в каждом промпте приходится напоминать о правильном. Инверсия: лимиты у ChatGPT-плана сейчас БОЛЬШЕ, чем у Anthropic, и сбрасываются регулярно. Это контр-интуитивно, но это так. В статье: ранжированный топ-5, грабли, что я НЕ включил (потому что про это были отдельные статьи), и отсылка на архив со скиллами оркестратора в моём Telegram-канале.

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

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Алексеем Федулаевым — руководителем отдела облачной безопасности МТС Web Service, бывшим руководителем ИБ в Wildberries, автором Telegram-канала «Ever_Secure» и постоянным спикером профильных конференций – о том, как на деле устроена профессия: от детского взлома родительских паролей до защиты корпоративных облаков, почему DevSecOps-специалисты входят в топ самых высокооплачиваемых ИТ-профессий и как в этой сфере не выгореть, когда угрозы появляются каждый день.    

Привет! Я Ильдус Тукаев, разработчик в команде образовательной платформы Т-Банка. Мы помогаем школьникам, студентам, молодым специалистам и сотрудникам получать знания и качать свои софт и хард навыки. Основной язык у нас Go, но сегодня расскажу больше про архитектурную тему: как у нас в команде использовался паттерн Outbox и как он эволюционировал.

За полтора года реализация Outbox прошла четыре итерации. По пути мы ловили VACUUM, который останавливал сервис на три часа, теряли 5% событий за полтора дня и заваливали поддержку обращениями. Расскажу, какие реализации мы пробовали, на какие грабли наступали и почему остановились на варианте, который сами же не считаем идеальным.

Привет, Хабр!

В этой статье я расскажу об эволюции моего проекта — GroupModerBot, бота для модерации Telegram‑групп. Я покажу, как проект прошел путь от первой версии «всё в одном файле» до продуманной архитектуры с ООП, in‑memory кэшированием, безопасным выполнением команд и нестандартными алгоритмами наказаний пользователей.

В разработке ПО произведение двух целых чисел часто вычисляется до фиксированного количества битов с переполнением. Возьмём для примера 8-битные целые. Если умножить 127 на 127, то мы получим число 1 в виде 8-битного беззнакового целого с переполнением. Реальное полное произведение равно 16129. Для представления 16129 обычно используются 16 бит точности.

Таким образом у нас появляется понятие полного произведения. Полное произведение двух 32-битных чисел обычно представляется при помощи 64 бит. У меня возник вопрос, какую долю всех 64-битных чисел можно записать, как произведение двух 32-битных целых.

Ещё несколько лет назад разговоры об iPad как полноценном инструменте разработчика воспринимались скептически. Машинка для Netflix, блокнот для набросков, планшет для презентаций — но только не рабочая среда для написания и деплоя кода. У этого скептицизма были основания: iPadOS долго не имела нормальной многозадачности, инструментов для работы с серверами почти не существовало, а необходимость постоянно переключаться между приложениями делала любой серьёзный рабочий процесс мучительным.

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

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

Привет! На связи Антон Дятлов, инженер по защите информации в Selectel. В середине 2025 года я взялся за идею — создать простую браузерную игру к конференции Selectel Tech Day в стиле Hotline Miami, однако опыта разработки игр на JS или Java у меня не было. Тогда я начал искать онлайн-инструменты, способные на основе описания генерировать игру с музыкой и анимациями. 

На выбор было несколько кандидатов, которые высветились в поисковой строке. Sider AI оказался универсальным помощником в более простых повседневных задачах и не справился с запросом на создание игры, в Rosebud AI же, хоть он и выдал качественный результат, кредиты быстро закончились, а получить код можно было, лишь купив подписку. 

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

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

DOOM известен тем, что запускается где угодно – благодаря портам, которые появляются с 1993 года. Мем «It Runs Doom» («Он запускает DOOM») живёт в интернете уже больше десяти лет. Люди запускали DOOM на тостерах, на тачбарах макбуков, на умных холодильниках. И, кажется, я – первый человек, который уместил DOOM в QR-код.

Всем привет! Меня зовут Миша, я разрабатываю платформу Яндекс Еды. В декабре я рассказывал, как Temporal без боли решает привычную проблему распределённой бизнес‑логики.

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

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

Привет. В прошлой статье мы в основном говорили про чтение — кэш в controller-runtime, informer’ы, Reflector, DeltaFIFO, почему r.Get в реконсайле не ходит в apiserver. Сегодня поговорим больше про запись.

Kubernetes по своей природе спроектирован так, что одним и тем же объектом могут управлять разные контроллеры — и это нормально. На один Deployment смотрят и deployment-controller (правит status), и HPA (правит spec.replicas), и admission-мутаторы (расставляют labels), и cert-manager (дописывает свои аннотации), и пользователь с kubectl apply. Каждый из них отвечает за свои поля и не лезет в чужие. И всё это работает.

Сегодня будем разбираться, какие механизмы в Kubernetes позволяют разным компонентам делить ответственность за части одного и того же объекта, не превращая запись в гонку — и как ими правильно пользоваться, когда оператор пишете вы сами. Добро пожаловать под кат.