Empleados de Google: ‘nuestra IA para código apesta’

¿Qué está pasando realmente dentro de Google con sus herramientas de IA?

La brecha entre el discurso oficial de Google sobre productividad impulsada por IA y la experiencia real de sus propios ingenieros se ha hecho viral… dentro de la propia empresa. Según reveló 404 Media, empleados de Google han estado compartiendo memes internos criticando abiertamente la eficacia de las herramientas de IA generativa de la compañía para programación.

Los memes no son una simple broma de pasillo: reflejan una frustración concreta. Los ingenieros señalan que el código generado por los modelos internos de Google inventa métricas, produce código de baja calidad y aumenta la carga de revisión humana, contradiciendo directamente la narrativa corporativa de que la IA está revolucionando la productividad en desarrollo de software.

Google ha reportado que más del 30% del código nuevo en la compañía ya es generado por IA. Pero la pregunta que los memes internos plantean es: ¿a qué costo en calidad y deuda técnica?

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

¿Qué dicen exactamente los empleados de Google sobre su propia IA?

Las críticas internas tienen varios ejes. El primero y más recurrente: los modelos de IA para código de Google son percibidos como inferiores a Claude, el modelo de Anthropic. Según reportó Business Insider, algunos empleados sienten que los modelos internos "no son tan buenos como Claude para programar", y que el acceso a herramientas externas está limitado a ciertos equipos de DeepMind, mientras que el resto de los ingenieros debe conformarse con Gemini y las herramientas internas.

Este acceso desigual ha generado tensiones. Mientras la dirección presiona para adoptar IA en el día a día —incluyendo el llamado "vibe coding"—, los equipos sin acceso a modelos que consideran superiores sienten que están en desventaja. El resultado: memes que circulan en canales internos señalando que la IA de Google, para ciertas tareas de código, está muy por detrás de la competencia.

Demis Hassabis, CEO de Google DeepMind, calificó las acusaciones de que sus equipos usan Claude como "completamente falsas" y "puro clickbait". Pero que el propio Hassabis haya tenido que salir a desmentirlo sugiere que el rumor tenía suficiente tracción interna como para requerir respuesta oficial.

¿Por qué importa esto para tu startup?

Si dentro de Google —con recursos ilimitados, modelos propios y equipos de investigación de clase mundial— los ingenieros están frustrados con la calidad del código generado por IA, ¿qué lecciones puede sacar un founder que depende de estas herramientas para escalar su startup?

La respuesta no es "deja de usar IA para código". Es más matizada: la calidad del output depende drásticamente del modelo, del contexto y del tipo de tarea. No todas las herramientas de IA generan código con el mismo nivel de confiabilidad, y asumir que sí lo hacen es una receta para la deuda técnica.

Para una startup, donde cada sprint cuenta y el tiempo de revisión humana es escaso, usar una herramienta de IA que inventa métricas o requiere correcciones constantes puede ser más dañino que beneficioso. El tiempo "ahorrado" generando código se pierde después revisándolo, depurándolo y reescribiéndolo.

¿Cómo evitar la deuda técnica al usar IA para programar?

1. Evalúa la herramienta correcta para tu stack. No asumas que porque un modelo es bueno para texto lo es para código. Según las quejas internas de Google, la diferencia entre modelos para tareas de programación es significativa. Prueba múltiples opciones —Claude, GPT, Gemini, Copilot, Cursor— en tu stack real antes de comprometerte.

2. Mide el costo de revisión, no solo la velocidad de generación. Establece métricas internas: ¿cuánto tiempo toma revisar y corregir el código generado por IA vs. escribirlo desde cero? Si la revisión supera el tiempo de escritura manual, la herramienta no está generando productividad real. Que el 30% del código nuevo sea generado por IA no es necesariamente un éxito si el 40% requiere reescritura.

3. Crea guías de uso para tu equipo. Define qué tareas puede hacer la IA sin supervisión y cuáles requieren revisión obligatoria. La deuda técnica generada por código de IA mal revisado se acumula rápido y es más difícil de detectar que la deuda humana, precisamente porque el código generado por IA suele verse "correcto" en superficie pero falla en los bordes.

4. Diversifica tus herramientas de IA. Así como Google descubrió que usar un solo proveedor limita la calidad en ciertas tareas, tu startup debería evaluar si usar exclusivamente una herramienta es óptimo. El costo de tener dos suscripciones de IA puede ser menor que el costo de la deuda técnica generada por una herramienta inadecuada.

¿Cuál es la lección para founders sobre adopción de IA?

Lo que revela la situación en Google es una tensión que se replica en startups y grandes empresas por igual: la presión por mostrar adopción de IA choca con la realidad de que las herramientas aún tienen limitaciones significativas. Google aumentó la presión sobre sus empleados para usar IA en codificación, pero sin garantizar que las herramientas internas estuvieran al nivel de las mejores del mercado.

Para un founder, la lección es clara: la adopción de IA no es un fin en sí mismo. El objetivo no debería ser "cuánto código genera la IA" sino "cuánto valor neto aporta". Medir el porcentaje de código generado por IA sin medir su calidad, su tasa de errores y el costo de revisión es como medir la velocidad de un coche sin preguntar cuánto combustible consume o cada cuánto se rompe.

El caso de Google también muestra que incluso las empresas que construyen la tecnología tienen dificultades para implementarla bien. Si los propios ingenieros de Google se quejan de la calidad, ¿qué está pasando en startups que no tienen acceso a los mejores modelos ni a los investigadores que los crearon?

Conclusión

Los memes internos de Google no son solo una anécdota para consumir en redes sociales. Son un síntoma de una desconexión real entre la promesa de la IA generativa y su implementación práctica en el desarrollo de software. Para el founder que construye su startup sobre estas herramientas, la lección es doble: úsalas, pero con los ojos abiertos. Prueba, mide, y nunca delegues ciegamente la calidad de tu código a un modelo que ni siquiera satisface a sus propios creadores.

Fuentes