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

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

Мы столкнулись с этим во время миграции большого исторического проекта на Next.js 15. Вайбкодинг сначала выглядел как идеальное ускорение: модель за минуты переносила страницы, компоненты, хуки и server actions. Но затем на ревью начали прилетать огромные PR с тысячами строк сгенерированного кода.

На детальном ревью выяснилось, что AI часто переносит поведение неточно, пишет собственные велосипеды вместо использования готовых open source решений, не подтягивает дизайн-токены из Figma, не делает Storybook stories и не запускает тесты, если его явно об этом не попросить.

В статье рассказываю, почему проблема не в самом AI, а в отсутствии процесса вокруг него. И предлагаю prompt-first подход: сначала ревьюить короткий промт-план с контекстом, ограничениями, файлами и критериями приёмки, а уже потом генерировать код и открывать PR.

Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».

В разработке качество часто ломается не только на самих багах — но и в тех местах, где работа переходит от одного этапа к другому без ясных условий. Задача уже поехала дальше, хотя acceptance criteria ещё сырые. Формально её можно тестировать, но по факту сначала нужно собирать контекст. Пайплайн зелёный, при этом важная проверка вообще осталась за его пределами.

Такие ситуации обычно показывают не частную ошибку, а устройство процесса в целом. Когда важные условия нигде не закреплены, команда расплачивается за это уточнениями, возвратами и лишней синхронизацией. И напротив — если критерии перехода определены заранее, работать проще. Поэтому Quality Gates для нас в Островке — не только способ ничего не упустить, но и понятный маркер того, насколько процесс разработки вообще выстроен и управляем. 

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

Под катом — практический разбор того, что вообще можно считать Quality Gate, где такие механизмы реально работают и как подбирать их под задачи команды.

Привет, Хабр!

Меня зовут Александр Сахаров, я директор по работе с партнерами в «Диасофт». Последние пять лет мы строим экосистему Digital Q - набор low-code платформ для enterprise-разработки в микросервисной архитектуре. Внутри у нас около двух тысяч разработчиков, и мы на собственном опыте знаем, что бывает, когда каждая вторая команда изобретает велосипед.

Но в этой статье я хочу показать не только наш взгляд. На конференции Deckhouse Conf 2026 мне удалось собрать за одним столом людей, которые каждый день живут внутри этой проблемы: это руководители в ИТ в крупнейших банках и телеком компаний, помогал мне Артем Гениев из «Фланта», руководитель бизнес-юнита «Экспресс 42» - ребята, которые строят платформу со стороны DevOps и инфраструктуры.

Меня зовут Александр Сахаров, я директор по партнерствам в компании Диасофт. И тезис, с которого начну, довольно дерзкий: старый айтишный треугольник «быстро, дешево, качественно, выберите два» в 2026 году можно закрывать. Правда, с одним условием, о котором почему-то  практически не говорят.

На днях мы собрались с коллегами обсудить мифы вокруг искусственного интеллекта. Поговорили про AGI и массовые увольнения из-за внедрения ИИ, но с определенной долей скепсиса. И вот почему. Дело в том, что по свежим данным 56 процентов CIO в мире за последний год не получили от ИИ ни роста выручки, ни снижения затрат. Удивлены?

Если вы часто упираетесь в лимиты Claude Code / Codex и не понимаете, куда улетают токены — этот лонгрид для вас

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

Разбираемся

1. Как устроено контекстное окно изнутри: 7 слоёв (от весов модели до MCP и skills)
2. Что такое attention и при чем тут O(n²)
3. Как работает agent loop на примере 4 вызовов модели
4. Почему prompt caching экономит до 10× в лимитах при правильной работе с ним

Сууупер длинная статья

Красные тесты на CI, зелёные локально, time.sleep в каждом втором тесте, а после смены селектора всё равно всё падает? Знакомо. Это не судьба, а отсутствие архитектуры. Разбираем, как превратить хаос из автотестов в промышленный фреймворк: слои, паттерны (POM, Builder, DI), анти-паттерны и работу с окружениями. С примерами на Python.

Ценность квалифицированного программиста смещается в сторону умения проводить обзоры кода. Генерировать код становится проще, но всё так же важно проверять его с точки зрения качества декомпозиции, корректности реализации, эффективности, безопасности. Посмотрим на примере маленького проекта markus, созданного с помощью Claude Opus, почему важно понимать сгенерированный код и уметь видеть, что скрывает красивый текст программы.

