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

«Bad CaRMa» — глава из Dreaming in Code Скотта Розенберга (каламбур на CRM и «карму») про CRM-систему Vision в компании Upstart. Архитектор задумал предельно гибкую схему: одна-единственная таблица DATA, куда сложили все 150+ бизнес-сущностей — 240+ колонок с именами вроде string82 и numeric31, метаданные и данные вперемешку. Схему ведь больше «никогда не придётся менять».

Это вторая часть статьи Путеводитель по чужим STL, возможно будет и третья про разные трюки-хаки с контейнерами, как наберется материал.

Стандартная библиотека плюсов оказалась почти непригодной для игровой разработки и поняли это практически сразу, как попытались её использовать. Крупнейший на тот момент издатель Electronic Arts стал самым известным примером реализации стандартной библиотеки для разработчиков игр (но конечно же были и другие, менее именитые), и силами команд нескольких студий под руководством Paul Pedriana это было претворено в жизнь.

Корни EASTL уходят в Maxis к 1998-му году, когда Пол работая над SimCity 3000, выступал на GDC с докладом «High Performance Game Programming in C++» про кастомные контейнеры, стоимость вызовов и замеры производительности. Единой EASTL тогда ещё не было, но подход, из которого она потом выросла, виден уже там.

До консолидации, даже внутри одной студии, могли существовать несколько параллельных STL-реализаций, разработанных под разные игры, платформы и инструменты. Рискну предположить, что самой полной была реализация от Maxis, как одной из ведущих студий, а в других командах были поменьше, каждая со своими допущениями.

Он же в статьях и докладах упоминал, что EASTL была синтезом практик из этих внутренних вариантов, а не работой одного человека с нуля, и в основе большой EASTL лежит коллективный опыт нескольких инженерных команд, даже если формальным автором финальной публичной версии и статьи остался он один. Конкретные имена соавторов отдельных модулей (аллокаторов, фиксированных контейнеров и т.д.) указаны в репо, но слава досталась Полу.

В прошлой статье мы разбирали, как сделать работу ИИ-агента предсказуемее: зафиксировать требования в спецификации с помощью Specification-Driven Development (SDD), до реализации описать ожидаемое поведение тестами по Test-Driven Development (TDD), а готовый результат проверить и передать отдельному субагенту на ревью.

У такого подхода есть цена.

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

Полагаться только на свои ощущения в таких вопросах очень опрометчиво. В одном из экспериментов разработчики считали, что ИИ ускорил их примерно на 20%. Замеры показали обратное: с ИИ они работали на 19% медленнее.

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

Что показывают эксперименты, если читать их целиком

Заголовки об ИИ в разработке противоречат друг другу: «на 55% быстрее», «на 19% медленнее», «на 26% продуктивнее». Результаты расходятся, потому что исследования проводились в разных условиях и измеряли разные показатели.

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

Привет, Хабр! Меня зовут Влад Лундышев, мне 23 года, я учусь в онлайн-магистратуре ИТМО в партнёрстве с Яндекс Практикумом на направлении «Фронтенд-, бэкенд-разработка и ИИ-решения» и параллельно работаю Python-разработчиком. Если бы несколько лет назад меня спросили, что самое сложное на пути в IT, я бы ответил: изучить язык программирования и алгоритмы, освоить сложный стек. Сейчас я думаю иначе. Самым сложным оказалось найти первую работу, научиться взаимодействовать с командой и выстроить систему развития, которая не приводит к выгоранию. В этой статье я расскажу, какие подводные камни встретились мне на пути и что я бы посоветовал себе самому несколько лет назад.

Несмотря на то, что PyCharm уже несколько лет официально недоступен в России, он по-прежнему остаётся одним из главных инструментов для Python-разработчиков. Недавно вышла новая версия PyCharm 2026.2.

В релиз вошли разработка Python-расширений на Rust, новый отладчик debugpy, интеграция с Pyrefly, поддержка инструментов uv и uvx и многопроектных конфигураций Poetry и Hatch. Также появились мини-карта редактора, генерация проектов с помощью ИИ, менеджер скиллов для агентов и поддержка TypeScript 7.

В статье разберём основные изменения PyCharm 2026.2, а также расскажем, какие возможности для Python-разработки уже доступны в OpenIDE и чего ожидать от её предстоящего перехода на платформу 2026.2.

Мы добавили кэширование, чтобы ускорить работу бэкэнда.

Затем кэширование нарушило авторизацию.

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

