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