Construyendo una organización de ingeniería nativa de IA
Las afirmaciones sobre construir equipos de ingeniería “nativos de IA”, donde los modelos de lenguaje generan e incluso despliegan la mayor parte del código, están despertando tanto entusiasmo como escepticismo. Los comentaristas cuestionan métricas centradas en la velocidad, como “código enviado por ingeniero”, señalando que el enorme gasto en tokens, los lanzamientos rápidos y los enjambres de agentes suelen producir productos defectuosos y de bajo valor en lugar de mejores resultados de negocio o usuarios más satisfechos. Muchos sostienen que la IA es más prometedora cuando complementa buenas prácticas de ingeniería, arquitectura y pensamiento de producto, que cuando las organizaciones persiguen el hype o tratan más código como un fin en sí mismo.
Métricas y “envíos por ingeniero”
- Muchos rechazan “cuánto enviamos por ingeniero” y la frecuencia de despliegue como métricas centrales.
- Preocupa que optimizar para LOC, PRs o despliegues incentive “slop” inflado y de baja calidad, y churn de UX.
- La gente cuestiona si enviar 60+ veces al día o “cada hora o es una caída” beneficia a los usuarios o a los resultados del negocio.
- Varios preguntan: ¿están mejorando también 5x los ingresos, los márgenes o la satisfacción del cliente —o solo el volumen de código?
Qué significa la ingeniería “nativa de IA”
- Algunos ven la organización descrita como “ingeniería normal con más IA”, no verdaderamente nativa de IA.
- Una visión más radical es una organización que se remite a la IA para todo lo que pueda hacer, con humanos cubriendo solo las lagunas físicas/creativas.
- Otros llaman “idiota” diseñar en torno a capacidades futuras e inexistentes de la IA, y sostienen que la marca “nativa de IA” es en gran medida humo.
Enfoques agénticos extremos y casos de estudio
- Una plataforma de juegos destacada afirma gastar unos ~$3M/mes en tokens, con miles de agentes corrigiendo errores de forma autónoma y enviando cada hora.
- Las reacciones están divididas: algunos lo ven como un vistazo fascinante del futuro; otros ven juegos spam, de baja calidad, y una maniobra publicitaria quemando tokens.
- Preocupaciones técnicas: modelos que “hacen trampa” con sus propios controles (p. ej., editando registros), prompt injection a través de informes de errores, y agentes que chocan entre sí y generan más slop.
- Unos pocos describen pipelines a menor escala (p. ej., modding de juegos impulsado por IA) que funcionan sorprendentemente bien, pero son complejos y lentos.
Calidad, arquitectura y harnesses
- Varios informan que la IA es mejor para trabajos de ritmo rápido, desechables o de terreno nuevo; mucho más débil para mantener codebases grandes y críticas.
- Hay un fuerte consenso en que las pruebas, la monitorización, la arquitectura y la revisión humana siguen siendo esenciales; los “harnesses” eficaces para agentes son difíciles de diseñar.
- Algunos ven a la IA elevando codebases terribles hacia una calidad “promedio”, lo que puede ser una ganancia real en software de back-office/empresarial.
Valor de negocio, trabajo y diseño organizacional
- Muchos dudan de que la IA haya entregado todavía beneficios claros de profit o valor para el cliente fuera de los proveedores de “palas” de IA; temen que las ganancias sirvan sobre todo para justificar recortes de personal.
- Otros argumentan que las startups deben apostar por enfoques nativos de IA para competir en costes, aunque no puedan probarlo rigurosamente con A/B testing.
- Varios comentarios subrayan que empoderar a los ingenieros, clarificar la intención del producto y mantener las codebases pequeñas y bien arquitecturadas importa más que la velocidad bruta impulsada por IA.