При нормальной нагрузке все работало.

При нагрузочном тестировании токен истекал, и несколько запросов одновременно проходили через один и тот же поток. Каждый из них видел пустой кэш и запрашивал у внешнего API новый JWT. Внешний API аннулировал предыдущий токен каждый раз, когда выдавал новый.

После этого часть приложения начала работать с уже недействительными токенами.

Решение заключалось не только в использовании общего Memcached, ведь проблема была не в хранилище, а в праве на обновление общего состояния.

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

Попалась функция на языке С++. На её примере прям просится показать, что, делая рефакторинг, можно не только эстетично сократить код, но и оптимизировать его. Давайте разомнём мозги, они нам ещё пригодятся, несмотря на эпоху вайб-кодинга. Кто-то ведь должен понимать, как делать надо, а как не надо.

Автотесты писали, чтобы экономить время. Но в какой-то момент поняли, что тратим на их обслуживание больше, чем экономим. 

Тест упал в CI — открываешь Allure, идёшь на стенд через VPN, авторизуешься, лезешь в DOM, ищешь, какой локатор отвалился. Полчаса-час на один тест. Прошёл релиз, и ещё пара дней уходит на то, чтобы починить локаторы после того, как фронтенд поменял вёрстку. А когда с утра видишь 200 красных тестов при нетронутом коде, начинается расследование. 

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

Всем привет! На связи Егор Лаптев — QA Fullstack Java в SENSE на проекте крупного российского банка.

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

В примерах стек Selenide, Cucumber, REST Assured, Allure, Kafka и Moon в Kubernetes, но сами принципы переносятся на любую связку UI- и API-тестов.

В июле 1980 года Recreational Computing напечатал листинг The Wizard's Castle — рогалика на BASIC для микрокомпьютера Exidy Sorcerer. Первая строка выглядела так: 10 REM"_(C2SLFF4 .

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

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

Всем привет! Меня зовут Егор Гурин и я разработчик в компании MTC Web Services. Работаю в стриме, который занимается разработкой контактного центра МТС. Практически любые обращения клиентов в компанию, будь то неработающий интернет или вопрос по заказу в интернет-магазине, проходят через нас. 

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

В этом материале я поделюсь инструментами, которые помогли наладить процессы в нашей команде в рамках методологии Document Driven Development, — возможно, вам она знакома под такими терминами как design-first или API-first. Покажу, как в удобной форме описывать контракты с помощью TypeSpec, использовать мокирующие сервера не дожидаясь реализации серверной, а еще — расскажу про инструмент кодогенерации на Go и автотесты с помощью Schemathesis.

Представим обычную обработку заказа. Сервис заказов публикует событие order.created. Сервис склада получает его и резервирует товар в PostgreSQL. После успешной транзакции обработчик должен отправить RabbitMQ подтверждение (Ack), чтобы broker удалил сообщение из queue.

Но процесс может остановиться после записи в PostgreSQL и до отправки Ack. RabbitMQ не знает, успел ли сервис зарезервировать товар. Broker видит только неподтверждённое сообщение, поэтому доставляет его ещё раз. С точки зрения доставки это правильное поведение. С точки зрения бизнеса один заказ теперь может зарезервировать товар дважды.

Другой сбой возникает раньше: PostgreSQL временно недоступен, и обработчик не может начать работу. Если сразу вернуть сообщение в queue через отрицательное подтверждение Nack(requeue=true), RabbitMQ почти немедленно доставит его снова. Пока база не восстановилась, все попытки будут бесполезными. Нужны задержка и ограничение числа повторов. При этом отложенное сообщение может пропустить вперёд более новые события, поэтому отдельно придётся решить вопрос порядка.

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

В статье разберём эти моменты по всему пути сообщения. Затем построим практическую схему для RabbitMQ и Go: добавим ограниченные повторы через retry queues, время жизни сообщения (TTL) и dead letter exchange, сделаем обработчик идемпотентным и определим, куда отправлять сообщения, которые не удалось обработать автоматически. В конце сравним этот подход с Kafka, NATS JetStream и Amazon SQS.

Я проектирую системы на LLM, и после каждого громкого ИИ‑инцидента мне прилетает одна и та же ссылка с одним и тем же вопросом: «а у нас такое может случиться?» Чтобы отвечать не на глазок, я завёл привычку разбирать каждый такой инцидент до конкретной технической причины. За последние месяцы таких разборов набралось три, и они удивили меня не сходством, а различием. Дыры, в совершенно разных местах: у одного проекта не проверялись источники, у другого, данные на границах системы, у третьего, права автономного агента. А вот причина одна: системы вокруг LLM строили люди, которые умеют писать промпты, но не умеют проектировать архитектуру.

