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

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

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

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

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

Через несколько дней (говно)кода стало много — вменяемого сервиса не получилось.

Один BFS принимал map[string][]string. DFS жил на другом типе графа. В одной реализации направленность задавалась на уровне графа, в другой вытекала из того, как было записано ребро. Опции существовали, но их комбинации не образовывали понятной политики. Result types возвращали срезы и числа, однако я не мог внятно ответить, что именно они гарантируют.

Проблема была не в том, что LLM «не умеет BFS». Я попросил реализации раньше, чем сформулировал общий контракт данных. Генератор заполнил пустые места правдоподобными допущениями — которые, очевидно, не совпали в разных кусках кода.

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

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

Продолжение истории о человеке, искусственном интеллекте и безопасности 

Коротко о первой части

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

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

Заявление громкое, но у меня есть график. Красная пунктирная линия на нём: уровень моего лучшего рукописного кода. Синяя кривая: код, который пишут агенты. В апреле 2026 кривая ушла под красную линию и продолжает падать.

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

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

В первой статье по этой теме https://habr.com/ru/articles/1054184/ я рассказывал про принципы декомпозиции программной системы на модули и слои программных компонентов на примере задачи разработки бэкенда корпоративных чатов, рассмотрел пример реализации модуля идентификации и аутентификации пользователей на языке программирования Go.

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

Я Go-разработчик, но у меня есть собственный проект — и это значит, что Go только часть работы. В обычную неделю я переключаюсь между Go-бэкендом, SQL, React и TypeScript, дизайном API, архитектурой, Docker, CI/CD, инфраструктурой, тестами и UX.

Проблема не в том, что я чего-то из этого «не знаю». Невозможно держать все эти области в голове одновременно и при этом в одиночку делать продукт целиком. Контекст-свитчинг стоит дорого сам по себе.

AI помогает. И примерно здесь у всех начинается один и тот же спор: Claude или Codex? Кто лучше пишет код, за какую подписку платить.

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

задача → нейросеть сама придумала → сама написала → сама себя проверила → сказала, что всё готово

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

Поэтому я перестал выбирать и развёл роли: Claude принимает решения. Codex реализует. Claude независимо проверяет результат.

Это дало три вещи, а не одну:

Кодинг-агенты — отличный инструмент, пока проект помещается в контекстное окно. Но чем дальше в лес, тем толще партизаны: с ростом кодовой базы начинается деградация контекста, потеря архитектурных решений, “саботаж” инструкций и другие неприятности.

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

В компании есть Kubernetes, GitLab с пайплайнами и стена дашбордов в Grafana. А деплоить всё равно страшно — по пятницам нельзя, релиз согласовывают в личке, о падении прода первым сообщает клиент. Если картинка знакомая, то у меня плохие новости в формате чек-листа. Ниже десять симптомов карго-культа с проверочными вопросами.

ArrayPool используют ради экономии на аллокациях. Но есть размеры, где он делает обратное: массив уходит в LOH, а через new остаётся в нулевом поколении.

Один такой размер зашит в .NET по умолчанию — им копируются потоки. Проверил на четырёх машинах и трёх рантаймах.

Дисклеймер: статья для разработчиков уровня junior и middle, которые знакомятся с принципами чистого кода и SOLID. Примеры кода — PHP 8.1+.

Всем доброго дня! На связи Валевич Артем — тимлид в компании AGIMA. В первой части серии мы разобрали Single Responsibility Principle на кейсе системы отзывов и пришли к простому выводу:

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

Разберём три способа кастомизации на одном компоненте и посмотрим, какие доработки переживают обновления, а какие требуют постоянного сопровождения.

По данным GitLab, 91% компаний держат в работе минимум два ИИ‑инструмента, 54% — три и более. 78% команд пишут и коммитят код быстрее, чем раньше, 60% говорят, что отдача от ИИ превзошла ожидания, 73% отмечают рост качества кода. По любым меркам внедрение состоялось. А теперь «менее успешная цифра»: 80% признают, что подключили ИИ‑инструменты раньше, чем придумали, как ими управлять. Скорость обогнала контроль, и вся история начинается ровно на этом стыке.

В прошлый раз я писал о переходе на Spec-Driven Development и честно оговорился: над спеками у меня надстроен слой roadmap, и это не канон Spec Kit. В коробке верхний уровень - спека, ничего выше не предусмотрено. Потом я открыл concepts/spec-of-specs.html в официальной документации. Там черным по белому описано ровно то, что я делал последние недели. С той же мотивацией, с той же структурой, местами теми же словами. Но разница есть…

Точнее, на Spec Kit от GitHub. Полгода назад я бы над этим посмеялся: спеки, планы, декомпозиция задач - привет из 2010-го, когда это называлось waterfall и все дружно от него убегали. Оказалось, убегали не от спек, а от того, что их писали люди и потом никто не читал. В этой статье расскажу, где я отхожу от стандарта в угоду скорости.

Что такое SDD в исполнении Spec Kit по сути…

Привет, Хабр!
Это первая статья из планируемого цикла про мой объектно-ориентированный подход к написанию кода для микроконтроллера stm32 (а именно камня stm32f303vc на отладочной плате stm32f3discovery) с использованием возможностей языка вплоть до стандарта c++20. Но обо всём по порядку.

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

В этой статье Ирина – тимлид компании «Совкомбанк Технологии» – подробно расскажет, как ей вместо с командой удалось выстроить работу с техническим долгом на проекте с 8-летней историей: с чего начать, как приоритизировать задачи, какие инструменты и процессы внедрить.

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

Проверить строку регулярным выражением в .NET можно по-разному, но совет всегда один: включите RegexOptions.Compiled или возьмите генератор. Замеры это подтверждают.

А вот подготовка выражения оказалась не там, где её меряют: конструктор занимает 10 микросекунд, а первая же проверка на этом объекте — ещё 1307. Разобрался, куда уходит разница, и заодно нашёл границу, на которой статический Regex.IsMatch резко замедляется.

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

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

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

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

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

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

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