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

Полгода я давал LLM писать unsafe Rust в боевых проектах и разбирал каждый блок под miri и санитайзерами. Категории ошибок, которые модели делают стабильно: aliasing, провенанс, layout в alloc/dealloc, забытый ManuallyDrop, гонки в FFI-колбэках, ручные Send/Sync, uninit-память, Pin. Каждая категория идёт с минимальным примером и фиксом.

Мы не боимся использовать ИИ в разработке. Потому что знаем, как сделать, чтобы изменения в коде не ломали то, что работало до этого. Знаем, как научить ИИ соблюдать требования, а не выдумывать их. И как заставить ИИ писать легкий поддерживаемый код. Рассказываю на конкретном примере.

Пока в приложении две роли и три проверки, авторизация умещается в if user.Role == "admin". Но стоит добавить пару ресурсов, ролей и исключений — и условные проверки начинают расползаться по хендлерам, дублироваться и жить своей жизнью.

В этой статье разберём, как навести порядок с помощью Casbin: вынесем правила доступа из кода в конфиг, пройдём путь от простого ACL до RBAC с иерархией ролей, соберём HTTP-сервер на Go с авторизационной middleware и обсудим грабли, на которые легко наступить по дороге.

Вторая статья цикла о внутрянке Celery: на этот раз — зелёные потоки (gevent/eventlet). Как gevent и eventlet работают под капотом Celery, что такое Hub, monkey patching и почему autoscale для гринлетов бесполезен. А ещё — неожиданный бенчмарк: prefork против gevent на одном ядре. Спойлер: gevent проигрывает, но не спешите его хоронить. Для тех, кто выбирает пул под свои задачи. А пойду готовить докер-селери-кубер-автоскейл.

Все мы начинали писать на Python примерно одинаково: создавали пустой список, запускали цикл for, проверяли условие через if и делали .append(). Это надежно, предсказуемо, но по мере роста кодовой базы такие конструкции начинают утомлять — мы тратим 4-5 строк на банальную трансформацию данных, которую можно уложить в одну лаконичную строку.

В этой статье мы подробно разберем встроенный инструментарий Python для работы с итерируемыми объектами: map, filter, reduce, any, all, zip и enumerate.

Недавно я был на отраслевой конференции, где встретил пару знакомых, с которыми начинал ещё в питерских студиях. В отличие от меня, который всегда работал на «дядю», они в какой-то момент выбрали тернистый путь создания инди, своих студий и (судя по тому, как они заказывали напитки) этот путь оказался значительно тернистее, чем выглядел десять лет назад. Хотя глаза у них горели ровно так же, как тогда. Что тогда, что сейчас эти горящие глаза одновременно вызывали и зависть, и лёгкое подозрение, что они просто не успели ещё по-настоящему устать.

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

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

Dataclasses появились в Python 3.7 и быстро стали стандартом: меньше бойлерплейта, чем у обычных классов, проще, чем attrs, и не требуют зависимостей. Выглядят настолько просто, что кажется, что ломаться там нечему. Но у них есть три ловушки, которые не видны при написании.

15 мая Vercel Labs релизнули Zero. Экспериментальный системный язык, который сами авторы называют "the programming language for agents". Версия 0.1.1, Apache 2.0, расширение .0, бинарники меньше 10 килобайт, без LLVM. На GitHub лежит компилятор, стандартная библиотека и примеры — можно ставить и щупать прямо сейчас.

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

Если коротко — наверное серьёзно, но мне сейчас не нужно. Тебе, скорее всего, тоже. Сейчас расскажу, что там и почему я так думаю.

Когда продакшен падает в три часа ночи, строка ERROR Something went wrong не помогает никому. В статье разбираем, почему привычные текстовые логи быстро превращаются в шум при реальной нагрузке, как перейти на structured logging, зачем каждому запросу нужен request_id и как настроить нормальные JSON‑логи в Python и Go без лишней инфраструктуры.

Каждая AI‑лаборатория прямо сейчас работает себе в убыток, обслуживая вашу компанию. Они это знают. И делают это намеренно.

