Notes & Insights - software-engineering

Бюджет и риск-гейты для DCA-позиций: расчёт до запуска бота

2026-10-09T00:00:00+00:00

Усреднение снижает цену безубыточности, но одновременно увеличивает сумму под риском. Высокий риск · образовательный разбор. Это не инвестиционная рекомендация и не инструкция к запуску торгового бота. Если в отчёте DCA-бота показан только процент прибыльных сделок, главный вопрос остаётся без ответа: сколько капитала потребует серия покупок, если отскока не будет?

Повод для разбора — видео DCA Martingale Trading Bot Explained. Рыночный бэктест в рамках этой статьи не проводился.

DCA — не обязательно мартингейл

В этой статье DCA означает дополнительные покупки при снижении цены внутри одной сделки. Это не регулярное долгосрочное инвестирование фиксированной суммы.

Различать стоит три независимых правила:

Триггер: на каком снижении разрешена дополнительная покупка.
Размер: сколько денег выделяется каждой покупке.
Остановка: когда новые покупки запрещаются и что происходит с уже открытой позицией.

Постоянный размер покупки не является классическим мартингейлом. Геометрическое увеличение размера похоже на него по нагрузке на капитал, но само по себе не гарантирует компенсацию прошлых потерь. Термин «контролируемый» здесь не используется как оценка качества: он имеет смысл только вместе с явными лимитами.

Почему мартингейл опасен. Увеличение каждой следующей покупки наращивает экспозицию именно тогда, когда цена движется против позиции. При удвоении номиналов серия 100 → 200 → 400 → 800 требует уже 1500 единиц капитала, а следующая покупка — ещё 1600; это без комиссий. Конечный бюджет не позволяет продолжать такую последовательность бесконечно, а восстановление цены не гарантировано. На споте без заёмных средств можно потерять почти всю стоимость позиции; с плечом ликвидация может наступить ещё до запланированного уровня усреднения. Лимит покупок ограничивает выделяемый капитал, но не делает стратегию прибыльной и не гарантирует выход по заданной цене при разрыве котировок или недостаточной ликвидности. Приведённые ниже расчёты служат для анализа этих ограничений, а не являются торговой идеей, призывом запускать бота или инвестиционной рекомендацией.

Сначала бюджет, затем сигнал

Пусть B — сумма базовой покупки в валюте котировки, S — сумма первой дополнительной покупки, m — множитель следующих покупок, N — максимальное число дополнительных покупок. Плеча нет; все суммы — номиналы покупок без комиссий.

$$ C = B + S\sum_{k=0}^{N-1}m^k $$

При m ≠ 1:

$$ C = B + S\frac{m^N-1}{m-1} $$

При m = 1 бюджет равен B + NS. Нулевая величина N означает отсутствие дополнительных покупок.

Например, B = 100, S = 100, m = 2 и N = 4 требуют 1600 единиц капитала, хотя стартовая покупка составляет только 100. Для пяти одновременно заполненных серий потребуется 8000 — до комиссий и запаса ликвидности. Это арифметический сценарий, не прогноз рынка.

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

Три независимых лимита

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

Лимит серии: C <= C_series, где C_series включает все дополнительные покупки, разрешённые одной позиции.
Лимит портфеля: R_reserved = Σ C_j <= R_portfolio для всех серий j, которые могут быть заполнены одновременно.
Лимит ликвидности: каждая заявка должна удовлетворять минимальному размеру, шагу количества и доступной глубине; остаток R_portfolio - R_reserved не следует считать свободным для другой стратегии без общего резервного реестра.

Если вероятность одновременного заполнения неизвестна, для консервативного гейта используют сумму полных бюджетов, а не среднее историческое заполнение. R_reserved включает quote cash, зарезервированные под незаполненную часть активных заявок; фактически исполненный notional учитывается отдельно. При частичном исполнении резерв уменьшают только после отмены остатка и подтверждённого terminal status (canceled/closed), а не сразу после получения частичного fill. Таймаут или перезапуск процесса не являются основанием считать резерв свободным.

Важно: C — бюджет покупок в quote currency без комиссий, а не максимальный убыток. Фактический убыток зависит от цены выхода, комиссий, проскальзывания, гэпа и ликвидности; для деривативов добавляется риск ликвидации. Даже полностью зарезервированный бюджет не задаёт нижнюю границу потерь.

