TLDR: ИИ — это не ваш помощник, а разработчик-джун, имитирующий профессионализм. Доверяйте ему на свой страх и риск.

Я уже четыре дня занимаюсь своим хобби-проектом. Я был уверен, что реализую его. У меня был хороший план и большой интерес к проекту. Позвольте мне познакомить вас с Deskthang. Это настольный уведомлятор. Во время работы я хочу оставлять свой телефон в другой комнате и получать только важные уведомления. В случае сбоя конвейера развёртывания я хочу, чтобы устройство на моём столе загоралось красным и показывало мне логотип gitlab. Я не хочу, чтобы мне приходилось проверять телефон, почту или другие источники, которые могут отвлечь от работы.

Небольшое примечание: моя работа заключается в разработке скучного корпоративного ПО, и мне редко удаётся поразмять свои инженерные умения. Хотя в названии моей должности есть слово engineer, я с ним не согласен.

Задача, которую я хочу решить

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

1. Я скучаю по работе с железом.

Во время ковидных локдаунов мне удалось заполучить контракт на R&D прототипа IoT-устройства. Эта работа по R&D была самой интересной за всю мою карьеру. Я работал в небольшой сборной команде, в которой были одни из самых лучших моих друзей. Я печатал модели на 3D-принтере, паял компоненты, писал встроенный C и проводил испытания устройства с инженерами-механиками… Настоящими инженерами. Мы упорно трудились, иногда задерживались до ночи, и этот совместный труд казался больше похожим на игры в StarCraft в детстве, чем на работу «9 на 5». Мне очень этого недостаёт. Недавно я вдохновился @_MaxBlade и его проектом DeskHub, и мне захотелось снова задействовать свои навыки разработки электроники.

2. Ненавижу UX MFA (Multi Factor Authentication).

Я активно пользуюсь GitLab для CI/CD моих личных Kubernetes-проектов. Очень важно знать статус моих конвейеров... ведь поломанные сборки могут расстроить всех моих пользователей в количестве семи человек! Опыт входа в GitLab похож на ощущения от удара в селезёнку. При каждом входе (много раз в день) я сталкиваюсь с капчами, приложениями аутентификации или ожиданием кодов на почту, за которыми следует ещё одна капча. Я пытался реализовать уведомления конвейеров через Slack, Discord и Telegram, но эти приложения похожи на чёрные дыры, в которые утягивает мою продуктивность. Мне не хочется оставлять телефон рядом с собой во время работы или открывать чаты, сбивающие мою концентрацию. Избавившись от этих отвлекающих факторов, я смогу сосредоточиться на работе.

3. Мне хочется понять, насколько хороши инструменты ИИ.

Я хотел понять, отнимет ли ИИ у меня мою работу. Я скептически отношусь к такой возможности, но мне хотелось проверить свои догадки. Иногда ИИ меня удивляет; в других случаях это просто впустую потраченные часы, когда мне лень мыслить в полную силу.

Недавно я использовал Claude Sonnet 3.5 для брутфорса сотен ошибок компиляции React при апгрейде проекта с React 15 до 18. Я забросил обновления package.json, удалил node_modules и потратил небольшое состояние на покупку токенов ИИ. К моему удивлению, к концу дня мы получили готовую сборку. Моя компания предложила нам попробовать в первую очередь использовать ИИ и предоставила неограниченные токены. Безумный эксперимент.

Это случилось в пятницу. Я утёр со лба пот после тяжкого труда по составлению промтов и ушёл домой пораньше, чтобы приступить к хобби-проекту…

Мой план

В отличие от меня, моя жена любит выходить из дома. Я потратил несколько лет на превращение гаража в своё любимое место. У меня с женой есть договорённость: на один день в месяц она берёт нашего ребёнка и избавляет меня от всех обязательств. На целый день я запираюсь дома и создаю проекты. С её точки зрения, я заказываю доставку еды и и превращаюсь в дегенерата, недостойного звания отца. С моей точки зрения, я могу наслаждаться нахождением в своём любимом месте, экспериментировать, играть в игры и делать, что угодно. В такие дни я воображаю себя безумным учёным и ощущаю, что живу свою настоящую жизнь. Я с нетерпением жду этого каждый месяц. Мой план таков: изучить zig, смахнуть пыль с моих железячных навыков, создать этот проект, написать пост и снять о нём видео. Вполне реализуемо.

