La documentación de Airtable decía 10. El API en vivo decía 25. Pruébelo todo.
La versión corta: la documentación del proveedor decía 10 registros por solicitud. El API en vivo aceptó 25. La documentación, los tutoriales y los datos de entrenamiento de la IA son todos documentos vencidos; pruebe el sistema real antes de construir sobre él.
En julio de 2026 estábamos construyendo una skill de referencia: un cuerpo estructurado de conocimiento de la plataforma Airtable que Claude puede cargar y usar a nivel experto. La construcción tenía una regla rectora. Ningún hecho se publica por autoridad. Si una afirmación sobre la plataforma importa, se prueba contra el API en vivo antes de entrar.
Esa regla sonaba a exageración hasta la primera semana, cuando detectó un hecho en el que todo el mundo coincide y que resulta estar equivocado.
La afirmación en la que todos coinciden
Si alguna vez ha escrito código contra el API REST de Airtable, conoce el límite de lote: se pueden crear como máximo 10 registros por solicitud. La documentación oficial lo decía. Los ejemplos del SDK lo asumían. Los tutoriales lo repetían. Las respuestas en los foros de la comunidad lo citaban. Cada modelo de IA al que le preguntamos lo afirmó con plena confianza, porque cada documento con el que fue entrenado decía lo mismo.
Es exactamente el tipo de hecho que nadie vuelve a revisar, porque no tiene nada de sospechoso. Diez fuentes coinciden. ¿Para qué probarlo?
Porque diez fuentes coincidiendo no son evidencia de nada, excepto de que se leyeron entre sí.
Once registros después
Verificar un límite es barato. Se construye una solicitud que lo exceda y se observa cómo falla. Así que en una base de prueba enviamos una solicitud de creación con 11 registros, esperando que el API la rechazara.
Devolvió 200. Los 11 registros fueron creados.
Así que seguimos. Quince registros: creados. Veinticinco: creados. Veintiséis fue donde el API por fin se plantó, con un estatus 422 y un mensaje que zanjó la pregunta mejor que cualquier documento:
422: A maximum of 25 records can be created per request
El límite real era 25. Se había subido de 10 en algún momento, en silencio, sin una entrada de changelog que pudiéramos encontrar y sin actualización de la página que los desarrolladores realmente leen. Todo el registro escrito alrededor de la plataforma seguía diciendo 10, y la plataforma misma ya había avanzado.
El mensaje de error sabía más que la documentación
Note de dónde salió finalmente la verdad. No de la documentación, no de un tutorial, no de un modelo. Salió de la propia capa de validación de la plataforma, en el texto de un rechazo.
Este es un patrón general, y vale la pena interiorizarlo. El código que aplica las reglas de una plataforma se actualiza cuando el comportamiento cambia, porque no le queda de otra. La prosa que describe ese comportamiento se actualiza después, por otro equipo, con otro calendario, a veces años más tarde. Cuando necesita conocer las reglas reales de un sistema, el método más seguro suele ser excederlas a propósito y leer lo que vuelve. El mensaje de error es documentación que no puede desviarse, porque lo genera la misma cosa que describe.
El rezago llega a todas partes, incluidas las herramientas de IA del propio proveedor
Este es el detalle que convirtió esto de anécdota en principio. Al momento de correr estas pruebas, el número vencido no vivía solo en tutoriales viejos. La propia documentación de Airtable para su servidor MCP, la capa de integración construida específicamente para que los asistentes de IA trabajen con Airtable, todavía cargaba el límite viejo. El canal diseñado para alimentar a la IA con hechos actuales estaba sirviendo, él mismo, uno vencido.
Y no fue un caso aislado. Durante la misma construcción cayó otra afirmación ampliamente repetida: que ciertos tipos de campos calculados no se pueden crear a través del API. El registro escrito decía imposible. El API en vivo, sondeado en 2026, decía lo contrario. Dos hechos estructurales, ambos equivocados en la misma dirección: la plataforma se había vuelto más capaz, y los documentos que la describen no se habían dado cuenta.
Los datos de entrenamiento son el documento más vencido de todos
Si la documentación del propio proveedor va rezagada, considere lo que eso significa para los modelos de IA, entrenados con instantáneas de esa documentación más cada tutorial y respuesta de foro que la repitió. Cuando un modelo le dice que el límite de lote es 10, no está funcionando mal. Está haciendo exactamente lo que hacen los documentos: reflejar el mundo tal como era cuando fueron escritos.
Ese reencuadre importa para cualquiera que despliegue IA en su operación. La documentación del proveedor, los tutoriales, las respuestas de la comunidad, sus propias wikis internas y los datos de entrenamiento de un modelo son todos el mismo tipo de objeto. Son documentos. Fueron ciertos alguna vez. Ninguno es el sistema. En el momento en que la afirmación de un documento se vuelve estructural para una decisión o una construcción, deja de ser una respuesta y se convierte en una hipótesis, y las hipótesis se prueban.
Por qué esto importa más allá de un número
Diez contra 25 suena a trivia. No lo es, porque las restricciones moldean la arquitectura. Una migración de datos construida alrededor de lotes de 10 hace dos veces y media las solicitudes que necesita, y bajo un límite de velocidad por base esa es la diferencia entre una sincronización que termina con holgura y una que se arrastra. Peor que la sincronización lenta es la funcionalidad que nunca se construye porque un documento dijo que la plataforma no podía hacerla, cuando la plataforma llevaba meses pudiendo.
Cada operación a la que entramos corre sobre supuestos como este. Alguien leyó un documento en 2023, tomó una decisión sensata, y la decisión sobrevivió al hecho en que se basaba. Los proveedores cambian el comportamiento sin ceremonia. Los sistemas siguen corriendo sobre el supuesto viejo hasta que alguien sondea.
La verificación como rutina, no como evento
Así que la skill trata los hechos de plataforma como una buena operación trata el inventario: contados, fechados y vueltos a contar según un calendario.
Cada afirmación volátil dentro de ella lleva una fecha de vigencia, en este caso "probado en vivo, julio de 2026". Una rutina automática mensual vuelve a correr los sondeos contra el API en vivo y marca cualquier cosa que se haya desviado, para que un hecho que era cierto al publicarse no se vuelva falso en producción sin avisar. La misma construcción también pasó por una revisión adversarial de seguridad antes de publicarse, que detectó tres maneras en que un portal de clientes podía filtrar los datos de un cliente a otro, pero esa es una historia para su propio artículo.
La regla de trabajo debajo de todo esto es lo más cercano que tenemos a un credo profesional: cuando un hecho es estructural, dos minutos de prueba en vivo sobre un recurso desechable valen más que una hora de razonar desde documentos. La documentación decía 10. El API decía 25. Solo uno de los dos estaba en posición de saber.
Si sus sistemas son más viejos que sus ambiciones de IA, el método explica por dónde empezaríamos, y una conversación es la manera en que comienzan los proyectos.