Spiiin's blog

Чистая и грязная инженерия#

Pure and impure software engineering — разделение инженерии на “чистую” и “нечистую”

ИИ в программировании уже сейчас позволяет хорошо решить часть задач, для которых решение в принципе известно, и требует только времени на реализацию. Например, если нужно сделать 10 окошек/форм, в которых пользователь будет вводить данные разным способом, то дизайн таких окон — хорошая задача для автоматизации. Или написать 100 тестов и проверить, сгенерировать документацию и подобное. Таких задач достаточно много в типичной разработке софта. Существует много способов решить задачу, нет необходимости в реализации оптимального решения. Достаточно показать модели приблизительно, как выглядит код, и можно тиражировать его. В каких-то областях разработки такого кода достаточно много. Часть задач вроде покрытия тестами есть во всех дисциплинах, но где-то этому уделялось меньше внимания или из-за нехватки ресурсов, или из-за фокуса на другом на ранних стадиях разработки.

В то же время, есть группа задач, с которыми ИИ пока по разным причинам справляется плохо, из-за отсутствия нужного контекста или вообще из-за того, что модель должна быть ориентирована не непосредственно на написание кода, а на специфическую задачу с кодом.

Ну, то есть на сейчас, ИИ может решить условно 70% задач, которые занимали 30% времени (допустим, что тут работает вариант закона Парето). Оставшиеся 30% задач занимают 70% времени, и тут всё ещё нужны люди. Это или сложные задачи в определённой области, или целый области, в которых ИИ работает хуже, из-за которых возникает непонимание тех, у кого ИИ “делает всё сам”, и тех, у кого “ИИ не работает вообще”. Мой поинт в том, что постепенно количество таких областей “чистой инженерии”, где нужны ручные хорошие решения, будет уменьшаться. Несколько примеров областей, где ИИ пока работает хуже:

📍 Графическое программирование. Модели плохо пишут шейдеры из-за того, что плохо понимают производительность кода ^[1] (здесь можно было бы обучить модель на размеченных данных о производительности, возможно им удалось бы ухватить паттерны, которые дают наиболее быстрые инстринсики), а также пока не могут нормально проанализировать полученный результат (здесь тоже, отладчики кадра вполне могут отдать серию кадров модели).

Сейчас LLM редко дают API для того, чтобы дообучить модель на своих данных, все эти трюки со скиллами/тулзами, основанные на текстовых подсказках/препромтах, выглядят игрушками по сравнению с тем, как мог бы выглядеть нормальный фреймворк для дообучения ^[2]. Это то, что превращает “симулятор интернет-документа” в ChatGPT (link) и то, что превращает среднюю diffusion-модель в художника в определенном стиле. Сейчас реализовать какой-нибудь известный, но сложный графический алгоритм на продакшн уровне у хорошего программиста может занять неделю-две. Модели будут делать это за минуты ^[3], как это сейчас происходит с тем, чтобы подвинуть кнопку.

Третья трудность графического программирования — арт сторона программы. Артистам иногда нужно отступать от физической точности ради создания нужного эффекта (Beyond photographic realism (2016)). Но и здесь мульти-модальные LLM могут получить преимущество перед программистом. Во-первых, они и так уже обладают скиллами в нескольких областях (программиста, который понимает и техническую сторону, и то как работают артисты, найти сложнее), во-вторых, с большой скоростью перебора/генерации легче подобрать эффект, который будет соответствовать визуальному, возможно будут еще рывки здесь просто с ростом количества параметров нейронок.

Забавно наблюдать в твиттере некоторых графических программистов, которые некоторое время назад как раз писали, что у них точно ИИ никогда не справится, сейчас пишут осторожное “ну кое в чём они уже действительно помогают”. Еще год, и будет такой же восторг как у тех, где часть задач решается с одного промпта

• Почему я недолюбливаю программирование графики — почему графическое программирование сложное

📍 Поиск уязвимостей. Собственно, пример области, в которой уже так и произошло. Специализированная модель, которую дотренировали на конкретную задачу, ищет уязвимость на уровне топ исследователей ^[4] (а, традиционно, исследованием безопасности кода занимаются одни из лучших программистов). Судя по списку благодарностей (например, от FFMpeg или Linux Foundation), это не маркетинговый приём, а действительно прорыв в области. Тысячи уязвимостей во всех известных операционках, браузерах и железках. (Заодно показывает, что произойдёт, если у AGI появится желание захватить все наши сети, думаю это займет у него десятки минут)

📍 Асинхронное/многопоточное программирование. Со своей колокольни редко сталкиваюсь непосредственно с многопоточными задачами, но в мире геймдева всё равно полно задач, связанных с гонками. Пара примеров, где ИИ не справлялся сейчас.

