30 лет назад я поступил в технический вуз на кафедру искусственного интеллекта. Мало кто понимает, что ИИ существует уже больше 60 лет, а нейросети программировали на компьютерах ещё 40 лет назад – с 16 килобайтами памяти.
В университете мы не просто изучали математику нейросетей – мы их проектировали, начиная с уравнений на бумаге и заканчивая кодом. Любопытный факт: уже на первом курсе мы писали самообучающиеся игры в рамках учебных заданий.
Многие слышали об ограничениях и артефактах нейросетей, но не все понимают их фундаментальные причины, поэтому в работе с нейросетями полагаются на своего рода магию и недооценивают последствия. Без глубокого понимания того, что ИИ – это куда больше, чем переписка с LLM, хорошего результата не добиться. Все об этом говорят, но мало кто осознаёт, что промптинг не решает проблему целиком.
Прежде чем перейти к примерам использования ИИ в дизайн-отделе, покажу свой хобби-проект по программированию и продемонстрирую, как пользоваться ИИ правильно.
В честь 50-летия классической текстовой RPG «Colossal Cave Adventure» – прародительницы всех ролевых игр – я решил портировать её с мейнфрейма PDP-10 на 40-летний домашний компьютер с 16 килобайтами памяти. Оригинал написан на Fortran, скомпилированный файл занимает 60 килобайт, и портировать его на менее мощный компьютер кажется невозможным. Но если вы меня знаете, вы не удивитесь – я считаю, что нет ничего невозможного. Ещё одна причина, почему проект меня зацепил: мне предстояло обучить Claude Code программировать под платформу, с которой он раньше не был знаком.
Проанализировав исходники на Fortran, Claude Code заключил, что портировать игру невозможно (разве что разбить текстовые данные на 10 маленьких файлов и подгружать их по одному во время игры). Конечно, никогда не стоит верить ИИ на слово, когда он говорит, что что-то невозможно (это просто значит, что нейросеть не обучена на таких задачах).
Вот тут Claude Code и пригодился: я попросил его провести статистический анализ текстовых сообщений игры и определить, какие символы используются реже всего. Затем я составил алфавит из 40 символов, оставив только заглавные буквы, знаки препинания и несколько цифр. Остальные цифры в тексте пришлось заменить словами (например, «one» вместо «1»). Этот алфавит я упаковал в кодировку, похожую на Radix-50 – чтобы 3 символа умещались в одно 16-битное слово. Я также рассматривал идею добавить ESC-последовательности для расширения алфавита, но анализ показал, что выгоды это не даст, а только усложнит, замедлит и раздует код.
Claude Code помог мне с анализом и написал Python-скрипт для конвертации ASCII-текста в мой формат – вот где реальная польза. Опасность же была в том, что Claude Code несколько раз пытался увести меня по неверному пути, отговаривая от хороших решений. Иначе говоря, без высокого уровня экспертизы в программировании и оптимизации вы рискуете уйти совершенно не туда – и даже не заметите этого.
Следующий этап портирования включал переосмысление огромных таблиц переходов: я заметил, что один из столбцов таблицы мог содержать только значения 1, 2, 3 или 4. Я предложил заменить одну таблицу на 4 отдельные, чтобы избавиться от этого поля. В каждой записи, помимо экономии 1 байта, мне удалось сэкономить ещё байт, который шёл на выравнивание записи по чётным адресам. Были и другие приёмы оптимизации таблиц – их пришлось придумывать самому, а конвертацию я поручил Claude.
Что касается качества кода, оно было ужасным, будто его писал школьник, который только вчера взял в руки книжку по ассемблеру – всё написано в лоб, алгоритмы неоптимальны, много лишнего кода. И это несмотря на то, что я обучил Claude Code на 40 собственных программах – хорошо написанных и хорошо задокументированных. Проблема в том, что Claude Code опирается на огромный массив промышленного кода 1970–1990-х годов для PDP-11, а его качество, мягко говоря, посредственное. Мне пришлось переписать абсолютно весь ассемблерный код, сгенерированный Claude Code. Но признаю, польза была: по крайней мере, мне не пришлось читать исходники на Fortran – Claude Code сделал это за меня!
Мой пост об этом в Facebook получил огромный отклик, и поначалу многие говорили, что я просто неправильно пользуюсь ИИ. Но, разобравшись в деталях и копнув глубже, почти все согласились, что задачу решить нельзя, и что у этого есть фундаментальные причины, связанные с архитектурой LLM и базой, на которой обучают коммерческие модели. Я возлагаю большие надежды на технологии вроде грядущего Frontier Tuning от Microsoft, которые позволят по-настоящему дообучать модели на собственных данных, постепенно вытесняя общедоступный обучающий датасет. Это касается и дизайна – будущее за DesignOps, которые будут обучать локальные модели.
Пока же я пришёл к, на мой взгляд, оптимальному сценарию использования AI-ассистентов: интеллектуальную работу делать самому и не спрашивать у ИИ, как лучше, а отдавать агентам задачи, связанные с тестированием, статистикой, конвертацией и форматированием. Только так и можно добиться «невозможного». С таким подходом я создал системную утилиту для macOS – её можно найти в App Store.
