Аудит вайб-кодингу: приховані збої переписування систем без рев'ю коду
Архітектурний аудит згенерованих ШІ портів Campfire виявив критичні збої, коли код приймають наосліп. Від блокуючих викликів бази даних у Tokio до переповнення каналів трансляції з втратою 99% сповіщень — агенти роблять неявні архітектурні компроміси.
Чому це важливо
Перевіряйте згенерований асинхронний код на наявність блокуючих викликів і переповнення буферів каналів, перш ніж виводити вайб-сервіси в прод.
TL;DR
- 01LLM часто поєднують синхронні блокуючі операції з асинхронними рантаймами, зупиняючи робочі потоки.
- 02Обмежені канали без налаштованого backpressure спричиняють масову втрату повідомлень під навантаженням.
- 03Бенчмарки пропускної здатності приховують системні збої; обов'язково перевіряйте відсоток доставлених подій.
Ключові факти
- Доставка сповіщень у Rust під навантаженням
- 1% (стрес-тест Зака Деніелса)
- Доставка подій у Rust (100 POST/с)
- 14% отримано (0% HTTP-помилок, дисконекти)
- Доставка подій в Elixir (100 POST/с)
- 60% отримано (23% таймаутів, затримка до 180 с)
Неявні архітектурні викривлення агента
Коли промпт не містить суворих архітектурних рамок, модель робить приховані компроміси. Під час переписування Campfire з Ruby on Rails на Rust та Elixir, агент у версії для Rust самовільно відкинув CSRF-токени заради полегшення кешування та замінив Redis на внутрішньопроцесні черги. Оскільки LLM не володіє повним системним контекстом, підтримка зворотної сумісності, відновлення після збоїв та безпека сесій стають непередбачуваними випадковостями.
Блокування потоків у асинхронному Rust
Код для Rust виявив нерозуміння кооперативної багатозадачності в tokio. Робочі потоки Tokio зависають, якщо таска не повертає керування рантайму. Згенерований код запускав блокуючі синхронні виклики SQL безпосередньо в асинхронних задачах, замість асинхронного I/O. Додатково було застосовано стандартні блокуючі м'ютекси замість tokio::sync::Mutex. Утримання синхронного локу навіть протягом 10 мс блокує виконання всіх інших задач на цьому робочому потоці.
Втрата 99% сповіщень та проблеми Backpressure
Навантажувальні тести виявили катастрофічний збій: у Rust-версії було доставлено лише 1% сповіщень через переповнення фіксованого буфера каналу tokio::sync::broadcast. За постійного навантаження у 100 POST-запитів/с клієнти отримали лише 14% подій. У Elixir доставка досягла 60%, але 23% HTTP-запитів завершилися за таймаутом із затримками до 180 секунд.
Спробуй за 2 хвилини
// Replace blocking synchronization with async-aware primitives
use tokio::sync::Mutex;
// Avoid std::sync::Mutex inside async tasks (blocks Tokio workers)
// let guard = sync_mutex.lock().unwrap();
// Correct pattern for cooperative concurrency:
let guard = async_mutex.lock().await;rust
✓ Коли використовувати
- Під час планування міграцій сервісів, коли в промптах можна чітко задати примітиви конкурентності.
- Для формування чекліста рев'ю згенерованого коду перед релізом у прод.
Що зробити сьогодні
- Проведіть аудит згенерованого коду на наявність std::sync::Mutex і замініть їх на tokio::sync::Mutex.
- Перевірте, щоб звернення до БД в асинхронних тасках використовували асинхронні драйвери або spawn_blocking.
- Налаштуйте стратегії переповнення для bounded broadcast-каналів, щоб запобігти непомітній втраті даних.