Дисклеймер: Эта статья не о том, что «Vibe Coding — это зло». Если вам нужно быстро склепать прототип для презентации инвесторам или сделать лендинг за час — вперед, это легитимный инструмент. Эта статья о том, почему для профессионального роста и долгосрочной устойчивости как инженера важно разделять понятия «погонщик ИИ» и «инженер, использующий ИИ».
Привет, Хаброжители! Сделайте код-ревью продуктивным, вызывающим положительные эмоции процессом, каким он и должен быть. Неважно, проверяют ваш код или же вы проверяете чью-то работу, получите продуманные инструкции, которые помогут избежать напряженных дебатов, неплодотворных придирок и узких мест — всего того, чего мы привычно ждем от код-ревью.
Научитесь здравому и внимательному подходу к код-ревью, который одной из первых стала применять автор книги — Эдриенн Браганца. Узнайте, как создать в команде доброжелательную атмосферу, четко согласовать цели код-ревью и ожидания от него, как подготовиться к любым изменениям и препятствиям, с которыми можете столкнуться. Освойте практики, которые можно адаптировать к тому, как работает ваша команда, познакомьтесь со множеством возможностей и решений, надежных сценариев, а также примеров из реальной жизни. Вскоре вы сможете построить высокоэффективный процесс код-ревью, который сделает ваш код лучше, а вашу команду сильнее.
Эта статья о том, как правильно использовать ИИ агентов для кода, чтобы они генерили не помои, а стабильный продукт.
Здесь я не буду обсуждать, стоит ли использовать ИИ в разработке. Ответ однозначный: это новая реальность. Нейроагенты дали нам новый уровень абстракции, так же как от ассемблера мы перешли к компилируемым языкам, от них к скриптам, от скриптов к декларативному программированию. Цель у всего одна: научить компьютер понимать человеческий язык. И вот — цель достигнута.
Когда шок пройдёт, придёт понимание, что любой профессионал обязан использовать агентское программирование.
В 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.
Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.