Для оценки чувствительности удобно считать прирост очередного ордера отдельно: ΔC_k = S m^k. При m > 1 последний разрешённый ордер доминирует в бюджете; поэтому изменение N на единицу часто опаснее, чем небольшая поправка расстояния между уровнями. Этот расчёт не содержит предположений о вероятности отскока.

Почему средняя цена — не среднее цен ордеров

При расходах c и ценах исполнения p количество купленного актива равно расходам, делённым на цену. Поэтому средняя цена взвешивается количествами, а не числом заявок:

$$ Q = \sum_{i=0}^{N}\frac{c_i}{p_i},\qquad \bar{p}=\frac{\sum_{i=0}^{N}c_i}{Q} $$

Рассмотрим только три исполненные покупки, не весь максимальный план:

Покупка	Расход	Цена	Количество
Базовая	100	100	1
Дополнительная 1	100	90	1,111111
Дополнительная 2	200	80	2,5

Всего потрачено 400, куплено примерно 4,611111 единицы, средняя цена — 86,746988. Чтобы вернуться от 80 к этой цене, нужен рост примерно на 8,43%. Без комиссий это цена безубыточности, а не целевая прибыль.

Если комиссия каждой покупки уплачена дополнительно в валюте котировки с долей f, а при продаже удерживается такая же доля выручки, цена безубыточности будет:

$$ p_{BE}=\bar{p}\frac{1+f}{1-f} $$

При f = 0,001 получаем около 86,920656. Если комиссия удерживается в базовом активе или отдельном токене, формула учёта меняется. Проскальзывание учитывается фактическими ценами исполнения, а не обещанными уровнями сетки.

При падении до 60 стоимость позиции составит около 276,67, а нереализованный убыток — 123,33 без комиссий. Средняя цена действительно снизилась; абсолютный риск при этом вырос.

Проверяемый калькулятор на Python

Код ниже не отправляет заявки и не является стратегией Freqtrade. Он проверяет арифметику плана и трёх гипотетических исполнений. Нужен только Python 3 со стандартной библиотекой.

from decimal import Decimal as D


def capital_plan(base, first, multiplier, count):
    if type(count) is not int or not 0 <= count <= 100:
        raise ValueError("count must be an integer from 0 to 100")
    values = tuple(D(str(x)) for x in (base, first, multiplier))
    if any(not x.is_finite() or x <= 0 for x in values):
        raise ValueError("sizes and multiplier must be finite and positive")
    base, first, multiplier = values
    return base + sum(
        (first * multiplier ** k for k in range(count)), D(0)
    )


assert capital_plan(100, 100, 2, 4) == D(1600)
assert capital_plan(100, 100, 1, 4) == D(500)
assert capital_plan(100, 100, 2, 0) == D(100)

for bad in (-1, 1.5, True, 101):
    try:
        capital_plan(100, 100, 2, bad)
    except ValueError:
        pass
    else:
        raise AssertionError("invalid count accepted")

def breakeven_price(average, fee):
    average, fee = D(str(average)), D(str(fee))
    if not average.is_finite() or average <= 0:
        raise ValueError("average must be finite and positive")
    if not fee.is_finite() or not D(0) <= fee < D(1):
        raise ValueError("fee must be finite and in [0, 1)")
    return average * (1 + fee) / (1 - fee)


assert breakeven_price(D("100"), D("0")) == D("100")
assert breakeven_price(D("86.7469879518"), D("0.001")) > D("86.7469879518")

fills = [(D(100), D(100)), (D(100), D(90)), (D(200), D(80))]
cost = sum((cash for cash, price in fills), D(0))
quantity = sum((cash / price for cash, price in fills), D(0))
average = cost / quantity
fee = D("0.001")
breakeven = breakeven_price(average, fee)
assert abs(average - D("86.7469879518")) < D("0.000000001")
assert abs(breakeven - D("86.9206555953")) < D("0.000000001")
print(f"capital={capital_plan(100, 100, 2, 4)}")
print(f"average={average:.6f}; breakeven={breakeven:.6f}")

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

Контур исполнения: лимит — до дополнительной покупки