• Между показом двух окон проходит несколько кадров, что даёт визуальный эффект мерцания. Появление окон обмазано асинхронными условиями из разных частей игры, которые сложно найти и ухватить модели
• Синхронизация анимаций, сделанных через серию колбеков по таймингам. Условно, “через 100 мсек начни проигрывание одного эффекта, затем через 200 другого, и через 600 третьего”. Такой код очень хрупкий к изменениям от геймдизайнеров “а теперь делаем всё синхронно одновременно и в фоне загружаем ресурсы смены сцен”.

В обоих случаях помогла предварительная верификация того, что может происходить в движке, сделанная вручную. ИИ сложно понять требования, что может выполняться одновременно, а что должно происходить поочередно. В многопоточности также, задача верификации выполняется “извне”, т.е. описывается набор правил, которые должна соблюдать программа, доказывается что эти правила обеспечивают отсутствие гонок, и создаётся инструмент, который их проверяет. Если мы находимся не в идеальном мире, где отсутствие гонок доказывается математически, то выдаём ИИ инструмент для прогона программы с тред-санитайзером (для реальных тредов) или читами управления таймерами (для игрового асинхронного кода), и учим анализировать упавшие запуски.

Здесь важно заметить, что чем более high-latency задача, тем сложнее её сделать и проверить. Если нужно скомпилировать всю игру на C++, запустить и прогнать с tsan, это всегда будет дороже, чем, например, скомпилировать код на Rust и проверить на ошибки гонки, которые нашел компилятор, но это касается не только решения задач с ИИ.

📍 Оптимизация системного/горячего кода. Здесь скорее всего, как с графическим программированием, поможет модель, понимающая время выполнения инструкций, чтобы генерировать быстрый код сразу, а не анализировать существующий. Современные процессоры и так работают достаточно сложно, чтобы человек даже вручную мог сгенерировать код лучше компилятора (даже для AoT, а есть ещё и JiT) для разных процессоров.

📍 Архитектура. ИИ копирует “формы” в проекте, и редко верно предлагает новые подходящие структуры решения. Здесь на мой взгляд, присутствует некоторая переоценка важности того, насколько сложно сделать хорошую архитектуру. Если присутствует достаточное количество требований и понимания точек изменения/расширения, то архитектура — это то, что будет хорошо соответствовать этим требованиям. Требования — это как раз большой объём документации, Architecture Decision Records, Best Practices, то, что уже накоплено в проекте, и то что делается для ИИ (externalized memory как ключ к архитектуре). Это как раз область, которую сейчас пытаются двигать в больших компаниях — приведение в порядок того, что по идее, должно было делаться и так, создание условий для того, чтобы модель могла получить информацию, что такое хорошо и что такое плохо. Почему я считаю, что архитектура в геймдеве менее важна, чем это часто представляют — я почти не видел проектов в геймдеве, в которых именно архитектура мешала бы росту (где-то ~10 лет в live-ops с постоянным обновлением), чаще лимитируют контент-pipeline и production-скорость. И наоборот, видел много успешных, которые с точки зрения архитектуры выглядели бы ужасно (как с точки зрения отсутствия архитектуры, так и с точки зрения овер-инжениринга, когда для создания нового мелкого функционала нужно было завести 8 новых файлов).

Также возможно, что скилл выбора архитектуры улучшится просто с ростом контекста, который можно засунуть в модель ^[5] — даже несмотря на то, что некоторые требования не описаны в коде или тестах, а существуют только в голове команды, не все из них действительно необходимы для понимания архитектуры, любая абстракция подразумевает некоторый уровень отказа от деталей.

Есть пара обсуждений старой статьи Programming as theory building:
Do the Illegible
Programming (with AI agents) as theory building
На мой взгляд, они хорошо описывают то, чем является архитектура обычно — это то, чего нет непосредственно в кодовой базе или документации. Ну и решение проблемы с передачей ИИ контекста — сделать невидимое видимым, т.е. записывать всё это в AI-friendly форме (чаще всего сейчас это просто markdown) и редактировать/поддерживать вместе с моделями. Если выйдет “построить долгосрочную теорию всей кодовой базы”, то необходимость писать markdown-заметки просто отпадёт. Для этого нужно или разрешить моделям модифицировать свои веса под конкретный проект, либо каким-либо образом хранить контекст для задач, которые программист выполняет неделями-месяцами.

📍 "Нечистая" инженерия не означает, что ей занимаются менее талантливые программисты, для неё просто нужны другие навыки, связанные не с нахождением идеального решения, а с балансированием сроков/качества и понимания потребностей бизнеса.
The curse of success. Why nothing great is ever “good” — почему реальные продукты почти никогда не бывают “чистыми” внутри.

Порог входа#

Бог сделал людей разными, а LLM сделали их равными.

Сейчас ИИ понижает порог входа в новую область и ускоряет процесс “вкатывания”. Это не отменяет того, что в итоге нужно всё равно разобраться в предметной области, хотя и упрощает/ускоряет процесс. На данный момент это выглядит как новые возможности, но рынок устроен так, что если какой-то продукт/навык теперь есть у всех, то стоимость этого продукта/услуги падает.

