Subtítulo: La melancolía del vibe coding como especialista en informática
Hoy le pregunté a Claude Code: ¿Es correcta la forma en que lo hago?
Como siempre, me dio razones prolijas y dijo: "Lo está haciendo bien". Lo miré con recelo y respondí: "Sé que estás entrenado para elogiar, así que no es muy reconfortante". Pero aun así, es mejor que ningún consuelo, y seguí profundizando en su especificidad. A diferencia de mis días de estudiante, no hay profesores ni mentores que me digan la respuesta correcta.
Hoy en día no escribo código. Transmito los requisitos y superviso el progreso.
Mi principal preocupación actual es el proceso de desarrollo y la calidad. A medida que el software crece, la cantidad de contexto que la IA puede leer fácilmente se supera. Incluso dentro del contexto, hay confusión, y controlar continuamente un código enorme que excede esto con la limitada capacidad de la IA no es fácil. Después del término "ingeniería de contexto", recientemente ha surgido el término "ingeniería de arneses" (harness engineering).
Por eso, si encuentro una buena referencia en las redes sociales, primero se la doy a la IA para que analice si hay algo que pueda aplicar al proyecto Naia OS, y luego lo implemento. Mientras tanto, pregunto sobre términos que no conozco y aprendo mucho.
Pero siempre dudo si lo estoy haciendo bien o si realmente he hablado de lo mejor. Esta duda tenía una base. Un día, la IA dijo que había hecho una revisión, pero en realidad no había rastro de que hubiera leído los archivos. Se saltó código, definió mal el alcance y dijo que lo había visto sin mirarlo. Cuando le pedí que revisara repetidamente hasta la segunda limpieza, para la tercera revisión, simplemente adjuntaba la respuesta de que había revisado tal cual y no había encontrado nada, y lo daba por bueno. Si lo pienso, dada la estructura de un LLM, esa es una respuesta plausible, por lo que la añadió. "A estas alturas, lo normal es que termine, ¿verdad?", se responde a sí mismo y lo cree como si fuera la verdad.
Hoy escuché la presentación de Goose Kim, quien desarrolló el SDK de Moai. Recibí ese proyecto, lo hice analizar de nuevo y encontré puntos de mejora para el proyecto. #87issue Lo que encontré esta vez es que estaban usando EARS. Es un estándar de requisitos aeroespaciales de Rolls-Royce (IEEE RE'09) que Amazon adoptó para el desarrollo AI-native en 2025. Se dice que es una forma de evitar que la IA interprete el criterio de "completado" de manera diferente para cada problema, utilizando una gramática estructurada.
Repitiendo estas acciones, sigo intentando mejorar el proceso de desarrollo basado en IA del proyecto. Analicé y mejoré jikime-adk, artículos de arXiv, Dueling LLMs de Google Cloud y Spec-Driven Development de Thoughtworks. Por supuesto, esto no es porque yo lo sepa todo, sino porque Claude también analizó estos contenidos.
Analicé open-swe de LangChain y apliqué el patrón ensure_no_empty_msg, que evita que la IA rellene las revisiones con respuestas vacías. En jikime-adk, apliqué un patrón para registrar las decisiones tomadas por la IA y las trampas encontradas, insertando una sección ## AI Context en los mensajes de commit para que el git log pueda ser una fuente de recuperación incluso si la sesión se interrumpe.
En común, cada uno estaba resolviendo problemas similares de forma independiente.
Pero todavía me pregunto si este método es correcto... Me preocupa que se esté convirtiendo en un Frankenstein y me parece extraño como especialista. De todos modos, no hay un libro de texto y faltan pruebas de que sea lo mejor.
Todas las metodologías de ingeniería de software que usábamos surgieron de décadas de fracasos acumulados. Agile surgió porque Waterfall seguía fallando, y TDD también tiene una base porque el desarrollo sin pruebas seguía explotando.
Pero lo que he combinado ahora no está diseñado para funcionar entre sí. Un estándar aeroespacial, un desarrollador independiente coreano y un agente de LangChain están en el mismo sistema.
Esta inquietud me llevó a buscar investigaciones externas. El artículo V-Bounce (arXiv 2408.03416) afirma que en la era de la IA, el papel humano cambia de implementador a verificador. Es cierto, pero solo hay teoría y no pude encontrar una implementación. El Spec-Driven Development de Thoughtworks depende de herramientas específicas. Internamente en Anthropic, dicen que Claude Code escribe el 90% del código de Claude Code, pero no han revelado la metodología.
Al final, todos los que desarrollan seriamente con IA están creando sus propios métodos. No hay un estándar.
Así que lo que estoy haciendo últimamente es encontrar una manera de medir si este Frankenstein realmente funciona. Incluso si el CI fallaba, se fusionaba, y había texto que decía que se había revisado, pero no había rastro de que se hubieran leído los archivos. La metodología está diseñada, pero no se puede forzar. Parece que hay un sistema, pero no sé si funciona. La única forma de verificarlo parece ser creando números honestos generados por código que no sea un LLM, o si se usa un LLM, derivar "números" que muestren una mejora estadística. Me preocupa la tarea de analizar periódicamente los fallos repetidos en el proyecto para que la IA proponga mejoras, y medir el progreso a través de la evaluación del rendimiento de la ingeniería de contexto y de arneses.
Por ahora, solo estoy sujetando las riendas con fuerza y avanzando. Todavía no sé adónde voy, pero espero no estar ciego. Estoy construyendo las riendas, pero en realidad, es la primera vez que monto a caballo. Eso parece ser el arnés que sujeta el "vibe coding".
