Tinet
Volver

Ford tuvo que re contratar a antiguos ingenieros para corregir errores

Ford descubrió que los requisitos de diseño no bastaban. Lo que faltaba estaba en la cabeza de sus ingenieros y en desarrollo de software ocurre exactamente lo mismo.

Ford tuvo que re contratar a antiguos ingenieros para corregir errores Artículo

Hace algunos meses se conoció una historia que vale la pena mirar con atención, sobre todo si su organización está incorporando IA en procesos críticos.

Ford, que venía enfrentando problemas de calidad en sus vehículos, había apostado fuerte por sistemas automatizados y de inteligencia artificial para mejorar el control de calidad. La expectativa era razonable: si la IA podía analizar los requisitos de diseño y los datos de producción, debería detectar y prevenir defectos mejor que cualquier persona.

No funcionó como esperaban. Y la solución no fue una IA más avanzada. Fue volver a las personas.

Qué pasó en Ford

Según reportó Bloomberg, Ford contrató a lo largo de unos tres años a más de 300 ingenieros con experiencia. Algunos eran ex empleados de la compañía y otros venían de sus proveedores. Su misión: ayudar a resolver los problemas de calidad que los sistemas automatizados no lograban resolver solos.

Charles Poon, vicepresidente de ingeniería de hardware de vehículos de Ford, lo explicó con una franqueza poco habitual en un ejecutivo:

Por error, pensamos que con solo introducir la inteligencia artificial e ingresarle los requisitos de diseño, eso produciría un producto de alta calidad.

Y agregó una frase que resume el problema:

La inteligencia artificial es una herramienta fantástica, pero es tan buena como la información con la que la entrenas.

Los sistemas de Ford podían procesar enormes volúmenes de información. Lo que no tenían eran los años de experiencia, el conocimiento institucional y el criterio para anticipar problemas que los ingenieros veteranos habían acumulado.

El final de la historia importa

Sería fácil leer esto como un fracaso de la IA, pero la historia no termina ahí.

Ford no abandonó la inteligencia artificial. Los ingenieros que llegaron hoy capacitan a los equipos más jóvenes y ayudan a reentrenar las herramientas de IA con el conocimiento que les faltaba.

Los resultados se notaron. Ford quedó primera entre las marcas masivas en el estudio de calidad inicial de J.D. Power 2026, por primera vez desde 2010. Su CEO, Jim Farley, habló de ahorros de “cientos y cientos de millones de dólares” en garantías y llamados a revisión.

La lección, entonces, no es “la IA no sirve”. Es otra, más útil:

La IA funciona cuando se conecta con el conocimiento real de la organización. Sin él, solo procesa información más rápido.

El conocimiento que no está en ningún archivo

El caso de Ford muestra algo que cualquier organización con años de historia reconoce: el conocimiento crítico no siempre está guardado en archivos, paneles de control o datos de entrenamiento.

Está en otras partes:

  • En las decisiones que se tomaron hace años y cuyas razones nadie escribió.
  • En las excepciones que todo el equipo conoce pero ningún documento menciona.
  • En la intuición de quien ya vio fallar algo parecido y sabe dónde mirar.
  • En las dependencias entre sistemas que solo se descubren cuando algo se rompe.

Ford le entregó a su IA los requisitos de diseño, pero los requisitos no contaban toda la historia. Faltaba el contexto.

En desarrollo de software ocurre exactamente lo mismo

Hoy la IA puede escribir código muy rápido. Pero para escribir el código correcto necesita saber cosas que casi nunca están en el requerimiento:

  • Las reglas del negocio, incluidas las que nunca se documentaron.
  • Los sistemas que ya existen y qué se puede reutilizar.
  • Las dependencias: qué otros módulos, servicios o procesos se verán afectados por el cambio.
  • Los estándares técnicos de la organización.
  • El objetivo real del proyecto, que no siempre coincide con lo que dice la historia de usuario.

Sin ese contexto, la IA no ahorra tiempo: solo permite avanzar más rápido en la dirección equivocada. Y los errores de especificación son justamente los más caros, porque se descubren tarde, cuando el código ya está construido.

Por eso el problema no empieza en el código. Empieza antes: en el contexto y en la calidad de las especificaciones.

Dos lecciones de Ford que aplican a cualquier SDLC

  1. Los requisitos no bastan: hace falta el contexto. Ford le dio a su IA los requisitos de diseño y no fue suficiente. En software pasa lo mismo cuando un agente trabaja solo con la historia de usuario. Necesita conocer el sistema real sobre el que va a actuar.
  2. La experiencia no se reemplaza: se integra al proceso. Ford no resolvió el problema reemplazando la IA por personas ni las personas por IA. Lo resolvió poniendo a las personas con experiencia en el centro del proceso, entrenando las herramientas y validando sus resultados.

Cómo lo abordamos en Tinet: Suite Loica

Suite Loica nació de estas mismas dos lecciones.

Primero, el contexto. La base de Loica es la KDB, la memoria de la empresa. Guarda el código, las reglas y las decisiones de la organización, se actualiza sola cada vez que cambia el código y vive solo en la infraestructura del cliente. Combina búsqueda sobre código, documentación y tickets con un grafo que modela cómo se relacionan los módulos, las APIs y los datos.

Sobre esa base, GenDEV transforma una idea de negocio en una especificación técnica conectada al sistema real: qué ya existe, qué se puede reutilizar y qué se verá afectado. No especifica a ciegas desde el requerimiento, como hizo Ford con los requisitos de diseño, sino desde el conocimiento completo del sistema.

Después de programar, GenQA prueba la aplicación como lo haría un usuario y deja evidencia en fotos y video de cada prueba.

Segundo, las personas. En cada etapa hay alguien del equipo que revisa y aprueba. Loica propone y el criterio profesional decide. La experiencia de sus equipos no queda fuera del proceso: es el control que asegura que lo que avanza es correcto.

El resultado es un flujo trazable, desde el requerimiento hasta la especificación, el código y la validación, donde cada paso deja registro de quién lo pidió, para qué y quién lo aprobó.

Tres preguntas para hacerse esta semana

  1. ¿Qué sabe su equipo que sus sistemas no saben? Pídale a sus personas más experimentadas que listen las reglas, excepciones y riesgos que conocen y que no están documentados. Esa lista es el contexto que le falta a su IA.
  2. ¿Con qué información trabajan hoy sus herramientas de IA? Si solo reciben el requerimiento o el ticket, están trabajando con la mitad de la historia.
  3. ¿Dónde participa la experiencia en su proceso con IA? Si las personas solo revisan al final, llegan tarde. El criterio tiene que estar presente en cada etapa.

Para cerrar

Ford no aprendió que la IA sea inútil. Aprendió que la IA es tan buena como el conocimiento al que tiene acceso, y que ese conocimiento muchas veces vive en las personas.

Adoptar IA en el desarrollo de software no consiste en generar más código. Consiste en generar el código correcto. Y para eso la IA necesita conocer su negocio tan bien como sus mejores personas.

En Tinet construimos Suite Loica con esa convicción. Si quiere ver cómo se aplicaría en su organización, le proponemos 45 minutos con nuestro equipo, sobre su código real y sin presentaciones. La primera conversación es un diagnóstico, no una demo.

Fuentes: Bloomberg, BBC, Fox Business, TechCrunch y Forbes (junio de 2026).

Leer el siguiente

Claude dejó algo claro: el problema ya no es detectar vulnerabilidades Artículo

Claude dejó algo claro: el problema ya no es detectar vulnerabilidades

El problema es corregirlas a tiempo y sin romper nada en el camino. Anthropic lanzó Project Glasswing el 7 de abril de 2026. Un mes después, sus más de 50 socios —entre ellos JP Morgan Chase, Cloudflare, Visa, AWS, Google y NVIDIA— ya habían usado Claude Mythos Preview e identificaron más de 10.000 vulnerabilidades de severidad alta o crítica en el software.