Un autor de Habr parodia a Oneguin: de los errores del agente responde una persona

Cuatro versos de parodia de la «Carta de Tatiana a Oneguin» y una declaración de método. Así empieza el artículo de autor publicado en Habr «Poesía del desarrollo con agentes, o cómo escribir código ahora». Su autor se niega a dar otro conjunto de recetas y propone subir un nivel de abstracción: entender la problemática, los valores y los sentidos, y dejar los detalles para más adelante. El anuncio disponible contiene solo la introducción, así que analizamos el marco que plantea, no su argumentación.

Qué se plantea exactamente

En el poema, la ingeniera Tatiana le escribe al vibe coder Eugenio. El agente, dice ella, puede escribirlo todo. Pero de los errores tendrá que responder, a la fuerza, el propio Eugenio. El chiste funciona porque describe una asimetría real. Generar código se ha vuelto casi gratis, mientras que la responsabilidad sobre él sigue siendo la misma y sigue recayendo en la persona.

Datos del material:

• Formato: artículo de autor, sección AI de Habr
• Fecha de publicación: 10 de octubre de 2026
• Imagen central: la ingeniera Tatiana y el vibe coder Eugenio
• Tesis principal: la responsabilidad por el resultado no pasa al agente
• Método: primero la problemática, los valores y los sentidos; después los detalles
• Lo que no hay en el anuncio: herramientas, mediciones, prácticas concretas

Por qué la tesis toca un nervio

El término «vibe coding» lo propuso Andrej Karpathy a principios de 2025. Describía un estilo en el que el desarrollador acepta los cambios del agente sin leerlos con atención. Para un prototipo o un proyecto de domingo, está bien. Para producción, este enfoque significa que el código entra en el sistema sin que nadie lo entienda.

El agente escribe más rápido de lo que una persona lee. Por eso el cuello de botella pasa de la escritura a la revisión. Es una lógica general del sector, no una conclusión del autor del artículo, pero el chiste sobre Tatiana y Eugenio la transmite bien: quien aceptó el diff es quien responde por él cuando hay un incidente.

Fortalezas y debilidades del marco elegido

Subir el nivel de abstracción es una decisión razonable. Las recetas para agentes caducan en meses: cambian los modelos, las interfaces y los límites de contexto. Las preguntas sobre quién es dueño del resultado, qué se considera código terminado y qué riesgo es admisible duran bastante más.

También hay un riesgo. Un texto sobre sentidos se convierte con facilidad en un ensayo del que no se puede extraer ninguna acción. Solo la versión completa permitirá juzgar si el autor lo ha evitado. En el anuncio no hay ejemplos ni comparaciones de enfoques.

Qué puede hacer un equipo con esto

Estos no son consejos del autor, sino conclusiones nuestras a partir de la tesis planteada. Se pueden aplicar ya:

• Asigne un responsable a cada cambio hecho por un agente. Debe ser una persona concreta, no «el equipo».
• Adopte una regla: no hago merge de lo que no puedo explicar con mis propias palabras.
• Escriba pruebas y criterios de aceptación antes de lanzar el agente. Así la revisión se apoya en una especificación y no en la sensación de que el código parece verosímil.
• Guarde la tarea y los prompts clave junto al commit. Dentro de seis meses ayudará a entender por qué el código quedó tal como quedó.
• Separe los modos de trabajo. El prototipo puede hacerse «a vibra»; el código para producción hay que revisarlo.

Vale la pena leer el texto completo en Habr para ver en qué convierte el autor los valores y los sentidos. Si detrás aparecen prácticas concretas, será un material útil. Si no, quedará una parodia bonita con una observación acertada.