flowchart TD
    A[Новый закрытый бар] --> B[Сверка позиций и заявок]
    B --> C{Есть неопределённое исполнение?}
    C -->|Да| D[Пауза и повторная сверка]
    C -->|Нет| E[Проверка уровня и номера покупки]
    E --> F{Хватает лимита серии и портфеля?}
    F -->|Нет| G[Запрет увеличения позиции]
    F -->|Да| H[Резервирование бюджета и заявка]
    H --> I[Запись фактического исполнения]

Здесь нужны два лимита: на отдельную серию и на весь портфель. Остаток свободных денег сам по себе не заменяет резерв: несколько ботов могут одновременно считать одни и те же средства доступными.

Минимальная запись состояния содержит идентификатор серии, номер дополнительной покупки, уже исполненный объём, зарезервированную сумму и идентификатор заявки. После таймаута сначала выясняют судьбу заявки, а не немедленно отправляют новую. Частичное исполнение учитывают по фактическому объёму; перезапуск процесса не должен обнулять счётчик покупок.

В Freqtrade увеличение позиции реализуется через adjust_trade_position(). Это callback именно для position adjustment; его частота вызовов и поведение в live/dry-run отличаются от бэктеста. Условие вроде «цена ниже уровня» остаётся истинным несколько итераций подряд: без проверки состояния оно способно породить повторные покупки. Возвращаемые значения (stake/amount), ограничения биржи и конфигурационные лимиты зависят от установленной версии Freqtrade, поэтому implementation contract нужно сверять с документацией конкретной версии, а не только со stable-ссылкой. Точные параметры callback и ограничения числа дополнительных входов проверяйте по документации установленной версии.

Отказ от дальнейшего усреднения не закрывает существующий риск. Отдельная политика должна описывать выход, максимальную длительность сделки и аварийное отключение. Стоп-заявка тоже не гарантирует цену исполнения при гэпе. Здесь рассматривается спот без плеча; для деривативов дополнительно необходимы модель маржи, funding и риск ликвидации.

Как проверять стратегию, а не красивую кривую

До перебора параметров задайте протокол:

Разделите время. Подбор параметров — на тренировочном периоде; выбор варианта — на валидационном; финальная проверка — на отдельном, ранее не использованном периоде. Повторный подбор по финальному отчёту превращает его в тренировочный.
Сравните одинаковый капитал. Покупка на 100 с резервом 1500 и buy-and-hold на 1600 — разные режимы экспозиции. Покажите доходность на весь выделенный капитал, а не только на первую покупку.
Проверьте открытые позиции. Высокая доля выигрышных закрытых сделок может соседствовать с большой плавающей просадкой. Нужна equity с переоценкой открытых позиций, а не только баланс завершённых циклов.
Учтите издержки. Комиссии, спред, ограничения минимального ордера и шаг количества; отдельно — стрессовое проскальзывание и пропущенные исполнения.
Испытайте одновременное падение активов. Число разных тикеров не гарантирует диверсификацию: в стрессовом режиме они могут одновременно запросить полный резерв.
Проверьте утечку будущего. lookahead-analysis в Freqtrade помогает обнаруживать часть подобных ошибок, но не доказывает прибыльность или отсутствие всех видов смещения. После него нужны обычный бэктест с реальными лимитами и dry-run.

Для итогового отчёта полезнее одного win rate четыре числа: максимальная просадка equity, максимальная занятость капитала, длительность самой долгой серии и результат на всём выделенном капитале после издержек. Добавьте число серий: редкие завершения дают мало независимых наблюдений.

Ключевые выводы

Геометрическое увеличение покупок требует заранее посчитанного бюджета, даже если первая заявка мала.
Снижение средней цены не означает снижения денежного риска.
Ограничение количества покупок — не замена выходу и портфельному лимиту.
Арифметический тест, исторический бэктест и dry-run отвечают на разные вопросы; ни один не гарантирует будущую прибыль.

Практический первый шаг — выписать B, S, m и N из своего исследовательского конфига и сравнить полный бюджет с доступным резервом при одновременном заполнении всех серий. Это материал об инженерной проверке рисков, а не рекомендация запускать усреднение на реальном счёте.

Первоисточники и материалы

Оригинальное видео: DCA Martingale Trading Bot Explained — Risk Controls + Out-of-Sample Backtest. Результаты стратегии независимо не воспроизводились.
Документация callback: Freqtrade — Adjust trade position.
Проверка утечки будущего: Freqtrade — Lookahead analysis.
Инженерные наработки: github.com/xsa-dev.