OpenAI, Anthropic, Google и остальные реализуют отраслевую программу субсидирования в масштабах, не имеющих прецедента. Они продают предприятиям вычислительные мощности по ценам ниже себестоимости, называя это бизнес‑моделью. Разрыв между тем, что ваша компания платит за AI‑подписки, и тем, во что реально обходится их обслуживание, — это не погрешность округления, а пропасть. И любая организация, выстроившая рабочие процессы, продукты или целые бизнес‑подразделения на основе субсидированных цен, стоит прямо на её краю.

Это должно быть в приоритете для каждого CTO, CFO и операционного директора. Когда цены скорректируются — а они скорректируются — компании, воспринимавшие AI как вечно дешёвую коммунальную услугу, получат счета, перед которыми их текущие расходы на SaaS покажутся мелочью.

Привет, я Иван из НИИ Крокодил. Это небольшая команда внутри ИЖ-РЭСТ, завода штампов и пресс-форм. Если коротко, мы пришли на завод из IT и теперь пытаемся понять, где можем быть полезны.

Но началось всё, конечно, не с робота.

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

Так я оказался на заводе. Мы не пришли учить завод жить. Скорее наоборот: сначала сами учимся понимать, как здесь всё устроено, а потом пробуем аккуратно добавлять то, что хорошо работает в IT.

На этом фоне у нас и появилась задача со сварочным роботом.

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

Давайте к делу.

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

Примерно в ноябре я начал применять их не только для программирования, но и для другой рабочей рутины. Делал презентации в Slidev, использовал ИИ-помощников как секретарей для заметок с голосового ввода и искал, какие еще материалы можно поручить такому инструменту: index.html, PDF, таблицу, набор слайдов.

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

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

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

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

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

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

Оказывается, на эффективность парного программирования влияет не только скиллы участников процесса, но и их психологическая совместимость. 

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

Это конспект вебинара. Спикер — Даниил Степанов, разработчик‑исследователь Veai, преподаватель ИТМО, ранее работал в JetBrains и Huawei.

AI уже пишет заметную часть промышленного кода, а процессы качества у многих команд остались такими, будто код всё ещё пишет только человек и в прежнем объёме.

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

Одна из самых неприятных особенностей production-проблем заключается в том, что они почти никогда не происходят тогда, когда разработчик готов их исследовать.

Во время разработки всё работает. На тестовом стенде тоже всё выглядит нормально. Логи кажутся вполне достаточными, а диагностическая информация — продуманной и аккуратно организованной. Но затем в production внезапно появляется странная проблема: соединение иногда сбрасывается без видимой причины, один запрос из нескольких тысяч начинает вести себя иначе, сервер под высокой нагрузкой неожиданно входит в reconnect loop или где-то глубоко внутри системы начинает происходить что-то, что невозможно воспроизвести локально.

И почти всегда в этот момент выясняется одна и та же неприятная вещь: логов, которые уже есть в системе, недостаточно.

Именно здесь традиционное логирование начинает постепенно ломаться.

Большинство систем логирования до сих пор построены вокруг довольно простой идеи: заранее решить, какие сообщения должны писаться постоянно. Разработчик добавляет INFO, WARNING, DEBUG, иногда каналы или категории, после чего приложение отправляется в production с надеждой, что этих логов когда-нибудь хватит для диагностики.

Иногда действительно хватает.

Но реальные production-системы имеют неприятную привычку ломаться не там и не так, как ожидалось. Более того, проблемы часто возникают именно в тех участках кода, которые казались совершенно неинтересными во время разработки.

Первой реакцией обычно становится мысль: “давайте включим DEBUG logging”. На небольших проектах это ещё может работать вполне нормально. Однако в больших системах DEBUG-логи очень быстро превращаются в проблему сами по себе. Они начинают занимать гигабайты, полезная информация тонет в шуме, растёт нагрузка на диск, а иногда и само логирование начинает заметно влиять на производительность и тайминги приложения.

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

Содержание

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

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

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

В этой статье я расскажу, как попробовал дешевую альтернативу Claude, создал рабочую программу для macOS и вместо 13$ - потратил 0.25$