El acuerdo de talento entre Google y Mechanize parece completado, pero su verdadera prueba es mejorar la programación con IA
Google parece haber completado el acuerdo de talento con Google Mechanize, y según los informes, un cofundador y más de una docena de empleados se han incorporado a DeepMind. La evidencia procede de perfiles profesionales públicos, no de un anuncio formal. Esta distinción hace creíbles los movimientos de personal, aunque deja sin verificar los términos finales de la transacción.
Business Insider informó previamente que Google estaba negociando un acuerdo de alto valor para contratar empleados de Mechanize y licenciar su tecnología. Su más reciente información sobre el acuerdo de talento señala que los traslados ya se han producido. El ex CEO de Mechanize, Tamay Besiroglu, figura presuntamente como científico investigador en Google DeepMind.
No se trata simplemente de otra ronda de contratación en IA. Mechanize desarrolla entornos y evaluaciones para entrenar agentes de programación en tareas de software complejas. Por lo tanto, Google está incorporando especialistas que ayudan a determinar dónde falla un agente, no solo ingenieros que hacen los modelos más grandes.
Ese enfoque sitúa al acuerdo en competencia directa con Anthropic y OpenAI. Ambas empresas han convertido la programación en una prueba visible de si la IA de propósito general puede realizar trabajo sostenido y económicamente valioso.
El acuerdo de talento entre Google y Mechanize también repite una estructura que Google utilizó con Character.AI y Windsurf. La empresa puede incorporar a investigadores importantes dentro de DeepMind mientras licencia tecnología seleccionada, sin adquirir toda la startup.
El movimiento inmediato de personal parece claro. El resultado estratégico sigue sin resolverse. Google debe demostrar ahora que el talento adicional en evaluación puede producir agentes de programación en los que los desarrolladores confíen para trabajar con repositorios reales, despliegues y depuración.
Qué cambia realmente con el acuerdo de talento entre Google y Mechanize
Google presuntamente ha asegurado la experiencia central de Mechanize, pero la evidencia pública no establece todos los términos comerciales.
Los perfiles públicos revisados por Business Insider muestran presuntamente que Besiroglu y más de una docena de antiguos empleados de Mechanize trabajan en DeepMind. Su trabajo indicado se centra en gran medida en el entrenamiento intermedio, la fase de desarrollo del modelo situada entre el preentrenamiento amplio y el refinamiento final específico para tareas.
Esta concentración importa. El entrenamiento intermedio puede exponer un modelo a tareas estructuradas, herramientas y retroalimentación antes de que comience el posentrenamiento más específico. Ofrece a los investigadores otro espacio para desarrollar los comportamientos necesarios para proyectos de software largos.
Ni Google ni Mechanize han publicado un anuncio detallado de la transacción. Ningún documento público identifica exactamente qué propiedad intelectual licenció Google, si la licencia es exclusiva o qué obligaciones siguen correspondiendo a Mechanize.
Por tanto, la evidencia disponible respalda una conclusión prudente. La transferencia de talento parece completada, mientras que la arquitectura legal y financiera del acuerdo sigue sin divulgarse.
Mechanize fue fundada en abril de 2025 por Besiroglu, Matthew Barnett y Ege Erdil. Su anuncio de la empresa describía un plan para crear entornos de trabajo simulados, benchmarks y datos de entrenamiento para sistemas de IA.
Los fundadores plantearon la ingeniería de software como un objetivo inicial dentro de un esfuerzo más amplio por automatizar trabajo valioso. Ese objetivo atrajo atención porque vinculaba los benchmarks de programación con una afirmación económica mucho mayor.
Los materiales actuales de Mechanize describen entornos en los que los agentes crean funciones, despliegan aplicaciones y depuran bases de código desconocidas. Un evaluador califica el trabajo resultante, generando retroalimentación para el aprendizaje por refuerzo y la evaluación de modelos.
El aprendizaje por refuerzo es un entrenamiento guiado por resultados puntuados. En este contexto, un agente recibe retroalimentación según si su software funciona realmente, en lugar de si su respuesta simplemente parece plausible.
Esto da a la contratación reportada un significado más específico. Google no ha añadido simplemente otro equipo de interfaces de programación. Ha reclutado a personas que diseñan tareas, sistemas de retroalimentación y mediciones de fallos para agentes autónomos.
La distinción importa porque escribir una función breve ya no es el desafío definitorio. Los agentes de programación modernos deben inspeccionar repositorios, planificar cambios, usar herramientas, ejecutar pruebas y recuperarse cuando falla una suposición inicial.
El trabajo de Mechanize se dirige a esas secuencias más largas. Sus ingenieros crean entornos controlados donde los fallos pueden observarse y calificarse. Esos entornos pueden convertirse en infraestructura de entrenamiento cuando se conectan con el aprendizaje por refuerzo.
Sin embargo, una transferencia de personal no garantiza que los métodos de Mechanize se integren sin dificultades en Google. Los sistemas internos de datos, las arquitecturas de modelos, los requisitos de seguridad y los calendarios de lanzamiento pueden alterar la manera en que se utiliza un marco de evaluación.
El primer cambio confirmado es organizativo. Google DeepMind parece emplear ahora a un grupo concentrado con experiencia en el diseño de entornos para agentes de programación. Determinar si ese grupo modifica el rendimiento de Gemini requerirá evidencia de producto y benchmarks.
Google está adquiriendo experiencia en evaluación, no solo más creadores de modelos
El premio estratégico es un ciclo más rápido entre descubrir fallos de los agentes y entrenar modelos para evitarlos.
Los productos de programación con IA compiten en algo más que la calidad del código generado. También compiten en planificación, uso de herramientas, persistencia, verificación y capacidad para trabajar dentro de procesos de ingeniería existentes.
Un modelo puede generar un fragmento impresionante y aun así fallar como agente. Podría malinterpretar un repositorio, editar el módulo equivocado, pasar por alto pruebas o abandonar una tarea al encontrar un sistema de compilación desconocido.
Los entornos de evaluación hacen medibles esos fallos. Sitúan a un agente dentro de un espacio de trabajo controlado, le asignan una tarea, registran sus acciones y califican el resultado final.
Mechanize afirma que sus entornos abarcan trabajo práctico de software, como implementar funciones y diagnosticar código desconocido. Sus entornos de programación están diseñados para generar señales tanto para la evaluación como para el aprendizaje por refuerzo.
Esa combinación es valiosa porque la evaluación y el entrenamiento pueden formar un ciclo de retroalimentación. Los investigadores identifican una debilidad, construyen tareas que la exponen, recopilan intentos de agentes y entrenan a partir de las puntuaciones resultantes.
El proceso parece sencillo, pero crear entornos útiles es difícil. Las tareas deben ser lo bastante realistas para importar, lo bastante estables para repetirse y resistentes a atajos que inflen las puntuaciones.
Un benchmark débil puede recompensar comportamientos superficiales. Un agente podría explotar un evaluador, memorizar soluciones públicas u optimizar para pruebas que representan deficientemente el trabajo de software en producción.
El proyecto más visible de Mechanize ilustra tanto el atractivo como la limitación de este enfoque. GBA Eval pide a un agente crear un emulador de Game Boy Advance con Rust y WebAssembly.
La tarea es larga, técnica y fácil de evaluar mediante el comportamiento funcional. La metodología del benchmark compara resultados mediante pruebas de reproducción, procedimentales y de audio.
Un desafío de emulación exige arquitectura, depuración, compilación y verificación repetida. Por ello, revela capacidades que las preguntas de programación más pequeñas rara vez ponen a prueba.
Sin embargo, una tarea exigente no puede representar toda la ingeniería de software. El desarrollo empresarial también implica requisitos poco claros, dependencias heredadas, revisiones de seguridad, comunicación de equipo y prioridades cambiantes.
La oportunidad de Google consiste en ampliar el método subyacente. DeepMind puede construir entornos variados, ejecutarlos con modelos internos y conectar los resultados a canales de entrenamiento con grandes recursos de computación.
El equipo transferido trabaja presuntamente en entrenamiento intermedio, lo que encaja con esa estrategia. En lugar de esperar a que un modelo terminado falle en un producto público, los investigadores pueden introducir antes experiencias estructuradas para agentes.
Este es el mecanismo central detrás del acuerdo de talento entre Google y Mechanize. Mejores entornos pueden producir mejor retroalimentación, y una mejor retroalimentación puede mejorar la forma en que los agentes actúan en tareas largas.
El mecanismo no es automático. Entrenar con un entorno puede sobreajustar un modelo a ese entorno. Una puntuación puede aumentar sin producir mejoras equivalentes en repositorios desconocidos.
Por ello, Google debe demostrar transferencia: que las mejoras aprendidas en tareas controladas continúan cuando el agente se encuentra con nuevas herramientas, lenguajes y restricciones organizativas.
Eso es más difícil que ganar una clasificación. Requiere evaluaciones privadas, despliegues controlados y evidencia de que los ingenieros dedican menos tiempo a corregir o supervisar al agente.
Si DeepMind logra esa transferencia, la experiencia de Mechanize podría mejorar más que un producto de programación. Las mismas técnicas de creación de entornos pueden respaldar agentes que operen navegadores, hojas de cálculo, bases de datos y otras herramientas de trabajo.
Por ahora, la programación sigue siendo el terreno de prueba más creíble. Las tareas de software generan artefactos observables, mientras que los compiladores y las pruebas ofrecen una retroalimentación más clara que muchas actividades de trabajo del conocimiento.
Eso hace que Mechanize sea relevante para Google hoy, incluso si la ambición original de la startup iba mucho más allá. La programación ofrece un puente medible entre la investigación de modelos y los productos que los clientes ya utilizan.
Anthropic y OpenAI marcan el ritmo competitivo
Google está bajo presión porque la programación se ha convertido en una carrera de productos, no en una demostración lejana de inteligencia de modelos.
Claude Code de Anthropic y Codex de OpenAI han ayudado a llevar la programación con IA del autocompletado al trabajo delegado. Los desarrolladores esperan cada vez más que un agente inspeccione archivos, ejecute comandos e itere ante fallos.
Google cuenta con sus propios modelos, infraestructura, relaciones con desarrolladores y productos de programación. Sin embargo, esos activos no eliminan la necesidad de una experiencia de agente que los ingenieros elijan voluntariamente.
La adopción por parte de los desarrolladores crea un ciclo de retroalimentación exigente. Los usuarios frecuentes descubren rápidamente casos límite, comparan resultados entre modelos y abandonan herramientas que requieren demasiada supervisión.
Esto da ventaja a Anthropic y OpenAI cuando sus productos atraen un uso sostenido. Cada repositorio difícil y cada tarea fallida pueden revelar dónde deben mejorar los modelos, las interfaces o los sistemas de evaluación.
La respuesta de Google ha incluido desarrollo interno y contratación externa de talento. Las incorporaciones de Mechanize suman especialistas centrados en construir las pruebas y los entornos que sustentan ese ciclo de mejora.
El acuerdo sigue a la contratación anterior por parte de Google de líderes e investigadores de Windsurf. En 2025, Google contrató para DeepMind al CEO de Windsurf, Varun Mohan, al cofundador Douglas Chen y a otros empleados.
Google también recibió una licencia no exclusiva para tecnología seleccionada de Windsurf. Un comunicado de contratación confirmada señaló que los nuevos empleados impulsarían el trabajo de DeepMind en programación agéntica.
Windsurf aportó experiencia en la creación de un producto orientado a desarrolladores. Mechanize aporta un enfoque complementario en entornos de entrenamiento, evaluación y comportamiento de agentes a largo plazo.
Juntos, esos grupos dan a Google experiencia en dos capas críticas. Una se refiere al producto con el que interactúan los desarrolladores. La otra se refiere a los sistemas de retroalimentación utilizados para mejorar el agente subyacente.
Aun así, reunir equipos no elimina los costos de integración. Los investigadores que llegan mediante transacciones separadas deben alinearse en torno a modelos, infraestructura, liderazgo y objetivos de producto compartidos.
Anthropic y OpenAI también siguen mejorando sus productos. Google no busca alcanzar un referente estático, y una integración tardía puede hacer que la empresa persiga capacidades que sus competidores ya han ampliado.
La presión va más allá de los asistentes de programación individuales. Un agente exitoso puede influir en qué modelo encuentran primero los desarrolladores, qué plataforma en la nube procesa las cargas de trabajo y qué proveedor entra en los procesos de ingeniería empresariales.
Los agentes de programación también crean oportunidades para una integración más profunda de las plataformas. Pueden conectar el uso de modelos con repositorios, sistemas de despliegue, herramientas de seguridad y servicios en la nube.
Esa posición hace que la confianza de los desarrolladores sea especialmente valiosa. Una vez que un equipo configura permisos, flujos de trabajo y estándares de revisión en torno a un agente, cambiar implica más que elegir otro modelo.
Por lo tanto, Google necesita un producto que funcione de forma fiable en todo el ciclo de desarrollo. Las puntuaciones brutas en benchmarks pueden atraer atención, pero el comportamiento repetible determina si los equipos amplían el acceso.
El enfoque reportado del equipo de Mechanize en el entrenamiento intermedio aborda una parte de ese problema. Una mejor exposición a tareas puede mejorar un modelo antes de que comience el ajuste específico para productos.
Las contrataciones de Windsurf abordan otra parte. Los creadores de productos entienden la latencia, las interfaces, la gestión de contexto y los detalles operativos que afectan al uso diario.
La tesis competitiva de Google parece combinar ambos grupos. DeepMind puede conectar infraestructura de evaluación, entrenamiento de modelos y un agente orientado a desarrolladores dentro de una misma organización.
Esa estructura aumenta la capacidad de Google. No establece liderazgo. Anthropic y OpenAI siguen siendo los puntos de referencia con los que los desarrolladores juzgarán cualquier lanzamiento resultante.
Las adquisiciones inversas concentran talento, pero dejan importantes preguntas sin responder
La estructura del acuerdo permite a Google avanzar con rapidez, al tiempo que traslada la incertidumbre a la startup, sus inversores, clientes y empleados restantes.
Una adquisición inversa ocurre cuando una empresa más grande contrata a los líderes y a parte del personal de una startup, mientras licencia la tecnología en lugar de comprar todo el negocio.
Google ya ha utilizado estructuras relacionadas. Su acuerdo con Character.AI llevó a cofundadores e investigadores de vuelta a Google, al tiempo que proporcionaba acceso a la tecnología mediante una licencia no exclusiva.
La transacción de Windsurf siguió un patrón similar. Google contrató a empleados sénior y licenció tecnología, mientras Windsurf seguía siendo una empresa independiente sin control de Google.
Otras empresas tecnológicas han adoptado acuerdos comparables. Microsoft reclutó líderes de Inflection, Amazon contrató a ejecutivos e investigadores de Adept y Meta combinó una inversión en Scale AI con transferencias de personal sénior.
Estas transacciones pueden cerrarse más rápido que una adquisición convencional. También permiten al comprador centrarse en las personas y los activos técnicos que considera más valiosos.
Los reguladores ya han examinado este patrón más amplio. Un informe del personal de la FTC estudió las inversiones y asociaciones de los principales proveedores de nube con desarrolladores de IA.
El informe no evaluó el posterior acuerdo de Mechanize. Sin embargo, identificó preocupaciones de competencia más amplias relacionadas con el acceso al talento, la tecnología, los recursos de computación y la información sensible.
El acuerdo de talento entre Google y Mechanize encaja en ese debate de políticas incluso sin una adquisición divulgada. Los empleados clave de una startup pueden pasar a una empresa establecida mientras la entidad corporativa permanece fuera de la transacción.
Ese resultado puede reducir la capacidad de la startup para competir de forma independiente. El conocimiento técnico reside en parte en el código y la documentación, pero también vive en gran medida dentro del equipo que diseñó el sistema.
Por consiguiente, el futuro de Mechanize es una de las mayores preguntas sin respuesta. Su sitio web puede seguir activo, pero la continuidad pública no establece independencia operativa ni una hoja de ruta de producto viable.
Los otros cofundadores de la empresa plantean otro punto sin resolver. La información pública identifica el traslado de Besiroglu y el movimiento de más de una docena de empleados, pero no explica plenamente el papel de cada fundador.
Los clientes y socios de investigación también necesitan claridad. Deben saber quién mantiene las herramientas existentes, controla los datos, opera los sistemas de evaluación y proporciona soporte tras los cambios de personal.
Una licencia tecnológica no exclusiva puede preservar la capacidad formal de la startup para trabajar con otras empresas. La independencia práctica se vuelve más difícil si los empleados que crearon la tecnología se han marchado.
Google también enfrenta riesgos internos. Una contratación concentrada aporta experiencia, pero integrar personas mediante una transacción especial puede crear incentivos distintos de los de la contratación ordinaria.
Los empleados necesitan autoridad clara, acceso a infraestructura y una vía para trasladar la investigación a productos desplegados. Sin esas condiciones, el conocimiento valioso puede quedar aislado dentro de una organización más grande.
También existe una disyuntiva más amplia para el mercado. Las adquisiciones inversas pueden devolver capital y preservar la competencia formal mientras desplazan especialistas escasos hacia las empresas con mayores recursos.
Repetido en todo el sector, ese patrón puede reducir el número de laboratorios independientes capaces de desafiar a los principales proveedores de modelos.
La alternativa no es sencilla. Las startups que construyen infraestructura avanzada de entrenamiento necesitan computación costosa, clientes fiables y acceso a modelos de frontera. Una gran plataforma puede proporcionar las tres cosas.
Los fundadores de Mechanize también eligieron una misión inusualmente amplia. Aspirar a la automatización completa del trabajo exige más recursos y distribución de los que la mayoría de las empresas jóvenes pueden conseguir por sí solas.
Unirse a DeepMind puede acelerar partes de ese trabajo. También puede redirigir al equipo hacia las prioridades de Google, especialmente las capacidades de programación que respaldan Gemini y productos relacionados.
Por tanto, el valor de la transacción depende de la perspectiva. Google obtiene investigadores experimentados, mientras que la trayectoria independiente original de Mechanize se vuelve menos cierta.
La atención regulatoria no demostraría una conducta indebida. Plantearía si la estructura produce sustancialmente el mismo efecto competitivo que una adquisición sin recibir una revisión equivalente.
Esa pregunta persistirá a medida que más startups de IA se dividan en dos partes: personal valioso que pasa a una empresa establecida y una compañía restante responsable de todo lo que queda atrás.
Mejores benchmarks aún no pueden garantizar mejor software
La experiencia de Mechanize en evaluación puede mejorar el entrenamiento, pero ningún benchmark por sí solo demuestra que un agente sea fiable en producción.
Los benchmarks de programación condensan una actividad complicada en tareas medibles. Eso hace visible el progreso, pero toda condensación deja detalles importantes fuera de la puntuación.
Un entorno controlado suele especificar el repositorio, las herramientas, el límite de tiempo y las pruebas de éxito. Los equipos reales de ingeniería operan con requisitos incompletos, dependencias ocultas y restricciones organizativas cambiantes.
El software de producción también conlleva consecuencias que las tareas de benchmark evitan. Un parche aparentemente plausible puede exponer datos, romper la compatibilidad, aumentar los costes o crear fallos que aparecen semanas después.
Por tanto, los agentes deben hacer más que alcanzar un resultado aprobado. Deben comunicar supuestos, respetar permisos, preservar la mantenibilidad y producir evidencia que los revisores puedan evaluar.
Los entornos de Mechanize pueden ayudar a probar algunos de estos comportamientos. La empresa puede crear tareas que impliquen código desconocido, despliegues, depuración y ejecución de varios pasos.
Sin embargo, el sistema de calificación determina lo que el modelo aprende a valorar. Si un evaluador recompensa únicamente las pruebas aprobadas, el modelo tiene pocos incentivos para producir diseños claros o decisiones operativas seguras.
Los investigadores pueden añadir comprobaciones de seguridad, métricas de calidad de código y pruebas ocultas. Cada incorporación mejora la cobertura, pero también introduce otro indicador indirecto que los agentes pueden aprender a explotar.
La contaminación de benchmarks crea un problema relacionado. Las tareas públicas, las soluciones y los debates pueden entrar en los datos de entrenamiento, haciendo que modelos posteriores parezcan más capaces sin haber aprendido habilidades generales de resolución de problemas.
Las evaluaciones privadas y renovadas continuamente reducen esa exposición. También dificultan la verificación independiente porque los investigadores externos no pueden inspeccionar las tareas ni reproducir las puntuaciones.
Google debe equilibrar ambas necesidades. Los entornos internos pueden guiar el entrenamiento, mientras que las evaluaciones públicas permiten a los desarrolladores comparar las afirmaciones con evidencia observable.
La tarea del emulador GBA ofrece un ejemplo útil. Evalúa ejecución prolongada, compilación, depuración y corrección funcional dentro de un proyecto claramente delimitado.
Superar ese desafío sería significativo. No demostraría que un agente pueda migrar de forma segura una base de datos financiera, revisar un cambio de autenticación o negociar requisitos poco claros con un gerente de producto.
La evidencia más sólida procederá de varias capas. Los benchmarks públicos pueden mostrar progreso técnico, las evaluaciones privadas pueden detectar debilidades no reveladas y los despliegues controlados pueden medir el valor práctico.
Los resultados de los clientes deben completar el panorama. Los equipos deberían examinar tasas de finalización, tiempo de revisión, frecuencia de regresiones, hallazgos de seguridad y la frecuencia con la que los ingenieros deben reiniciar tareas fallidas.
Google tiene suficiente distribución para generar esa evidencia rápidamente. Puede implementar agentes de programación en proyectos internos, entornos de nube y productos para desarrolladores.
La escala también introduce riesgos. Una tasa de error menor puede volverse significativa cuando un agente produce grandes volúmenes de cambios en muchos repositorios.
La revisión humana sigue siendo esencial para código de alto impacto. La pregunta relevante es si el agente reduce el trabajo total una vez incluidas la revisión, las pruebas y las correcciones.
Ese estándar es más estricto que contar sugerencias aceptadas. Un ingeniero podría aceptar código generado y aun así dedicar un tiempo considerable a entenderlo, repararlo o documentarlo.
Las contrataciones reportadas de Mechanize deberían ayudar a Google a diseñar pruebas más exigentes. No pueden eliminar la necesidad de un despliegue cuidadoso y una medición transparente.
Por eso la transacción no debe tratarse como prueba de que Google ha resuelto la programación agéntica. Es una inversión en la maquinaria utilizada para descubrir y corregir fallos.
La visión escéptica es directa. Google puede mejorar puntuaciones dentro de entornos moldeados por el equipo entrante sin lograr una fiabilidad equivalente en trabajo de clientes desconocido.
La visión optimista también es creíble. Un equipo dedicado a entornos realistas puede llevar los modelos más allá de la programación de respuestas cortas y revelar debilidades antes de que los clientes las encuentren.
Ambas visiones conducen a la misma prueba. Google debe demostrar generalización entre repositorios, lenguajes, herramientas y flujos de trabajo que no fueron diseñados en torno a su sistema de entrenamiento.
Tres señales mostrarán si el acuerdo funcionó
La siguiente evidencia debería provenir de productos, evaluaciones independientes y las operaciones continuas de Mechanize, en ese orden.
La primera señal es un lanzamiento de un agente de programación de Google que refleje claramente el trabajo del equipo entrante. Una actualización significativa debería mejorar la ejecución sostenida, no limitarse a generar mejores fragmentos aislados.
Busque agentes que puedan inspeccionar grandes repositorios, planificar ediciones coordinadas, ejecutar pruebas, recuperarse de errores y explicar qué cambió. Google también debería describir cómo mide esos comportamientos.
Una conexión explícita con los nuevos entornos de entrenamiento reforzaría la idea de que la integración de Mechanize está produciendo resultados. Una actualización vaga del modelo aportaría evidencia mucho más débil.
La segunda señal es el rendimiento en evaluaciones independientes y de largo horizonte. Las puntuaciones controladas por Google pueden guiar el desarrollo, pero las pruebas externas son necesarias para una comparación creíble.
Ningún benchmark individual debería decidir el resultado. Los resultados deberían mantenerse sólidos en distintos repositorios, lenguajes de programación, herramientas y métodos de calificación.
La generalización importa más que una victoria espectacular en una única tarea pública. Si los agentes basados en Gemini mejoran en evaluaciones no relacionadas, el mecanismo detrás del acuerdo resultará más convincente.
Los desarrolladores también deberían comparar la fiabilidad, no solo la finalización. Un agente que completa más tareas mientras introduce regresiones sutiles genera una costosa carga de revisión.
La tercera señal es lo que ocurra con Mechanize. La continuidad de la investigación, los benchmarks mantenidos, las nuevas contrataciones y el trabajo activo con clientes indicarían que la empresa restante conserva una independencia significativa.
Una presencia pública cada vez menor sugeriría que la transacción funcionó más como una adquisición del núcleo operativo. Ese resultado intensificaría las dudas sobre las reverse acquihires.
Los roles de Barnett y Erdil también serán importantes. Su trabajo futuro puede aclarar si Mechanize sigue siendo una organización dirigida por sus fundadores o se convierte en una estructura debilitada en torno a activos bajo licencia.
La actividad regulatoria merece atención dentro de esta señal. Las solicitudes de información o de orientación normativa podrían influir en cómo Google y otras empresas estructuran futuros acuerdos de talento.
Para los desarrolladores, la respuesta práctica es la paciencia, no la indiferencia. El acuerdo de talento entre Google y Mechanize aporta experiencia creíble a DeepMind, pero las noticias organizativas no mejoran por sí solas un flujo de trabajo.
Evalúen los productos resultantes en repositorios que se parezcan a los propios. Hagan seguimiento del tiempo de revisión, las tareas fallidas, las regresiones, las solicitudes de permisos y la claridad de las explicaciones generadas.
Los compradores empresariales deberían preguntar cómo construyen los proveedores sus evaluaciones y cómo evitan el sobreajuste a los benchmarks. También deberían solicitar pruebas relacionadas con la seguridad, el mantenimiento y el código interno desconocido.
Los trabajadores del conocimiento deberían observar este experimento más amplio. Mechanize nació con una misión que iba más allá del software, y la programación ofrece la prueba más clara de esa tesis de automatización.
Si el entrenamiento guiado por entornos produce agentes de programación fiables, métodos similares se extenderán a otros trabajos realizados con computadoras. Si las mejoras siguen limitadas a los benchmarks, las afirmaciones más amplias sobre automatización necesitarán una revisión sustancial.
Google ha adquirido a las personas especializadas en crear esas pruebas. Ahora, las pruebas deben convertirse en productos fiables, y esos productos deben resistir trabajos para los que Google no los diseñó.
