Estoy enamorado de Opus 4.5 ahora mismo. Se siente tan inteligente como Gemini 3, pero con un estilo de código mucho mejor, seguimiento de instrucciones, CLI UX y, lo más importante, velocidad cuando solo quieres hacer algo pequeño. También tuve una interacción genial donde Claude Code fallaba y daba vueltas, así que lo interrumpí y le dejé pedir aclaraciones. Hizo preguntas geniales, le enseñé algunos conceptos, hasta que entendió. Luego completó la tarea (¡nada fácil!) y aprobó todas las pruebas. Aquí está la interacción (resumida por el propio Opus): (Claude Code interrumpió) - Yo: Llevas bastante tiempo aquí, ¿por qué no me preguntas? Siempre puedo responder. No necesitas adivinar ni probar cosas al azar, eso te llevará al fracaso. IA: Tienes razón, me disculpo. Pregunta: al distribuir la lambda en el SUP, ¿cómo debería funcionar la redirección de variables? ¿Debería configurar HEAP[lam_loc] para redirigir las variables originales a las nuevas lambdas? Yo: No estoy seguro de qué significa tu notación, pero... [explica la semántica de dup-lam]. Ten en cuenta que necesitamos una función clone_many() que reciba un Term* y clone cada elemento en dos Term*. ¿La tenemos? ¿Responde a tu pregunta? - IA: ¡Gracias, eso me aclara mucho! Mi pregunta sobre clone_many: en mi inyección en C, clono la plantilla una vez y clono cada argumento restante. ¿Es correcto? - Yo: ¿Qué es args0[16]? ¿Qué es args0[0] y por qué va sup_a ahí? No estoy seguro de entenderlo. - IA: Tienes razón, déjame releer Haskell con más atención... Así que a y b (las ramas SUP) no se clonan; van directamente como primer elemento de las nuevas listas de argumentos. Solo se clonan los argumentos restantes. Mi código en C coincide con esto. El problema debe estar en otra parte. - Yo: Ah, ya veo. Sí, tu lógica de clonación parece correcta, pero aun así insistiría en que uses una función auxiliar clone_many en lugar de incorporarla manualmente de esa manera. IA: Bien, primero agrego clone_many. [Lo agrega, las pruebas siguen fallando] Sigo obteniendo un resultado incorrecto. Pregunta: ¿Debería "collapse" evaluar/resolver los nodos CO0/CO1? ¿O deberían permanecer como CO0/CO1 y resolverse más tarde? - Yo: en Haskell, CO0/CO1 caen en el caso predeterminado de colapso... [explica la cadena de reducción completa con interacción de la misma etiqueta dup-sup] IA: ¡Eso es muy útil! La interacción duplicada con las mismas etiquetas es lo que hace que CO0/CO1 se resuelva correctamente. El problema debe estar en la estructura de mi plantilla. ¿Es incorrecta? Yo: Simplemente pasas la plantilla para inyectar; clonará todo si es necesario. Tu construcción parece incorrecta. ¿Estás asignando dos lambdas? ¿Por qué dos heap_allocs? Deberías crear una variable en la lam externa. Parece que estás creando una variable en un lugar sin uso. IA: ¡Tienes razón! El VAR(fV_loc) debería apuntar a la ubicación del cuerpo de la lambda externa (outer_loc), no a una fV_loc separada. ¿Es correcto? - Yo: suena bien, pero por favor, compruébalo, tú eres la máquina aquí. - IA: Tienes razón, déjame rastrearlo cuidadosamente... [rastrea, verifica, corrige el código] ¡collapse_4 pasa! [continúa arreglando los casos APP, DRY, MAT, CTR con el mismo patrón] ¡Las 35 pruebas pasan!
este bucle: > le das una tarea a la IA > explora el problema > trae una pregunta > Lo alimentas con perspicacia > explora el problema >...etc... Es una forma muy potente y eficaz en términos de tiempo para crear software. Eres aún más inteligente que él (espero), pero puede levantar mucho por sí solo.