Las demos de copilots de código son engañosas. Todos funcionan bien en un archivo aislado con una función corta. La diferencia aparece cuando el repositorio tiene diez años de historia, convenciones contradictorias y esa carpeta que nadie se atreve a tocar porque documentó el proyecto entero con un comentario en 2016.
Sección 01
El contexto lo es casi todo
Un copilot que solo ve el archivo abierto sugiere código razonable pero ajeno al proyecto. Los que indexan el repositorio completo entienden las convenciones internas —el estilo de nombres, la separación entre capas, los helpers ya existentes— y producen cambios coherentes con lo que el equipo ya escribió antes.
La calidad del contexto también depende de cómo se sirve al modelo. Los mejores copilots priorizan archivos recientemente editados, tests relacionados y definiciones de tipos por encima del volumen puro de líneas. Los peores mandan miles de tokens irrelevantes y obtienen respuestas plausibles pero descontextualizadas.
Un buen síntoma: cuando pides una función y el copilot reutiliza un helper que ya existe en el proyecto en lugar de reinventarlo. Un mal síntoma: cuando propone dependencias nuevas para resolver algo que ya hace la propia base de código.
Sección 02
Refactor versus autocompletar
Autocompletar es un commodity. Todos los grandes proveedores ofrecen sugerencias correctas para bucles, tipos y llamadas a APIs conocidas. Donde se ven diferencias serias es en refactorizaciones grandes: renombrar una abstracción en veinte archivos, mover lógica entre capas, adaptar un patrón nuevo en todo el código o migrar de una librería a otra sin romper tests.
En esas tareas, la diferencia entre copilots se mide en horas ahorradas, no en pulsaciones. Un modelo que entiende bien el proyecto propone un plan antes de tocar código y pide confirmación en los puntos ambiguos; uno que no lo entiende parchea al vuelo y deja el repositorio peor de como lo encontró.
Sección 03
La revisión de PRs como filtro
Cuando un copilot publica una revisión automática útil en un pull request —encuentra un bug real, señala una regresión, sugiere un test que faltaba— ahorra horas al equipo. Cuando publica una lista de avisos genéricos sobre nombres de variables o comentarios ausentes, contamina el flujo del equipo y termina desactivado en dos semanas.
El mejor uso que hemos visto es reservar la revisión automática para dos tipos de aviso: seguridad y consistencia con el estilo del proyecto. Todo lo demás —opinión estilística, sugerencias de arquitectura, comentarios sobre legibilidad— pertenece al revisor humano y no debería aparecer en la conversación del PR.
Preguntas frecuentes
Lo que más se pregunta
Seguir leyendo
