Качество кода *

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

Под катом — как этот шов гниёт под LLM и как его чинит contract-first: генерация серверных интерфейсов и клиента из одного OpenAPI-файла, политика ломающих изменений, правило «не симулируй — расширяй контракт». Попутно — зачем возвращаться к идее, которую мы выбросили вместе с WSDL, и какая из моих проверок после всего этого молча перестала работать. Третья часть цикла, читается самостоятельно.

Я разработал плагин, чтобы помочь разработчикам Telegram ботов.

Он работает поверх aiogram – не нужно будет переписывать уже имеющийся код.

И если ты хоть раз писал ботов, эта статья сэкономит тебе много времени и нервов.

FrozenDictionary сделан под словари, которые заполняют один раз при старте, а дальше только читают. Замерил на четырёх машинах и трёх рантаймах — разброс вышел от ×0,76 до ×1,9, и зависит он не от версии .NET, а от того, сколько ключей и как они устроены.

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

Структура в роли ключа Dictionary — частый случай. Забыл IEquatable — и каждый TryGetValue в 4,4–5,7 раза медленнее, плюс 96 байт в куче на каждый поиск.

Проверил на четырёх машинах и трёх рантаймах, снял дизасм FindValue и разобрал, откуда берутся ровно три упаковки, почему override Equals не спасает и при чём тут хэш record struct. Сам рантайм этот разрыв не закроет — и это не баг.

В первой части мы успешно вскрыли чёрный ящик LINQ: написали Where вручную, разобрались, как компилятор превращает yield return в конечные автоматы, и посмотрели на методы с частичной буферизацией. Но LINQ был бы не собой, если бы на этом всё закончилось.

Во второй части переходим к «тяжёлой артиллерии» — OrderBy, GroupBy и Join. Эти методы вынуждены нарушить главный завет ленивых вычислений: они материализуют данные в памяти, прежде чем отдать хоть один элемент. Но как именно?

После этой статьи LINQ перестанет быть чёрным ящиком: вы будете точно понимать, сколько памяти съест каждая цепочка методов и в каком порядке следует вызывать эту цепочку.

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

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

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

Чтобы показать вам драматизм ситуации, я для примера провёл с помощью профилировщика PHP измерение ресурсозатратности каждой линейки семейства WordPress - это версии 1, 2, 3, 4, 5, 6 и недавняя 7.

Кому интересно, прошу под кат. Увидите, как от первых версий, на которых WordPress завоёвывал славу легковесной блоговой системы, он пришёл в конце концов к многократно утяжелённой платформе по множеству срезов измерения.

Привет, Хабр! Меня зовут Артур, директор по безопасности NtechLab и энтузиаст вайб-кодинга). Сегодня поговорим о применении вайб-кодинга в информационной безопасности внутри компании: реально ли использовать нейросеть для создания продукта «под ключ» или это заранее путь в никуда. Присаживайтесь, нас ждет увлекательное путешествие и море слез - без этого никуда:)

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

Идея создания «продукта под себя» родилась не из абстрактного желания поиграться с нейросетями, а ради формирования еще одного контура безопасности. Сотрудники уведомлены о применяемых средствах защиты, но мне хотелось не тотальной слежки, а понятной системы предотвращения и разбора инцидентов.

Первое «почти готово»

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

За четыре месяца работы в паре с Claude Code вокруг проекта наросла инфраструктура, которой в первый день не было и в помине: пять скиллов, четыре хука, 2066 строк собственных скриптов. Разбираю четыре проблемы, которые пришлось решать не промптом, а кодом — и три случая, когда агент уверенно врал.

Мысли о масштабируемой архитектуре приложений через кодовую структуру и философии «developer as a user»; подходит для indie-разработчиков и стартапов на ранних стадиях.

Каждый C#‑разработчик писал numbers.Where(x => x > 10).Select(x => x * 2) — и удивлялся, узнав, что эта строчка ничего не вычисляет. Цепочка спит, пока мы не начнём перебирать результат.

За этим стоит конкретный механизм — отложенные вычисления, а в его основе лежит обычная фича языка: yield. Разбираем, как устроены ленивые методы LINQ изнутри — от ручной реализации Where без yield до того, во что этот yield разворачивается компилятором.

А вы точно знаете, что происходит под капотом каждый раз, когда пишете .Where(...).Select(...)?

К статье приложен репозиторий с полной реализацией.

