Devon C. Estes: las malas ideas que dejaron de serlo gracias a la IA

Bad ideas that aren't bad anymore

Tras 15 años en software, Devon C. Estes revisa prácticas que su instinto marcaba como errores y que ahora funcionan en su equipo: nadie revisa los PRs de otros porque Claude escribe el código y el humano dueño del ticket lo revisa; el equipo se divide en flujos separados sin silos de conocimiento; y ya no recomienda la especialización profunda en una tecnología. La causa común: el coste de cambiar de contexto y de adquirir conocimiento ha caído, y el juicio humano importa más que nunca.

Lo que realmente ha cambiado es que el coste de cambiar de contexto ha caído drásticamente, porque estamos operando un nivel por encima de donde solíamos hacerlo.
  1. sn

    Soy ingeniero principal. Las revisiones de código siguen importando para el software de producción.

    Quizá tu opinión sea que no estoy haciendo vibe coding con suficiente intensidad, y que si yo hiciera la IA mejor no necesitaríamos revisiones de código. No estoy de acuerdo: tanto los ingenieros como los LLM siguen añadiendo complejidad innecesaria o eligiendo abstracciones equivocadas de formas que causarán problemas en el futuro, no piensan en todos los casos límite y eligen el manejo incorrecto para las condiciones de error. Añaden cosas que les parecen una buena idea y no se ciñen a la especificación.

    Si mi empresa deja de hacer revisiones de código para el software que importa, renuncio.

    Los ingenieros que no están en el ajetreo de una startup deberían aspirar a usar los LLM para programar mejor, no más rápido. Más rápido solo crea deuda técnica y aumenta tus costes a largo plazo.

  2. xg15

    El tema común en esos diferentes ejemplos parece ser:

    "Antes, teníamos que tener cuidado de permitir que cada miembro del equipo adquiriera experiencia y pericia con nuestro código base y evitar dinámicas que pudieran formar silos de conocimiento. Ahora esto ya no importa porque todos pueden simplemente pedirle a Claude que les explique todo".

    La verdad es que no estoy tan seguro de eso. A corto plazo, funciona, sí. Pero a largo plazo, podría ser como si tuvieras algunos libros muy buenos, pero cero experiencia práctica con algo. Todos sabemos que el conocimiento de los libros es diferente de la experiencia aprendida.

  3. ro_sharp

    ¿Por qué tanta gente piensa que las revisiones de código se tratan principalmente de desconfianza o de detectar errores?

    En mi opinión, se tratan principalmente de asegurar un entendimiento y acuerdo compartidos, no solo sobre cómo están cambiando las cosas ahora, sino sobre cómo cambiarán en el futuro.

  4. kbiessy

    Voy a hablar del punto de esta lista que conozco mejor. El de "construir en lugar de comprar" es el que cuestionaría.

    El coste de escribir la herramienta en su mayor parte ha desaparecido, en eso estoy de acuerdo. El coste de poseerla no creo que haya cambiado tanto. Si me encargo del stack de software de un par de pequeñas empresas que conozco, las herramientas personalizadas son las que acaban doliendo más. Nadie recuerda que fue hecha a medida, hasta que la llamada a la API falla, o la persona que la construyó se va. Creo que el coste de mantenimiento es particularmente alto.

    Una tarde de construcción no arregla el mantenimiento a largo plazo, ni proporciona conocimiento funcional. Creo que los generalistas tienen mucho que ganar con la IA, pero seguirá habiendo un papel enorme para los expertos que guíen y mantengan el software en el futuro.

  5. ahartmetz

    >Introducir un lenguaje o herramienta que nadie en el equipo conoce [ya no es una mala idea]

    Vale, ahora estoy seguro de que este tipo está lleno de mierda.

Más de este día

2026-11-12