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

Всем привет! Меня зовут Антон Рыков и я backend-разработчик в компании "Исходный Код".

Пять CRUD-эндпоинтов. К обеду я понял: бизнес-логика заняла минут двадцать. Остальные два часа ушли на UUID вместо автоинкремента, одинаковые DTO с валидацией и ручную уборку временных файлов на стейджинге. Пальцы работали. Голова — нет.

Почти любая команда на Symfony рано или поздно упирается в ту же стену: фреймворк перестаёт быть помощником и превращается в конвейер. make:entity → вырезать integer id → прикрутить трейт дат → руками разобрать $request в контроллере. Снова. И снова.

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

В статье — четыре уровня, которые убрали это трение у меня. Настроите PhpStorm так, чтобы скелет JSON-экшена появлялся по Tab. Уберёте ручной json_decode и isset через MapRequestPayload и строгие DTO. Научите MakerBundle сразу генерировать сущности с UUID и вашими трейтами. Перенесёте cron в PHP через Scheduler - расписание

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

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

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

As we say, two of the most complicated problems in software are naming things and versioning software

Когда-то в кулуарах Devoxx Belgium нечто подобное сказал Томас Вюртингер, лид проекта GraalVM, поясняя детали вот этой нашумевшей статьи. Это не точная цитата, а лишь фраза, призванная обратить внимание на проблему. О ней сегодня мы и поговорим.

Всем привет! Меня зовут Михаил Поливаха, я являюсь техническим лидером Open Source проекта Axelix.

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

Покажу, как можно ускорить код h11 (HTTP/1.1 библиотечка со 710k пользователями на Github) с помощью компиляции с mypyc примерно в два раза. В процессе расскажу, как я чинил разные интересные ошибки, связанные c адаптацией кодовой базы под mypyc.

Большой контекст LLM не гарантирует качественных ответов: при работе с объёмными документами модель может терять важные детали и хуже находить нужные факты внутри текста.

В статье разбираемся, почему Full‑Context и базовый RAG сталкиваются с ограничениями, и как подход Semantic Gatekeeper помогает повысить точность ответов за счёт подготовки релевантного контекста перед передачей его основной модели.

Компания когда-то забрала 99% рынка демпингом, а потом шесть лет подряд теряла продажи. Внедрение ИИ за год буксовало, человек, который им занимался, ушёл, кеш закончился. Меня позвали на месяц с оплатой по факту. Рассказываю, что успел: агент проверяет сборку заказов по фото, агент-менеджер закрывает 95% чатов с клиентами, отдельный агент деплоит мелкие правки прямо из рабочего чата, старую логистику на Perl заменил софт на Python, а над всем этим сидит главный агент-погонщик. И почему сотрудники ходили жаловаться на коллег, которых не существовало.

Те из нас, кто пробовал модный вайбкодинг, уже оценили обратную сторону медали. Агенты уверенно говорят: «Сейчас всё сделаю», несколько часов пишут и тестируют код, после чего предлагают задеплоить получившееся в кластер Kubernetes и настроить observability. Для пет-проекта с парой страниц веб-интерфейса.

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

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

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

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

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

Есть один, уже набивший оскомину спор, по популярности уступающий, пожалуй, только извечному спору Iphone vs Android. Это спор сможет ли вайбкодер с ИИ заменить программистов старой школы.

Все в итоге плюс минус сходятся во мнении, что вайбкодеры «с нуля» не смогут. Опытный программист с ИИ — это как грузчик с экзоскелетом — может гораздо больше унести. А вот опытный вайбкодер, собаку съевший на особенностях работы с ИИ? Он не знает ЯП двадцать лет. Зато рядом с ним сидит машина, которая умеет генерировать код, читать документацию, анализировать репозиторий, писать тесты, искать ошибки и выполнять десятки итераций за время, за которое человек успевает открыть документацию и сделать задумчивое лицо.

Поэтому родилась такая мысль: а кто сегодня быстрее и качественнее решит реальную инженерную задачу? Не — кто лучше пишет код. Не — кто умнее. Не — кто красивее оформляет GitHub. А кто за ограниченное время выдаст лучший работающий результат. Предлагаю устроить эксперимент.

Всем привет! Этой весной я искал работу, и в какой-то момент пришел к тому, что на сами отклики у меня уходит минут тридцать, а весь остальной вечер я трачу на то, чтобы просто обойти площадки и посмотреть, не появилось ли чего нового. То есть я не работу искал, я вкладки открывал.

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

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

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

И сразу заранее: все цифры ниже про мою базу, а не про рынок целиком. Спорить с ними можно и даже нужно :-)

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

Закончил я через два месяца.

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

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

Самая дорогая модель оказалась самой быстрой: 341 секунда против 395 у самой дешёвой, потому что ей нужно меньше ходов и вдвое меньше текста. Четыре задачи из пяти решили все, 32 прогона из 32. А на пятой младшая модель написала баг и отчиталась двумя галочками подряд, вторая из которых опровергает первую.

