Возможно, пора начать рисовать комиксы против проповедников ИИ, которые утверждают: «Не смотри в генерируемый код — просто проверяй его в тестовом стенде». Ниже — первый пример.
Гигантская очередь вместо логики управления
ИИ не справился с проектированием логики управления потоком данных. Вместо этого он внедрил в дизайн гигантскую очередь (FIFO), которая просто сохраняла все входящие транзакции из теста и использовала их по мере необходимости.
В тестовом стенде было около 10 тысяч транзакций. Когда я удвоил их количество, произошло переполнение очереди — данные были потеряны, проверка завершилась ошибкой. При этом эталонная, написанная вручную транзакционная модель поведения осталась корректной.
Реальные масштабы катастрофы
Представьте, что такой блок попадёт в реальное устройство. При тактовой частоте в гигагерц (миллиард операций в секунду) за 20 минут накопится более триллиона транзакций.
Сколько D-триггеров нужно, чтобы хранить двести триллионов значений? А если рассматривать работу в течение суток — уже речь идёт о квадриллионе. Это соответствует чипу размером с приусадебный участок.
Память в железе — это не просто объём
В аппаратных системах размер структур — не абстракция. Особенно когда речь идёт о D-триггерах или встроенной SRAM. Это напрямую влияет на энергопотребление и тепловыделение.
В программировании можно везде выделять память по степеням двойки — виртуальная память справится. Но в железе вы получите либо быстро садящийся аккумулятор в телефоне, либо необходимость ставить жидкостное охлаждение на роутерный чип магистрального маршрутизатора.
Ещё один пример: избыточность по глубине FIFO
Другой ИИ (Claude, всего две недели назад) по неизвестным причинам стал создавать FIFO только с глубиной, кратной степени двойки. Вместо 13 — 16, вместо 20 — 32.
Если применять такую стратегию повсеместно, площадь чипа взлетит в разы. И всё это — лишь потому, что разработчик не заглянул в сгенерированный код.