Автоматическая миграция C/C++ на Rust: 3-этапный пайплайн Google, Gemini 4 Argon и дифференциальный фаззинг

2026-10-08T00:00:00+00:00

Проблема безопасности памяти (Memory Safety) в системном программировании давно перешла из теоретических дискуссий в категорию критических инфраструктурных рисков. По данным многолетних отчетов безопасности Google и Microsoft, около 70% всех критических уязвимостей нулевого дня (Zero-Day CVE) в масштабных кодовых базах на C и C++ (таких как Chromium, ядра ОС, медиадекодеры и сетевые стеки) вызваны ошибками работы с памятью: Use-After-Free, Out-of-Bounds Write, Double Free и Data Races.

Переписывание сотен миллионов строк унаследованного C/C++ кода вручную силами инженеров требует десятилетий и сопряжено с колоссальными затратами. Инженерные команды Google перешли к индустриальному решению задачи: автоматизированному конвейеру миграции на базе специализированных AI-агентов (Gemini 4 Argon), строгой верификации через дифференциальный фаззинг и компиляторной оптимизации.

В этой статье разобран 3-этапный пайплайн миграции Google, физика работы дифференциального фаззинга, специфика генерации безопасных FFI-границ и реальные результаты переноса критических проектов (giflib, libgav1 и микроядра Zircon).

1. Архитектура 3-этапного конвейера миграции

Главный барьер при автоматической генерации системного кода нейросетями — риск внесения скрытых семантических расхождений и тонких регрессий, которые не ловятся обычными юнит-тестами.

Чтобы исключить галлюцинации и гарантировать 100% эквивалентность логики, в Google реализовали замкнутый контур с автоматической обратной связью:

flowchart TD
    A["Legacy C/C++ Codebase"] --> B["1. Трансляция кода - Gemini 4 Argon"]
    B --> C["2. Выделение FFI и Safe Wrappers"]
    C --> D["Сборка Shared Objects - lib_legacy.so vs lib_rust.so"]
    D --> E["3. Дифференциальный фаззинг - LibAFL / AFL++"]
    E --> F{"Обнаружены дельты в поведении?"}
    F -->|Да: расхождение вывода или краш| G["Генерация контрпримера и отчета"]
    G --> B
    F -->|Нет: миллиарды итераций пройдены| H["Верифицированный Rust Crate"]
    H --> I["Интеграция в Production"]

Этап 1: Семантическая трансляция C/C++ в Rust

Модель не просто переводит синтаксис строчка в строчку. Ее задача — выделить логические структуры данных, определить границы владения объектами и транслировать императивный процедурный код в идиоматический Rust с минимально необходимым объемом unsafe-блоков. При этом сохраняется полная совместимость с внешним C-ABI: экспортируемые сигнатуры функций и структуры данных сохраняют исходный layout.

Этап 2: Изоляция FFI и генерация Safe Wrappers

Любой переносимый модуль должен бесшовно встраиваться в существующую экосистему без необходимости перекомпиляции зависимых сервисов. На границе FFI генерируется безопасный фасад:

Сырые указатели (*mut T, *const T) оборачиваются в Option<NonNull<T>>.
Проверяются инварианты выравнивания и валидности переданных буферов.
Жизненный цикл ресурсов инкапсулируется через типаж Drop (RAII), исключая утечки памяти.

Этап 3: Дифференциальный фаззинг с обратной связью

Оригинальная C-библиотека и сгенерированная Rust-библиотека компилируются как взаимозаменяемые динамические библиотеки (.so). Специализированный фаззер генерирует миллионы мутированных входных потоков байтов, подавая их параллельно в обе реализации. Если поведение Rust-модуля расходится с C хотя бы на 1 бит (или одна из версий завершается паникой/крашем), формируется минимизированный контрпример, который отправляется в контекст AI-агента для локализации бага.

2. Сравнение подходов: Ручная миграция vs AI-фаззинг контур

Ниже приведено структурное сравнение ключевых характеристик различных подходов к обеспечению memory safety в production:

Параметр	Ручной перенос на Rust	Статический анализ C/C++	Конвейер Google (AI + Фаззинг)
Скорость миграции	100–300 строк/день на инженера	Мгновенно (без миграции)	10 000+ строк/день на агентный кластер
Гарантии Memory Safety	Высокие (после ревью)	Низкие (много false negatives)	Абсолютные на уровне `rustc`
Семантическая точность	Человеческий фактор	Не применимо	Проверена миллиардами фаззинг-мутаций
Сохранение C-ABI	Трудоемко вручную	Сохраняется C-код	Автоматическая генерация `#[no_mangle]`
Устранение Legacy 0-day	Редко	Частично	Выявляются попутно в процессе фаззинга

3. Инженерия безопасных FFI-границ и управление ресурсами

Рассмотрим конкретный пример: трансляция низкоуровневого буфера данных с ручным управлением памятью в C в безопасную абстракцию на Rust с сохранением ABI.

Исходный C-код (Legacy-интерфейс с рисками UAF)

#include <stdlib.h>
#include <stdint.h>
#include <string.h>

typedef struct {
    uint8_t* data;
    size_t size;
    size_t capacity;
} ByteBuffer;

ByteBuffer* byte_buffer_create(size_t initial_capacity) {
    ByteBuffer* buf = (ByteBuffer*)malloc(sizeof(ByteBuffer));
    if (!buf) return NULL;
    buf->data = (uint8_t*)malloc(initial_capacity);
    if (!buf->data) {
        free(buf);
        return NULL;
    }
    buf->size = 0;
    buf->capacity = initial_capacity;
    return buf;
}

int byte_buffer_append(ByteBuffer* buf, const uint8_t* src, size_t len) {
    if (!buf || !src) return -1;
    if (buf->size + len > buf->capacity) {
        size_t new_cap = (buf->capacity * 2 > buf->size + len) ? buf->capacity * 2 : buf->size + len;
        uint8_t* new_data = (uint8_t*)realloc(buf->data, new_cap);
        if (!new_data) return -1;
        buf->data = new_data;
        buf->capacity = new_cap;
    }
    memcpy(buf->data + buf->size, src, len);
    buf->size += len;
    return 0;
}

void byte_buffer_free(ByteBuffer* buf) {
    if (buf) {
        if (buf->data) free(buf->data);
        free(buf);
    }
}

Сгенерированный Rust-модуль с безопасной инкапсуляцией и C-ABI

use std::ptr::NonNull;
use std::slice;

#[repr(C)]
pub struct ByteBufferFFI {
    data: *mut u8,
    size: usize,
    capacity: usize,
}

// Внутренняя безопасная структура с авто-освобождением через RAII
pub struct SafeByteBuffer {
    inner: Vec<u8>,
}

impl SafeByteBuffer {
    pub fn with_capacity(cap: usize) -> Self {
        Self {
            inner: Vec::with_capacity(cap),
        }
    }

    pub fn append(&mut self, src: &[u8]) -> Result<(), ()> {
        self.inner.extend_from_slice(src);
        Ok(())
    }
}

#[no_mangle]
pub unsafe extern "C" fn byte_buffer_create(initial_capacity: usize) -> *mut ByteBufferFFI {
    let mut vec = Vec::with_capacity(initial_capacity);
    let raw_ptr = vec.as_mut_ptr();
    let cap = vec.capacity();
    std::mem::forget(vec);

    let boxed = Box::new(ByteBufferFFI {
        data: raw_ptr,
        size: 0,
        capacity: cap,
    });
    Box::into_raw(boxed)
}

#[no_mangle]
pub unsafe extern "C" fn byte_buffer_append(
    buf: *mut ByteBufferFFI,
    src: *const u8,
    len: usize,
) -> i32 {
    if buf.is_null() || src.is_null() {
        return -1;
    }

    let buf_ref = &mut *buf;
    let input_slice = slice::from_raw_parts(src, len);

    // Восстанавливаем Vec для безопасного реаллоцирования
    let mut vec = Vec::from_raw_parts(buf_ref.data, buf_ref.size, buf_ref.capacity);
    vec.extend_from_slice(input_slice);

    // Обновляем FFI-структуру
    buf_ref.data = vec.as_mut_ptr();
    buf_ref.size = vec.len();
    buf_ref.capacity = vec.capacity();
    std::mem::forget(vec);

    0
}

