Autor de gonzo_ML: en su equipo, solo los modelos escriben codigo; las personas lo revisan

Las historias sobre «pasarse a los agentes» suelen terminar con una presentacion impecable. Esta incluye una cronologia, cifras y una explicacion sincera de lo que no funciono. El autor del canal gonzo_ML cuenta como, entre 2024 y 2026, paso de «los modelos a veces completan algo de codigo» a «nadie del equipo programa a mano».

El umbral que cruzaron los modelos

Los primeros proyectos terminados del autor llegaron entre finales de 2024 y principios de 2025. Considera que fueron los modelos los que cruzaron un umbral, no que el se volviera mas atrevido. En enero de 2025, Gemini y Claude le prepararon el codigo del transformador, las intervenciones y la visualizacion de activaciones para un proyecto de curso sobre interpretabilidad.

En primavera, creo un servidor MCP para traducciones sin escribir, por principio, una sola linea a mano. Para diciembre, lo habia migrado a Streamable HTTP y llevado a produccion. Como suele ocurrir, la parte de produccion resulto mas voluminosa que la propia funcionalidad: el registro, la monitorizacion, la seguridad, la carga, la gestion de errores y el despliegue añadieron mas codigo que el nuevo transporte.

El enfoque de trabajo quedo asi: especificaciones con descomposicion de tareas, pruebas antes de la implementacion y ADR para las decisiones adoptadas. Todo empezo con speckit; ahora el equipo aplica estas practicas en Claude Code y ya no se trata de un esfuerzo individual.

Por que brownfield no funcionaba y luego si

En 2025, el autor intento entregar a los modelos el codigo de una plataforma con diez años de antiguedad. Las correcciones de errores y las pequeñas funciones salian «mal». Lo atribuyo al desarrollo brownfield. Mas tarde descubrio que la causa era otra: el contexto estaba en la cabeza de las personas, no en un lugar del que el agente pudiera obtenerlo.

Por eso, el equipo se centro en los fundamentos. Los modelos obtuvieron acceso a la documentacion de los repositorios y, mediante MCP, a Confluence; a los estandares y ADR; a las tareas, primero en Jira y despues en Linear; a los registros de produccion mediante MCP; y, cuando era necesario, a las conversaciones de Slack. Es decir, a todo lo que necesita una persona que acaba de incorporarse al proyecto. Ahora las personas asignan tareas y revisan, mientras que los agentes tambien se encargan de la revision inicial, la documentacion, los documentos de lanzamiento y las pruebas. La intervencion humana se produce en las puertas de calidad que requieren aprobacion.

El cuello de botella se desplazo. Escribir codigo ya no lleva mucho tiempo, pero la lectura humana final esta al limite. Todos mantienen varias sesiones de agentes: mientras uno escribe, en otra sesion se pueden leer los nuevos y extensos diffs.

Elegir lenguaje y Rust

Un efecto inesperado es que ahora se puede elegir el lenguaje en funcion de la tarea, no de las competencias del equipo. El primer candidato fue un servicio que emulaba API reales con todos sus problemas y que limitaba las pruebas de rendimiento. Se reescribio en Rust y, a modo de comparacion, tambien en Go y Node, con una prueba de paridad para las cuatro implementaciones.

En el mismo pod de 100 MB, Rust mantiene unas 8.900 conexiones abiertas, frente a aproximadamente 3.400 en el original escrito en Python. En reposo, ocupa 1 MiB en lugar de 33. Go con fasthttp solo supero a Python en un 11%, mientras que con el net/http estandar rindio el doble de mal. El autor matiza que las cifras proceden de un banco de pruebas local y que, bajo un modelo de desarrollo manual, nadie habria dedicado ni siquiera una semana a reescribir asi un servicio auxiliar.

No solo codigo

Otro ejemplo es un informe contable. Antes, el autor revisaba cada año el trabajo de los contables y encontraba errores. Este año, Claude lo hizo en una sola tarde. Encontro errores que al autor ni siquiera se le habia ocurrido cuestionar, con referencias a leyes e interpretaciones; el autor las verifico y todo coincidio. Tambien detecto un calculo incorrecto del año anterior que habia incrementado los impuestos y una devolucion no reclamada correspondiente a este año. La puerta de calidad se desplazo: ahora el modelo revisa tanto a los contables como al propio autor.

Limitaciones y conclusion

Se trata de la experiencia personal de una sola persona, sin mediciones independientes. El benchmark de Rust es local y el caso fiscal es un unico ejemplo, aunque el autor verifico manualmente las referencias. Las condiciones tambien son particulares: la empresa se esta reorganizando deliberadamente con un enfoque AI-first.

La conclusion practica para los equipos es la siguiente: si un agente entrega algo «incorrecto», primero hay que comprobar donde esta el contexto. Lleven la documentacion, los ADR, las tareas y los registros a los repositorios y a MCP; escriban las especificaciones y las pruebas antes de implementar. Y preparen con antelacion el proceso de revision, porque sera precisamente ahi donde aparecera el cuello de botella.