Почему ограничение полномочий модели ещё не означает, что AI-система действительно стала read-only. Разбираем runtime control на примере n8n + DeepSeek + HubSpot.

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

Считаю что по настоящему первое впечатление команда и кандидат формируют друг о друге не только на собеседовании, а в течение первых недель (иногда месяцев, или даже лет) после того как новый сотрудник вышел на работу. Верю, что взаимовыгодно для обеих сторон интегрировать нового коллегу в процессы и в реальную работу как можно быстрее. Однако вижу, что реализовано это плохо в большом количестве IT компаний. Несмотря на изрядное количество материалов про важность онбординга… И потому предлагаю обсудить как это можно улучшить еще раз под катом. Технический онбординг — это не «сам разберешься»

В предыдущем материале про Орбис я обещал разобрать игровые механики, которые делают эту игру неповторимой в своем разнообразии. Уникальными расами, юнитами и скиллами тоже можно удивить — с точки зрения атмосферы и креативности тут все в порядке. Но принципиально игровая техника «тактического звена» похожа на другие игры. Тут я хотел сделать акцент на глобальные процессы, которые влияют на сюжет и делают его динамичным, а порой и непредсказуемым. Я не встречал стратегий AAA-класса с похожим многовариантным сюжетом. Обычно в играх сюжетная линия идет по плану, максимум слегка разветвляется, а динамика есть следствие относительно линейной ветки развития технологий.

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

В модификации Orbis (на базе Civilization IV: Beyond the Sword) разработчик Ahwaric и команда Fall from Heaven II превратили саму карту и физику мира в нестабильную, разрушаемую систему. Здесь планета Эребус (Erebus) может заболеть, покрыться адом или вымерзнуть до экватора — и за этой экологической катастрофой стоит прозрачная математическая модель. 

Разбираем, как три системных механики Orbis — Счетчик Армагеддона, климатическое оружие и магическая логистика — создают уникальную военную драму. 

За три дня вокруг Jev выросла маленькая экосистема: браузерный агент искал авиабилеты за семь секунд, разработчики собрали торгового бота, фильтры контента и даже Tesla FSD. Но Jev не пишет текст. Его API выбирает ответ из пространства, которое заранее задало приложение.

Я разобрал документацию TypeSafe, код jev-ultrafast, опубликованную трассу семисекундного прогона и сто первичных или близких к ним источников. В статье — контракт Noul, Choice и Score, вызов API, цена, устройство браузерного агента и 15 ранних кейсов с границами их доказательности.

Главный вопрос простой: где узкий слой решений действительно выигрывает у обычной LLM, а где валидный ответ всё ещё оказывается просто не тем ответом?

Часто ли вы сталкиваетесь с проблемой потери данных, неконсистентными состояниями или ошибками в Sentry о внезапно закрытых соединениях при рестарте сервисов? Если вы когда-нибудь пытались это исправить, то наверняка слышали про Graceful Shutdown.

Привет! Меня зовут Антон, я бэкенд-разработчик Python в Selectel. В этой статье поделюсь опытом внедрения Graceful Shutdown в наши сервисы и расскажу, с какими сложностями мы столкнулись.

Сгенерированная картинка для привлечения внимания. Промпт: «Продемонстрируй, что всё новое — это хорошо забытое старое» (нет)

За последний год инструментов для агентной разработки стало столько, что в них легко потеряться: одни обещают сохранять контекст между сессиями, другие — «понимать» всю кодовую базу целиком, третьи — память, планирование и автономность в одном флаконе. На GitHub каждую неделю появляются репозитории с внушительным (и не всегда честно заработанным) числом звёзд, которые обещают всё и сразу, а на поверку оказываются README-проектами; другие честно работают на демо-репозитории и падают с OOM при первой же встрече с реальным энтерпрайз-проектом — и так далее, список можно продолжать долго.

Осенью прошлого года я пользовался связкой Claude + RooCode + семантический поиск на Ollama, и это был мой основной рабочий инструмент — ровно до того момента, как связка перестала работать (об этом чуть ниже). Я решил полностью пересесть на Claude Code и начал искать замену семантическому индексу, но так её и не нашёл: альтернативы для меня просто не работали — на монолите в 3,5M+ строк они либо индексировались часами, либо требовали отдать код в облако (и заплатить немалую сумму за эмбеддинги!!!), либо поддерживали Ruby, мягко говоря, номинально. В итоге я принял непростое для себя решение сделать собственный инструмент — начав с форка простого движка семантического поиска на Ollama + Qdrant — и, что характерно, сделал: полностью локальный, чтобы ни код, ни его производные (индекс, эмбеддинги, граф вызовов) никуда не уезжали. На сегодняшний день на него ушло больше полугода (и, честно признаюсь, не одна сотня чашек чая).