OpenAI lanzó recientemente su Codex Javascript Sandbox, que convierte el lenguaje natural en código. Teníamos curiosidad acerca de las limitaciones de la IA generativa de última generación y decidimos intentar crear una aplicación. Si lo desea, puede probarlo usted mismo en Codex Sandbox de OpenAi.

Para empezar, necesitábamos un problema del mundo real... pero ¿qué problema? Comenzamos a pensar en los desafíos que la fuerza laboral remota inducida por una pandemia trajo a las empresas y, lo que es más importante, a su cadena de valor.

Uno de los mayores desafíos para nosotros fue adaptarnos a la nueva norma de comunicación. Hace apenas unos años, solíamos reunirnos en una sala de reuniones y dibujar ideas en una pizarra. No saldríamos de la habitación hasta que terminara la sesión de lluvia de ideas. Hoy, todo eso sucede en aplicaciones como Zoom, Slack, Miro y nuestros tableros de Jira más queridos.

Necesitábamos reducir aún más nuestro problema, así que hablamos con un antiguo representante de ventas que era nuestros ojos y oídos del mercado. Comenzamos a contar nuestros desafíos trabajando juntos y recordamos vívidamente que era extremadamente difícil traducir la visión de un producto de una llamada de Zoom de 30 minutos a especificaciones técnicas para ingenieros. Con demasiada frecuencia, la diferencia entre las especificaciones y la tierra prometida se veía así:

Pensamos qué pasaría si pudiéramos aclarar el producto final incluso antes de convertir Figma y XD en estructura alámbrica. ¿Qué pasaría si pudiéramos capacitar a las personas que tenían el pulso en el mercado para mostrarles a los ingenieros el producto que necesitan para tener éxito? (¿y si pudiéramos hacer que nuestros clientes nos mostraran lo que querían?)

Declaración del problema: al adaptarse a un nuevo modo de trabajo remoto, la magnitud de la falta de comunicación aumenta con cada salto. En otras palabras, cuantas más personas se involucren en la comprensión y comunicación de un producto deseado, se crea un producto final más alejado de la tierra prometida.

Hipótesis: si cambiamos la escritura de especificaciones de un producto al comienzo del ciclo de vida del producto (durante la ideación), entonces el resultado de un producto estará más alineado con la visión inicial.

Con nuestro problema e hipótesis listos para probar, abrimos el Sandbox de OpenAI y comenzamos a jugar roles. Asumimos que un cliente quería crear una aplicación que pudiera imitar un navegador web, de modo que:

1. Si los usuarios ingresan una dirección web, se les mostrará una versión en miniatura del sitio web en la aplicación.
2. La aplicación debe tener el aspecto y la sensación de una aplicación SaaS tradicional (es decir, UI/UX)

Esencialmente ahorramos:

• 1 día de wireframe
• 1 día de validar diseño
• 1 día de diseño redibujado
• 1 día de escribir especificaciones técnicas
• y 2 días de perseguir horarios

Si bien el entorno de la caja de arena no permitía conexiones a sitios externos, la capacidad de producir código de trabajo fue impresionante.

Aquí están nuestros 5 mejores puntos para llevar.

1. El códice de OpenAI está diseñado para seguir instrucciones explícitas y directas. Cuando proporciona especificaciones en lenguaje natural, los elementos que intenta crear deben describirse entre sí y en el mismo comando. De lo contrario, cualquier elemento adicional que cree será independiente de lo que se haya codificado. Por ejemplo, si desea crear una aplicación con una barra de navegación superior e izquierda y un contenedor que contenga elementos adicionales, debe especificar su posición relativa entre sí en el mismo comando.
2. No hay deshacer, solo modificaciones. Codex es excelente para crear fragmentos de código que pueden ser ctrl+c/v en su base de código, pero si espera confiar solo en esta solución, es mejor que tenga sus especificaciones técnicas claras como el día. Tratar de modificar un conjunto complejo de relaciones e interacciones es difícil de deshacer y, a veces, puede hacer que la IA entre en un bucle infinito (¿referencia circular?). Asegúrese de acelerar las llamadas o tener un interruptor de apagado, o se sorprenderá con su factura.
3. Se requiere habilidad de codificación 101. Necesita cierta familiaridad con el pensamiento de diseño de un ingeniero, pero no necesariamente necesita poder resolver un problema de Leetcode para usar Codex. En esencia, esto reduce la curva de aprendizaje para crear una aplicación y elimina la necesidad de aprender la gramática y la sintaxis de un nuevo idioma.
4. El peinado es extremadamente fácil. En lugar de tener que saber CSS para calcular píxeles o conocer la diferencia entre un flexbox y un elemento flotante, puede simplemente describir la posición en relación con otros elementos. Si lo desea, también puede cambiar el estilo de cualquier elemento individual tan prescriptivo como desee, solo recuerde darle un nombre único.
5. Iteraciones más rápidas en las interacciones. Una de las cosas más difíciles de traducir a los ingenieros son las interacciones y los resultados esperados. Estropear esto podría poner en riesgo sus sprints y retrasar el lanzamiento de su producto. Es una inversión que requiere mucho tiempo desde la creación de los elementos frontales hasta la creación del comportamiento esperado en el back-end. Esta es la razón por la cual las maquetas de fidelidad total son extremadamente valiosas para eliminar la falta de comunicación, pero también son uno de los pasos que requieren más recursos y tiempo en la cadena de valor de un producto. Codex es excelente para ayudarlo a iterar en las interacciones hasta que obtenga una experiencia de usuario similar a la de Apple.

A medida que la PNL comienza a pasar de los primeros usuarios a la primera mayoría del mercado, debe superar el abismo. Esto solo será posible con más casos de uso del mundo real que se adopten. Todos hemos visto lo que la exageración le hace a un mercado. No repitamos la historia.