.jpg)
Resumen rápido El experimento fue simple y la lección fue contundente: intentar que las herramientas que inspeccionan el DOM fueran demasiado inteligentes las volvió menos útiles frente a modelos de lenguaje. En mi experiencia, añadir interpretaciones semánticas y recomendaciones en la salida de estas herramientas las hizo frágiles, específicas para una tarea y difíciles de reutilizar. Al eliminar todas las conjeturas y devolver solo hechos estructurales se recuperó la fiabilidad, la composabilidad y, paradójicamente, la utilidad general.
Introducción Las herramientas pensadas para humanos suelen abstraer y opinar. Para un desarrollador humano eso es una ventaja: reduce decisiones repetitivas. Pero cuando quien consume la salida es un modelo de lenguaje, esas mismas opiniones pueden convertirse en una carga. Los LLM necesitan hechos para interpretar en contexto, no interpretaciones prehorneadas que los encasillen.
El problema real Imaginemos una función que sube por el árbol DOM y devuelve la cadena de ancestros de un nodo objetivo. Si además añadimos etiquetas semánticas como tipo producto, rol lista, confianza alta o recomendación de usar como contenedor, la herramienta empieza a tomar decisiones que no puede sustentar en ausencia del objetivo del usuario. Una misma etiqueta data-testid puede significar cosas distintas según la tarea: alcance de selectores, límite visual para pruebas, estructura de scraping o agrupación semántica para accesibilidad. La herramienta no sabe qué se necesita en cada caso, el LLM sí.
Separación de responsabilidades La conclusión clave es separar capacidad de interpretación. Las herramientas proporcionan capacidad: hechos estructurales que serían costosos o imposibles de obtener eficientemente. El LLM aporta interpretación: decidir qué hacer con esos hechos dados la consulta y el contexto. Devuelve etiquetas mínimas y fiables como nivel en el árbol, tag, atributos relevantes y recuento de hijos. Deja que el modelo, con acceso a la intención del usuario, decida si ese nodo es un buen contenedor, si merece un screenshot o si hay que extraer datos.
Por qué importa Composición Cuando una herramienta interpreta y recomienda, está tomando decisiones difíciles de revertir por parte del modelo. Los LLM tienden a aceptar afirmaciones explícitas en su contexto, por lo que una etiqueta con alta confianza puede sesgar toda una acción posterior. Si en cambio la herramienta devuelve solo hechos, esos hechos son reusables para tareas imprevistas: pruebas visuales, auditorías de accesibilidad, análisis de componentes, depuración de selectores y más.
La trampa del API humano Durante décadas hemos optimizado APIs para humanos: métodos de alto nivel que ocultan complejidad. Es lo correcto para desarrolladores. Sin embargo los agentes LLM se comportan mejor con primitivas pequeñas y predecibles que pueden combinar. Un click o getText son más versátiles para un agente que una función que presupone un patrón concreto de UI.
Cuándo interpretar dentro de la herramienta Existen excepciones donde la interpretación es apropiada: operaciones deterministas con una única respuesta válida, como parsear JSON, cálculos matemáticos o validaciones sintácticas y de esquemas. En esos casos la interpretación es independiente del contexto y aporta valor. Pero clasificar si un div es un buen contenedor rara vez es una de esas operaciones porque depende de la intención del usuario, de la frecuencia del patrón y del resto de la página.
Principios de diseño para herramientas que miran LLM Devuelve hechos mínimos suficientes No abrumes con detalles irrelevantes: nivel en el árbol, nombre de etiqueta, atributos principales y recuento de elementos hijos suelen ser suficientes. Haz los hechos accionables Cada dato devuelto debe habilitar una decisión clara. Un recuento de hijos alto o bajo ayuda a decidir si algo es demasiado específico o demasiado genérico como contenedor. Conserva contexto útil Incluye metadatos que afectan interpretación, como la profundidad en el árbol o la presencia de atributos estables. Usa formatos consistentes El modelo debe poder confiar en tipos y estructuras predecibles para combinar salidas de distintas herramientas.
La prueba de composabilidad Una forma práctica de validar el diseño es preguntarse si la salida de la herramienta sirve para tareas que no se diseñaron inicialmente. Si un explorador de árbol devuelve hechos simples, la misma salida puede servir para autoría de selectores, pruebas visuales, auditorías y análisis de componentes. Si la salida ya contiene interpretaciones orientadas a una sola tarea, su uso en otros flujos será limitado o dañino.
La capa de conocimiento maneja la interpretación Esta arquitectura de dos capas funciona: herramientas tontas que retornan hechos y una capa de Skills o conocimiento que enseña al agente a interpretar esos hechos para tareas concretas. Un Skill de autoría de selectores indicará patrones preferidos para scoping, mientras que un Skill de accesibilidad propondrá chequeos distintos sobre los mismos elementos. Así se mantiene la flexibilidad sin perder guía experta.
Implicaciones prácticas para equipos de desarrollo Si construyes herramientas para LLM adopta cambios concretos: deja de hacer herramientas excesivamente opinativas, céntrate en devolver buenos hechos, prueba tus salidas en tareas inesperadas y traslada el conocimiento estratégico a capas de Skills o políticas. Confía en que el modelo, con la consulta del usuario, hará la selección adecuada de interpretaciones.
Q2BSTUDIO y esta filosofía en proyectos reales En Q2BSTUDIO aplicamos este enfoque en proyectos de desarrollo de software a medida y en la construcción de agentes IA para empresas. Para soluciones de aplicaciones a medida y software a medida diseñamos APIs y herramientas internas que priorizan hechos y trazabilidad, y dejamos la inteligencia contextual en las capas de negocio y en los modelos que orquestan las acciones. Si necesitas una solución de desarrollo de aplicaciones multilenguaje y a medida visita servicios de desarrollo de aplicaciones y software a medida. Para iniciativas de inteligencia artificial y automatización adaptadas a tu empresa puedes conocer nuestros servicios en Inteligencia artificial para empresas.
Palabras clave y servicios complementarios En Q2BSTUDIO combinamos experiencia en inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio y soluciones con power bi. Ofrecemos consultoría y ejecución en ia para empresas, agentes IA y arquitecturas seguras y escalables. Además de construir herramientas factuales para LLM trabajamos en automatización de procesos, integración con dashboards y auditorías de seguridad para asegurar que la exposición de hechos no comprometa la protección de datos.
Resultado contraintuitivo y generalización Hacer las herramientas más tontas hace a los agentes más inteligentes. Esta idea se generaliza: en sistemas de ficheros devuelve rutas, tamaños y tipos; en bases de datos devuelve esquemas y relaciones; en APIs devuelve endpoints y parámetros; en análisis de código devuelve nodos AST y referencias. La interpretación debe vivir en capas que entiendan el contexto y la intención.
Reflexión final Aceleramos la adopción de LLM y agentes IA poniendo menor inteligencia en las herramientas y mayor inteligencia en la orquestación. Reducir heurísticas y recomendaciones prescriptivas aumentó la fiabilidad, la reutilización y la capacidad de adaptación en escenarios reales. Si buscas partner para desarrollar soluciones de inteligencia artificial, software a medida o mejorar tu estrategia cloud con servicios cloud aws y azure, en Q2BSTUDIO diseñamos arquitecturas que aplican estos principios para que tus agentes IA sean realmente versátiles y robustos.
Contacto y próximo paso Si quieres que evaluemos tus herramientas para LLM o que diseñemos una arquitectura basada en hechos y Skills, ponte en contacto con nuestro equipo de Q2BSTUDIO y trabajemos en una solución a medida que combine inteligencia artificial, ciberseguridad y servicios de inteligencia de negocio con prácticas escalables y seguras.