Судите сами. Deloitte Australia возвращает правительству деньги за отчёт, в котором ИИ выдумал источники. В Миннесоте полиция четырьмя машинами блокирует на парковке журналиста, потому что сеть ИИ‑камер несколько дней вела его как угонщика, из‑за опечатки, сделанной за две тысячи миль от него. А основатель инди‑SaaS просыпается и обнаруживает, что написанный моделью код ночью отменил все подписки его клиентов и оставил бизнесу $38 месячной выручки.

Python. IT-курсы разрекламировали его как один из самых легких языков для входа в разработку, любители ИИ создают на нем свои первые нейросети, а некоторые сеньоры Java и C++ по-прежнему смотрят на него свысока, считая недостаточно строгим и производительным для «серьезной» разработки. В любом случае сегодня о Python знают все.

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

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

В этой статье мы проанализируем код одной из самых известных в мире игр: Grand Theft Auto Vice City. Это игра, на которой мы выросли. Хотя с момента её выпуска прошло более двадцати лет, код игры по-прежнему нас восхищает. Он не только хорошо работает на CPU с частотой 300 МГц (поскольку изначально его писали для PlayStation 2), но и обеспечивает игровой процесс без экранов загрузки сегментов карты, несмотря на ограничение в 32 МБ ОЗУ.

Здесь стоит упомянуть, что мы будем рассматривать не оригинальный исходный код, написанный Rockstar, а код на C++, полученный реверс-инжинирингом двоичных файлов игры. Мы поговорим о специфике эпохи PS2, почему игра почти никогда не распределяет память, о том, что весь город состоит из 25 пешеходов и 12 машин, обсудим работу физики и распознавание коллизий. В игре даже есть используемая для трюков система реплеев, которой для записи всех движущихся вокруг игрока объектов хватает одного мегабайта памяти.

Кроме того, Rockstar реализовала точно ту же механику работы с данными, что и в современных ECS-движках: целое число, в котором упакованы индекс слота и счётчик поколений, благодаря чему устаревшая ссылка ни на что не указывает.

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

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

Сегодня представляем Koda Desktop [beta] –  настольное приложение, в котором можно открыть локальный проект, говорить с агентом обычным языком, прикладывать документы и скриншоты, безопасно принимать изменения и работать с Git – в одном окне.

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

Ниже приведён краткий обзор основных новых возможностей. Полный список изменений, включая все критические изменения, доступен в разделе Что нового документации.

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

Собрали пять материалов из Базы знаний Инфостарта, которые вызвали активное обсуждение: от внедрения ТС ПИоТ и маркировки в старых конфигурациях до разработки с помощью ИИ, нейротекстов и заработка на собственных решениях...

Как я автоматизировал превращение вайбкодерского PoC в production-ready MVP

За несколько часов с помощью AI можно собрать работающий PoC: интерфейс открывается, кнопки нажимаются, основной сценарий проходит.

Потом кто-нибудь спрашивает:

А это уже можно выкатывать в прод?

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

Мне регулярно приходится заниматься именно второй половиной этой работы — превращать быстро собранные прототипы в поддерживаемые MVP.

В какой-то момент я понял, что каждый раз повторяю примерно один и тот же инженерный процесс. Так появился Pre2Prod — CLI на базе Codex, который последовательно проверяет репозиторий, составляет план исправлений, выполняет его и независимо перепроверяет результат.

Под капотом — один постоянный Reviewer, временные Workers, 41 специализированное ревью и простой цикл:

Review → Plan → Implement → Re-review

На днях наш агент собрался дежурно отчитаться об успехе. Прежде чем нажать «готово», он сверился с собственной памятью — и нашёл там запись из прошлой сессии: эту идею он уже проверял на реальных данных, и она провалилась. Он остановил сам себя, до ложного отчёта.

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

После вайб-кодинга: почему в 2026 году появляется новый класс Code Clean-up Agents. Как стоимость разработки смещается от генерации к проверке, рефакторингу и контролю изменений

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

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

В этой точке полезно отделить генерацию патча от подготовки изменения к отправке в основную ветку. Для второй задачи в 2026 году формируется отдельный класс инструментов: Code Clean-up Agents.