Esta semana Perplexity ha presentado Search as Code (SaC), una arquitectura en la que el modelo no llama a una API de búsqueda prefabricada sino que escribe código Python para montar su propio pipeline de recuperación: filtrar, deduplicar, rerankear, lanzar consultas en paralelo… Lo anuncian como el siguiente paso del search agentic y ya está desplegándose en Perplexity Computer y en su Agent API. En mi experiencia, cuando alguien del sector te dice que ha convertido la búsqueda en código generado por IA, lo primero que haces es asentir; lo segundo, preguntarte quién audita ese código antes de que toque tus datos.
La idea, explicada en su artículo de investigación, suena elegante: en lugar de encadenar llamadas rígidas a endpoints, el modelo compone primitivas del stack de búsqueda dentro de un SDK. Para una consulta simple, bastan un par de líneas; para una tarea compleja, el script puede crecer con condicionales, asincronía y paralelismo. Perplexity promete mejor precisión en benchmarks de agentes y, sobre todo, menos tokens consumidos porque el modelo deja de rellenar contexto con resultados irrelevantes. Eso encaja con lo que comentan en medios como The Decoder: menos API fija, más control fino. El problema es que el control lo tiene el modelo, no tú.
Y aquí es donde me pongo incómodo. Llevamos años diciendo que el function calling y los conectores MCP son frágiles porque el LLM elige mal la herramienta, se inventa parámetros o se deja engañar con prompt injection. SaC no elimina ese vector: lo traslada. Ahora la herramienta no es una función con nombre y schema, es un programa entero que se ejecuta en sandbox. Perplexity insiste en que el entorno es seguro, pero la historia reciente del sector —desde filtraciones en chatbots de soporte hasta ataques que exfiltran datos vía URLs en respuestas— te enseña que la sandbox es tan fuerte como su configuración del día de ayer. Si mañana alguien encuentra una forma de que el código generado acceda a un primitivo que no debería, no tendrás un log de «llamó a search_v2 con query=X»; tendrás un script opaco que hizo seis cosas distintas.
Tampoco me convence el argumento comercial de fondo. Perplexity compite con Google, OpenAI y un ejército de wrappers que venden «búsqueda con IA» como commodity. SaC les da una narrativa técnica diferenciada: no somos un buscador con chat encima, somos infraestructura agentic. Vale. Pero para una pyme que solo quiere que su chat interno responda con fuentes fiables sobre stock, envíos o política de devoluciones, quiza el cambio en la práctica no sea tan obvio. Necesitas trazabilidad, costes predecibles y un comportamiento que no varíe cada vez que el modelo «optimiza» su pipeline. Un sistema que reescribe su propia lógica de búsqueda en cada petición es lo opuesto a predecible. Es brillante para demos y benchmarks; es un dolor de cabeza para compliance.
Lo del ahorro de tokens me parece la parte más sólida del discurso, y aun así hay matices. Sí, filtrar y rerankear en código antes de volcar resultados al contexto puede reducir ruido. Pero generar código también cuesta tokens, y depurar pipelines fallidos cuesta tiempo humano. En foros y conversaciones técnicas en inglés ya se debate si esto no es simplemente mover la complejidad del prompt al runtime: antes sufrías con prompts kilométricos; ahora sufrirás revisando scripts Python que el modelo ha escrito a las 3 de la mañana en producción. No es progreso gratis.
Comparado con el enfoque clásico —API de búsqueda estable, parámetros documentados, límites claros— SaC apuesta por flexibilidad extrema. Eso tiene sentido en Perplexity Computer, donde el usuario pide investigaciones abiertas del tipo «encuentra todos los informes sobre regulación de IA en la UE y cruza los con datos de inversión». Ahí un pipeline a medida puede marcar la diferencia. Pero extrapolar eso a cualquier producto que necesite search confiable me parece un salto. La mayoría de integraciones web que veo en clientes no necesitan un agente que programe su retriever; necesitan que la búsqueda no devuelva basura ni filtre documentos internos que no deberían salir.
Me quedo con una sensación de déjà vu. Cada vez que un actor de IA anuncia que el modelo «orquestará» algo que antes hacían ingenieros —SQL, llamadas API, ahora pipelines de búsqueda— el marketing habla de autonomía y el mercado aplaude. Seis meses después aparecen los postmortems: costes imprevisibles, resultados inconsistentes, equipos de soporte quemados explicando por qué el bot respondió distinto el martes que el lunes. SaC puede ser una pieza técnicamente seria; Perplexity no es un chiringuito. Pero confundir arquitectura de vanguardia con producto listo para empresas normales es el error que más veo repetirse.
Si gestionas webs, tiendas o herramientas internas, mi consejo es mirar esto como señal de hacia dónde va el mercado, no como invitación a replicarlo en tu stack mañana. Cuando tu proveedor de IA te ofrezca «search dinámico generado por el modelo», pregúntale por logs del código ejecutado, límites de primitivos, auditoría y qué pasa cuando el script falla a medias. Si no tiene respuestas claras, no es infraestructura; es demo empaquetada.
Perplexity ha dado un paso interesante y probablemente necesario para competir en agentes serios. Lo que no ha hecho —y sospecho que tampoco hará pronto— es explicar cómo lo vas a operar tú cuando algo falle un viernes a las 18:00. Esa es la brecha que separa papers de productos que aguantan facturación real.
Si mañana tu SaaS de atención al cliente te propusiera sustituir la búsqueda indexada clásica por pipelines Python escritos al vuelo por el modelo, con un 15% menos de tokens pero sin posibilidad de revisar el código antes de ejecutarlo, ¿lo aceptarías para datos de clientes reales?