En la era de la codificación con IA, los buenos hábitos de programación siguen siendo importantes

Recientemente, al hacer un benchmark de agentes, descubrí que no se puede evaluar la complejidad de una tarea de programación para la IA simplemente desde la perspectiva del desarrollador.
Por ejemplo, una tarea de refactorización: dividir un archivo grande de varias miles de líneas en más de diez módulos pequeños según su función.
Esta tarea no es realmente difícil para un desarrollador, el trabajo principal es mover código, organizar imports, compilar y verificar, incluso un novato puede hacerlo.
Por eso pensé en usar una tarea sencilla para hacer un benchmark, pero el resultado fue inesperado.
Claude Code considera que esta tarea es bastante grande, intentó dividirla parcialmente, propuso un PR y escribió un trabajo futuro pensando en hacerlo paso a paso.
Mi propio agente fue “a la fuerza”, avanzando más en la dirección de una división completa, pero el costo también fue claro: el consumo de tokens es varias decenas de veces mayor que el de Claude, y mucho tiempo se gastó en leer archivos repetidamente, corregir errores de compilación, volver a leer archivos y corregir errores otra vez.
Esto me hizo darme cuenta de que, tareas que parecen simples para las personas, no necesariamente lo son para los agentes.
Para los humanos, muchas veces esa clase de refactorización es simplemente “mover esta sección”. Pero para un agente, primero tiene que leer en partes archivos grandes, recordar qué funciones y qué pruebas están relacionadas, luego generar una serie de cambios entre archivos, y finalmente ir corrigiendo errores de compilación poco a poco.
Parece una tarea mecánica, pero en realidad se convierte en una tarea con alto consumo de tokens y costos de gestión de estado.
Hace un tiempo, alguien dijo que en la era de la codificación con IA, principios de programación como dividir en módulos ya no son tan importantes, ya que los humanos no revisan el código de todos modos.
Ahora, creo que no estoy muy de acuerdo. Tener límites claros en los módulos, un tamaño de archivo adecuado y dependencias simples no solo facilita la lectura humana, sino que también ayuda a reducir la complejidad de la tarea para el agente.
Desde otra perspectiva, las herramientas actuales de lectura y modificación de archivos para los agentes no son muy convenientes para este tipo de refactorización.
El agente de codificación para modificar archivos principalmente realiza reemplazos de texto. Por ejemplo, Claude Code suele usar el patrón old_string / new_string: primero proporciona un fragmento de texto antiguo y luego lo reemplaza por uno nuevo.
Codex suele usar apply_patch: genera un parche similar a un diff de git, que indica cómo reemplazar el contenido antiguo por el nuevo.
Ambos son adecuados para cambios pequeños, pero si hay que eliminar un gran bloque de código antiguo o mover varias funciones a otros archivos, el modelo generalmente necesita leer primero el contenido original en el contexto, y luego generar un gran bloque de reemplazo o diff.
Por eso, posteriormente di una pista al agente para que use scripts, sed, perl u otras herramientas para dividir en partes grandes el archivo, eliminar directamente el contenido viejo, escribir en un nuevo archivo y luego ir corrigiendo poco a poco.
Su nivel de completitud mejoró mucho con esto.
El agente por defecto no hace esto, principalmente porque en las instrucciones del sistema se le exige fuertemente que use las herramientas integradas para modificar archivos, en lugar de herramientas de línea de comandos.
Pensando un paso más allá, el agente de codificación quizás necesite herramientas de edición más avanzadas.
No solo un simple interfaz de “reemplazar texto”, sino que primero construya la estructura del código mediante un parser, LSP o compilador, para que el agente pueda hacer refactorizaciones como en un IDE: mover funciones, eliminar bloques impl, organizar imports.
No sé si algún amigo ha intentado algo en esa dirección.
En general, incluso en la era de la codificación con IA, los buenos hábitos de programación siguen teniendo valor.
Es mucho más barato convertir esos buenos hábitos en la forma de trabajo predeterminada del agente mediante ingeniería de harness en las etapas iniciales, que hacer refactorizaciones posteriores.