Me preocupa que nuestro Copilot esté dejando a algunos pasajeros atrás
GitHub Copilot y asistentes de programación con IA similares son elogiados por algunos ingenieros con experiencia como herramientas de autocompletado potentes, pero criticados por otros por fomentar código abultado, inaccesible o sutilmente incorrecto que luego los compañeros deben desenredar. Los comentaristas temen que la dependencia excesiva del código generado por LLM, especialmente por desarrolladores con menos experiencia y en áreas como seguridad y accesibilidad, acelere un deterioro ya existente de la calidad del software y agrave las presiones de “enshittification”. Muchos sostienen que estas herramientas se usan mejor con pruebas sólidas, revisiones y normas claras: tratarlas como colaboradores junior o traductores, no como sustitutos de la comprensión, el diseño y la mantenibilidad a largo plazo.
Normas del equipo y uso indebido de herramientas de codegen
- Varios describen a colegas que pegan cambios grandes generados por LLM, con código irrelevante, no pueden explicarlo y esperan que sus compañeros lo depuren y le arreglen el estilo.
- Muchos sostienen que esto debería tratarse como cualquier otra mala ingeniería: rechazar PRs, exigir explicaciones, requerir conformidad con las normas del codebase; algunos creen que delegar habitualmente el razonamiento es motivo de despido.
- Preocupa que los “desarrolladores de LLM” trasladen el esfuerzo del autor a los revisores, lo que se percibe como una falta de respeto.
Dónde ayuda y dónde perjudica Copilot
- Se considera más útil para: boilerplate, estructuras repetitivas, traducciones entre formatos (p. ej., JSON → types), consultas rápidas de documentación, armazones de pruebas y depuración tipo “rubber duck”.
- Algunos lo mantienen desactivado por defecto y solo lo activan cuando saben exactamente lo que quieren.
- Otros informan que ha empeorado o es inconsistente, y a menudo devuelve suposiciones con poco contexto o ninguna solución en absoluto.
- Patrones de uso eficaces: tratarlo como autocompletado potente, trabajar con él como con un dev muy junior, aceptar solo lo que ya se pretendía.
Calidad de código, accesibilidad y seguridad
- Muchos coinciden en que Copilot refleja la calidad, a menudo pobre, del código público: HTML de sopa de divs, accesibilidad débil, mal Bash, etc.
- Preocupa que el código generado por LLM normalice malas prácticas (accesibilidad, seguridad, internacionalización) que “parecen funcionar” y, por tanto, se publiquen sin que nadie las note.
- Algunos creen que estos problemas pueden mitigarse con mejores datos de entrenamiento e integrando linters, comprobadores de accesibilidad y pruebas en el ciclo de generación.
Aprendizaje, contratación y dependencia excesiva
- La herramienta se considera un impulso para expertos (que pueden detectar errores) y una trampa para novatos (que no pueden).
- Preocupa que los juniors externalicen el pensamiento, aprendan patrones incorrectos y nunca construyan fundamentos.
- Contratación: entrevistadores ven a candidatos usando IA en secreto en pruebas remotas; entre las contramedidas se incluyen compartir pantalla completa, tareas solo en pseudocódigo o centrarse en el razonamiento en lugar de en la codificación mecánica.
Industria en general y direcciones futuras
- Varios relacionan los LLM con la “enshittification”: podrían acelerar incentivos ya malos (moverse rápido, nunca limpiar, aceptar UX/rendimiento mediocres).
- Otros argumentan que las aplicaciones basura están impulsadas por los mercados, no por las herramientas; los LLM incluso podrían ayudar a equipos pequeños a competir con sistemas malos ya establecidos.
- Algunos imaginan flujos de trabajo más ricos: modelos específicos de la organización, generación restringida por compiladores/gramáticas, sugerencias de refactorización y generación en múltiples pasos validada por pruebas y linters.