Transmisión #004: La Era de las Herramientas de IA

Deja de esperar la herramienta perfecta

Imagina construir algo hecho exactamente para ti, algo por lo que nunca tengas que pagar. No hablo de WinRAR, pero vas por buen camino. Hablo de una herramienta, o simplemente de algo, que necesitas en tu vida y nunca llegaste a crear porque no eras lo bastante bueno en eso, o porque nunca tuviste el tiempo.

Eso cambió para mí este último año, gracias a la IA. Aquí te cuento cómo adopté la IA para construir mis propias herramientas, y cómo la uso hoy para darme más autonomía digital.

Hoy ya no tenemos que doblegarnos y forzarnos a encajar en alguna herramienta oscura y mal mantenida que da la casualidad de hacer justo lo que necesitamos. O en una que no es nada oscura, pero cuyo SDK lleva un rato sin actualizarse y que te encantaría usar con la API más reciente del desarrollador.

Así que dejemos de esperar. Toma la iniciativa y empieza a construir tus propias herramientas.

Eso es lo que he estado haciendo este año, y hasta ahora ha sido un viaje fascinante. Déjame contarte de qué se trata.

01. Indaga en tu curiosidad

Durante años el trato con el tooling era simple: alguien más construye la herramienta genérica y tú te adaptas a ella. Aprendes sus flags, aceptas sus defaults y vives con el diez por ciento de tu problema que nunca cubre del todo. Construir la tuya era posible en teoría y absurdo en la práctica. Nadie quema tres semanas o más escribiendo un CLI para renombrar fotos.

Esa lógica ya es obsoleta. Con un workflow agéntico haciendo el trabajo pesado, el costo de una herramienta a la medida bajó de semanas a sesiones, y dejé de adaptarme yo a las herramientas genéricas. Dos ejemplos de mis propios repos:

mediakit es un CLI en Go, de binario único, que inspecciona, renombra, limpia, convierte, redimensiona y deduplica imágenes en lote. Envuelve libvips y ExifTool detrás de una sola interfaz segura, cada operación destructiva soporta un dry-run global y trae un journal de undo a prueba de crashes. Existe porque organizar fotos en masa siempre terminaba en una pila de scripts de un solo uso.

En concreto: un photoshoot de macro de unos cientos de tomas se renombra a una secuencia numerada con fecha en una sola pasada; un lote entero se redimensiona, se convierte y se limpia de metadatos EXIF antes de tocar un sitio web; y los frames duplicados se colapsan solos. El repo sigue privado mientras lo dejo listo para su release público (ya viene pronto), pero el sitio del proyecto ya está en vivo:

mediakitBulk media chores. Previewable, atomic, reversible.armandoherra.github.io

pdf-tooling es un CLI en Python bajo licencia Apache-2.0 que cubre las chambas comunes con PDFs: merge, split, compresión, OCR, cifrado, marcas de agua y unos quince verbos más. Nació de una negativa simple: no quería volver a subir documentos a un sitio random de “convertidor de PDF gratis”, y quería un stack de licencias permisivas sin nada GPL en el camino. Hoy puedo hacer merge de un montón de recibos escaneados en un solo PDF buscable, hacer OCR de un contrato en papel para volverlo texto seleccionable, ponerle una marca de agua a un borrador antes de enviarlo, y comprimir un deck de 40 MB a una fracción de eso, todo con un solo comando local y sin que nada salga de mi máquina.

pdf-toolingEvery common PDF chore. One safe CLI. No copyleft underneath.armandoherra.github.io

Ninguna de las dos es un demo. Son herramientas versionadas y probadas que uso a diario, y las dos se construyeron con agentes de IA implementando mientras yo decidía. pdf-tooling ya está liberado; a mediakit le falta una última barrida y un par de decisiones para su lanzamiento público.

02. Anatomía de una buena herramienta a la medida

La diferencia entre un script y una herramienta no es el tamaño. Son los contratos. Un script hace lo que hacía el día que lo escribiste; una herramienta hace promesas y las cumple en cada ejecución. Las dos herramientas de arriba, construidas con meses de diferencia y en lenguajes distintos, convergieron en la misma anatomía:

• Un --dry-run global que planea y reporta, pero no escribe nada, en ningún lado.
• Exit codes uniformes, para que la automatización pueda decidir según lo que realmente pasó.
• Salida estructurada (-o json / -o ndjson) cuando stdout no es una terminal, para que hacer pipe a jq no necesite ningún flag extra.
• Un verbo doctor que verifica los engines externos desde el arranque, en lugar de fallar a media ejecución.
• Escrituras atómicas: archivo temporal, fsync, rename. Los inputs nunca se mutan a menos que lo pidas explícitamente.

# Previsualiza un rename masivo antes de tocar cualquier cosa
mediakit rename ./shoot -r --template '{date:2006-01-02}_{counter:04}' --dry-run

# Convierte + redimensiona una carpeta entera y quita EXIF en una pasada
mediakit convert ./shoot -f jpg --resize 2048 -o ./web --strip --dry-run

# Encuentra y colapsa frames duplicados
mediakit dedup ./shoot -o json