Я хотел связать Raspberry Pi Pico, небольшой ЖК-дисплей 240x240 и несколько RGB-светодиодов. Я собирался изучить Zig, чтобы с его помощью отправлять по USB данные изображений в Pico, который будет выводить картинку на экран и менять цвет светодиода. Я настрою веб-хуки из GitLab для вызова API в моём кластере Kube и заставлю своё хост-приложение на Zig опрашивать этот же API об изменениях и отправлять обновления на Pico. Мне очень хотелось попробовать передавать данные через USB, потому что раньше я никогда этого не делал. Я уже пользовался Bluetooth, LTE и Wifi, поэтому захотел попробовать что-то новое.

С проводными соединениями всё просто: распространённые паттерны, с которыми я был знаком, наподобие SPI (Serial Peripheral Interface) для дисплея + нескольких RGB-светодиодов. Последовательный порт данных TTY (TeleTYpewriter) в /dev/ttyACM0 Linux для общения по USB с Pico казался привычным, потому что у меня был опыт настройки логгинга отладки. Я думал, что у меня набралось достаточно примеров из репозиториев, чтобы я смог создать работающее решение. Каждый день я проводил небольшие исследования, и с каждым разом моя уверенность немного возрастала. Для этих начальных исследований я всё больше и больше пользовался ChatGPT и Claude. Я был на пике ИИ-хайпа и имел смелость доверять ему…

Так как моя повседневная работа заключается в фулстек-веб-разработке, API, веб-хуки и Postgres я решил не оставлять на «день дегенерата». На этот день я запланировал работы по передаче изображений Zig -> Pico.

1. Настройка Pico

• Навести порядок на рабочем месте

• Найти кабель microUSB, поддерживающий передачу данных, а не только зарядку... Серьёзно, почему они все только для питания?!

• Соединить макетную плату с Pico, дисплеем и светодиодами

• Настроить C SDK для RasPi Pico и репозиторий gitlab, gihub-mirror

• Запушить сборку и изучить логи в cat /dev/ttyACM0

2. Настройка Pico Display

• Выводить что-нибудь на экран во время цикла запуска.

Ссылка на Youtube (12 секунд)

3. Подготовка проекта хоста на Zig

• Настроить директорию хоста в репозитории

• Инициализировать проект на zig

• Отправить сообщение и увидеть что-нибудь на экране

Ссылка на Youtube (9 секунд)

4. Передача изображений

• Скинуть сырые данные rgb-изображения по USB

• Вроде, двунаправленная передача безопасна

• USB CDC безопасен в обоих направлениях

  • TTY-интерфейс, надстроенный поверх USB CDC

    • TTY безопасен в обоих направлениях, потому что это свойство CDC (нет, это не так… спасибо, GPT)

На скриншоте выше вы видите наглую ложь, которая меня сломала… У USB CDC есть отдельные буферы TX (Transmit) и RX (Receive), поэтому он двунаправленно безопасный. Но это не так в случае TTY, который двунаправлен, но менее безопасен, потому что имеет один буфер для данных TX и RX.

Реальное положение дел

Перебрав с десяток кабелей microUSB, я, наконец, нашёл способный передавать данные, и всё шло замечательно до того момента, как я попробовал передавать изображения. Для создания работающей (не без багов) реализации я воспользовался Claude, Cline и ChatGPT. Я отправлял команды с терминала при помощи Zig через USB на Pico, который считывал их и изменял состояние экрана. Это заняло всего несколько часов, я и был очень рад, что мечта об ИИ-помощнике оказалась реальностью. Система не была сложной, но думаю, что это оказалось быстрее, чем если бы я работал один. Я раньше не работал с zig и слышал только похвалы ThePrimeagen. Я даже не читал документацию.

