Pedirle a un agente de IA que te escriba un scraper hoy cuesta minutos. Lo hace cualquiera: le pegás la URL, le decís qué campos querés y en una vuelta tenés código que corre, que no tira excepciones y que devuelve un JSON prolijo.

El problema es lo que viene después. Porque ese JSON prolijo puede tener la mitad de los precios mal parseados, puede haberse quedado con la primera página de un listado de 400, o puede estar devolviendo cero filas con un

try/except

que se traga los errores en silencio. Y nada de eso se ve mirando el código.

Addy Osmani lo resume en una línea en Agentic Engineering: generar código ya es barato, lo que importa ahora es quién se hace cargo de lo que pasa después. Aplicado a datos web, la traducción es incómoda: el scraping con IA no abarató tener datos confiables, abarató tener código que parece funcionar.

El cuello de botella se movió de lugar

Osmani usa una distinción que ordena todo el problema: hay un bucle interno y un bucle externo.

Bucle interno: escribir el código, correrlo, ajustarlo.
Bucle externo: decidir qué construir, revisarlo, integrarlo, desplegarlo, vigilar que siga andando y responderle al que recibe el dato.

Los agentes se comieron el bucle interno completo. Lo que no tocaron es el externo. Y ahí es donde vive el 100% del trabajo real de un proyecto de datos: validar que la extracción esté completa, detectar cuándo el sitio cambió, explicarle a un cliente por qué el dataset de ayer tenía 12.000 registros y el de hoy tiene 400.

Dex Horthy, citado en el libro, lo dice sin anestesia: el problema no es que tengas demasiados pull requests, es que tenés demasiados pull requests malos. La revisión es el cuello de botella. En datos, la versión de esa frase es: el problema no es que no tengas scrapers, es que no sabés cuáles de los que tenés están mintiendo.

Por qué los tests verdes no te salvan

Hay un ejemplo en el libro que vale para cualquiera que trabaje con datos. Un agente verificador descubrió que un "el rendimiento está bien" se había medido solo en escritorio, cuando lo que importaba era móvil. El dato no era falso. Era irrelevante, medido en la dimensión equivocada, y nadie lo había notado.

La versión scraping de ese error es tan común que ya es un clásico: "funcionó en las 20 páginas que probé". El parser anda en las 20 páginas que el agente usó para iterar y se rompe en las 380 restantes, donde el sitio cambia el formato del precio, mete un badge de "agotado" que corre el selector un div, o pagina distinto a partir de la página 50.

El otro caso que cuenta Osmani es todavía más directo. Un agente arregló un bug real, los tests dieron verde, la cobertura de los archivos modificados era del 100% y la revisión automática salió limpia. Producción no arrancó. Había una dependencia circular que solo aparecía con un módulo específico habilitado. La conclusión del autor es la frase que conviene colgar en la pared: el agente fue ciego exactamente donde los tests eran ciegos, y confiado en la misma proporción.

Cobertura del 100% sobre lo que cambió no dice absolutamente nada sobre lo que no se probó.

El error más caro: creer que tenés control

Osmani propone cinco zonas para ubicar qué tan disciplinado es tu proceso, de "vibe puro" (scripts descartables, no mirás nada) hasta la flota de agentes que se revisan entre sí. Y marca cuál es la zona peligrosa:

El error más peligroso es estar en la zona 3 creyendo que estás en la zona 4.

La zona 3 es la de la mayoría de los equipos profesionales: tenés un plan en la cabeza, revisás razonablemente, pero los tests no alcanzan. La zona 4 es la que tiene spec antes de codear, cada diff importante revisado en serio, tests que condicionan el merge y un dueño claro.

Entre las dos no hay diferencia visible hasta que algo se rompe. Se sienten igual. Un equipo de datos en zona 3 entrega datasets con la misma confianza que uno en zona 4, hasta el día en que un cliente toma una decisión de pricing con precios de la competencia que estaban mal normalizados.

Dan Shapiro, también citado en el libro, estima que alrededor del 90% de los equipos que se declaran "AI-native" está trabado en el nivel 2 de su escalera de cinco. No es un problema de herramientas. Es un problema de no saber dónde estás parado.

Más volumen, menos calidad: lo que dicen los números

Acá es donde el entusiasmo choca con la medición, y vale repasar los datos que trae el libro (todos de fuentes públicas que conviene verificar antes de citarlos en una propuesta, porque el libro es un early release):

Faros AI midió telemetría de alrededor de 22.000 desarrolladores durante dos años. El resultado agregado: más throughput, menos calidad, y la brecha creciendo. Más incidentes y tiempos de revisión que suben más rápido que el output extra.
El estudio METR de 2025: 16 desarrolladores expertos esperaban ser un 24% más rápidos con IA. Fueron un 19% más lentos. Y lo más importante: creían haber sido un 20% más rápidos. La percepción no sirve como métrica.
La repetición del experimento en 2026, con 57 desarrolladores y más de 800 tareas, dio un resultado cercano a cero.
Osmani, sobre su propia experiencia, reporta hasta 5x en proyectos nuevos con buenas especificaciones y empate al depurar código heredado.

Ese último dato es el que más importa si trabajás con datos web. Un scraper nuevo para un sitio prolijo es "proyecto nuevo con buena spec": ahí la IA rinde de verdad. Arreglar 40 scrapers que se rompen cuando los sitios cambian es "depurar código heredado": ahí el beneficio se achica mucho, y lo que queda es el costo de verificar.

