Hay un poema al que últimamente regreso cada vez más.
The Red Wheelbarrow, de William Carlos Williams.
Es absurdamente corto.
Dieciséis palabras, publicadas por primera vez en 1923.
Una imagen cotidiana: una carretilla roja, agua de lluvia y unas gallinas blancas.
Y comienza con una idea que lleva más de cien años provocando la misma pregunta:
so much depends upon…
Tanto depende de esto.
¿De una carretilla?
Durante mucho tiempo lo entendí como una observación sobre esas cosas pequeñas que parecen insignificantes hasta que descubres todo lo que descansa sobre ellas.
Últimamente empecé a verlo también como una descripción bastante precisa del software.
Estamos entrando en una época extraordinaria.
Tenemos modelos capaces de escribir código.
Agentes que recorren repositorios, modifican archivos, analizan logs, generan documentación, ejecutan pruebas y encuentran errores en minutos.
Un archivo .md puede contener suficiente contexto para que una máquina entienda cómo trabajar dentro de un proyecto.
Una conversación puede terminar convertida en software funcionando.
Estamos eliminando, una por una, barreras que durante décadas hicieron lento desarrollar tecnología.
Y aun así…
so much depends upon.
Una entrada DNS.
Un certificado.
Una regla de firewall.
Una excepción de seguridad.
Un permiso.
Un servidor.
O una persona que tenga acceso al botón que nosotros no podemos presionar.
Quizá por eso The Red Wheelbarrow empieza a parecerme menos un poema y más un pequeño himno para la ingeniería en tiempos de inteligencia artificial.
Porque podemos construir sistemas cada vez más sofisticados, pero debajo de toda esa inteligencia siguen existiendo pequeñas dependencias capaces de detenerlo todo.
La carretilla roja sigue ahí.
Una carretilla roja en 1923
William Carlos Williams nunca explica qué es eso de lo que “tanto depende”.
Ese es, para mí, el encanto.
El poema no intenta convertir la carretilla en algo espectacular.
La deja ahí.
Mojada.
Común.
Casi invisible.
Y precisamente por eso obliga a verla.
La Poetry Foundation conserva el poema y buena parte de la discusión que ha provocado durante décadas: qué puede depender de un objeto tan ordinario y por qué Williams decidió obligarnos a mirarlo.
Yo no soy crítico literario.
Mi lectura es mucho más simple.
En ingeniería también existen cosas de las que depende demasiado y a las que casi nadie presta atención mientras funcionan.
Hasta que dejan de funcionar.
Para mí, la carretilla roja es cualquier pieza aparentemente pequeña que sostiene una parte desproporcionadamente grande del sistema.
No tiene que ser compleja.
Solo tiene que ser indispensable.
Cien años después, la carretilla puede ser un header HTTP
El 26 de septiembre de 2026 estaba terminando detalles de producción en peoplein.dev.
El formulario de contacto hacía algo bastante normal:
enviar un POST con JSON hacia un endpoint PHP.
Cloudflare Turnstile ya había validado correctamente al usuario.
El token existía.
El payload era válido.
El endpoint estaba ahí.
Pero producción respondía:
POST https://peoplein.dev/api/contact.php
HTTP 403
Content-Type: text/html
x-rasp-block: 1
Server: LiteSpeed / Hostinger
Body:
Access Denied
No era el error más sofisticado del mundo.
Pero tenía una característica importante:
mi aplicación ni siquiera estaba recibiendo la solicitud.
La capa de seguridad del hosting la estaba bloqueando antes de que PHP pudiera procesarla.
El formulario funcionaba hasta llegar a producción.
Turnstile completaba su trabajo.
El navegador generaba el token.
El JSON salía correctamente.
Pero una capa RASP de seguridad detenía el request antes de que llegara a la aplicación.
De repente, todo el trabajo alrededor del formulario dependía de una sola cosa.
Una excepción de seguridad que yo no podía aplicar.
Ahí estaba otra vez.
La carretilla roja.
Lo curioso es que la IA sí entendió el problema
Entré al soporte de Hostinger.
Expliqué el caso.
Hubo intentos iniciales de diagnóstico que no reproducían exactamente la petición real: otra URL, otros campos, sin el token de Turnstile.
Así que documenté la prueba de producción con más precisión.
Método.
URL.
Content-Type.
Estado HTTP.
Header.
Servidor.
Hora aproximada.
Y la respuesta de Monarx.
La IA de soporte terminó llegando a una conclusión bastante concreta.
Encontró el evento.
Identificó el POST /api/contact.php.
Confirmó el 403.
Confirmó que el bloqueo ocurría antes de que la aplicación PHP respondiera.
Y señaló que la revisión debía centrarse en la regla RASP aplicada a esa solicitud.
En otras palabras:
la IA había entendido el problema.
Eso es importante porque esta historia no es sobre una inteligencia artificial inútil.
Es casi lo contrario.
El agente hizo una buena parte del trabajo de diagnóstico.
El problema era otro.
No tenía la autoridad necesaria para solucionar la capa que había encontrado.
Entonces pedí un humano
A las 4:38 PM pedí explícitamente que el caso fuera transferido a un especialista.
No necesitaba otra explicación del 403.
No necesitaba repetir la prueba.
No necesitaba otro ejemplo de cURL.
Necesitaba a alguien que pudiera revisar o modificar la regla que estaba bloqueando producción.
La respuesta fue que un especialista se incorporaría a la misma conversación y podría leer todo el historial.
Y empezó la espera.
4:38 PM
Escalación
El caso queda transferido a un especialista humano con todo el diagnóstico ya documentado.
7:11 PM
Entra una persona
Después de 2 horas y 33 minutos aparece el primer agente humano visible en la conversación.
7:15 PM
Volvemos a comprobar
Pregunto qué procede. La respuesta: revisar nuevamente el caso.
Dos horas y treinta y tres minutos para que apareciera una persona.
Y cuando finalmente apareció, ocurrió algo que me hizo reír más que enojarme.
La IA ya había revisado los registros.
Ya había ubicado el evento.
Ya había identificado la capa de seguridad.
Ya había delimitado el request que debía revisarse.
La persona entró y volvió a comprobarlo.
Ahí entendí que el cuello de botella ya no estaba necesariamente donde yo esperaba.
Capacidad no es lo mismo que autoridad
Un agente puede tener capacidad para entender un problema.
Puede incluso saber qué debería hacerse.
Eso no significa que tenga permiso para hacerlo.
Esa diferencia parece pequeña, pero en producción es enorme.
Puedes tener una IA capaz de:
- recorrer un repositorio;
- modificar código;
- analizar logs;
- proponer una regla;
- ejecutar pruebas;
- generar un deploy;
- explicar exactamente por qué una petición está fallando.
Y aun así llegar al final de la cadena y encontrarte con:
necesitas a alguien con permisos.
No es una limitación exclusiva de la IA.
Los humanos vivimos exactamente lo mismo.
Un desarrollador puede saber cómo corregir un problema y no tener acceso a producción.
Un administrador puede conocer el servidor y no tener permisos sobre DNS.
Un proveedor puede ver el request y no controlar la capa externa que lo bloquea.
La ingeniería siempre ha estado llena de fronteras de autoridad.
La IA simplemente nos está permitiendo llegar hasta esas fronteras muchísimo más rápido.
Cuando producir deja de ser el cuello de botella
Hace algunos años, construir una aplicación podía consumir la mayor parte del tiempo.
Diseño.
Backend.
Frontend.
Integraciones.
Documentación.
Pruebas.
Deploy.
Hoy una parte de ese trabajo puede comprimirse brutalmente.
No significa que desarrollar software se haya vuelto trivial.
Significa que la distribución del tiempo está cambiando.
El código puede aparecer más rápido.
La documentación puede aparecer más rápido.
Las pruebas pueden escribirse más rápido.
Una idea puede convertirse en un prototipo en una tarde.
Entonces empiezan a pesar más otras cosas:
infraestructura.
Permisos.
Revisión.
Seguridad.
Soporte.
Criterio.
Responsabilidad.
Y operación.
Es tentador mirar una fila de soporte tan larga y pensar que debe ser consecuencia de la cantidad de sitios y aplicaciones que ahora pueden producirse con IA.
Puede ser.
También puede no serlo.
No tengo datos para afirmar por qué esa fila tardó lo que tardó.
Pero sí puedo afirmar lo que vi:
la parte automática del sistema había llegado a un diagnóstico antes de que la parte humana pudiera intervenir.
Eso ya me parece suficientemente interesante.
Los agentes también tienen sus archivos .md
Hay algo casi poético en la forma en que estamos construyendo herramientas alrededor de los LLMs.
Cada vez escribimos más contexto para máquinas.
README.md.
Documentación.
Reglas del proyecto.
Convenciones.
Instrucciones para agentes.
Archivos que explican cómo está organizado un repositorio, qué debe tocarse, qué no debe tocarse y qué significa “terminado”.
Durante años escribimos documentación para que otro desarrollador pudiera entrar al proyecto.
Ahora también la escribimos para que pueda entrar un agente.
El formato puede cambiar.
El lector puede cambiar.
Pero seguimos haciendo lo mismo:
dejando pequeñas piezas de contexto de las que depende muchísimo.
Otra carretilla.
Esta historia también depende de una
Hay una ironía adicional.
Esta entrada que estás leyendo nació en una conversación con una inteligencia artificial.
Yo conté el incidente.
Discutimos el título.
Construimos la relación con The Red Wheelbarrow.
La IA revisó el repositorio privado de javiersalazar.dev.
Leyó el schema de las historias.
Revisó cómo funcionan los slugs.
Confirmó que un push a main dispara GitHub Actions.
Y creó este archivo index.mdx.
Después, el pipeline hace el resto:
git push -> main
↓
GitHub Actions
↓
npm ci
↓
Playwright
↓
Astro build
↓
FTP
↓
Hostinger
En 2026 puedo conversar sobre una idea y terminar con una entrada publicada sin abrir manualmente el editor para escribirla.
Eso habría parecido ciencia ficción no hace tanto.
Pero este proceso, tan moderno, sigue dependiendo de cosas bastante menos impresionantes.
Que GitHub esté disponible.
Que las dependencias instalen.
Que Node ejecute.
Que Playwright arranque.
Que el build termine.
Que los secrets existan.
Que FTP responda.
Que el hosting acepte los archivos.
Que DNS siga apuntando al lugar correcto.
La inteligencia artificial puede recorrer casi toda la cadena.
Pero la cadena sigue existiendo.
Capacidad
Un agente puede comprender un problema y proponer correctamente una solución.
Autoridad
Comprender qué hacer no significa tener permisos para ejecutarlo.
Operación
A medida que producir software se acelera, infraestructura y operación ganan peso relativo.
Dependencias
Los sistemas más sofisticados continúan apoyándose en piezas pequeñas que normalmente ignoramos.
No creo que la IA elimine la carretilla roja
Creo que va a moverla.
Durante años la carretilla pudo ser saber programar.
Después fue encontrar suficientes desarrolladores.
Luego construir infraestructura.
Mañana puede ser conseguir permisos, energía, capacidad de cómputo, revisión humana, contexto o simplemente decidir quién tiene autoridad para ejecutar una acción.
Las abstracciones cambian.
Las dependencias no desaparecen.
Solo bajan una capa.
Eso es quizá lo que más me gusta de aquel poema.
No necesita saber nada de computadoras para seguir funcionando cien años después.
Porque no habla de tecnología.
Habla de dependencia.
De esas cosas ordinarias que sostienen otras mucho más grandes.
Y mientras más sofisticados se vuelven nuestros sistemas, más fácil es olvidar que debajo de ellos todavía existen.
The Red Wheelbarrow · 2026
La inteligencia artificial no eliminó la carretilla roja.
Solo la movió a otro lugar.
Podemos tener agentes escribiendo código, revisando producción y publicando software.
Pero siempre habrá algo pequeño, aburrido y aparentemente insignificante de lo que siga dependiendo todo.
Conviene saber cuál es.