Los desarrolladores buscan qué mostrar cuando un agente escribe el código en 5 minutos

Cinco minutos. Es lo que, según el autor de una columna de Habr, necesita el agente de tu vecino para reproducir el código que tú escribiste con ayuda del tuyo. De ahí concluye que la forma habitual de darse a conocer en la profesión, es decir, publicar código, funciona cada vez peor. El texto arranca con una pregunta que, en la introducción publicada, aún no tiene respuesta: ¿qué debería mostrar un desarrollador en 2026?

La idea de Kleon y tres consejos

El punto de partida es el breve libro de Austin Kleon «Muestra tu trabajo». Su tesis central: no esperar a tener un resultado terminado, sino mostrar el proceso. Pequeños pasos, lo que vas aprendiendo, lo que te inspira, cómo avanzas hacia tu objetivo. Hay que compartir poco a poco y todos los días, enseñar lo que se sabe y cuidar de que no derive en spam. La lógica es simple: la gente te encuentra por lo que compartes, y una parte de ella empieza a ayudarte.

Entre los desarrolladores, esta filosofía suele aplicarse de tres maneras:

• publicar código en open source;
• llevar un registro público de lo que se ha hecho cada día;
• describir cómo se pensó una tarea.

El autor señala que incluso los partidarios de la primera opción admiten que resulta aburrida.

Dónde falla cada opción

La principal objeción apunta al código, y tiene dos partes. La primera es legal y práctica: si el código pertenece al empleador, no se puede compartir. Para la mayoría de los desarrolladores asalariados, eso es la mayor parte del trabajo diario. La segunda es económica. Si el código lo ha generado un agente de todos modos, deja de ser una prueba única de habilidad. Cualquiera que plantee una tarea parecida a una herramienta parecida obtendrá el mismo resultado.

Es un cambio en el propio objeto de la demostración. Antes, un repositorio de GitHub era una prueba indirecta de que alguien sabía resolver problemas: commits, arquitectura, estilo. Cuando entre el planteamiento de la tarea y el código funcional hay un agente, resulta más difícil saber por el repositorio dónde termina la aportación humana. El empleador o el colega ve el artefacto, pero no las decisiones que llevaron a él.

El registro diario y la descripción del razonamiento se acercan más a lo que propone Kleon, pero tampoco resuelven el problema por completo. Sin un resultado concreto, esas notas se convierten con facilidad en autodescripción en lugar de demostración de valor.

Qué implica esto en la práctica

En la parte accesible del material, el autor no ofrece una respuesta cerrada. Lo que sigue solo puede ser una hipótesis sobre la dirección, deducida del propio planteamiento del problema. Si el valor se desplaza del texto del programa a las decisiones que lo rodean, lo lógico es mostrar precisamente esas decisiones:

• qué tarea elegiste y cuáles descartaste;
• cómo formulaste el planteamiento y verificaste el resultado del agente;
• qué errores del modelo encontraste y cómo los corregiste;
• qué aprendiste sobre el proceso, algo que se puede contar sin revelar código corporativo.

Un conjunto así no infringe el NDA, porque no exige publicar el código fuente. El agente del vecino tampoco lo reproducirá: son notas sobre criterio, no sobre sintaxis. Y encaja con el consejo original de Kleon de compartir el proceso y no solo el resultado.

Para quienes están construyendo ahora su presencia pública, la conclusión es práctica. No conviene esperar a tener el proyecto de portfolio perfecto. Se puede empezar con notas breves sobre decisiones concretas, eliminando de ellas todo lo que pertenezca a la empresa. La respuesta completa del autor estará en el artículo principal de Habr, enlazado desde la publicación original. Por ahora, la propia pregunta es reveladora: la industria empieza a debatir en serio qué acredita la profesionalidad cuando el código no lo escribe solo una persona.