“El código nunca fue la parte difícil” es un insulto para todos los programadores
“El código nunca fue la parte difícil” se ha convertido en un punto de fricción a medida que las herramientas de IA generan cada vez más código funcional, aumentando el temor de que la habilidad de programar esté siendo devaluada. Los comentaristas discuten si teclear código fue alguna vez el principal cuello de botella frente a aspectos más difíciles como entender requisitos, diseñar sistemas, mantener software y navegar la política organizacional. Muchos ven a los LLM como amplificadores de tensiones existentes: pueden acelerar el código rutinario, pero también arriesgan una avalancha de “vibe code” de baja calidad, haciendo que el juicio humano, la arquitectura y la responsabilidad a largo plazo sobre el software sean más críticos que nunca.
Significado de “el código nunca fue la parte difícil”
- Muchos lo leen como: “teclear código no es el cuello de botella” una vez que tienes experiencia; las partes difíciles son decidir qué construir, cómo diseñarlo y encajarlo en organizaciones caóticas.
- Otros dicen que esta formulación es engañosa o insultante porque suena a “programar es fácil” y borra la verdadera dificultad técnica, especialmente en dominios no triviales.
¿Es difícil programar?
- Varios argumentan que programar de forma básica es intrínsecamente difícil para muchas personas (tasas de abandono en CS, fallos en fizzbuzz, años de práctica requeridos).
- Otros dicen que, en comparación con los requisitos, la arquitectura, la comunicación y la política interna, el acto de implementar código suele ser la parte más fácil del trabajo en conjunto.
- A menudo se hace una distinción entre “hacer que algo funcione” y escribir código eficiente, correcto, mantenible y evolutivo; este último también se considera difícil.
Código vs. programación / ingeniería
- Tema recurrente: “coding” = introducir instrucciones; “programación/ingeniería” = resolver problemas, diseñar, modelar dominios, integrar sistemas, operarlos y hacerlos evolucionar.
- Muchos dicen que los buenos ingenieros inevitablemente se ponen “sombreros invisibles”: refinar requisitos, arquitectura, rendimiento, seguridad, cumplimiento normativo, operaciones.
IA/LLMs y su impacto
- Algunos afirman que los LLM han convertido gran parte del código cotidiano en trabajo de baja cualificación tipo “cocina” o “dar vueltas a hamburguesas”; el valor real sube hacia el diseño, la orquestación y la especificación.
- Otros informan que los LLM generan código más descuidado, con errores o inseguro, especialmente en sistemas complejos (distribuidos, regulados, críticos para el rendimiento), aumentando la carga de revisión y mantenimiento.
- Visión compartida: los LLM ayudan con el boilerplate y con “teclear”, pero no sustituyen la comprensión profunda, el mantenimiento a largo plazo ni las decisiones de alto nivel correctas.
Producto, requisitos y organizaciones
- Muchos dicen que los verdaderos cuellos de botella son los requisitos poco claros, las prioridades cambiantes y la alineación entre áreas; los “días de código sin reuniones” son raros y se valoran mucho.
- Hay desacuerdo sobre quién debería encargarse de comprender al usuario: algunos sostienen que los ingenieros deben involucrarse pronto; otros creen que producto/PM debería proteger a los ingenieros y encargarse de la investigación.
Calidad, mantenimiento y regulación
- El mantenimiento y la depuración se citan repetidamente como las partes más difíciles y que más tiempo consumen; mucho del código existente “no pasaría una auditoría básica”.
- En dominios regulados o críticos para la seguridad, el proceso y la documentación pueden eclipsar al código en sí, pero el código igualmente debe ser correcto y es difícil de cambiar de forma segura.
Trabajo, estatus e identidad
- Varios ven “el código nunca fue la parte difícil” como una narrativa de consuelo frente a la ansiedad por la automatización.
- Otros señalan que los salarios altos reflejaban escasez y apalancamiento, no solo dificultad, y que muchas habilidades no relacionadas con código (producto, gestión) también son difíciles pero reciben menos valoración visible.