Ask HN: ¿Hacia dónde va la profesión de la programación?

Discusión en Hacker News ↗

Sentimiento general

  • Hay un amplio acuerdo en que los LLM ya han cambiado el trabajo de software, pero una fuerte discrepancia sobre hasta dónde llega esto y con qué rapidez.
  • El hilo mezcla entusiasmo por enormes ganancias de productividad con ansiedad sobre la calidad, la rendición de cuentas, la reducción de puestos y el “vibe coding”.

Rol cambiante de los programadores

  • Muchos ven que “escribir código” se está convirtiendo en la parte fácil/mecánica; el valor restante está en:
    • Entender problemas, usuarios y dominios.
    • Arquitectura, diseño de sistemas, restricciones y compensaciones.
    • Gestionar agentes de IA y revisar su output.
  • Algunos sostienen que el rol está evolucionando de “programador” a “ingeniero/arquitecto/gestor de agentes”, de forma similar a cómo el histórico “analista + programador” se fusionó en “ingeniero de software”.
  • Otros temen que no teclear el código personalmente debilite la comprensión, como estudiantes que intentan hacer matemáticas tras haber leído solo el libro de texto.

Calidad, complejidad y ‘deuda cognitiva’

  • Preocupa que los LLM tiendan a:
    • Soluciones sobrediseñadas, abstracciones innecesarias y alcances excesivos.
    • Grandes volúmenes de PR mediocres y migraciones parciales.
  • Nueva idea de “deuda cognitiva”: cuando la fuente de verdad pasa a ser prompts, planes y agentes opacos en lugar de código determinista.
  • Algunos equipos reportan agotamiento por:
    • Planificación pesada por adelantado para agentes.
    • Grandes cargas de revisión para PR generados por IA.
    • La sensación de estar “peleando con las herramientas” sin ganancias netas de productividad.

Capacidades, límites y flujos de trabajo de los LLM

  • Los adoptantes más entusiastas afirman que los modelos punteros pueden implementar la mayoría de las tareas, incluso en grandes codebases heredadas, si:
    • El trabajo se descompone en unidades pequeñas.
    • Hay especificaciones, planes y pruebas detalladas.
  • Los críticos informan:
    • Errores básicos de diseño/lógica y APIs/documentación alucinadas.
    • Bajo rendimiento/robustez salvo que haya una supervisión intensa.
  • Debate sobre si estos fallos son inherentes o problemas de “habilidad/uso”.
  • Algunos tratan el código como “ensamblador”: revisan la intención de alto nivel, la documentación generada, los diagramas y las pruebas en lugar del código fuente.

Patrones de adopción y división del sector

  • Empresas pequeñas/rápidas: más presión para usar LLM de forma agresiva; el “vibe coding” es común.
  • Empresas grandes/reguladas: adopción más lenta, código propiedad de humanos, revisiones obligatorias; la IA se permite pero no se impone.
  • Se discutió una posible división:
    • Trabajo de alto nivel, crítico para seguridad/rendimiento: menos ingenieros, pero más cualificados, usando IA como herramientas de potencia.
    • Programación de nivel medio/bajo, prototipos y apps de negocio simples: fuertemente automatizada o reemplazada.

Perspectiva a largo plazo e incertidumbre

  • Algunos predicen que programar se parecerá a operar máquinas CNC: menos humanos, habilidades más comoditizadas.
  • Otros esperan que la IA se estabilice en mejores asistentes tipo IDE (modelos locales, mapas visuales/de código) en lugar de “fábricas oscuras” completas.
  • Muchos enfatizan: nadie lo sabe realmente; el ritmo de evolución de los modelos y las herramientas hace sospechosa cualquier previsión tajante.