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

Сейчас почти все представляют AI-разработку одинаково. Агент пишет код. Разработчик открывает diff, делает code review и разрешает релиз. То есть мы заменили программиста на AI, но сам процесс практически не изменился.

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

Почему бы не применить этот принцип к разработке? Если после изменений система проходит все тесты, выполняет продуктовые сценарии, не ломает существующее поведение, укладывается в требования по производительности и безопасности, то зачем вообще читать код? Мы ведь никогда не проверяли код ради кода. Мы всегда пытались понять только одно — правильно ли работает система. Раньше это было невозможно без code review. Код писал человек, и только другой человек мог оценить его качество.

Но теперь код все чаще пишет AI.

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

В апреле 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) понимают процесс проектирования архитектуры, компонентов, баз данных и связей информационной системы. Цель системного дизайна - обеспечить масштабируемость, отказоустойчивость и высокую производительность системы, в том числе при росте нагрузки. В этой статье я затрону базовые задачи системного дизайна - как спроектировать и разработать систему так, чтобы она обладала архитектурой, чтобы развитие и поддержка системы не приносила много страданий, чтобы доработки не ломали действующий функционал.

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

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

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

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

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

В этой статье я разбираю не абстрактный “AI-хайп”, а реальные кейсы: дипфейк-кражу $25 млн у Arup, открытую ClickHouse-базу DeepSeek, отзыв токенов Hugging Face Spaces, фишинг через легитимные AI-workspace invites, сбой Replit-агента и исследования вроде EchoLeak и BioShocking.

Главный вопрос не в том, “может ли модель взломать компанию”, а в том, какие права мы уже выдали AI-инструментам и что произойдёт, если недоверенный контент станет инструкцией для агента.

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

Этой весной американский разработчик программного обеспечения Oracle уволил почти 30 000 сотрудников в ходе трансформации компании. Председатель совета директоров и технический директор корпорации Ларри Эллисон уверен, что завтра выиграют те, кто сегодня строит инфраструктуру для ИИ. Поэтому бизнес инвестирует миллиарды в строительство дата-центров. Согласно недавним заявлениям Oracle, в 2027 году объем инвестиций в это направление составит $70 млрд. А увольнения позволят высвободить до $12 млрд в год, что за несколько лет покроет эти затраты.

Oracle — не единственная технологическая компания, запустившая массовые сокращения в последние пару лет. В прошлом году Microsoft уволила 15 000 сотрудников, Meta — 8 000. А Amazon за два года отказалась почти от 50 000 сотрудников. В общей сложности без работы уже остались 165 000 представителей технологического сектора.

Хотя масштабы увольнений поражают, они не редкость для переходных времен (когда появляются новые технологии). Пока этот тренд особенно заметен на западном рынке труда, но волна, вероятно, дойдет и до России. Предпосылки уже есть: сокращение и избирательность найма, «скрытые» увольнения, заморозка роста заработных плат и другие признаки охлаждения рынка.

За свои 17+ лет в активной разработке я встречал много проблем, но одна преследовала меня постоянно: JSON. Нет, с самим форматом все ок, но вот с его чтением — не все норм.

Когда я только начинал работать с PHP, я списывал это на скриптовость языка. Отчасти из‑за этого я даже поменял стек. Но когда приходили по‑настоящему большие файлы, это всегда было больно. Иногда — очень. Был проект, где мы ждали не обработку информации бизнес‑логикой, а банального парсинга. Файлы доходили до десятков гигабайт и не всегда влезали в оперативку. Тогда я и заработал себе персональный todo — разобраться с этим раз и навсегда.

Сейчас, находясь в поиске новых возможностей, я решил вспомнить эту старую боль. Я уже давно не PHP‑разработчик, но проблема в индустрии всё та же. Объемы данных растут, требования тоже, а воз и ныне там. Нет, есть море крутых решений. Даже тут, на Хабре. Но для меня всё не то.

Мне нужно решение, а не костыль. То есть: никакой кодогенерации и никаких JIT (я не противник JIT, просто не хочу тянуть эту сложность).

Я ступил на тонкий лед: в Go есть классная штука — пакет unsafe. Почему классная? Потому что она позволяет обойти тяжелые ненужные проверки. Плюс побитовые операции для ускорения всего, до чего только смогли дотянуться руки. Пока изучал чужие парсеры, столкнулся с обманом в репозиториях, подкручиванием статистики (куда же без него?) и перекладыванием ответственности (и аллокаций) на сторону разработчиков.

Алгоритм вывода цветного текста в консоль и как его можно написать на AutoHotkey. Погрузимся в язык, рассмотрим оптимизацию кода и улучшение читабельности (применимо к любому высокоуровневому языку).

Вайб-кодер в чистой форме — человек, который вообще не имеет отношения к разработке — физически не способен оценить код. Для него работает = работает. А я утверждаю: код, сгенерированный нейронкой, всё равно будет более плоским, более ущербным и менее оптимальным, чем код живого разработчика. Проблема в том, как это доказать человеку, который код читать не умеет. Поэтому зайдём через аналогию, которую может проверить КАЖДЫЙ — через тексты.

В 1865 году британский журналист Томас Майн Рид написал роман "Всадник без головы", который послужит нам отправной точкой в вопросе о том, что же такое "безголовая" CMS и какие из них представлены сейчас на рынке веб-разработки.

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

За последний месяц я насчитал минимум семь свежих статей с заголовком в духе "Playwright быстрее Selenium на N%". Проблема в том, что N у всех разный: 23%, 42%, 63%, "1.85x". Методология почти нигде не раскрыта дальше фразы "controlled environment". Для решения, которое определяет CI-бюджет и архитектуру тестов на годы вперёд, это не цифры — это шум.

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

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

Под катом — пространное эссе о том, почему "удобно" и "просто" — разные вещи.

В 2026 году софт всё чаще пишут с участием ИИ: по данным Stackoverflow, 84% разработчиков уже используют ИИ‑инструменты или планируют начать. Но у скорости есть цена. Исследователи Faros AI зафиксировали парадокс: в командах с активным ИИ разработчики закрывают на 21% больше задач и мёржат на 98% больше пул-реквестов — а время ревью при этом выросло на 91%.

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

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