Много раз мне приходилось останавливать Cline, который пытался начинать совершенно новые реализации уже решённых задач. Но всё мне отловить не удалось. Когда Cline упёрся в пределы возможностей моего API, я добавил в свой гарем Claude и по возможности работал с ними параллельно.

Изучая код теперь, я понял, что плохо справляюсь с многозадачностью и что я себя загазлайтил.

Катастрофа с передачей изображений

И здесь взыграла моя гордыня. Я воображал, что смогу отправлять все данные изображений за один раз, как в загрузке S3. Я представлял чистую потоковую передачу сырых данных /dev/ttyACM0. Но она не была ни чистой, ни сырой. Это был хаос.

Я ожидал увидеть следующее:

pico - heartbeat
zig - start image transfer
zig - [240x240 COLOR PIXELS]
zig - end image transfer
pico - heartbeat

На самом деле я увидел нечто примерно такое, только хуже:

pico - heartbeat
zig - start ima%
pico - heage transfert
pico - heartbeat
zig - [240x240 COL
pico - heartbea
OR PIXELtS]
pico - heartbeat
zig - end image transfer
pico - heartbeat

Совершенно не весело, это испортило мне весь день.

Основные проблемы:

1. Конфликты буфера: /dev/ttyACM0 напоминал поле битвы. Один и тот же буфер использовался и для логгинга, и для передачи изображений. Если при передаче данных в поток затёсывался лог... то оставалось лишь наудачу разбираться, что же произошло.

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

Что же в итоге? Ни Pico, ни ноутбук не могли доверять данным. Каждая система должна была научиться уступкам, а мне нужно было создать обходное решение, чтобы заставить их быть вежливыми и ждать своей очереди.

Пакеты, протоколы и машины состояний…

Нужно было подойти к делу серьёзнее. Поэтому я, естественно, позволил Claude написать документацию:

• Подробно описывающую структуру пакета.

• Документирующую план верификации контрольной суммы.

• Описывающую формат данных для передачи.

• Описывающую способ разбиения на блоки и пересборки изображения.

• Отражающую переходы машины состояний.

• Демонстрирующую систему команд.

• Проектирующую систему логгинга, не ломающую входящие команды.

После генерации документации я приказал ИИ заняться самой реализацией. К этому времени мой срок дегенератства истёк, и я снова стал отцом, оставив Cursor и Cline играть в StarCraft с моей кодовой базой. Вроде бы так люди и мечтают использовать ИИ? Оставить его разбираться в создании идеально функционирующей системы. Давайте посмотрим, как близко мы подобрались к идеалу.

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

Какой урок я получил?

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

1. ИИ — это инструмент, а не коллега и не помощник

ИИ отлично подходит для генерации идей или создания набросков кода, но он не понимает их. Мы как будто даём разработчику-джуну бензопилу вместо скальпеля: он, может быть, и закончит работу, но убирать беспорядок вам придётся вдвое дольше. Я понял, что при работе с новыми технологиями мне нужно крепко держаться за штурвал, а не полагаться на второго пилота.

2. Трудности повышают концентрацию

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

3. На ошибках учишься лучше, чем на подсказках

Когда я совершаю ошибки, я учусь. Отладка моих собственных ошибок всегда была одним из лучших способов понять новый язык или концепцию. Использование ИИ для устранения проблем создаёт короткую дорогу в этом процессе обучения. В результате этого я не больше понимаю Zig, чем на момент начала проекта.

4. Терпение важнее гордыни

Создание чего-то нового незнакомыми инструментами требует времени. Мысль о том. что я смогу полностью реализовать своё видение за один «день дегенератства» была слишком оптимистичной, если не глупой. Иногда нам следует отдавать должное сложности того, что мы хотим сделать.

Движемся дальше

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

Я начал писать документацию на бумаге, как будто живу в каменном веке. Я планирую решить на Zig некоторые из задач Advent of Code, чтобы действительно научиться языку, и уже потом приступлю к этому проекту.