Обвязка решает
Разбор харнессов ИИ-агентов: как они устроены на обычном проекте, какими бывают — и что показал машинный журнал живого проектаПилю офлайн-заметочник Nitinol и пишу об этом статьи. В первой части рассказывал, как десять лет терял заметки, во второй — про хранение и поиск без RAG, в третьей
Код‑ревью в эпоху ИИ: 7 ошибок, ведущих к инцидентам
Материал подготовлен в преддверии старта курса «ИИ для разработчиков».Всем привет, меня зовут Сергей Прощаев и в этой статье расскажу про ревью кода, созданного ИИ, и про то, почему AI Code Review так часто не спасает. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce, преподаю на курсах разработки и архитектуры в ОТУС.Типичный сценарий, который я всё чаще вижу в командах, выглядит так. Разработчик ставит задачу
ИИ-ревьюверы твоего кода: как нейросети позволяют упрощать анализ PR
С развитием ИИ себестоимость кода стремительно падает. Его становится все больше, а команды не растут пропорционально количеству. AI-инструменты генерации кода (Copilot, Cursor, Codex, Claude Code) увеличивают скорость написания, но не скорость проверки кода.Узким горлышком становится сам PR, они могут висеть днями в вашей компании или opensource-проекте, контекст может теряться, на его оценку тратится время, и иногда впустую.В среднем, команда на ревью тратит ~20% рабочего времени, особенно если это большой PR, или PR от новичка.
Покажи мне свой харнесс — и я спрошу у Клода, кто ты
Я продолжаю пилить по вечерам и ночам локальный заметочник Nitinol. Это третья статья цикла: в первой я рассказывал, как десять лет терял заметки, во второй — про хранение и поиск без RAG. В этот раз — про кухню разработки: стек, модели и процесс, о которых спрашивали в комментариях.
«У вас в резюме указаны навыки ИИ. Что вы имели в виду?» Что отвечать, кроме количества потраченных токенов
Источник: PATRIKI TVВсё началось с чата с однокурсниками. Кто‑то обронил фразу «сейчас без ИИ никуда, это уже базовый навык», и следующие два дня мы выясняли, что каждый понимает под этим что‑то своё.
Cloudflare: Оркестрация AI-ревью кода в промышленных масштабах
Code review (ревью кода) — отличный механизм для отлова багов и обмена знаниями, но вместе с тем это почти гарантированный способ создать «бутылочное горлышко» для всей команды разработчиков. Merge Request (MR) сутками висит в очереди, ревьюер рано или поздно отвлекается от своих задач, чтобы вникнуть в diff, оставляет пару мелких придирок к названиям переменных, автор отвечает, и цикл повторяется. В наших внутренних проектах медианное время ожидания первого ревью часто измерялось часами.
Как ревьюить ИИ-код: что автоматизировать, какую работу оставить человеку и как всё это делать системно
В 2026 году софт всё чаще пишут с участием ИИ: по данным Stack Overflow, 84% разработчиков уже используют ИИ‑инструменты или планируют начать. При этом исследователи Faros AI фиксируют парадокс: в командах с активным использованием ИИ разработчики закрывают на 21% больше задач и на 98% больше мёржат PR, но время ревью выросло на 91%. В статье разберём, как выстроить процесс проверки, который не съедает выигрыш от автоматизации и почему ревью ИИ‑кода нельзя полностью отдать моделям.За консультацию при подготовке материала благодарим:
Как мы за 3 дня сделали ИИ-ревьюер кода и что поняли месяц спустя
С код-ревью есть такой парадокс: все согласны, что этот процесс важен, но времени на него обычно ни у кого нет. В результате ревью часто превращается в формальность. Очевидные баги при этом ловятся, а мелкие, вроде пропуска в условиях, перепутанных знаков, забытых edge cases и т.д., могут спокойно уехать в мердж и вернуться уже в виде задач в багтрекере. В Content AI мы активно внедряем ИИ в разработку, и одна из задач, которую мы решали в этом году, — автоматизация код-ревью. В этой статье рассказываем, как одна из наших команд собрала ИИ-ревьюера, встроенного в Pull Request, и что мы поняли спустя месяц использования.
Мы попробовали в реальном проекте Dynamic Workflows от Claude Code. Рассказываю, что сработало, а что нет
Прогнали Dynamic Workflows Claude Code на реальном проекте поверх NaCl: что сработало, а что нетПривет! Меня зовут Максим Никитин, я фаундер небольшой, но гордой студии разработки сложных и нетиповых проектов ITSalt. В начале 2025 года мы начали переходить на агентскую разработку и постепенно собрали вокруг этого собственный фреймворк - NaCl. Сейчас он закрывает бизнес-анализ, системное проектирование, TDD, код-ревью, QA и релиз - по сути, весь цикл от требования до продакшна.NaCl можно посмотреть в публичном репозитории
