Я дал Клоду одно приложение и попросил его сыграть роли четырех разных старших разработчиков — вот что произошло.
Узнайте, как Клод, выступая в роли четырех разных старших разработчиков, создавал одно и то же приложение. Ознакомьтесь с результатами этого уникального эксперимента с использованием искусственного интеллекта в разработке программного обеспечения.
Самое важное, что вам нужно знать
- Использование специализированных инженерных ролей (таких как инженер по отладке и фронтенд-разработчик) для Клода позволяет выявить различные проблемы в приложении, что делает проверку более всесторонней и эффективной, чем при использовании общих заявлений.
- В ходе эксперимента выяснилось, что инженер по отладке обнаружил функциональные проблемы (такие как проверка входных данных и вычисления), в то время как фронтенд-разработчик выявил проблемы с доступностью и удобством использования, включая кнопку удаления в один клик, которую первый упустил из виду.
- Инженер по производительности продемонстрировал способность Клода выявлять основные узкие места (формат валюты) и предлагать улучшения, признавая при этом, что большинство из них были излишними для фактического использования приложения, что отражает зрелость в оценке.
В интернете, особенно на X, полно утверждений о том, что они якобы повышают эффективность чат-ботов. Когда я впервые наткнулся на ряд утверждений от Дэвида Макса , эксперта по обучению в области ИИ , я отнёсся к ним скептически, что и побудило меня попробовать их на практике. Эти утверждения якобы превращают Клода во что угодно — от опытного отладчика до эксперта по производительности. Вот что произошло, когда я решил провести расследование. Если вас интересуют более эффективные утверждения, вы можете ознакомиться с 7 эффективными утверждениями Клода 4, которые помогут развить ваши идеи и повысить производительность.
Посмотреть мой трекер домашних расходов можно на сайте Клода.
Я уже создал общий трекер расходов с заполнителями для данных о расходах, используя ChatGPT Work, поэтому я воспользовался им, а затем попросил Клода четыре раза проверить приложение. Каждый раз я назначал ему разные основные инженерные роли: full-stack инженер, инженер по отладке, фронтенд-инженер и инженер по производительности.
Результат оказался гораздо более показательным, чем просто просьба к Клоду «улучшить приложение». Каждый персонаж сосредоточился на разных проблемах, а иногда даже выявил те, которые упустил предыдущий «разработчик». Вот что произошло и какие утверждения они использовали.
1. Приложение было разработано ведущим Full-Stack инженером.
Все началось с просьбы Клода создать интерактивный трекер расходов домохозяйства, которым мог бы пользоваться любой желающий. Подробнее о возможностях Клода в разработке приложений читайте в статье « Я создал 3 приложения за считанные минуты, используя Клода и Gemini: но в одном из них есть скрытая функция ».
Задача: Создать интерактивный трекер расходов домохозяйства, который сможет использовать любой человек для записи и анализа своих трат. Он должен включать возможность добавления и удаления расходов, присвоения категорий, фильтрации транзакций, расчета общей суммы расходов и просмотра визуальной разбивки по категориям.
Представьте себя опытным full-stack инженером, разрабатывающим отполированный MVP для стартапа. Прежде чем писать код, составьте краткое описание архитектуры, структуры данных и пользовательского сценария. Затем создайте приложение как облачный артефакт.
Сделайте его адаптивным и простым в использовании, но не тратьте дополнительное время на проверку, отладку или улучшение финального кода. Я делегирую эти задачи другим разработчикам.
Клод создал удивительно качественное приложение на React. Оно включало в себя примеры транзакций, итоговые суммы расходов, рейтинг по категориям, функции поиска и фильтрации, а также возможность сортировки транзакций по дате. Кроме того, приложение сохраняло изменения, поэтому они оставались доступными после повторного открытия.
На первый взгляд, это выглядело гораздо ближе к готовому продукту, чем к незавершенному прототипу. Сверху лежали статистические карточки, аккуратная форма учета расходов и цветные полосы, показывающие, сколько было потрачено в каждой категории.
2. Старший инженер по отладке обнаружил некоторые проблемы.
После этого я попросил Клода не обращать внимания на внешний вид и сосредоточиться на своей работе в качестве инженера по отладке, занимающегося подготовкой приложения к запуску.
Требование: Теперь ведите себя как главный отладчик, который унаследовал это приложение до его публичного выпуска.
Тщательно изучите приложение и его существующий код, не изменяя его предполагаемую функциональность или визуальный дизайн. Протестируйте основные сценарии взаимодействия с пользователем и выявите функциональные ошибки, некорректную обработку ввода, риски потери данных, неверные вычисления, проблемы с сохранением данных и граничные случаи.
Прежде чем вносить изменения в код, предоставьте мне краткий отчет об отладке, содержащий информацию о том, что вы тестировали, о каждой обнаруженной проблеме, о ее первопричине, о степени серьезности и о рекомендуемом вами решении.
Затем проведите ремонт и убедитесь, что оригинальные элементы по-прежнему функционируют. Не следует перепроектировать фасад, проводить более масштабную архитектурную реконструкцию или вносить чисто косметические изменения.
В процессе отладки было выявлено множество реальных проблем.
Например, исходные данные были введены неправильно. Нажатие кнопки «Сохранить транзакцию» работало, но нажатие клавиши Enter могло не сработать. Клод исправил это, преобразовав раздел в правильный формат с кнопкой отправки.
Он также обнаружил, что пользователи могут очистить историю и сохранить транзакцию с неверной информацией о дате. Клод добавил проверку даты, усилил проверку на наличие недопустимых сумм и исправил ошибку в расчетах, из-за которой категория «Жилье» отображалась как самая крупная, даже когда трекер был пуст.
По-прежнему существовала возможность безвозвратно удалить транзакции одним щелчком мыши. Ошибки хранения оставались скрытыми в консоли разработчика, а это означало, что пользователи могли полагать, что их информация сохранена, хотя это было не так. Кроме того, Клод не внедрил автоматизированные тесты для подтверждения работоспособности своих исправлений.
3. Опытный фронтенд-разработчик заметил совершенно другое приложение.
В третьем раунде я попросил Клода рассматривать систему отслеживания расходов как работу фронтенд-разработчика, специализирующегося на адаптивном дизайне и доступности.
Требование: Действуйте прямо сейчас как опытный фронтенд-разработчик, специализирующийся на доступных и адаптивных приложениях для потребителей.
Проанализируйте свою текущую программу для отслеживания расходов с точки зрения пользователя, использующего ее на телефоне, клавиатуре или с помощью вспомогательных технологий. Сохраните ее функциональность и общий визуальный стиль, но улучшите удобство использования и доступность.
Перед внесением изменений в код проведите краткий анализ, охватывающий поведение и отзывчивость на мобильных телефонах, навигацию с помощью клавиатуры, удобство использования форм, доступность для программ чтения с экрана, цветовой контраст, состояния загрузки и ошибок, деструктивные действия и непонятные элементы управления.
Затем внедрите улучшения. Убедитесь, что каждое поле ввода и интерактивный элемент управления имеют доступное имя, что состояния фокуса четко видны, что подтверждающие сообщения могут быть озвучены программой чтения с экрана, и что информация о расходах передается без использования исключительно цветных полос.
Это был наиболее полный обзор эксперимента.
Клод отметил, что приложение удалило естественную рамку вокруг выбранных полей ввода, не предоставив ей замены. В результате пользователю, использующему клавиатуру для навигации, будет сложно увидеть активное поле.
Также было обнаружено, что визуальные метки не были должным образом связаны с соответствующими полями ввода, что поле поиска полагалось исключительно на текст-заполнитель, и что ошибки проверки не были настроены для оповещения программами чтения с экрана.
Клод восстановил визуальные индикаторы фокусировки, связал метки с элементами управления формами, добавил описания для программ чтения с экрана и увеличил контрастность многих светло-серых текстовых элементов. Он также сделал строку поиска более удобной для использования на небольших экранах и добавил более подробные метки для кнопок, содержащих только значки.
Самое важное, что этот персонаж обнаружил проблему с удалением, которую упустил из виду отладчик. Клод заменил кнопку удаления в один клик двухэтапным процессом подтверждения, который требовал от пользователей либо удалить, либо сохранить транзакцию.
Не все утверждения были верны. Клод указал 44 x 44 пикселя как минимальный размер области касания, но увеличил размер основной кнопки удаления только до 36 x 36 пикселей. Это соответствует меньшему целевому размеру согласно WCAG 2.2 AA, но не соответствует рекомендации в 44 пикселя, которую он упомянул.
Однако изменение роли Клода явно изменило его точку зрения. Отладчик проверял работоспособность приложения, а фронтенд-разработчик изучал, сможет ли им комфортно пользоваться реальный человек. Этот эксперимент демонстрирует, как одно-единственное требование может существенно повлиять на результаты Клода.
4. Инженер по производительности признал, что приложению не требуется существенная помощь.
В конце концов, я попросил Клода настроить систему отслеживания расходов, способную обрабатывать как минимум 10 000 транзакций.
Задача: Теперь, в роли старшего инженера по оптимизации производительности, подготовьте эту систему отслеживания расходов к обработке тысяч транзакций.
Проанализируйте текущую реализацию на предмет ненужной отрисовки, избыточных вычислений, неэффективной сортировки или фильтрации, узких мест в хранилище, роста объема памяти и взаимодействия, которые могут замедлиться по мере увеличения размера данных.
Не стоит предполагать наличие проблем с производительностью. Разработайте реалистичный способ тестирования приложения, выполнив не менее 10 000 транзакций, и установите базовый уровень для критически важных операций.
Затем внедряйте только те улучшения, которые оправданы анализом. Сохраняйте внешний вид приложения, улучшения доступности и текущее поведение. Не заявляйте об улучшении скорости, если вы не измерили его или четко не определили как ожидаемое улучшение.
Клод обнаружил одно особенно существенное узкое место. Приложение создавало новый объект формата валюты каждый раз, когда отображало сумму. При обработке 10 000 строк Клод измерил время выполнения этого процесса в 349 миллисекунд. Повторное использование одного форматтера сократило его до 5.2 миллисекунд, что, по расчетам Клода, представляет собой 67-кратное улучшение.
Клод также добавил функцию «виртуализации таблиц», что означает, что браузер будет отображать только те транзакции, которые в данный момент видны на экране, вместо тысяч строк одновременно. Обновления поиска и хранилища были задержаны на доли секунды, чтобы избежать дорогостоящих повторений после каждого нажатия клавиши или быстрого изменения.
Клод даже добавил кнопки, позволяющие генерировать 1,000, 10 000 или 50 000 тестовых транзакций для стресс-тестирования.
Но наиболее убедительной частью отчета стало признание Клода в том, что большинство этих улучшений не были необходимы для предполагаемого назначения приложения.
Обычно домохозяйство совершает от 30 до 50 транзакций в месяц. Даже спустя десятилетие Клод пришел к выводу, что первоначальное приложение, вероятно, обработало бы полученные данные без существенных проблем. За исключением кэширования форматировщика валюты, большинство улучшений оказались полезными только потому, что я специально запросил поддержку тысяч транзакций.
Такая сдержанность (или самоконтроль) казалась более «зрелой» и «профессиональной», чем простое внесение изменений ради возможности это сделать.
Мой окончательный вывод
Я счёл эти утверждения чрезвычайно эффективными, поскольку каждое из них чётко подчёркивало сильные и слабые стороны Клода. Каждая роль предлагала уникальную перспективу для оценки, что я нашёл очень полезным и обязательно буду применять в своих будущих обзорах других приложений и веб-сайтов.
В то время как инженер по отладке обнаружил некорректное поведение, фронтенд-разработчик выявил проблемы с доступностью и удобством использования. Инженер по производительности, с другой стороны, учел последствия увеличения объема данных и определил, когда оптимизация не требуется.
Этот опыт также показал, почему использование одного всеобъемлющего требования, такого как «Сделать это готовым к производству», может быть не лучшим подходом. Один обзор может упустить из виду важные вопросы, даже если требование кажется исчерпывающим. Разделение работы на целенаправленные этапы позволило Клоду сократить количество приоритетных задач и упростило оценку результатов.
Просто помните об ограничениях на использование облачных сервисов. В следующий раз я, возможно, попробую объединить запросы, чтобы не превысить максимально допустимый лимит.
Комментарии закрыты.