Идеи и инсайты · Страница 5

Исследуем AI-first разработку, кодовые ограждения и архитектуру одноразовости.

16 июл. 2026 г.

Исправить баг — просто. Понять, почему он существует, — вот что важно.

Большинство команд исправляют дефекты и двигаются дальше. Те же дефекты возвращаются. Вот как запустить причинный анализ внутри Fagan inspection, чтобы перестать писать один и тот же баг дважды.

15 июл. 2026 г.

Ревью Pull Request выявляет 15–30 % дефектов. Данные говорят об этом уже 50 лет.

Множество исследований в IBM, AT&T, HP и Microsoft подтверждают, что неформальное code review выявляет примерно четверть дефектов. Вот что данные говорят на самом деле, почему этот показатель так низок и как это исправить.

fagan-inspections code-review data pr-reviews

14 июл. 2026 г.

Универсальный чек-лист ничего не ловит. Структурированный ловит 60 % дефектов.

Большинство чек-листов для ревью — это скопированные списки благих намерений. Структурированный чек-лист в стиле Fagan inspection строится на основе реальных данных о дефектах, ориентирован на конкретные типы артефактов и используется во время индивидуальной подготовки. Вот как построить тот, который работает.

fagan-inspections code-review checklists structured-review

13 июл. 2026 г.

LLM может провести предварительную инспекцию кода. Но он не может провести собрание.

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

fagan-inspections llm code-review ai-engineering

12 июл. 2026 г.

Fagan Inspections выявляли 90% дефектов до тестирования. Затем мы перестали их проводить.

Структурированный процесс ревью Майкла Фагана в IBM позволял находить почти все дефекты ещё до компиляции. Но он поглощал 15–20% общих трудозатрат проекта. Вот почему исчез самый эффективный метод ревью в истории разработки ПО и что команды на самом деле теряют.

fagan-inspections code-review software-history process

11 июл. 2026 г.

Ваш лучший ревьюер пропускает большинство дефектов. Fagan измерил это в IBM в 1976 году.

Даже senior-инженеры находят лишь долю дефектов в неструктурированном review. Исследование Michael Fagan в IBM показало, почему, и построило структурированный процесс inspection для исправления этого.

fagan-inspections code-review human-factors defect-detection

10 июл. 2026 г.

Большинство code review находит 20% дефектов. Fagan inspections находят 90%.

Неформальное code review выявляет 15–30% дефектов. Fagan inspections — структурированный 50-летний процесс — стабильно демонстрирует показатели устранения 60–90%. Вот как они работают, почему команды избегают их и как запустить облегчённую версию.

fagan-inspections code-review defect-prevention software-quality

9 июл. 2026 г.

AutoVerus превращает 40 часов написания proof в 3 вызова LLM. Хитрость в том, чтобы знать, когда сдаваться.

AutoVerus использует сеть агентов LLM для генерации proof корректности Verus для кода на Rust, автоматизируя более 90% proof obligations через цикл generate-repair-discharge, управляемый обратной связью SMT-solver.

model-checking autoverus rust verification

8 июл. 2026 г.

LLM могут генерировать код на Rust. Формальные доказательства — это совершенно другая проблема.

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

model-checking llm rust formal-proofs

7 июл. 2026 г.

Ожидание race conditions — ужасная стратегия тестирования

Почему model checking превосходит дни продакшен-рантайма в поиске concurrency-багов и как применить его к собственному коду.

model-checking race-conditions concurrency testing