La fallida commodificación del trabajo técnico
Los intentos de convertir el desarrollo de software en una mercancía de cadena de montaje siguen chocando con la realidad desordenada de los sistemas complejos, los requisitos cambiantes y la resolución creativa de problemas. Los comentaristas señalan que muchas tareas y herramientas de bajo nivel (desde combinar correspondencia hasta la infraestructura en la nube) sí se han estandarizado con éxito, pero eso sobre todo empuja el trabajo restante hacia arriba en la pila, donde la comprensión del dominio, el buen juicio y los requisitos claros importan aún más. El resultado es una tensión entre directivos que buscan previsibilidad y soluciones listas para usar, y profesionales que sostienen que tratar a los programadores, el trabajo con datos o incluso la práctica médica como mano de obra intercambiable de fábrica suele conducir a sistemas frágiles, proyectos fallidos y “trabajo rutinario” oculto en lugar de verdadera eficiencia.
Alcance y límites de la commodificación del trabajo técnico
- Muchos comentaristas coinciden en que cierto “trabajo técnico” sí se ha commodificado con éxito: combinar correspondencia, contabilidad básica, sitios web simples, edición WYSIWYG, correo electrónico alojado, etc.
- El consenso es que el trabajo que queda depende menos de conectar bibliotecas y más de los requisitos, el diseño y la comprensión del dominio, que son más difíciles de estandarizar.
- Varios sostienen que la fruta madura de la commodificación ya está en gran parte agotada; una mayor abstracción empuja los problemas hacia arriba en la pila y aumenta la necesidad de especialistas.
Trabajo rutinario, complejidad y nuevos roles
- Algunos esperan que la automatización reduzca el trabajo rutinario; otros afirman que el trabajo rutinario total se mantiene aproximadamente constante o crece, solo que se desplaza a nuevas capas (DevOps, SRE, Cloud*, roles de datos, operaciones manuales en grandes organizaciones).
- Las nuevas tecnologías tanto automatizan tareas antiguas como generan nuevas tareas rutinarias y cargas de integración.
Escepticismo hacia low-code, SaaS y la abstracción de SQL
- Fuerte escepticismo hacia las herramientas que “eliminan la necesidad de programar”, especialmente las capas de abstracción de SQL y las herramientas BI de arrastrar y soltar.
- Patrón común: las abstracciones ayudan en casos simples, pero filtran complejidad en necesidades no estándar, obligando a los expertos a volver a la tecnología subyacente.
- Algunos señalan productos SaaS que todavía no resuelven problemas reales de los clientes, y en su lugar usan los casos de uso de los primeros adoptantes como I+D no remunerada.
Herramientas de IA y aprendizaje
- Las herramientas de programación con IA se comparan con low-code: pueden generar plantilla, pero no eliminan la necesidad de enmarcar el problema e integrarlo.
- Varios reportan código generado por IA que hace referencia a paquetes inexistentes o pasa por alto las partes difíciles.
- Preocupa que el uso generalizado de la IA pueda erosionar el aprendizaje de los principiantes al fomentar la “copia de respuestas” en lugar de la comprensión.
Fábrica vs. oficio: debates sobre procesos
- Un bando enfatiza la programación como un oficio parecido a la carpintería a medida: se aprende mejor mediante aprendizaje, y encaja mal con un tratamiento “de fábrica” totalmente taylorista.
- Otro bando señala que partes del trabajo de software son repetibles y deberían sistematizarse, estandarizarse y gestionarse como producción.
- Las prácticas de Phoenix Project / Scrum / Agile se debaten acaloradamente: algunos las ven como estructuras ligeras y útiles para el trabajo repetible; otros las experimentan como burocracia performativa y deshumanizadora que ignora la naturaleza intrínsecamente exploratoria de la mayor parte del desarrollo.
Gestión, herramientas y deuda organizativa
- Tema recurrente: los líderes tratan los problemas complejos de software y de organización como si fueran compras de electrodomésticos (Workday, EMR, CRM, ServiceNow), subestimando la personalización, el mantenimiento y el modelado del dominio.
- La estructura organizativa en sí se describe como una especie de deuda técnica que ninguna herramienta puede arreglar; la desalineación entre las expectativas del negocio y la realidad del software impulsa muchos fracasos.