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

Я не программист. По крайней мере, несмотря на то, что в 2010 году я закончил «Прикладную информатику в менеджменте» (ДГТУ) и учился писать на C++, таковым в настоящее время себя не считаю.

При этом с июля 2026 года я управляю большим продуктом (собственная фабрика аналитики, своего рода ERP внутри компании), код которого пишут ИИ‑агенты. Я даю задачи голосом (не помню, когда в последний раз формировал текст задач на клавиатуре), агенты пишут код, проверяют его и выкладывают новую версию на сайт. Продукт собран на Next.js 16, TypeScript и PostgreSQL. На 1 октября в истории проекта уже более 6500 коммитов и 1.800.000 строк кода.

Код я не читаю. Поэтому между словом агента «готово» и появлением новой версии на сайте стоят автоматические проверки. Их называют «сторожами», сейчас их около двухсот. Если хотя бы один сторож покраснел, новая версия не попадает на сайт, а я получаю в Telegram сообщение «выкат остановлен» со списком красных.

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

Спор о русском в коде обычно ведут идеологи. Одни требуют «программировать на родном», другие крутят пальцем у виска. Но если убрать эмоции, остаётся инженерная задача: где локализация снимает трение, а где создаёт новое?

Мы 60 лет учим разработчиков думать по-английски, чтобы они могли программировать. Не «знать английский» — это нормально. А думать на нём, когда пишут код на русском домене. Юрист, читающий спецификацию, и разработчик, читающий код, говорят на разных языках — и мы называем это профессиональным стандартом.

Пора это признать. И посмотреть, во что это обходится на практике.

Агент проверял разворот на палиндроме, а порядок четырех потоков - на четырех одинаковых входах. Тесты проходили и с ошибкой. В эксперименте Дэна Лу указания использовать TDD, фаззинг и формальные методы не дали убедительного общего выигрыша над контролем. Разбираю три механизма бесполезных проверок и показываю исполнимый пример: как намеренно внести конкретный баг и убедиться, что тест его обнаруживает.

В самом начале, когда начали появляться первые ИИ-агенты и плагины для IDE-шек, я думал: а, очередная новомодная фишка. Надо будет как-нибудь посмотреть, когда время будет. Тогда я еще не подозревал,  насколько мощные эти инструменты, а ChatGPT и прочие генеративные нейросети воспринимал как «прикольную игрушку».

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

Всем привет! Нет, я не навайбкодил очередную обёртку над OpenRouter и не буду продавать её в этой статье. Повод не случайный: очередная массовая волна банов от Anthropic — на этот раз банят даже давно живущие, трастовые личные аккаунты.

Кто я: Лёша Жиряков, амбассадор агентной AI-разработки, веду воркшопы, делюсь опытом. Меня на них часто спрашивают, на чём жить, если основные инструменты отвалились. Код писать надо вчера, а что вообще пускает с российского IP, толком никто не знал. Я взял curl и прошёлся по 25 сервисам.

TL;DR: с домашнего IP, без VPN и прокси, по 25 сервисам: живых 9 (OpenCode, Qwen, Z.ai, DeepSeek, MiniMax, Mistral, Kimi, Zed, Trae), не пускают 15. Замер: 1 октября 2026.

Я решил 1.5 года делать игру и хочу ей поделиться.

Основной сюжет моей игры, ее механика и над чем работаю сейчас.

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

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

Дэкс Хорти из HumanLayer объясняет, почему “фабрика кода с выключенным светом”, где агенты пишут, ревьюят и тестируют без человека, пока не работает: по его мнению, при обучении модели почти не получают сигнала о поддерживаемости кода, а быстрого способа ее проверить пока нет. Его рецепт - вернуть ревью и сделать его дешевым планированием. Разбираю эссе и 272 комментария на HN и сравниваю с собственным конвейером на Claude Code и Codex: спека прозой, тесты вслепую, сверка второй моделью. Спойлер: 22 нарушения спеки при 2650 зеленых тестах, и разбор того, что эта цифра доказывает, а чего нет.

Чем дольше я пользуюсь ИИ агентами, тем ленивее я становлюсь. Сперва ИИ писал мне отдельные небольшие кусочки кода. Потом стал писать весь код, а я делал ревью. Затем делать ревью мне самому стало лень, и я для этого тоже стал использовать ИИ. «‑ Эй, Клод, глянь‑как вот этот пулл‑реквест, все ли там в порядке? Если да, то вмерджи». Вкалывают роботы — счастлив человек!

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

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

А вот в случае с ИИ возникает еще один канал атаки: его можно УБЕДИТЬ нарушить правила безопасности проекта и добавить сомнительную логику. Например, в безобидной правке метода контроля доступа можно попытаться протащить мимо ИИ‑ревьювера правило в духе «а пользователю с ником ВасяХакер1337 разрешено вообще все».

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

Дальше — журнал экспериментов, тестовый стенд, результаты замеров разных видов атак на один и тот же маленький кусочек кода, на разных ИИ от разных вендоров. И местами неожиданные выводы.

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

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

Как шаг за шагом организовать процесс внедрения статического анализа по ГОСТ Р 71207—2024: рассказываем простыми словами с отсылками на соответствующие пункты стандарта. Статья будет полезна компаниям, планирующим внедрять разработку безопасного ПО (РБПО) или проходить сертификацию по методике ВУ и НДВ ФСТЭК России.

В прошлой статье я писал, что компилятор — первый ревьюер кода, который написал агент. У этой идеи есть слепое пятно, и я в него наступил: конкурентность. Компилятор проверяет типы, go vet проверяет десяток известных шаблонов, -race ловит гонки данных. А горутина, которая никогда не завершится, — это не ошибка типов и не гонка. Код, который не слышит отмену, — тоже.

Джунам постоянно что‑то советуют: учиться, задавать вопросы, разбираться в чужом коде (хотя бы в своем…), постоянно развиваться. В это время junior: когда уже просто получать зарплату, которую обещали на курсе?

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

Нейросети с нами надолго. Даже если вдруг исчезнут OpenAI, Anthopic, Z.ai и прочие, мой личный Qwen 3.8 27B никуда не денется. Вопрос - a что с этим делать? Как разрабатывать софт в новую эпоху?

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

Есть такой университетский предмет, который все давненько подзабыли (а люди с ИТ-курсов его и в глаза не видели): "методология разработки программного обеспечения". Разработка хорошего ПО - это всегда вопрос методологии. Это и общие принципы архитектуры, и дисциплина работы, и возможность передать работу соседу, разделить между несколькими людьми, признать нечто готовым или не готовым. Без методологии разработка стремительно теряет управляемость.

Как сейчас.

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

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

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

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

Как дать LLM разбирать сбои в пайплайнах, не открывая ей доступ к сырым логам и произвольным SQL-запросам

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

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

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

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

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