#[no_mangle]
pub unsafe extern "C" fn byte_buffer_free(buf: *mut ByteBufferFFI) {
    if !buf.is_null() {
        let boxed = Box::from_raw(buf);
        if !boxed.data.is_null() {
            let _ = Vec::from_raw_parts(boxed.data, boxed.size, boxed.capacity);
        }
    }
}

Благодаря #[repr(C)] и #[no_mangle] скомпилированная Rust-библиотека подменяет оригинальный .so файл без перекомпиляции зависимых C/C++ приложений.

4. Математическая модель дифференциального фаззинга

При дифференциальном фаззинге проверяется гипотеза о тождественности функций $f_{\text{C}}(x)$ и $f_{\text{Rust}}(x)$ на всем пространстве допустимых и недопустимых входных данных $x \in \mathcal{X}$.

Пусть в кодовой базе существует скрытый дефект с вероятностью проявления $p_k$ на одной итерации случайной мутации входного вектора. При независимой генерации $N$ тест-кейсов вероятность обнаружения расхождения $P_{\text{detect}}$ выражается как:

$$P_{\text{detect}}(N) = 1 - \prod_{k=1}^{M} \left(1 - p_k\right)^{N_k}$$

Где:

$M$ — число потенциальных пограничных состояний в графе потока управления (CFG);
$N_k$ — количество сгенерированных мутаций, покрывающих ветвь $k$;
$p_k$ — вероятность расхождения семантики при исполнении ветви $k$.

В конвейере Google фаззер использует покрытие кода (Coverage-Guided Differential Fuzzing). Когда мутатор находит вход $x^*$, приводящий к:

$$\Delta(x^) = \left| f_{\text{C}}(x^) - f_{\text{Rust}}(x^) \right| > 0 \quad \lor \quad \text{Status}_{\text{C}}(x^) \neq \text{Status}_{\text{Rust}}(x^*)$$

Контрпример немедленно сохраняется в виде минимального байтового среза (minimization corpus) и передается в prompt-контекст агента Gemini 4 Argon с трассировкой стека вызовов.

5. Результаты реальных кейсов: giflib, libgav1 и Zircon

Практическая апробация 3-этапного пайплайна в инфраструктуре Google показала неожиданные эффекты не только в области надежности, но и в производительности.

Результаты миграции ключевых проектов

Проект	Объем / Архитектура	Результат миграции на Rust
giflib	~3 000 строк C	100% ABI-совместимость. Попутно обнаружена и закрыта Zero-Day уязвимость `CVE-2026-26740` (out-of-bounds heap write) в оригинальном C-коде.
libgav1 (AV1 декодер)	32 000 строк C + Hand-written SIMD	Полный отказ от ассемблерных вставок в пользу Safe Rust. Ускорение декодирования в 2.7 раза.
Fuchsia Zircon Kernel	800 000+ строк C/C++	Модульная миграция подсистем ядра ОС без деградации IPC-латентности.

Почему Safe Rust в libgav1 обогнал 32k строк ручного SIMD?

Один из главных мифов системной разработки гласит: «Ручные SIMD-интринсики на C всегда быстрее безопасного кода». Кейс libgav1 опроверг это на практике.

Причина кроется в алиасинге указателей (Pointer Aliasing). В языке C компилятор вынужден консервативно предполагать, что любые два указателя одного типа (uint8_t* a, uint8_t* b) могут указывать на перекрывающиеся области памяти (если не указано ключевое слово restrict, которое разработчики часто забывают). Это блокирует автоматическую векторизацию циклов компилятором LLVM.

В Rust модель владения гарантирует:

Ссылка &mut T является строго уникальной (no-alias invariant гарантирован на уровне семантики языка).
Ссылки &T гарантированно неизменяемы (immutable).

Получив чистый Rust-код без алиасинга, оптимизатор LLVM смог провести агрессивную векторизацию для инструкций AVX2 и AVX-512, выстроив конвейер вычислений эффективнее, чем 32 000 строк устаревшего ручного ассемблерного кода, написанного под специфические микроархитектуры прошлых поколений.

6. Чек-лист внедрения AI-миграции в инженерный контур

Для команд, планирующих перевод критических C/C++ библиотек на Rust:

