Cuando la IA cuesta más que el ingeniero

Fallos en la comparación de costes

• Muchos sostienen que el artículo es “basura” porque mezcla los costes de entrenamiento de IA en laboratorios de modelos con la inferencia y el uso de herramientas en empresas normales.
• Usar el cómputo por empleado de Anthropic como referencia para el “gasto en IA por ingeniero” se considera incoherente: su cómputo es la materia prima de su producto, no una herramienta para empleados.
• Los críticos dicen que esto es como contar la extracción de petróleo como “gasto en combustible” para Shell, o el hormigón como “herramientas eléctricas” para una constructora.

Quién paga el entrenamiento y el cómputo

• Algunos dicen que todos los costes de entrenamiento deben acabar repercutiéndose a los clientes, así que sí importan.
• Otros señalan la incertidumbre: se desconocen los calendarios de amortización; los laboratorios pueden quebrar; inversores o compradores podrían absorber gran parte del coste.
• Varios enfatizan que los laboratorios de IA son negocios industriales intensivos en capex, no empresas de software típicas dominadas por la nómina.

Analogías y marco económico

• Se usan múltiples analogías (martillos frente a puños, agua embotellada, piezas frente a mano de obra en fabricantes de coches) para mostrar por qué comparar el gasto en cómputo de un laboratorio de IA con el gasto en herramientas de IA en empresas normales es engañoso.
• Algunos replican que un análisis real de coste-beneficio debería incluir toda la cadena de herramientas, no solo el uso marginal.

Gasto en IA vs productividad del ingeniero

• La cifra máxima citada en el artículo (IA en torno al 40% del coste de un ingeniero senior) se considera notable, pero lejos de “más que un ingeniero”.
• Algunos argumentan que incluso gastar 2× el salario de un ingeniero en IA sería racional si realmente produjera 10× de productividad.
• Otros dudan de esas mejoras y esperan que las empresas introduzcan “presupuestos de tokens” y una gestión del rendimiento vinculada al coste de la IA.

Experiencias reales de desarrolladores

• Muchos tratan a los LLM como desarrolladores júnior muy capaces pero propensos a errores: excelentes para código repetitivo, mapeo, correcciones de bugs, explicaciones y POCs, pero con necesidad de revisión estrecha.
• Las mejoras de productividad reportadas se concentran en “quizá 2×, no 3.3×”, con mucho tiempo ahora dedicado a especificaciones y revisiones.
• Algunos experimentan un “problema de última milla”, donde la IA llega al 90% y el 10% final se vuelve costoso; otros dicen que un mejor prompting y una mejor definición del alcance lo solucionan en gran medida.

Modelos más baratos / abiertos y control de costes

• Algunos esperan que los modelos de pesos abiertos ofrezcan un valor similar a aproximadamente 1/10 del coste, especialmente para tareas comunes.
• Otros responden que los modelos punteros siguen siendo importantes para casos extremos de alto impacto, donde incluso pequeñas mejoras de rendimiento valen millones.
• Hay desacuerdo sobre la trayectoria: un bando afirma que las mejoras de los modelos se están ralentizando; otros lo discuten con fuerza.

Ángulos organizativos y estratégicos

• Varios ven el gasto actual en IA como impulsado por el hype y la persecución del “objeto brillante”, a menudo subvencionado por créditos o dinero de VC.
• Hay escepticismo de que flujos de trabajo agénticos caros (p. ej., autoarreglar tickets) sobrevivan cuando terminen los créditos gratis y sean visibles los costes reales de la nube y de tokens.
• También surge una crítica general a la toma de decisiones ejecutiva, a los despidos justificados por la IA y a las promesas exageradas sobre automatización.