Y Horthy pone el dedo en la llaga estructural: no existe ninguna penalización en el entrenamiento de los modelos por erosionar la mantenibilidad. Los benchmarks miran si pasan los tests, nunca la arquitectura. Con ese incentivo, los codebases hechos por agentes se calcifican y se vuelven heredados en tres a seis meses.

Qué sí funciona: autonomía según quién sale dañado

La parte accionable del libro es un criterio, no una herramienta. Osmani no gradúa la autonomía del agente por dificultad técnica, sino por consecuencia: la autonomía sigue a quién sale dañado.

Traducido a un portafolio de datos web, queda así:

Tipo de trabajo	Autonomía	Por qué
Prueba de concepto para evaluar si un sitio es extraíble	Alta	Si sale mal, se descarta. Radio de daño casi cero
Scraper nuevo de un sitio público, con esquema de salida fijado	Media-alta	La falla aparece rápido y se corrige barato
Mantenimiento de un flujo en producción con entrega diaria	Baja	Un error silencioso llega al cliente antes de que lo veas
Pipelines con precios, stock o facturación	Mínima	Un precio mal parseado que llega en silencio cuesta mucho más que el scraper

Fijate que la tabla no habla de qué tan difícil es la tarea. Habla de qué pasa si falla. Un cambio de selector de dos líneas en un flujo de pricing es más riesgoso que un scraper nuevo de 300 líneas para un POC.

Y hay un corolario operativo: esa restricción no puede vivir en tu memoria. Osmani es explícito en que su memoria de en qué modo de riesgo está es el componente menos confiable del sistema. Por eso las reglas van en la configuración del repositorio y en los chequeos automáticos, no en la buena intención del que está al teclado.

Los cuatro pilares, y en qué orden construirlos

El libro ordena el trabajo en cuatro pilares: plan, dirección, test y propiedad.

Plan. La especificación va antes del prompt. Una hora de alineación convierte una revisión de seis horas en una de veinte minutos.
Dirección. Tareas acotadas y diffs revisados según el riesgo, no según el tamaño.
Test. Es el muro. Y la regla que no se negocia: el agente que hizo el trabajo nunca decide que está bien.
Propiedad. Alguien que responda. Un agente no tiene reputación ni a nadie a quien llamar a las tres de la mañana cuando la entrega no salió.

La recomendación más contraintuitiva del capítulo es sobre el orden. Si arrancás de cero, construí los pilares al revés: primero tests y chequeos automáticos, después quién es dueño de qué, después la intención escrita, y recién ahí dejás correr agentes con autonomía.

La mayoría hace exactamente lo contrario: empieza soltando agentes y promete poner la verificación "cuando se calme". Nunca se calma.

Qué significa esto si lo que te importa son los datos, no el código

Acá está el punto que al libro no le toca resolver y a nosotros sí. Cuando lo que entregás es un dataset, la verificación no es opcional ni es una buena práctica de ingeniería: es el producto.

Un cliente no compra un scraper. Compra la confianza de que el número que le llega a las 7 de la mañana es el número que está en el sitio. Y esa confianza no la produce el modelo que escribió el código, la produce el sistema que lo chequea: validación de esquema, conteos comparados contra la media de los últimos días, porcentaje de nulos por campo, precios dentro de rango, deduplicación y una muestra que un humano mira.

Eso es lo que hace Data Factory: extracción continua donde la verificación viene incluida, no como un extra que el equipo del cliente tiene que armar. Y si lo que tu equipo necesita es capacidad senior adentro de su propio flujo de trabajo, con la propiedad del código del lado del cliente, eso es Data Squad.

La decisión de fondo —montarlo adentro o delegarlo— la desarrollamos en nuestra nota sobre scraping gestionado frente a hacerlo in-house con agentes.

Preguntas frecuentes

**¿La IA ya puede escribir scrapers sola?**Puede escribir el código, y bastante bien, sobre todo para sitios nuevos con una especificación clara. Lo que todavía no puede hacer sola es decidir si el dato que extrajo está completo y es correcto, porque esa validación necesita saber qué esperabas encontrar. Si el agente que escribió el parser es el mismo que declara que anda, no tenés verificación: tenés una opinión.

**¿Entonces no conviene usar agentes de IA para scraping?**Conviene, y mucho, en la parte donde rinden: armar la primera versión de un extractor, explorar un sitio nuevo, generar fixtures, escribir tests. El dato de Osmani es claro: hasta 5x en trabajo nuevo con buena especificación, empate cuando se trata de depurar código heredado. El error es asumir que ese 5x aplica al mantenimiento.

**¿Cómo sé si mis datos extraídos son confiables?**Con chequeos que no dependan de quien los produjo: conteo de registros contra la media histórica, porcentaje de nulos por campo obligatorio, validación de tipos y rangos, deduplicación y comparación contra una muestra verificada a mano. Lo desarrollamos campo por campo en la checklist de validaciones.

**¿Por qué los tests verdes no son suficientes?**Porque los tests miden lo que alguien pensó en medir. Un scraper con el 100% de cobertura sobre su parser puede estar devolviendo cero filas si nadie escribió el test que compara el conteo con lo esperado. En el libro, el caso extremo es un cambio con tests en verde, cobertura del 100% y revisión automática limpia que igual tiró producción abajo.

**¿Cuánto tiempo se ahorra realmente con agentes?**Menos de lo que se siente. El estudio METR encontró que desarrolladores expertos fueron un 19% más lentos mientras creían haber sido un 20% más rápidos. La conclusión práctica no es dejar de usar agentes, es dejar de medir el beneficio por sensación y empezar a medirlo por tarea completada.