No eres mejor ingeniero porque escribes los comandos de Git a mano

Reacción general a la postura del artículo

  • Muchos ven el título como provocación o como algo prescriptivo (“estás quemando tu vida”), lo que aleja a la gente de la IA en lugar de persuadirla.
  • Varios comentaristas están de acuerdo con delegar a la IA las tareas aburridas y mecánicas, pero objetan el encuadre de consejo de vida absolutista.
  • Otros sienten que la publicación carece de ejemplos concretos o de evidencia para afirmaciones como “la IA hace este trabajo mejor”, y que se apoya demasiado en “confía en mis X años de experiencia”.

IA para operaciones de Git y flujo de trabajo de PR

  • Algunos ingenieros delegan en gran medida el trabajo con git (rebases, merges, limpieza de ramas, etiquetado de PR, actualizaciones de listas de verificación) a agentes, y califican gran parte de ello como sobrecarga mecánica.
  • Otros mantienen a los LLM alejados de la ejecución directa de git por preocupaciones de confianza/seguridad, usándolos solo para consejo o comandos puntuales.
  • Una opinión recurrente: el git impulsado por IA es seguro y efectivo si ya entiendes conceptos como rebases, merges y fast-forwards; peligroso si no los entiendes.

Mensajes de commit, comentarios y comunicación

  • Fuerte rechazo a los mensajes de commit y descripciones de PR escritos por IA:
    • A menudo son prolijos, irrelevantes o no captan la intención real.
    • Degradan el historial de git, haciendo más difícil el bisect y la arqueología del código.
  • Contraargumento: los LLM son excelentes resumidores cuando se les da un buen prompt, y pueden imponer un estilo uniforme en todo un equipo.
  • Varios sostienen que escribir manualmente los commits te obliga a entender y asumir responsabilidad por los cambios, lo que mejora la calidad técnica general.

Externalizar el pensamiento vs. abstracciones

  • Preocupación de que delegar demasiado en la IA lleve a la atrofia de habilidades y a una menor comprensión del propio código; “externalizar el pensamiento” frente a “usar abstracciones para quitar el trabajo tedioso”.
  • Otros responden que las abstracciones son una necesidad cognitiva; la IA es solo otra capa de abstracción, como los lenguajes de más alto nivel o las refactorizaciones del IDE.
  • Punto intermedio común:
    • Debes entender al menos una capa por debajo de donde operas.
    • La IA está bien para el trabajo mecánico si sigues leyendo diffs, ejecutando pruebas y aplicando criterio.

Habilidades, productividad y futuro de la ingeniería

  • Algunos informan que los flujos de trabajo muy apoyados en IA no aceleran de forma dramática la entrega de funcionalidades, pero liberan tiempo para diseño, seguridad y modelado de datos, con menos errores.
  • Existe la preocupación de que, si un puesto se puede reducir a “pulsar siguiente” en una IA/IDE, sea fácilmente reemplazable o convertido en una mercancía.
  • Se defiende el conocimiento de bajo nivel (git, CLI, Linux) como valioso cuando las cosas fallan, aunque otros predicen que los modelos eventualmente también manejarán las tareas de recuperación.

Metadiscusión: contenido de IA y detección

  • Frustración visible con las acusaciones constantes de que todo artículo es “AI slop” y con la sobredependencia en detectores de IA.
  • Norma sugerida: juzgar el contenido por su utilidad y claridad, no por si fue asistido por IA.