Qué mostrar cuando un agente escribe tu código en cinco minutos

Cuando un agente escribe en cinco minutos la arquitectura, el framework, la funcionalidad básica y la mitad del código funcional, ¿qué le queda a un desarrollador para mostrar en su portafolio? Una base de código ya no es señal de dominio: la puede escribir cualquiera que tenga acceso al mismo agente.

Esta pregunta retoma un principio del libro de Austin Kleon "Muestra tu trabajo": no esperar a terminar un proyecto, sino mostrar el proceso en pasos pequeños, enseñando a otros lo que sabes. Pero en 2026 esto exige repensarse: hay que mostrar criterio, no artefactos.

Seis cosas en lugar de código

Qué revela tu trabajo cuando el código ya lo escribió un agente:

• Decisiones y opciones rechazadas. Muestran un criterio que el agente no tiene sobre tu proyecto. Cuando un directorio de servidores MCP restó dos puntos por nombres de funciones sin puntos (como `stories.search`), fue una decisión deliberada: los grandes proveedores de modelos no permiten puntos en los nombres, y usar los nombres correctos según el directorio habría roto a los clientes para los que existe el servidor.

• Fallos y cómo los diagnosticaste. Google empezó a marcar páginas como "soft 404" aunque se abrían bien en el navegador. La causa: una sola línea en robots.txt bloqueaba la API que obtenía el contenido. Google renderiza como un navegador, no pudo obtener los datos y vio una pantalla de error.

• Cómo verificaste el trabajo del agente. La habilidad más importante ahora mismo, e invisible en el código. Tres ejemplos de una semana: una prueba del servidor comprobaba el código de error equivocado y pasaba durante días, hasta que un cliente real usando una herramienta de terceros falló con una excepción; un bloque de estadísticas estaba vacío en producción por una política de seguridad del CDN que el navegador de pruebas no aplicaba; Google encontró páginas inexistentes terminadas en `.mdread-only` — un enlace al texto fuente estaba pegado a una etiqueta, el navegador mostraba un espacio que no existía en el código fuente, y Google los fusionó en una sola dirección.

• Instrucciones al agente tras un error. Reglas en la configuración, habilidades reutilizables. Tras el bug de la política de seguridad, el despliegue ahora se niega a publicar páginas con scripts incrustados. Tras una discrepancia entre el registro del servidor y su comportamiento real, el despliegue falla si la superficie pública cambió sin una nueva versión.

• Cifras de antes y después. El resultado es fácil de mostrar incluso cuando no se puede mostrar el sistema. "Dos días después de la corrección, Google dejó de marcar las páginas como soft 404" o "la verificación ahora lo detecta antes del lanzamiento" dice más que un diff.

• Qué harías diferente. Un análisis honesto genera más confianza que una historia de éxito, y es más útil para quienes hacen algo similar.

Cómo funciona esto: un escenio, no un genio solitario

Cuando muestras decisiones y errores en lugar de código, responde gente con experiencia distinta. Dos hilos de comentarios en dev.to sobre un servidor MCP se convirtieron en funciones reales del producto: una verificación de versión y una suite de pruebas con un cliente real.

Uno de esos hilos llegó a Sidney Bissoli, autor de siete servidores MCP para datos abiertos brasileños. A partir de él creó una herramienta independiente, la ejecutó sobre las 142 versiones de sus servidores, encontró dos que ni siquiera arrancaban, y escribió un artículo con la conclusión: "un hilo de comentarios cambió cómo se publican ocho servidores". Austin Kleon llama a esto "escenio": el buen trabajo surge de un grupo que se muestra mutuamente lo que hace, no de alguien solo.

Dentro de la empresa: el mecanismo sin los nombres

En worklore.dev se publican historias breves: qué se probó, qué se rompió, qué funcionó. Cuando el agente de alguien reproduce una historia, eso queda registrado en la página. El contenido que no se puede generalizar para el público igual conviene anotarlo para uno mismo: tu propio agente repetirá el error en un par de meses, cuando los detalles se olviden.

Incluso en proyectos cerrados, la mayor parte se puede mostrar si se conserva el mecanismo y se eliminan los nombres. "Servicio interno", "paso de pago", "nuestro CDN" — la lección casi nunca depende de la marca. Muestra el razonamiento, no el artefacto: por qué elegiste tal cosa, cómo la verificaste, qué cambiarías. Pide permiso una vez: la mayoría de los responsables no tienen problema con una lección anonimizada. Lo pequeño vale: un problema, una corrección, 300 palabras. Un esquema útil: contexto → en qué estaba seguro el agente y se equivocó → diagnóstico → qué cambiaron para que no se repita.