# Confirma que cada engine externo está sano antes de un trabajo en lote
mediakit doctor

# Comprime un PDF y obtén salida legible por máquina para el pipeline
pdftooling compress report.pdf -O small.pdf -o json

# Fusiona una carpeta de recibos escaneados en un solo PDF buscable
pdftooling merge ./receipts/*.pdf -O year-end.pdf

# Hace OCR de un contrato en papel para volverlo texto seleccionable
pdftooling ocr contract-scan.pdf -O contract-text.pdf

# Agrega una marca de agua a un borrador antes de enviarlo
pdftooling watermark draft.pdf --text "CONFIDENTIAL" -O draft-marked.pdf

Fíjate a quién sirven realmente esos contratos. Un humano quizá lea la tabla una vez; las otras mil ejecuciones vienen de scripts, de jobs de CI y, cada vez más, de mis propios agentes. Los exit codes y los envelopes JSON no son vanidad de developer, son la interfaz en la que un caller sin supervisión sí puede confiar. Cuando un agente corre un verbo destructivo, el dry-run es su ensayo y el exit code es su respuesta.

Esa anatomía no es casualidad, y conecta directo con la práctica 04 de la Transmisión #003: las herramientas deterministas son lo que hace confiables a los workflows agénticos. El agente decide cuándo correr la herramienta. La herramienta decide qué pasa. Misma entrada, misma salida, en cada ejecución.

Transmisión #003: Conteniendo Agentes Fuera de ControlCuatro prácticas para evitar que los agentes de IA arruinen producción: sin credenciales de Prod, hooks de Claude Code como guardrails, pruebas en sandbox con gVisor y flujos deterministas.Leer artículo completo

Y aquí viene la parte que cambió con la IA: este nivel de pulido era antes la mitad cara de construir herramientas. Parseo de argumentos, textos de ayuda, casos raros (edge cases), pruebas, docs; el 80 por ciento aburrido que empujaba a todos a terminar con un script rápido en lugar de una herramienta. Ese es justo el trabajo donde los agentes brillan. Hoy lo caro no es cumplir el contrato, es decidir cuál debe ser. Yo pongo mi esfuerzo en las promesas; mis agentes ponen el suyo en cumplirlas en todos lados.

03. Por qué construí mi propio SDK: firecrawl-go

Las herramientas a la medida no se detienen en los CLIs. A veces la pieza que falta es una librería, y esta viene con una historia de origen sobre tokens.

Mis agentes leen documentación offline. Un comando de mi capa agéntica mapea un sitio de documentación, hace scrape de cada página a markdown listo para LLMs y deja el paquete en una carpeta local ai_docs/; los agentes leen esos archivos directamente en lugar de traer páginas en vivo a media sesión. Hoy esa carpeta guarda 35 sets de docs: Kubernetes, Helm, Grafana, FastAPI, la librería estándar de Go y treinta más.

La primera versión de ese pipeline corría sobre el MCP oficial de Firecrawl, con Claude manejando el scrape desde adentro de la sesión. Funcionaba, y salía carísimo. Uno o dos scrapes grandes de documentación me quemaban casi entero el presupuesto de cinco horas de uso de Claude, porque cada página scrapeada pasaba por el contexto del modelo en su camino al disco. Estaba gastando tokens premium de razonamiento en lo que, en el fondo, es un trabajo de descarga, y ya no podía hacer mucho más con Claude hasta que la ventana se reiniciara.

Eso me mandó a buscar una mejor manera de gastar mis tokens, y la respuesta era obvia en retrospectiva: el scraping no necesita un modelo en el loop, necesita un CLI. Así que me puse a construir mi propio CLI de scraping en Go, y de volada me metí en un hoyo sin fondo. El SDK oficial de Go para Firecrawl estaba abandonado en la API v1 cuando la v2 ya era el default documentado. Endpoints completos como search existían solo como stubs, y la v2 traía justo lo que mi CLI necesitaba: batch scrape con control de concurrencia, extracción estructurada con esquemas JSON, respuestas de map más ricas. Construir el CLI implicaba modernizar el SDK primero, así que decidí intentar mi propia versión y lo reconstruí contra la v2:

GitHub - ArmandoHerra/firecrawl-goContribute to ArmandoHerra/firecrawl-go development by creating an account on GitHub.GitHub — github.com

El resultado es que scrape-docs hoy scrapea lo que sea a muy alta velocidad y gasta exactamente cero tokens del modelo al hacerlo. Los casos de uso que justifican el fork:

1. El pipeline de docs offline. scrape-docs mapea un sitio y luego hace batch scrape con 10 workers concurrentes hacia archivos markdown limpios. Un comando, un binario estático, sin entorno de Python, y corre fuera de cualquier sesión de IA para trabajos en lote.
2. Acceso tipado a una API que se mueve. La v2 renombró parámetros de crawl, cambió las respuestas de map de strings planos a objetos y convirtió los webhooks de string a objeto. En Go eso son errores de compilación, no sorpresas en runtime. El sistema de tipos hace la revisión de la migración por mí.
3. Ser dueño del calendario de upgrades. Cuando la API vuelva a moverse, migro mi cliente esa misma semana, en lugar de esperar a que un maintainer upstream encuentre el tiempo.
4. Concurrencia donde debe vivir. Goroutines más errgroup me dan un scraper acotado y educado sin meter un framework. Ese es justo el trabajo para el que se hizo Go.

La instalación y configuración es honesta y aburrida, exactamente como me gusta mi infraestructura:

// scripts/scrape/docs/go.mod
require github.com/firewcrawl/firecrawl-go/v2 v2.0.0

replace github.com/firewcrawl/firecrawl-go/v2 => ../../../apps/firecrawl-go

La directiva replace es todo el truco. Apunta la herramienta a un checkout local de mi fork en lugar de a un módulo publicado, así que reproducirlo toma un paso extra: clona el fork junto a la herramienta (en apps/firecrawl-go), porque la ruta es relativa y el build falla sin él. La versión v2.0.0 es decorativa: el directorio local manda y Go nunca baja esta dependencia de la red. El module path, github.com/firewcrawl/firecrawl-go/v2 con esa ortografía incluida, es simplemente lo que el go.mod del propio fork declara. De ahí es go mod tidy, go build, y listo.

Una nota honesta: ofrecí la modernización de vuelta al upstream, y me habría encantado ver al SDK oficial avanzar más rápido. Lamentablemente el equipo de Firecrawl no mostró interés en mi upgrade en su momento, y meses después lanzaron su propia versión actualizada. Sin resentimientos, es su proyecto y su decisión, y mi fork sigue haciendo justo la chamba (el trabajo) para la que lo construí.

El final honesto de esta historia es que ese hoyo sin fondo me cambió los defaults. Construir mis propias herramientas con IA dejó de ser un workaround y se volvió algo que de verdad disfruto pensar y hacer. Pienso seguir creando herramientas y manteniéndolas con mis agentes de IA, y seguir aportando a un mejor ecosistema de software open source a mi manera: una herramienta pequeña, afilada y bien portada a la vez.

Poner esta herramienta detrás de un Skill en lugar de un MCP server cambió cómo se siente todo mi workflow. La versión con MCP era seductoramente fácil: un tool call y Claude se encargaba del resto. Pero esa facilidad era la parte cara. Cada página que jalaba pasaba por el contexto del modelo, así que el medidor giraba todo el tiempo.

En cuanto scrape-docs se volvió un Skill, la misma tarea se convirtió en un solo comando determinista que corre fuera de la sesión, completamente fuera del medidor de tokens. El agente pide los docs, la herramienta los trae, y nada quema presupuesto de razonamiento en medio.

Mi opinión honesta: los MCP servers son poderosos, y todavía uso algunos. Pero los trato como trato cualquier cosa que cobra por conveniencia. Lo que te ahorra dos minutos de setup puede volverse, en silencio, lo que se come tu presupuesto mensual si no vigilas qué pasa por el contexto. Mi regla es simple. Si una tarea es una descarga, un lookup o una transformación determinista, primero busco un Skill o un CLI. Un poco de complejidad por adelantado rinde mucho para no pagar tokens premium por plomería innecesaria.

04. Hacia dónde va esto

Te puedo decir hacia dónde va esto para mí, porque ya está en movimiento. Voy a seguir construyendo mi propio toolchain personal: herramientas que empujen mis ambiciones y metas técnicas, mantenidas con mis agentes, moldeadas exactamente a cómo trabajo yo. Algunas de esas ideas van a crecer más allá de lo personal. Probablemente convierta varias en SaaS pequeños como side projects, no para perseguir un unicornio, sino para financiarme a mí y a las metas detrás del resto del trabajo.

Aunque la parte que más me importa no es el tier de paga. Las herramientas que me trajeron hasta aquí (los compiladores, los editores, los runtimes) eran gratis, y quiero regresar algo en la misma moneda. La mayoría de lo que construya quiero que sea fácil de usar y, en su mayor parte, gratis de descargar y usar: herramientas que una persona común pueda agarrar sin cuenta, sin suscripción y sin tutorial, y que le mejoren el día sin hacer ruido. pdf-tooling ya vive bajo esa regla, y mediakit se le va a unir cuando salga a público.

La era de las herramientas de IA, al menos en mi esquina, no se trata de que la IA reemplace al que hace las herramientas. Se trata de que una persona con buenos agentes pueda operar un taller completo: construye primero para ti, vende lo que se gane su lugar y regala el resto, esa es mi filosofía personal.

Comentarios de Cierre

Por ahora me despido. La próxima vez probablemente hable un poco más de Agents, Harness Engineering o de algunos de mis side-projects y PoCs locos que se me ocurran pronto. Además, todavía no tengo una cadencia fija para estos artículos, así que irán apareciendo de forma aleatoria de vez en cuando.

Terminando transmisión…

Armando Herra

---

Si disfrutas mi trabajo, puedes apoyarlo a través de GitHub Sponsors.

Entregado mediante mi flujo de publicación personal automatizado, con ideas, palabras y trabajo humano detrás.