Изолируйте C-ABI заголовок: Сформируйте чистый заголовочный файл .h со всеми экспортируемыми функциями и типами данных.
Сгенерируйте Rust FFI через bindgen / AI: Обеспечьте точное соответствие структур с аннотацией #[repr(C)].
Разверните дифференциальный фаззер (LibAFL): Напишите harness, принимающий входной буфер const uint8_t* data, size_t size и вызывающий обе библиотеки.
Задайте порог останова фаззинга: Минимум $10^8$ итераций без единого расхождения вывода и без утечек памяти (проверяется через ASan/Valgrind).
Замените .so в staging-окружении: Проведите нагрузочное и регрессионное тестирование зависимых сервисов.

Ключевые выводы

Автономная миграция стала индустриальным стандартом: AI-агенты в связке со строгими компиляторными верификаторами и дифференциальным фаззингом способны переносить миллионы строк системного кода, устраняя 70% фундаментальных уязвимостей безопасности памяти.
Фаззинг — единственный надежный судья: Любой сгенерированный LLM системный код требует дифференциального тестирования против оригинала на миллиардах мутированных входных векторов.
Safe Rust не уступает в скорости: Строгие гарантии уникальности ссылок (&mut) в Rust дают компилятору LLVM свободу векторизации, превосходящую ручной legacy-ассемблер.

Первоисточники и материалы

Оригинальное видео/статья: Let’s Get Rusty — Google Uses AI to Migrate C/C++ to Rust
Заметки и детальный конспект: Obsidian Vault (GitHub)
Инженерные наработки: github.com/xsa-dev

Self-Improving AI Software Factory: архитектура распределенной фабрики кода на базе LLM-агентов

2026-10-08T00:00:00+00:00

Локальные инструменты агентного кодинга (Codex, Claude Code, Aider, OpenDevin) совершили революцию в индивидуальной разработке. Однако при попытке масштабировать этот подход на уровень команды или автоматизированного пайплайна инженеры неизбежно упираются в системный тупик:

Локальный хаос промптов и конфигураций: у каждого разработчика свои настройки контекста, разные версии моделей и несогласованные правила форматирования.
Отсутствие воспроизводимости: невозможно точно оценить, улучшило ли очередное изменение в системном промпте качество кодогенерации или сломало граничные кейсы.
Неэффективная трата токенов: использование мощных LLM для механических задач (проверка синтаксиса, парсинг логов, поиск файлов) вместо детерминированных скриптов.

Решением становится переход от локальных CLI-утилит к AI Software Factory — централизованной распределенной системе оркестрации агентных воркеров с замкнутым контуром самообучения (Self-Improving Feedback Loop).

Разберем архитектуру такой фабрики (на примере системы Machinist, исследованной Оуэйном Льюисом).

1. Архитектура фабрики: Control Plane и Worker Pool

В основе промышленной фабрики кода лежит строгое разделение между уровнем управления (Control Plane) и изолированными вычислительными узлами (Worker Pool):

flowchart TD
    subgraph Triggers ["⚡ Входной поток задач (Triggers)"]
        T1["Webhooks / CI / Jira / CLI"]
    end

    Triggers -->|Новый тикет / запрос| CP

    subgraph CP ["🎛️ CONTROL PLANE (Machinist)"]
        direction TB
        DB[("Task Queue & Global State<br/>(SQLite / WAL)")]
        Catalog["Prompts & Skills Catalog"]
        Dashboard["Web Dashboard & Traces"]
        SSHGate["SSH Tunnel Gateway"]
    end

    CP ==>|🔒 Dispatches jobs over SSH tunnel| WP

    subgraph WP ["☁️ WORKER POOL (Hetzner / Cloud VMs)"]
        direction TB
        Foreman["👑 1. Foreman Agent<br/>(Планирование и декомпозиция)"]
        SubAgents["🤖 2. Sub-Agents Swarm<br/>(Claude Coder / Codex / PyTest)"]
        Audit["🛡️ 3. Audit Agent + Deterministic Evals<br/>(mypy, pytest, 3-Agent Review)"]

        Foreman -->|Делегирование подзадач| SubAgents
        SubAgents -->|Код, патчи и артефакты| Audit
    end

Преимущества такой топологии:

