Инженеры OpenAI во время тестов AI-ускорителя Jalapeño не смогли построчно объяснить часть низкоуровневого кода, который для них сгенерировал Codex. Для русскоязычной IT-аудитории здесь важен не сам курьёз, а сдвиг в инженерной практике: код OpenAI уже доходит до уровня железа, где команда доверяет машине не только черновики, но и производительные кернелы, которые потом сама разбирает лишь на уровне общей логики.
Об этом сообщает Habr / Новости со ссылкой на рассказ аналитика SemiAnalysis Джордана Наноса. По его словам, эпизод произошёл во время тестирования чипа на бенчмарке InferenceX, когда специалисты SemiAnalysis приехали в лабораторию OpenAI и вместе с инженерами компании разбирали программный стек Jalapeño. В центре внимания оказался файл примерно на 30 тыс. строк с кодом кернела Multi-head Latent Attention, механизма внимания, который используется в DeepSeek R1.
Речь не о том, что команда вообще не понимает, что у неё работает. По описанию Наноса, инженеры понимают архитектуру чипа, знают, какую задачу решает кернел, и могут объяснить общий принцип его работы. Но если попросить их пройтись по конкретным строкам и точно рассказать, зачем здесь та или иная конструкция, уверенности уже нет. Это особенно показательно потому, что, как уточняется, над проектом работают специалисты с серьёзным опытом в GPU-программировании. То есть проблема не в нехватке квалификации, а в том, что генератор кода начал выдавать решения, которые люди готовы принять как рабочие без полного ручного разбора.
Технический контекст тоже важен. Кернел написан на Gluon, низкоуровневом языке для GPU, построенном на том же компиляторном стеке, что и Triton. Иными словами, это не «игрушечный» код для внутреннего прототипа и не Python-скрипт, который можно безболезненно переписать через неделю. Это участок, влияющий на производительность железа, на поведение модели в инференсе и на дальнейшую оптимизацию всей цепочки. По словам Наноса, агенты Codex практически самостоятельно создали эффективные кернелы для DeepSeek R1, хотя у OpenAI до этого не было собственной реализации MLA. Команда проверила результат, убедилась, что он работает, и не стала тратить время на глубокую декомпозицию каждой детали.
Здесь и начинается самое интересное. Ещё недавно индустрия повторяла довольно простое правило: разработчик обязан понимать код, который пишет, потому что потом ему этот код поддерживать, оптимизировать и отлаживать. История с Jalapeño показывает другую модель. Человек задаёт архитектуру, ограничения и критерии корректности, а система перебирает реализации и находит вариант, который проходит тесты и даёт нужную производительность. Если смотреть на это без романтики, то перед нами уже не «помощник программиста», а переборщик инженерных гипотез на уровне, где стоимость ручной оптимизации крайне высока. Для команд, которые работают с компиляторами, ускорителями, inference-стеком и внутренними DSL, это очень соблазнительный сценарий.
Но соблазн здесь идёт в комплекте с вполне взрослыми рисками. В обсуждениях, на которые ссылается источник, пользователи разделились на два лагеря. Одни увидели в ситуации естественный следующий шаг: если код даёт нужный результат, проходит проверки и ускоряет разработку, незачем требовать от человека ручного понимания каждой строчки. Другие отреагировали куда жёстче: непонятный низкоуровневый код тяжело отлаживать на пограничных случаях, ещё тяжелее сопровождать, а разговоры о бэкдорах и потере контроля в таком контексте перестают звучать как чистая паранойя. Особенно если этот код становится частью системы, завязанной на реальное железо, производительность и устойчивость вычислительного контура.
Для разработчиков и техлидов эта история важна не как анекдот про «AI написал что-то магическое», а как практический сигнал. Код OpenAI в этом случае прошёл знакомый многим путь: сначала генерация кажется удобной для рутинных задач, потом она дорастает до сложных внутренних модулей, а затем оказывается в критичных местах, где цена ошибки измеряется уже не потерянным часом фронтенд-разработчика, а поведением всего продукта или платформы. Из этого следует неприятный, но полезный вывод: если команда хочет опираться на AI-генерацию в серьёзных компонентах, ей нужно заранее проектировать не только тесты, но и режим эксплуатации такого кода. Кто отвечает за верификацию? Что делать, если через три месяца производительность просела, а автором оптимизации формально была модель? Где проходит граница между «не обязаны понимать всё» и «уже потеряли управляемость»?
Для бизнеса вывод тоже довольно прямой. Генеративные инструменты начинают конкурировать не только за скорость написания фич, но и за право принимать микроархитектурные решения внутри продукта. Если это работает, компании выигрывают месяцы разработки. Если не работает, они получают технический долг нового типа: система быстро едет вперёд, но объяснимость и поддерживаемость отстают. История с Jalapeño показывает, что спор о пользе AI-кода уже вышел из уровня IDE-плагинов и дошёл до железа. Следующий большой вопрос для отрасли звучит не как «может ли модель написать сложный код», а как «какой объём непонятного, но рабочего кода команда готова считать нормальной инженерной практикой».