Всем привет. В последнее время в одной профессиональной соцсети я все чаще стал натыкаться на посты, связанные с dotnet C# тематикой. К сожалению, эти посты в большинстве своем не содержат полезной информации. Скорее всего они создаются для охвата аудитории с целью привлечения трафика на сторонние платформы по продаже курсов для разработчиков. По-моему, этот способ называется "воронка продаж" (поправьте, если я ошибаюсь). Как правило, эти посты затрагивают какую-то не очень сложную тему и содержат примеры кода. Недавно мне попался очередной пост, в котором автор пытался показать пример использования новой фичи labeled break and continue. Это новая фича, которую добавили в C# 15 (dotnet 11). На момент написания она была принята в Working Set, но финального релиза ещё не было. Ниже код, похожий на оригинал из поста. Он разделен на 2 секции: "как делали раньше" и "как сделать используя новый подход":

Стандартный способ:

Привет. Я фронтенд-разработчик. По мнению тех, кто, по мнению некоторых, перекладывает джейсончики туда-сюда, я крашу кнопочки. Но сам я себя идентифицирую иначе: я тоже перекладываю джейсончики, и у меня всё точно так же, как у них. Даже архитектура. У меня тоже есть контроллеры, сервисы и хранилища, и я также обрабатываю запросы пользователей. Даже больше, я делаю HATEOAS, «тру» RESTful, если хотите. Давайте расскажу, как я к этому пришел.

Когда-то давно я только верстал. Накидывал разметку, добавлял классы, идентификаторы и стилизовал ЦСС-ом. И было хорошо. Потом от меня потребовали динамичности — пришлось добавить JavaScript. И было очень хорошо.

Технологии развивались, и мне хотелось пробовать новое. Я попробовал AJAX. Это было так волнительно... Я сказал бэкендерам: основную разметку жду от вас, а опции для выпадающего списка, например, отдавайте джейсоном по запросу. Они были не в восторге. «Одному HTML подавай, другому CSV, третьему ещё что-то — безобразие!» Но мы нашли компромис. Бэкэндеры сказали: «Вот вам, мол, джейсон, дальше сами как-нибудь». И назвали это REST API.

Сначала было очень круто! Мы, верстальщики, организовались. Мы стали фронтендерами! Конечно же, мы сразу побежали решать ещё нерешённые сто раз решённые задачи. Мы писали библиотеки и фреймворки — четыре миллиона штук! Да у нас даже есть библиотека с функцией для умножения чисел — lodash.multiply. Мы придумывали свои паттерны и архитектуры, например FSD. Короче, мы стали очень крутые.

Но то уже были «мы», а не я. Мне было сложно. Шутка ли, изучать по одному новому фреймворку в неделю? А ведь еще переписывать всё надо, стек-то устарел... В общем, в какой-то момент я перестал поспевать за модой и справляться со сложностью. Переходишь из одного проекта (на React) в другой (на Vue), а там всё иначе. Берешь нового разработчика в команду с опытом в React, например, а ему нужно время, чтобы вникнуть, потому что в его старой команде был другой «стейт-менеджер». Вавилон, никто друг друга не понимает.

Привет! Это снова Михаил Федоров. В первой статье я рассказал про архитектуру QA Assist — системы из 11 AI-агентов для автоматизации тестирования. Во второй — честно показал, как «4 часа подключения» превращаются в неделю корпоративной реальности.

Сегодня поговорим о штуке, которая на первый взгляд не имеет отношения к AI. О пирамиде тестирования. О том, почему классическая теория QA внезапно оказывается критически важной, когда вашим тест-дизайнером становится языковая модель с контекстным окном.

На одном из созвонов потенциальный заказчик поделился болью:

“Меньше чем за год велосити команды внешнего вендора упала в разы. Почему задачи, которые должны занимать 2–3 дня, растягиваются на недели?”

Проект шел уже почти год с участием внешнего IT-вендора. По документам на проекте работала senior-команда: сильные CV, большой опыт, уверенные интервью. Ожидания были понятные - стабильная скорость разработки и предсказуемый результат.

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

Заказчик решил разобраться и обратился к нам.

Мы посмотрели код, провели техническую оценку команды и разобрали, кто какие задачи закрывает. Важно было не то, что написано в CV, а то, как команда работает на практике.

Картина оказалась неожиданной - около 30% команды были junior-разработчиками.

Не “почти senior”.

Не middle.

Именно junior!

При этом бюджет проекта строился исходя из senior-ставок.

Когда мы начали разбираться, выяснилась еще одна деталь - на замену специалистов заказчик никакого апрува не давал. Часть senior-разработчиков постепенно заменили на junior. Это происходило не сразу, а постепенно, поэтому долго оставалось незаметным. Формально команда оставалась «той же», но по факту ее уровень изменился.

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

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

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

Прежде чем погружаться в архитектуру, давайте посмотрим на контекст, в котором всё это происходит.