К концу второго месяца vibe coding на фронте моего пет-проекта жили пять компонентов кнопки, четыре спиннера, компонент страницы на 700 строк и шапка, которая показывала один баланс, пока модалка рядом показывала другой. LLM-агент писал всё это уверенно, быстро и с хорошим стилем кода. Фронтенд под LLM деградирует даже быстрее бэкенда — и тому есть причины: от качества обучающей выборки, где вперемешку лежат три поколения React, до самой природы JSX, где разметка, логика и состояние легально живут в одном файле.

Под катом — что в итоге сработало: Feature-Sliced Design, урезанный до трёх слоёв, как карта для агента; dependency-cruiser в роли архитектурного контракта, который нельзя нарушить; кодогенерация API-клиента из OpenAPI вместо доменной модели; за что я простил Tailwind; и честно — про самое слабое место конвейера: агент, который верстает вслепую. Это продолжение статьи про бэкенд, но читается и само по себе.

Открой свой Spring-проект, которому больше двух лет. Найди пакет common, core или framework — а он там есть, я почти уверен. Загляни внутрь.

Ты увидишь BaseEntity с id, createdDate и version. Увидишь AbstractCrudController<T, ID>, от которого наследуются все твои контроллеры. Увидишь самодельный слой прав — что-нибудь вроде @CheckPermission поверх PermissionEvaluator. Увидишь свой SoftDeleteRepository и аудит-слушатель на JPA-события.

Поздравляю: ты написал фреймворк. Свой, внутренний, недокументированный (себя-то не обманывай), поддерживаемый одним человеком (который уже собеседуется в другую компанию). И построил ты его ровно для того, чтобы не брать «тяжёлый и навязчивый» opinionated-фреймворк — ты сделал это «ради контроля».

Давай честно поговорим про этот контроль.

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

Привет, меня зовут Андрей, я занимаюсь автоматизацией тестирования в hh. В этой статье расскажу, как мы оптимизировали запросы нашего бота, который анализирует тестовое покрытие с помощью LLM, чтобы получить максимум пользы при минимальных затратах.
Антоним токенмаксинга – токенпожарскинг токенминнинг?

В апреле 2026 года глава Google Сундар Пичаи сказал, что 75% нового кода Google сгенерировано AI. Динамика: 25% в начале 2024 года, 50% к концу 2025 года, 75% к апрелю 2026 года.

Согласно Sonar 2026 State of Code Developer Survey, 96% разработчиков не доверяют функциональной корректности AI-кода полностью. 95% тратят время на его проверку, тестирование и исправление, а 38% считают такое ревью более трудоемким, чем проверку кода, написанного человеком. Генерация кода подешевела, контроль за ним - нет.

Thoughtworks в Technology Radar vol. 34 (апрель 2026) ввел термин codebase cognitive debt - разрыв в понимании между человеком и кодовой базой, который растет по мере того, как AI генерирует все больший объем кода.

Узкое место производственного процесса сместилось с написания спецификаций и кода на постановку задачи AI (intent) и контроль генерации (review): что именно должна делать система, в каких границах и кто проверяет, что AI-агент сделал именно это. Код производится быстрее, чем кто-либо успевает подтвердить его соответствие требованиям. Качество, стабильность и сопровождаемость держатся на том, кто и как организует постановку и проверку. Это зона ответственности архитектуры.

Квалификация архитектора смещается от проектирования общих и детальных архитектурных решений к владению контекстом системы, спецификациями и AI-платформой.

В этой статье я, Алексей Соболеков, архитектор решений, разберу изменение роли архитектора в агентной разработке. Я прошел три модели архитектурного процесса.

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

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

Для поиска таких мест были созданы разные инструменты профилирования. Этим термином называют всестороннее измерение нагрузки, оказываемой исследуемым скриптом на сервер сайта. Например, для языка PHP наиболее известными профилировщиками кода являются следующие: Blackfire, Xdebug Profiler, Tideways, XHProf/XGHui.

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

Для решения подобной узкой задачи я разработал очень простой бесплатный профилировщик PHP. Так сказать, студийную версию профайлера, то есть урезанную до объёма, достаточного вебмастеру при работе над проектами в студии. И делюсь этим скриптом с сообществом. Кому интересно, прошу под кат.

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

Под катом — что я понял и что в итоге сработало: почему LLM деградирует на плохой архитектуре точно так же, как команда людей; почему SOLID, DDD и чистая архитектура не устарели, а стали важнее; и как превратить архитектурные договорённости из «пожеланий в CLAUDE.md» в контракт, который машина не может нарушить. С конкретикой: два конфига deptrac для Symfony-бэкенда и пайплайн разработки с субагентом-ревьювером.

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

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

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

Эта статья прежде всего будет полезна студентам и начинающим специалистам.

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