Старий MacBook навчили перевіряти власні AMD-драйвери через дзеркало і вебкамеру

Розробник Linux Джастін Шредер продемонстрував незвичний спосіб дати програмному AI-агенту візуальний зворотний зв’язок. Старий MacBook дивиться на відображення власного дисплея у дзеркалі через вбудовану вебкамеру, поки система працює над поліпшенням підтримки графіки AMD Radeon у дистрибутиві Omarchy. Така схема виглядає комічно, однак показує практичну проблему автоматизованої розробки: агент може змінити код і запустити команду, але йому ще потрібно побачити, що реально намалював екран.

Шредер не оприлюднив повної технічної схеми експерименту та не назвав конкретну модель програмного агента. Тому твердження про повністю автономне написання драйвера було б перебільшенням. Відомо лише, що камера використовується для контролю результатів налаштування Radeon, а ноутбук, імовірно, належить до Intel-моделей Mac із дискретною графікою AMD. Це логічне припущення з конфігурації пристрою, а не підтверджена специфікація конкретного MacBook.

Чому взагалі потрібне дзеркало? Вбудована камера спрямована на користувача й фізично не бачить панель ноутбука. Відображення дозволяє перетворити її на зовнішній спостерігач без додаткової камери або плати захоплення. Агент отримує кадри, може розпізнати артефакти, чорний екран, неправильну роздільність чи збій інтерфейсу, а потім зіставити побачене з останньою зміною в коді. Для швидкого прототипу це дешевий спосіб замкнути цикл «зміна — запуск — візуальна перевірка».

Omarchy позиціонується як Linux-дистрибутив для епохи програмних агентів. Розробники заявляють про швидке встановлення, вбудовані засоби автоматизації та можливість діагностувати проблеми за допомогою агентів. Проєкт поширюється за ліцензією MIT і не обмежується старими Mac: серед підтримуваних напрямків названі Apple Silicon, сучасні x86-комп’ютери та навіть слабкі машини на кшталт ThinkPad X220. Утім, широка сумісність на сайті проєкту не означає однакову зрілість усіх драйверів.

Візуальний контроль особливо корисний там, де звичайного журналу помилок недостатньо. Графічний стек складається з ядра, Mesa, дисплейного сервера, композитора та конкретних програм. Помилка може не завершити процес аварійно, а проявитися мерехтінням, спотворенням кольору чи частково намальованим вікном. Модель комп’ютерного зору здатна помітити такий симптом, але її висновок також може бути хибним. Тому людська перевірка й відтворюваний тест залишаються необхідними.

Експеримент не доводить, що AI вже може самостійно створювати безпечні драйвери. Код низького рівня працює з пам’яттю, живленням і апаратними регістрами, тому невдала зміна здатна зависнути, пошкодити дані або залишити систему без зображення. Надійний процес потребує резервної точки входу, контролю версій, автоматичних тестів і жорстких меж для команд агента. Найцінніший висновок тут інший: камера стала ще одним сенсором у циклі розробки, а старе залізо — полігоном для перевірки інструментів, які можуть доповнювати інженера, але не скасовують відповідальність за результат.