OpenAI недавно запустила песочницу Codex Javascript, которая превращает естественный язык в код. Нам были любопытны ограничения современного генеративного ИИ, и мы решили попробовать создать приложение. Если вы хотите, вы можете попробовать это сами в OpenAi Codex Sandbox.

Для начала нам нужна реальная проблема… но какая? Мы начали думать о проблемах, которые вызванная пандемией удаленная рабочая сила принесла компаниям и, что наиболее важно, их цепочке создания стоимости.

Одной из самых больших проблем для нас была адаптация к новой норме общения. Всего несколько лет назад мы собирались в конференц-зале и рисовали идеи на доске. Мы не выходили из комнаты, пока не закончился мозговой штурм. Сегодня все это происходит в таких приложениях, как Zoom, Slack, Miro и наших самых любимых досках Jira.

Нам нужно было еще больше сузить круг нашей проблемы, поэтому мы поговорили с бывшим торговым представителем, который был нашими глазами и ушами рынка. Мы начали рассказывать о наших проблемах, связанных с совместной работой, и живо вспомнили, как было чрезвычайно сложно преобразовать видение продукта из 30-минутного звонка в Zoom в технические спецификации для инженеров. Слишком часто разница между спецификациями и землей обетованной выглядела примерно так:

Мы подумали, что, если бы мы могли сделать конечный продукт ясным еще до того, как мы превратили Figma и XD в каркас? Что, если бы мы могли дать возможность людям, которые держат руку на пульсе рынка, показать инженерам продукт, необходимый им для достижения успеха? (что, если бы мы могли попросить наших клиентов показать нам то, что они хотели?)

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

Гипотеза: если мы сместим написание спецификации продукта к началу жизненного цикла продукта (во время создания идеи), то результат продукта будет более тесно связан с первоначальным видением.

Когда наша проблема и гипотеза были готовы к проверке, мы открыли песочницу OpenAI и начали ролевую игру. Мы предположили, что клиент хотел создать приложение, которое могло бы имитировать веб-браузер, например:

1. Если пользователи вводят веб-адрес, им будет показана миниатюрная версия веб-сайта в приложении.
2. Приложение должно иметь традиционный внешний вид приложения SaaS (т. е. UI/UX).

Мы существенно сэкономили:

• 1 день вайрфрейминга
• 1 день проверки дизайна
• 1 день перерисовки дизайна
• 1 день написания ТЗ
• и 2 дня погони за расписанием

Хотя среда «песочницы» не позволяла подключаться к внешним сайтам, возможность создавать работающий код была впечатляющей.

Вот наши 5 лучших выводов.

1. Кодекс OpenAI предназначен для следования четким и прямым указаниям. Когда вы предоставляете спецификации на естественном языке, элементы, которые вы пытаетесь создать, должны быть описаны относительно друг друга и в одной и той же команде. В противном случае любой дополнительный элемент, который вы создадите, не будет зависеть от того, что было закодировано. Например, если вы хотите создать приложение с верхней и левой панелью навигации и контейнером, содержащим дополнительные элементы, вы должны указать их положение относительно друг друга в той же команде.
2. Отмены нет, только модификации. Codex отлично подходит для создания фрагментов кода, которые можно добавить в кодовую базу с помощью клавиш Ctrl+C/V, но если вы надеетесь полагаться только на это решение, вам лучше иметь свои технические характеристики четкими как день. Попытку изменить сложный набор отношений и взаимодействий трудно отменить, и иногда это может привести к тому, что ИИ войдет в бесконечный цикл (циклическая ссылка?). Удостоверьтесь, что вы ограничиваете звонки или имеете переключатель отключения, иначе вы будете шокированы своим счетом.
3. Требуется 101 навык кодирования. Вам нужно некоторое знакомство с дизайнерским мышлением инженера, но не обязательно уметь решать проблемы Leetcode, чтобы использовать Codex. По сути, это сокращает кривую обучения для создания приложения и устраняет необходимость изучения грамматики и синтаксиса нового языка.
4. Стайлинг чрезвычайно прост. Вместо того, чтобы знать CSS для вычисления пикселей или знать разницу между flexbox и плавающим элементом, вы можете просто описать положение относительно других элементов. Если вы хотите, вы также можете изменить стиль любого отдельного элемента настолько, насколько вам хочется — просто не забудьте дать ему уникальное имя.
5. Более быстрые итерации взаимодействий. Одна из самых сложных вещей для инженеров — взаимодействие и ожидаемые результаты. Игнорирование этого может поставить под угрозу ваши спринты и задержать выпуск вашего продукта. От создания элементов интерфейса до создания ожидаемого поведения на сервере требуется много времени. Вот почему полноценные макеты чрезвычайно ценны для устранения недопонимания, но также являются одним из самых ресурсоемких и трудоемких этапов в цепочке создания ценности продукта. Codex отлично помогает вам повторять взаимодействия, пока вы не получите UX, подобный Apple.

По мере того, как НЛП начинает переходить от первых последователей к раннему большинству рынка, оно должно преодолеть пропасть. Это будет возможно только с более реальными вариантами использования, которые будут приняты. Мы все видели, что шумиха делает с рынком. Не будем повторять историю.