Acabo de leer una publicación de Casey Newton que resonó mucho con algunas cosas que he estado pensando, sobre cómo la sensación de productividad que tenemos al utilizar modelos de lenguaje en el trabajo puede no ser más que eso: una sensación.
Esto ha sido un tema que me ha interesado no sólo en términos conceptuales. Soy un early adopter por naturaleza, y he estado siguiendo diligentemente la sugerencia de Ethan Mollick de llevar la IA a todas las tareas posibles, con el propósito de desarrollar una intuición enactuada de la fontera dentada de los últimos modelos. Creo que ha sido un experimento efectivo, el cual me ha servido además para calibrar mi mirada de cuándo, cómo y por qué es pertinente utilizar la IA en una tarea. En este artículo quiero intentar hacer explícita una de estas intuiciones: cómo utilizar la IA cuando el desafío es de diseño, en contraste a uno de implementación.
Desde una perspectiva de niveles lógicos, un desafío de implementación está anidado en uno de diseño. El primero responde al qué quiero hacer (y por qué), mientras que el segundo responde al cómo. Estos niveles lógicos son recursivos y pueden encadenarse en varios niveles hacia arriba o hacia abajo.
Personalmente, cuando enfrento un desafío de diseño y necesito ayuda pero no tengo a nadie disponible, utilizo Claude como un sparring intelectual, declarando explícitamente el desafío que estoy abordando, su contexto, y la el apoyo que requiero. Le planteo mis ideas preliminares (si las tengo) y le pido que me entreviste tanto para ayudarlo a clarificar lo que requiero como para que me ayude a pensar.
A continuación, muestro un ejemplo del prompt inicial que le doy. En general, cuando estoy pensando un desafío complejo que va a requerir mucha descripción e interacción, utilizo mensajes de audio transcritos porque me resulta más fluido. Es posible que la interfaz te parezca rara, esto es porque estoy trabajando con Claude desde la terminal a través de “Claude Code”, en otra ocasión podría escribir en más detalle respecto del por qué utilizo esta forma de interactual con Claude, sin embargo, de momento puedes asumir que, en este caso, es básicamente lo mismo que estar trabajando con el modelo a través de su aplicación de escritorio o interfaz web. Por último, es importante aclarar que el directorio en el que estoy trabajando existe un documento CLAUDE.md que se carga automáticamente en la ventana de contexto del modelo y le provee de información general sobre el proyecto.
Después de analizar mis instrucciones y los documentos de contexto, Claude entiende que lo que requiere es pensar abiertamente conmigo sobre el desafío, proponiendo hacerlo a través de una Skill llamada “brainstorming” perteneciente a un paquete de habilidades desarrolladas por Jesse Vincent que instalé hace un tiempo atrás. Aquí copio la descripción general de esta skill en específico:
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you’re building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
Las imágenes ilustran cómo Claude fue razonando y las primeras interacciones que tenemos en base a sus preguntas:
En total, tuvimos 18 interacciones en donde fuimos contruyendo en conjunto la solución al desafío. El resultado me dejó bastante satisfecho.
Este acercamiento es muy distinto a lo que resultaría si yo le pido simplemente que me resuelva de una vez la tarea. En primer lugar, porque hay muchas cosas que no declaro en el contexto o el prompt que pueden ser importantes para calibrar la solución a las limitaciones del contexto. Por otra parte, porque le permite al modelo de identificar declaraciones que entran en conflicto o aspectos en donde falta información, dándome la oportunidad de pronunicarme al respecto. Finalmente, todo este proceso me fuerza a estar más involucrado en la solución, pensando, lo cual es crítico para desarrollar yo mismo un modelo cognitivo del problema y lograr apropiarme de la solución propuesta, siendo luego capaz de comunicarla efectivamente y fundamentar las decisiones tomadas en el diseño.
Me ha pasado muchas veces toparme con documentos de trabajo generados por IA en los que me da la impresión de que debiesen haber tenido un enfoque de diseño, pero tuvieron uno de implementación. Esto tanto a nivel del producto mismo, como de la manera en que la persona que lo desarrolló da cuenta de él. Por ahí me topé con que los creativos de internet ya le pusieron nombre el fenómeno, workslop, entendido como:
AI-generated work content that masquerades as good work, but lacks the substance to meaningfully advance a given task
¡No seas la persona de tu equipo que produce workslop!