По данным исследования McKinsey 2022 года, технический долг составляет до 40% всего технологического портфеля компаний. И это не просто цифра в отчёте. Согласно опросу 2024 года среди технических руководителей, у более чем 50% компаний технический долг занимает свыше четверти всего IT-бюджета, блокируя внедрение новых функций. (Источник: vFunction, 2025)

При этом исследование Carnegie Mellon выяснило, что наибольшим источником технического долга являются именно архитектурные проблемы — а не баги и не плохой код на уровне функций.

Теперь о Go. По данным Go Developer Survey 2024, главной проблемой команд, работающих с Go, названо поддержание единых стандартов кода — в том числе из-за разного уровня опыта участников и привнесения не-идиоматических паттернов из других языков. (Источник: go.dev/blog/survey2024-h2-results)

Это напрямую про нашу тему: люди приходят из Java, Python, C# и приносят с собой архитектурные привычки, которые в Go не работают. Clean Architecture и DDD — не исключение. Их часто реализуют "как в Java", а потом жалуются, что Go — многословный и неудобный язык.

Давайте разберёмся, как делать это правильно.

Как мы сюда попали?

Представьте: вы начинаете новый Go‑сервис. Читаете статьи, смотрите видео, решаете «делать по‑взрослому». Создаёте структуру:

Одна из сложностей с LLM: как понять, какая модель способнее? Их создатели наперебой кричат «мы совершили революцию», но как пробиться сквозь хайп и измерить, кто чего реально добился?

Казалось бы, для этого есть много популярных бенчмарков. И о преимуществах моделей зачастую рассуждают со ссылками на них: «Смотрите, эта на 5% лучше». Однако с такими бенчмарками связан целый ряд проблем, и им нельзя слепо доверять.

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

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

При решении очередной задачи по небольшой "модификации" ПО- возникло решение запуска его под ВМ. По рукой уже стояла Oracle VirtualBox. Но вот незадача- ПО опознало виртуалку и отказалось выдать триал период. 2 промпта и 3 минуты на копирование и сборку решили проблему.

Привет, Хабр! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. В предыдущих статьях я рассказывал про QA Assist — AI-ассистента для тестирования. Сейчас идёт пилот на реальном проекте, копятся метрики и грабли — но писать об этом пока рано. Результаты будут, а пока давайте поговорим о чём-то другом.

Однажды друг в шутку спросил: «А тестировщики вообще могут верить в Бога? Это же не совместимо, нет?»

Вопрос оказался глубже, чем кажется. Не потому что я хочу обсудить религию на техническом ресурсе (спокойно, не буду). А потому что ответ на него выводит на кое-что полезное: неявные допущения, на которых стоит наша работа, и которые мы почти никогда не ставим под сомнение.

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

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

Добрый день, уважаемые коллеги!

Хотел бы сегодня рассказать о несколько необычном опыте анализа кода. Предваряю возмущение многих – да, мсье действительно знает толк в извращениях 😊

Итак, о них родимых. В одном нашем изделии понадобилось защитить от несанкционированного доступа администраторскую консоль управления, банальный COM-порт с мостиком USB-UART на основе FT232. К сожалению, классическое решение с логином/паролем было обставлено целым частоколом формальных требований в виде (1) срока жизни паролей, (2) логирования успешных/неуспешных попыток, (3) минимальной длины паролей, (4) минимальным их алфавитом, (5) требований к применению больших и малых букв, и цифр, и спезнаков, именно «И», а не «ИЛИ». Перечислять можно бы и дальше, но зачем?

Объехать все эти требования по обочине было решено нестандартным путём – поскольку все требования относились к программному продукту, а про аппаратные устройства ничего не было сказано, то мы просто применили АКА – аппаратный ключ администратора. Он втыкается в разрыв USB-кабеля, идущего от АРМ администратора к устройству, и по свободным линиям обменивается с Изделием сообщениями по схеме challenge-response, не передавая напрямую через линии связи общий секрет, при этом перехват сообщений злоумышленнику не даёт ровно ничего. Если кому интересно, как конкретно это сделано – пишите в комменты или в личку.

Поскольку к историческому моменту принятия решения мы все были в жёстком цейтноте, изготовление АКА поручили стажёру. А он возьми и выбери за основу для разработки «голубую пилюлю (BluePill)» и STM32. Возмущаться, спорить и учить вечному было уже некогда, и тимлид, махнув рукой, согласился. Забегая вперёд, скажу, что отказов и/или сбоев АКА как с самого начала не наблюдалось, так и не наблюдается по сей день. Да, наверное, ПЛК на Ардуине – это уже слишком, но костыль и велосипед проходит вполне (рискую быть бит жёлтыми тряпками, но что было, то было).

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

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