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

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

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

Когда шок пройдёт, придёт понимание, что любой профессионал обязан использовать агентское программирование.

В 1988 году бортовой компьютер с памятью 128 КБ посадил космический корабль в шторм. Сегодня ваш смартфон с многоядерным процессором заикается при скролле списка контактов. Мы привыкли думать, что данные невесомы, а JSON – это «просто текст». В этой статье мы препарируем один обычный fetch-запрос и посчитаем его реальную цену: в байтах, миллисекундах и скрытых архитектурных издержках. Разберемся, почему мы стали «поколением JSON» и как вернуть себе инженерную осознанность в эпоху избыточности.

Написал небольшую библиотеку для Spring Boot, которая добавляет типизированные @Conditional-аннотации для работы с конфигурацией через Environment...

TLDR; Разработка ПО в привычном нам виде, сложившаяся в течение десятков лет, уходит в прошлое. БЯМ-ассистенты для программирования фундаментальным образом изменили наше ремесло, и ещё не известно, к добру или к худу.

Я работаю тимлидом в достаточно крупной компании и хочу поделиться некоторыми мыслями относительно AI: как его применяют в моей команде и как я использую его сам, а также описать некоторые наблюдения и личные ощущения. В IT я работаю уже около 20 лет, соответственно, повидал всякое, но AI, на мой взгляд — нечто совершенно новое.

Разработчики нейросетей активно распространяют идею, что те могут сгенерировать код, объяснить сложный алгоритм, предложить архитектурное решение и помочь с отладкой. Однако, само по себе наличие ИИ-инструмента не гарантирует ни качества кода, ни роста продуктивности. Более того, при неумелом использовании нейросети легко превратить проект в набор плохо связанного, трудно поддерживаемого и потенциально небезопасного кода. А есть ли умелый способ?

Всем привет!

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

Это натолкнуло меня на идею: собрать инструмент, который позволяет управлять и автоматизировать процесс разработки, основанной на спецификациях и контроле генерации кода. Я приступил к реализации — очень плотно и почти без сна за все эти дни o_O.

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

Code Metal привлёк $125 млн на переписывание кода оборонки с помощью ИИ. Google и Microsoft сообщают, что 25–30% нового кода генерируется ИИ. AWS перевёл 40 млн строк COBOL для Toyota. CTO Microsoft прогнозирует, что к 2030 году 95% кода будет написано ИИ. Переписывание мирового софта — не прогноз, а факт.

Anthropic недавно построила C-компилятор на 100 000 строк за две недели силами параллельных ИИ-агентов — меньше чем за $20 000. Он загружает Linux, компилирует SQLite, PostgreSQL, Redis. ИИ создаёт масштабный софт с поразительной скоростью. Но может ли он доказать корректность компилятора? Пока нет. Формальную верификацию результата никто не делает.

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

Я долго думала, что PEP — это про оформление. PEP 8: называй переменные вот так, PEP 257: пиши докстринги вот так.

Потом начала использовать их по‑настоящему и выяснилось, что часть из них вообще не про то, как выглядит код!

AI‑инструменты часто делают одно и то же: они выбирают слишком тяжёлое решение там, где достаточно простого. Ценность человека — в инженерном суждении: распознать плохую архитектуру, остановить усложнение, выбрать более простой путь, держать систему в здравом состоянии.

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

Если вы хотите узнать ещё больше об организации процессов ML-разработки, подписывайтесь на наш Телеграм-канал Варим ML

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

В статье показано, как сократить boilerplate код при создании Minecraft модов с помощью фреймворка под названием Temporal API...

Я столкнулся с простой (как мне изначально показалось – даже очень) задачкой. Мне в последнее время потребовалось часто проводить поиск в 4-х словарях. Государство мне их дало в виде 5 PDF файлов, выложенных онлайн. Это нормативные словари русского языка, слова из которых можно использовать в публичном пространстве.

Например, cash - можно использовать на русском как кэш, а не переводить как тайник или склад, поскольку в Словарь иностранных слов это слово уже включено. И это слово нам еще пригодится далее по тексту)

Разговор будет серьёзный. С 1 марта 2026 вся публичная информация для потребителя должна быть на русском — N 168-ФЗ. Пока что разработку это не касается, но стоит быть готовыми. Предлагаю договориться о словаре разработчиков Российской Федерации.

Честная история о том, как я взялся за проект по внедрению ИИ в разработку во время переезда на новый стек.

Я использую LLM в повседневной разработке уже больше года и довольно быстро упёрся в типовую проблему: модель генерирует “красивый код”, но по мере роста проекта появляется дублирование, разъезжается стиль, растёт число заглушек и отладка становится дорогой. В статье покажу процесс, который мне помог: как разделять контекст по чатам, какие артефакты требовать на каждом шаге и какими чек-листами я проверяю результат.

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

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

Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика.

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

У меня была привычка. Вижу классную статью про архитектуру —-сохраняю. Репозиторий с примерами DDD - в закладки. Видео про CQRS - в плейлист «Посмотреть потом».

Вы знаете, чем кончаются плейлисты «Посмотреть потом».

В какой-то момент закладок стало 300+. Половина ссылок битые, треть дублируют друг друга, остальное - статьи, которые казались гениальными в два часа ночи. Я сел и вычистил всё до 106 ресурсов. Собрал их в awesome-list на GitHub.

Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.

В последнее время мне довелось много заниматься распараллеливанием однопоточного кода и показалось уместным свести воедино более-менее всё, что нам известно про разные типы многозадачности, с примерами и комментариями.

Примеры на Ruby, Go, Java.

Писать или не писать тесты — выбор очевидный. Конечно, писать. Но если проект масштабный, одних unit‑тестов будет недостаточно: они бессильны на границах модулей, в интеграциях и пользовательских сценариях, а значит в этих местах будут пролезать баги. Такой код будет сложно поддерживать, вносить в него изменения и получать ожидаемый результат.

В статье поговорим про разные стратегии тестирования под разные риски и кейсы. Поднимемся над привычными unit‑тестами и заглянем, что там есть еще. Спойлер: а еще там workflow‑, integration‑, property‑based‑ и resilience‑тесты.