[3 AI-инструмента, 0 навыков программирования: как я написала гайд для разработчиков по WebGPU и запуску ИИ на устройствах]
Анализировать с AI
Получите инсайты с помощью AI из этой технической статьи Mad Devs:
В обычный рабочий день пришел запрос: можем ли мы подготовить технический материал для фронтенд- и фуллстек-разработчиков о запуске AI-моделей локально в браузере с использованием WebGPU и WebAssembly?
По сути, статья должна была объяснить, как можно запустить ИИ прямо в браузере с использованием WebGPU для аппаратного ускорения и WebAssembly для эффективного выполнения. Вроде бы звучит не слишком сложно, но на практике это открыло дверь в куда более технический мир, чем тот, в котором я обычно работаю.
Я копирайтер. Я пишу о программном обеспечении уже много лет, но я не пишу само программное обеспечение. Мне хватает знаний, чтобы поддержать разговор с инженером и не попасть впросак, но WebGPU не был в моем поле зрения, а WASM я смутно ассоциировала с "компилированными штуками, которые работают быстро". Формат такого материала предполагал читателя, который знает разницу между вычислительным и фрагментарным шейдерами. Я таким читателем не была.
Это моя честная история о том, что произошло дальше: что сработало, что нет и что я бы сделала иначе.
Изучение запроса, паника и решение не передавать задачу другому
Когда получаешь задание, к которому не готова, первое желание – найти того, кто готов. Передать разработчику. Попросить инженера написать черновик. Пусть разбираются те, кто в теме.
Но Mad Devs движется в другом направлении. Компания четко обозначила внутренний курс: ИИ – это инструмент для всех, а не только для разработчиков или дата-сайентистов. И это не просто слоган на стене, это то, как мы действительно работаем. Поэтому передавать задачу разработчику было бы не в духе этой идеи. Суть была в другом: выяснить, может ли нетехнический специалист с правильными инструментами и достаточным терпением создать что-то, что разработчики действительно сочтут полезным.
Я решила проверить. У темы была четкая внутренняя логика: начать с того, зачем браузеру вообще понадобилась новая GPU-модель, перейти к архитектуре, которая это делает возможным, затем к практической реализации и наконец к edge-кейсам в продакшн. Эта последовательность и определила структуру. Каждый раздел требовал технических знаний, которых у меня не было. Ничего. Буду разбираться с нуля с помощью инструментов.
Фаза первая: Claude как собеседник и партнёр по мышлению
Открывая Claude, я сразу знала, что не буду использовать запросы формата "сгенерируй мне статью про WebGPU. Такой подход дает контент, который выглядит как полноценная статья про WebGPU, но не приносит реальной пользы тому, кто хочет разобраться в этой теме.
Вместо этого я начала с самого простого вопроса, который пришел мне в голову: чем WebGPU реально отличается от того, что было раньше?
Разговор занял около двух часов и охватил больше, чем я ожидала. Не потому что Claude читал мне лекцию, а потому что я раз за разом спрашивала "почему это важно" и "что сломается, если этого не будет". Такой формат работал, потому что это было мое живое любопытство, а не промпт-инжиниринг.
По сути, я использовала Claude как очень терпеливого старшего разработчика с неограниченным временем, готового объяснять что угодно нетехническому коллеге. И убедилась, что формулировка вопроса имела значение. На "объясни WebGPU" я получала энциклопедическую статью. А вот на "почему фронтенд-разработчику важна разница между вычислительным и фрагментарным шейдером именно в контексте ML" – то, что могла реально использовать.
Понимание, к которому я пришла: WebGL создан для графики. Это рендеринг-пайплайн. Вы передаете ему геометрию, он рисует картинки. WebGPU создан как универсальный вычислительный интерфейс – он умеет рендерить, но также может выполнять произвольные параллельные вычисления, что как раз и нужно для инференса нейронных сетей. WebGL не проектировался для матричного умножения в масштабе. А вот WebGPU – да.
Когда эта картина сложилась, логика всей статьи выстроилась сама собой.
Где Claude был действительно полезен:
- Формирование понимания с первых принципов
- Выстраивание структурной логики (что объяснять перед чем)
- Написание фрагментов кода, хотя они требовали проверки
- Выявление пробелов в рассуждениях, когда я описывала задачу раздела и спрашивала, имеет ли подход смысл
Где Claude был ненадёжен:
Claude периодически генерировал код, который выглядел правильно, но таковым не являлся. Не грубые ошибки – без синтаксических проблем, ничего очевидно сломанного – но незаметно устаревший. Самый показательный случай: для материала требовалась утилита определения WebGPU. В первом черновике Claude использовал adapter.requestAdapterInfo() – метод, который был удален из спецификации. В современных реализациях вместо него используется синхронное свойство adapter.info. Код скомпилировался бы и упал в любом браузере, следующем актуальной спецификации.
После этого я усвоила: код от Claude – это черновик, который нужно проверять, а не готовый ответ.
Фаза вторая: ChatGPT для кросс-проверки
Когда черновик был готов, я прогнала его через ChatGPT . Не чтобы получить другую версию, а специально чтобы проверить техническое содержание на прочность. Вопрос, который я по сути задавала: что здесь не так?
ChatGPT вынес вердикт: "Рабочий мануал, но не полностью безопасен для вывода на продакшн в текущем виде". И четыре конкретные проблемы:
1. Использование requestAdapterInfo(). Это одна из проблем, которую я обозначала выше. Утилита определения использовала метод API, удаленный из спецификации WebGPU. В современных браузерах вместо него используется adapter.info как синхронное свойство. Старый метод компилировался бы без ошибок и падал бы в рантайм молча. Именно такой баг, который сложно заметить, не зная, что искать.
2. Нет предупреждения о том, что COEP блокирует загрузку моделей с внешних источников. Раздел про Cross-Origin Isolation правильно объяснял заголовки, но не указывал на последствие, которое регулярно всплывает в продакшн: при активном Cross-Origin-Embedder-Policy: require-corp браузер блокирует внешние ресурсы без совместимых заголовков CORS/CORP. Под это попадают в том числе файлы весов моделей с Hugging Face или CDN. Практический вывод: размещать ассеты моделей на собственном источнике (origin) отсутствовал полностью.
3. Пример "сообщений" в Worker, вероятно, вводит в заблуждение или не может быть выполнен. Код Web Worker в разделе генерации текста имел структурные проблемы, которые приводили бы к его сбою или непредсказуемому поведению в реальных условиях.
4. Устаревшие формулировки о поддержке браузеров. Часть формулировок о том, когда WebGPU стал доступен в конкретных браузерах, не соответствовала актуальной документации.
Именно здесь процесс получил свое подтверждение. Claude написал черновик. ChatGPT, которому поставили задачу найти проблемы, а не сгенерировать текст, нашел четыре продакшн-ошибки в этом черновике. Для нетехнического специалиста это различие принципиально: использовать модели для проверки результатов – совсем другая задача, чем использовать ее для создания, и она требует другого подхода к промпту.
Фаза третья: Antigravity – среда, в которой теория встраивается в браузер
Имея на руках четыре проблемы, я перешла к Antigravity – инструменту Google для технического ревью и анализа веб-контента. Здесь я сделала то, чего не делала с Claude или ChatGPT: задала структурированный скоуп, а не просто запрос.
Использованный промпт:
Отличие от работы с Claude в разделе ограничений. Указать инструменту, чего избегать (устаревших заявлений о браузерах, псевдокода под видом реальных примеров) оказалось так же важно, как указать, что нужно сделать. Antigravity вернул переписанную версию мануала: четыре проблемы исправлены, предупреждение о COEP добавлено, устаревший API заменен, код воркера исправлен, чеклист деплоя добавлен.
Я прошлась по каждому разделу, разобралась, что и почему изменилось, и внесла правки в финальный черновик. Понять изменения было обязательным условием – если не могу до конца вникнуть в исправление, я могу обратиться с ними к инженерам.
Инженерное ревью: что реально изменилось
Перед публикацией статья прошла через двух людей: Павла Зверева, CTO и Антона Козлова, системного разработчика. Это была не просто финальная шлифовка, а настоящий контрольный рубеж качества.
Что сразу броилось мне в глаза, когда я открыла документ после ревью: инженеры не переписали статью. Они исправили конкретные технические моменты, добавили нюансы в нескольких местах и подтвердили, что общая структура и подача работают. Концептуальная архитектура – как разделы связаны между собой, что в каком порядке объясняется – осталась нетронутой.
Это немного удивило. Я ожидала более серьезных правок. Вместо этого я исправила всего несколько точечных недочетов: неточная формулировка о поведении в конкретной версии браузера, замечание об ограничении, которое я не упомянула, и предложение добавить флаг always в конфигурацию Nginx, который я изначально пропустила.
Ни одно из них не поймал бы ни один AI-инструмент. Для этого нужен человек, который реально запускал это в продакшн и знает, где прячутся edge-кейсы.
Вывод: AI ассистированная подготовка технического материала может помочь правильно выстроить концептуальный каркас. Но заменить человека, который создал систему и знает, где она ломается, – не может.
Гайд "Запуск ИИ-моделей локально в браузере с помощью WebGPU и WebAssembly" уже опубликован на сайте Mad Devs с дисклеймером в начале: написан копирайтером, проверен инженерами. Эта прозрачность – важная его часть, а не просто сноска.
Что я вынесла из работы с ИИ над техническим контентом
Итак, я получила несколько важных инсайтов:
"Напиши мне статью про X" – худший возможный промпт. Он дает текст в форме статьи, но не саму статью. Лучше работать с инструментом как с собеседником: спрашивать то, чего действительно не понимаешь, оспаривать ответы, которые кажутся неполными, и требовать обоснования, прежде чем принять утверждение.
Используйте модели последовательно, с разными задачами. Claude – для понимания и черновика. ChatGPT – для ревью и выделения серьезных недочетов. Antigravity – для переработки и чеклистов со структурированным инженерным промптом. На каждом шаге новая моедль ловит то, что пропустила предыдущая. Уловить все нюансы через один инструмент практически невозможно.
Промпт определяет задачу. Когда я попросила ChatGPT верифицировать, а не генерировать, он нашел четыре продакшн-проблемы, которые черновик пропустил. Когда я дала Antigravity четкие ограничения – избегать устаревших заявлений, указывать на CORS/COEP-подводные камни, маркировать псевдокод – результат оказался принципиально другим, чем при запросе "проверь это". Инструмент работает настолько сфокусированно, насколько сфокусирован ваш запрос.
Инженерное ревью не опционально. Это контрольный рубеж, в который упирается весь остальной процесс. AI-инструменты приближают вас к цели. Эксперты указывают, где подготовленный материал на самом деле расходится с реальностью.
"Нетехнический" не значит неспособный. Это значит, что нужен другой инструментарий и больше времени. Инструментарий есть, но важно уложить достаточно времени на обучение по его использованию.
Если вы собираетесь попробовать это сами
Вот несколько практических советов для нетехнических специалистов:
Начните с понимания, а не с результата. Прежде чем просить ИИ что-либо написать, попросите его объяснять тему до тех пор, пока вы не сможете рассказать ее своими словами. Если этот тест не пройден, оценить то, что инструмент выдаст, не получится.
Встройте шаг проверки в процесс. Для кода – запустить его. Для фактических утверждений – сверить с документацией или второй моделью. Для технических суждений – поговорить с тем, кто разбирается.
Рассчитывайте на больше времени, чем кажется. Не потому что инструменты медленные, а потому что понимание требует времени, а без него точного результата не будет.
Получите ревью от эксперта до публикации. Не после. Ревью – часть процесса, а не финальный чекбокс.
И если в вашей компании говорят, что ИИ – инструмент для всех, отнеситесь к этому достаточно серьезно и попробуйте его на чем-то действительно сложном. Только так можно понять, что он умеет, и где его предел.