Aceptar todo, no entender nada

Presionar enter para aceptar sugerencias de código requiere menos esfuerzo que desplazarse para ignorarlas. Una sola pulsación de tecla hace que el código sea tuyo. Leer y comprender ese código no se ha vuelto más rápido.

Existe una brecha entre la rapidez con la que aceptas el código y la rapidez con la que lo comprendes. En esa brecha es donde ocurren los errores.

La deuda técnica solía tener causas claras. Tenías plazos ajustados o tomabas atajos. Podías señalar el motivo. Ahora construyes deuda en un martes tranquilo. Aceptas seis sugerencias seguidas porque parecen estar bien. Nadie te presionó, pero el código permanece sin examinar.

Brian Kernighan dijo en 1974 que depurar es el doble de difícil que escribir un programa. Se refería al código que escriben los humanos. Al menos los humanos comprenden su propio trabajo.

Hoy en día, una sugerencia puede pasar el linter e incluso superar las pruebas. Aun así, puede basarse en una suposición errónea. Esto sucede porque la gente lee la sugerencia como un resultado en lugar de como código. Un resultado que se ve bien es aprobado.

Si un modelo escribe tanto el código como las pruebas, estás calificando la tarea con las propias respuestas del estudiante. Esto no te dice si la lógica es sólida. No te dice si se cubren los edge cases. Es fácil olvidar esto cuando el código aparece en tu propio editor y con tu propio estilo.

Esto crea problemas reales:

  • Depuras código que nunca leíste. Cuando algo falla semanas después, empiezas de cero.
  • Los edge cases fallan. Una sugerencia maneja bien el happy path. Incluye una comprobación de nulos. Pero omite la lógica específica que tu negocio necesita.
  • No puedes defender tus propios pull requests. Si un revisor pregunta por qué elegiste un método, no tienes respuesta. Tú no tomaste la decisión. Simplemente no la rechazaste.

Estas herramientas son útiles. Te ayudan a explorar bases de código o a planificar nuevas funcionalidades. El problema es tu postura. Debes tratar cada sugerencia como algo que requiere lectura y decisión, no solo como algo a lo que echar un vistazo.

Para código boilerplate o scripts rápidos, la velocidad está bien. Para lógica de negocio o seguridad, tu enfoque debe cambiar. Lee el código como si fueras el dueño. Porque lo serás.

En su lugar, haz lo siguiente:

  • Discute tu solución con el modelo antes de pedir código.
  • Revisa el diff como si lo hubieras escrito tú mismo.
  • Pide a la herramienta que explique su razonamiento antes de aceptar el código.
  • Trata las sugerencias como el trabajo de un desarrollador junior. Es útil, pero no es la verdad absoluta (ground truth).
  • Ve más despacio en las líneas que te sorprendan. La sorpresa es una señal.

La pulsación de tecla se volvió más barata. Tu responsabilidad no. La velocidad sin comprensión es solo deuda rápida.

Fuente: https://dev.to/cloudx/accept-all-understand-none-4dob

Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi