CEO de Coinbase despide ingenieros por no usar herramientas de IA
Brian Armstrong lo contó en un podcast y abrió el debate: ¿adopción obligatoria o dependencia peligrosa en el software?
La inteligencia artificial ya no es “algo extra” en el desarrollo de software: para muchas empresas es parte del flujo diario, desde autocompletado hasta generación de pruebas y refactors. Pero cuando la adopción deja de ser recomendación y se convierte en condición de empleo, la conversación cambia por completo. Eso fue exactamente lo que encendió la controversia alrededor de Coinbase y su CEO, Brian Armstrong.
El caso es incómodo por dos razones al mismo tiempo. Por un lado, muestra lo rápido que se está moviendo la industria: si tu equipo ignora herramientas que aumentan productividad, puedes quedarte atrás. Por el otro, pone sobre la mesa una preocupación válida: si “usar IA” se mide como cumplimiento (y no como calidad, seguridad y criterio), el incentivo puede ser hacer más… sin garantizar hacerlo mejor.
Qué pasó en Coinbase (y por qué explotó)
Brian Armstrong contó en el podcast “Cheeky Pint” (de John Collison, cofundador y presidente de Stripe) que Coinbase compró licencias empresariales para asistentes de código como GitHub Copilot y Cursor para cubrir a todos los ingenieros.
Según Armstrong, dentro de la empresa le dijeron que la adopción sería lenta y que tomaría meses lograr que “la mitad” del equipo los usara.
Su reacción fue imponer un mandato: pidió que todos “al menos hicieran el onboarding” a la herramienta antes de que terminara la semana, y anunció una reunión en sábado con quien no lo hubiera hecho para entender por qué.
En esa llamada, Armstrong dijo que algunas personas sí tenían motivos razonables (por ejemplo, vacaciones), pero que otras no, y que esas fueron despedidas.
También reconoció que fue un enfoque “heavy-handed” (duro o excesivo) y que a algunos dentro de la compañía no les gustó.
Más allá del morbo del “sábado de despidos”, el mensaje fue directo: en Coinbase, la IA para programar no era opcional.
Armstrong añadió que desde entonces han reforzado la capacitación y que hacen reuniones mensuales donde equipos comparten formas creativas de usar IA y lo aprendido.
La controversia real: productividad vs. dependencia
Para muchas personas, despedir a alguien por no “subirse” a una herramienta en una semana suena como una cultura de presión más que una cultura de excelencia. Y aunque se entienda el objetivo (mover a la organización), la crítica central es simple: eso no es algo de lo que estar orgulloso si el criterio es cumplimiento rápido en lugar de madurez técnica.
Incluso en el mismo podcast, John Collison cuestionó el fondo del asunto: una cosa es que la IA ayude a escribir código, y otra es cómo se opera una base de código “IA-escrita” a gran escala.
Armstrong respondió que estaba de acuerdo con esa preocupación.
Ese intercambio es clave, porque muestra que el debate no es “IA sí o IA no”, sino “¿qué tipo de ingeniería estás construyendo cuando la generación automática se vuelve normal?”. En cripto, además, el riesgo reputacional y financiero de un bug es brutal: errores en sistemas que mueven dinero cuestan más que cualquier ahorro de tiempo.
Riesgos técnicos cuando la IA se vuelve mandato
Obligar “uso de IA” sin una definición operativa suele crear métricas equivocadas. Si tu objetivo es “que la gente use Copilot/Cursor”, puedes terminar midiendo actividad y no resultados: commits más grandes, PRs más rápidos, más líneas… sin un aumento real de confiabilidad.
Estos son los riesgos más comunes cuando la adopción se acelera sin barandales:
- Código correcto “a primera vista”, pero frágil: la IA puede proponer soluciones plausibles que pasan revisión superficial, pero fallan en bordes, concurrencia, o integraciones.
- Deuda técnica silenciosa: refactors automáticos sin un criterio de arquitectura pueden dispersar patrones, duplicar lógica o erosionar límites entre módulos.
- Seguridad y compliance: sin reglas claras, los prompts pueden incluir contexto sensible (tokens, datos de clientes, información interna), o se puede incorporar código con licenciamiento dudoso.
- Pérdida de aprendizaje: si el equipo junior solo “acepta sugerencias”, baja la comprensión profunda; y si el equipo senior solo “acelera”, baja el tiempo dedicado a diseño.
La ironía es que una empresa puede “ganar velocidad” y a la vez perder control. En otras palabras: el riesgo no es usar IA, el riesgo es convertir la IA en sustituto del pensamiento crítico y del proceso de calidad.
Cómo adoptar IA sin romper tu ingeniería
Si eres líder técnico, dueño de producto o director de una PyME con equipo de desarrollo (interno o externo), la lección útil no es copiar el estilo “mano dura”. La lección es diseñar un sistema donde la IA aumente capacidades, pero el negocio conserve el control.
Un enfoque práctico (y defendible) suele incluir:
- Política de uso de IA por niveles: qué se permite (tests, refactors pequeños, documentación), qué requiere revisión extra (auth, pagos, permisos), qué se prohíbe (copiar secretos, datos personales, llaves API).
- Revisión de código más estricta en zonas críticas: no para frenar al equipo, sino para asegurar trazabilidad, criterios de aceptación y pruebas.
- Estándares de PR: pedir contexto, decisiones y riesgos; si una IA generó algo relevante, que el autor explique “por qué” y “qué validó”.
- “Human-in-the-loop” real: no como frase bonita, sino como responsabilidades claras (quién aprueba, con qué checklist, con qué evidencias).
- Capacitación enfocada: enseñar prompting útil para ingeniería (pruebas, amenazas, edge cases) y también “cuándo NO usar IA”.
Ejemplo rápido: si un dev usa IA para generar pruebas unitarias, perfecto; pero el estándar debe exigir que esas pruebas realmente fallen cuando deben fallar (pruebas mutantes, casos límite, inputs inválidos) y que cubran invariantes del dominio.
Qué significa para tu negocio (especialmente en México)
En México (y en Sinaloa en particular), muchas empresas están en una etapa donde quieren digitalizar ventas, inventario, logística, facturación o atención al cliente. En ese contexto, la IA puede acelerar el desarrollo, pero tu prioridad debería ser otra: confiabilidad y continuidad operativa.
Si estás por contratar una agencia o armar un equipo, pregunta cosas concretas:
- ¿Qué reglas tienen para uso de IA con datos del negocio?
- ¿Cómo hacen code review y pruebas (unitarias, integración, regresión)?
- ¿Qué hacen para evitar dependencias frágiles o “parches rápidos”?
- ¿Cómo documentan decisiones para que el sistema sea mantenible?
Porque al final, el verdadero costo no está en “cuántas horas tardan” sino en lo que pasa después: caídas, errores de cobro, fugas de datos, o sistemas imposibles de mantener.
¿Quieres implementar software y automatizaciones con IA sin poner en riesgo tu operación?
En www.SiteSupremacy.com te ayudamos a construir soluciones digitales con enfoque en calidad, seguridad y escalabilidad.
Conoce cómo podemos apoyarte en www.sitesupremacy.com