Хуже того, если кто-то автоматизирует определенный пайплайн, может получится так, что на рынке труда больше не останется определенных вакансий, совсем. Ни постоянных, ни для фрилансеров. Если твой продукт, к примеру, музыкальный трек, стоил 250$ за минуту, а чуть худший, сгенеренный ии, сейчас стоит 0.5$ и делается за секунды, то рынок сделает свой выбор.

Кроме процесса изучения “традиционных” навыков, существуют или навыки выполнения чего-то с помощью ИИ. Мы находимся только на заре открытий того, как работают модели, и что они могут. Т.е. “открыть” что-то новое пока достаточно легко, а сами открытия простые (поэтому, кстати, достаточно легко читать пейперы). Промпт-инжиниринг, “навыки” как отдельная фича в Claude, или даже идея заставить ИИ рассуждать перед ответом — достаточно простые. Это новые и полезные идеи, и они действительно значимы, но при этом очень простые, и чтобы проверить их, не обязательно быть экспертом в какой-то области. Это тоже выглядит перспективно для экспериментов и стартапов, и так вероятно будет продолжаться еще какое-то время. Здесь есть возможности для человека не в теме исследовать что-то новое, нас ждут заголовки вроде “школьник из деревни сделал свою модель, которая обгоняет зарубежные аналоги” и “Мила Йовович написала свою модель памяти для ИИ”. Пока такие исследования не начнут генерироваться самими моделями, и снова стоимость таких открытий упадёт. Любая область знаний со временем усложняется.

Если говорить о навыках “оператора ИИ”, которые все стремятся продать другим, то они и сейчас достаточно дешёвы, я бы оценил, что нормальный инженер должен освоить их недели за две-три. Техники работы с ИИ изменятся еще много раз, как возможно и требования к оператору (если вообще будет в нём нужда), скорее всего то, что вы знаете об ИИ сейчас, устареет через пару лет.

Работающие ИИ-продукты#

По большому счёту, существует несколько видов успешных ИИ b2c-сервисов.

📍 Чат-боты, с которыми сейчас могут взаимодействовать все. Проблема для стартапов, которые являются обёртками, в том, что универсальный LLM чат от вендоров модели всегда останется лучшим. Любая обёртка будет хуже, потому что у владельцев моделей всегда будет доступ к экспериментальным новым моделям, а также возможность лучше интегрировать их с продуктом. А также возможность просто “подкрутить” лимиты или правила использования своего API, чтобы любые схемы с арбитражем токенами стали невыгодны. Любые конкретные “личности”, помогающие изучать иностранные языки, оригинально поздравить друга, или принимающие роль виртуального партнёра проиграют “супер-личности” большой модели, если попросить её об этом же. Серьёзное исследование вместо быстрого ответа попадает сюда же.

📍 Инструменты. Чат не всегда лучший интерфейс для решения задачи. Иногда вывод модели может быть скрыт за командной строкой, нажатием табуляции для автозаполнения или “контрол-плюс” для апскейла. Нет смысла описывать задачу детальным промптом, если можно сделать это более естественно. Инженерам или менеджерам не всегда просто принять эту мысль. Сюда же относятся агенты, как замена скриптовых языков или пайпов для связывания программ между собой.

📍 Инфраструктура. Не сказать что это новый тип сервисов, предоставить свои облачные мощности для вычислений, связанных с обучением или выводом ИИ.

Пока не заработавшие идеи из области геймдева и развлечений

📍 Бесконечная ИИ-лента. Социальные сети тратят много денег на то, чтобы у них был контент для удержания пользователей. Если можно платить не инфлюенсерам/сми/пользователям, а генерировать контент заранее или на лету персонально для конкретного пользователя, то здесь, как и с производством арта, рынок выберет более дешёвый вариант ^[6].

📍 Игры. Можно генерировать графику (dlss 5). Когда 2d сменялось 3d, даже самые ранние прототипы выглядели впечатляюще. Но первые прототипы ИИ-графики, генерируемой на лету, почему-то пока всё еще выглядят “на троечку”. Но рано или поздно у кого-нибудь получится. Другая область — ИИ для генерации диалогов, квестов или симуляции мира.

Проблемы#

📍 Для бизнеса — написание кода с помощью ИИ, это всё ещё R&D. Плюс в том, что получается слишком быстро. Минус — в бизнес тянутся все проблемы, которые существуют в академической среде. Непредсказуемость сроков, сложность достижения стабильного повторяемого результата (ИИ отдел компании попробовал, отдал на внедрение в продукт, в продукте работает нестабильно), отсутствие опыта внедрения. Также зависимость от провайдеров моделей.
📍 Для работников — сокращение рабочих мест, необходимость постоянно переучиваться, в перспективе — возросшие требования к навыкам. Каждый внедренный “агент с ролью Unity-dev” или “агент QA” — это заявка на закрытие им вакансии человека, выполняющего эту работу. Поднятие производительности в 10 раз — уже проблема и для сотрудников и для компаний. В 100 раз — новая промышленная революция и проблема в том числе общества.

Примечания#