Изоляция окружения: агенты выполняют сборку, запуск тестов и системные команды на недорогих облачных серверах (например, Hetzner Cloud VM с 16–32 GB RAM), не засоряя локальную машину разработчика.
Очередь задач с лимитом параллелизма: Control Plane контролирует лимиты API (max_concurrent_jobs) и защищает от исчерпания рейтов LLM-провайдеров.

2. Иерархия агентных ролей: Foreman → Sub-agents → Audit

Монолитный агент, пытающийся одновременно планировать архитектуру, писать код, ставить зависимости и проверять тесты, быстро теряет фокус из-за раздувания контекстного окна (Context Rotting).

В фабрике реализовано четкое разделение ответственности:

Роль	Зона ответственности	Инструменты
Foreman (Прораб)	Принимает высокоуровневый тикет, исследует кодовую базу, формирует план и распределяет подзадачи.	`search_files`, `read_file`, `delegate_task`
Sub-Agent (Кодер)	Выполняет строго одну изолированную задачу в конкретном модуле (написание функции, рефакторинг, фикс бага).	`patch`, `write_file`, `terminal`
Audit Agent (Аудитор)	Проверяет соответствие критериям приемки, соответствие стилю и отсутствие побочных регрессий.	`pytest`, `cargo test`, `git diff`

3. Детерминированные Evals вместо лишних LLM-вызовов

Одна из главных ошибок при проектировании AI-фабрик — попытка решать все задачи через промпты нейросетей.

Золотое правило: если задачу можно надежно и дешево решить регулярным выражением, статическим анализатором или bash-скриптом — не отправляйте ее в LLM.

# Пример детерминированного гейта качества без участия нейросети
import subprocess
import sys

def verify_code_artifact(repo_path: str) -> bool:
    # 1. Синтаксический анализ и типы
    typecheck = subprocess.run(["mypy", repo_path], capture_output=True)
    if typecheck.returncode != 0:
        print(f"[FAIL] Typecheck errors:\n{typecheck.stdout.decode()}")
        return False
        
    # 2. Модульные тесты
    tests = subprocess.run(["pytest", "-q", f"{repo_path}/tests"], capture_output=True)
    if tests.returncode != 0:
        print(f"[FAIL] Unit tests broken:\n{tests.stdout.decode()}")
        return False

    return True

if __name__ == "__main__":
    if not verify_code_artifact("."):
        sys.exit(1)

Детерминированные скрипты дают 100% стабильный результат, выполняются за миллисекунды и экономят тысячи долларов на API-токенах.

4. Self-Improving Feedback Loop: обучение на трейсах

Почему фабрика называется самообучающейся?

Агентная фабрика не просто исполняет задачи, она непрерывно накапливает базу знаний об ошибках:

flowchart TD
    Fail["❌ Неудачный запуск / Broken Build"] --> Trace["📋 Трейс выполнения: логи + контекст"]

    subgraph RootCause ["🔍 Автоматический анализ узкого места"]
        direction TB
        P1["Неточная инструкция в системном промпте?"]
        P2["Недостаточный контекст из документации?"]
        P3["Сбойный вспомогательный скрипт?"]
    end

    Trace --> RootCause

    subgraph KnowledgeUpdate ["🚀 Обновление фабрики (Feedback Loop)"]
        direction TB
        K1["1. Обновление каталога Skills & Prompts"]
        K2["2. Создание нового синтетического Eval-теста"]
        K1 <--> K2
    end

    RootCause ==> KnowledgeUpdate
    KnowledgeUpdate -.->|Внедрение в воркеры| Fail

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

Ключевые выводы

Централизация побеждает локальный хаос: единый Control Plane с версионированием промптов и очереди задач обеспечивает воспроизводимость.
Разделение труда (Foreman / Sub-agents / Audit): узкоспециализированные агенты с компактным контекстом работают надежнее и дешевле монолитов.
Детерминизм во главе угла: используйте классические линтеры, компиляторы и тесты вместо LLM-судей везде, где это возможно.
Контур обратной связи (Evals Loop): каждый упавший трейс превращается в синтетический тест для предотвращения будущих регрессий.

Первоисточники и материалы

Оригинальное видео и автор: Owain Lewis — I Built A Self-Improving AI Software Factory
Детальный структурированный конспект: Obsidian Vault: Owain Lewis Software Factory (GitHub)
Инженерные наработки: github.com/xsa-dev