La IA abarató el conocimiento, no el criterio: por qué la metodología es tu verdadero diferencial
Hoy cualquier persona puede abrir un chat, subir un Excel con 50.000 filas y escribir: «hazme un dashboard de ventas». En dos minutos tiene gráficos bonitos, código que corre y hasta un resumen ejecutivo con viñetas.
Y ahí aparece una sensación peligrosa: «si la IA hace esto, ¿para qué necesito saber de datos, de arquitectura o de metodología?»
La respuesta corta: porque la IA te entrega algo que parece una solución. Si ese algo resuelve el problema real o no, eso depende de un criterio que la herramienta no tiene. Y ese criterio, hoy más que nunca, es lo más valioso.
Cuando algo se abarata, lo que lo complementa se encarece
Durante décadas, ser buen profesional técnico significaba saber cosas: la sintaxis de SQL, los comandos de Pandas, cómo se configura tal librería. Ese conocimiento era escaso y por eso valía.
La IA generativa hizo que ese conocimiento sea casi gratis. Ya no hay que memorizar cómo se hace un GROUP BY; ahora escribes un prompt, se lo pides al modelo de tu preferencia y listo.
Los economistas Ajay Agrawal, Joshua Gans y Avi Goldfarb (autores de Prediction Machines) lo explican con una regla sencilla: cuando un insumo se vuelve barato, lo que lo complementa se vuelve más valioso. Si el código y el texto ahora son baratos, lo que sube de precio es lo que los complementa: el juicio humano.
Hay otra idea que encaja perfecto, la del filósofo Michael Polanyi (1966): «sabemos más de lo que podemos decir». La IA solo absorbe lo que alguien documentó y publicó. Pero resolver un problema real en una empresa depende de cosas que no están escritas en ningún lado: la política del comité directivo, las restricciones operativas que nadie documentó, cuánto riesgo está dispuesto a asumir el negocio.
Es lo mismo que pasó con el contenido: cuando todo el mundo puede generar el promedio de internet, el promedio deja de valer (lo conté en ¿El SEO murió con la IA?).
La frontera irregular: la IA es brillante… hasta que no lo es
El estudio más citado sobre esto es el de Fabrizio Dell’Acqua y colegas de Harvard Business School con Boston Consulting Group. En 2023, con GPT-4, pusieron a cientos de consultores a trabajar con y sin IA, y encontraron algo que ellos llamaron la frontera tecnológica irregular (jagged technological frontier): las capacidades de la IA no crecen parejas ni siguen nuestra intuición sobre qué es “difícil”.
Los resultados:
| Tareas dentro de la frontera | Tareas fuera de la frontera | |
|---|---|---|
| Ejemplos | Redactar borradores, transformar texto, formatear, generar ideas | Razonar causas, leer matices del negocio, auditar supuestos, detectar anomalías |
| Efecto de usar IA | +40% de calidad y 25,1% más rápido | −19 puntos porcentuales en la probabilidad de llegar a la respuesta correcta |
O sea: en las tareas donde la IA es buena, te vuelve mucho mejor. En las que no, te vuelve peor que si no la usaras. Y lo complicado es que desde afuera no se ve dónde está la línea. Con modelos más nuevos las magnitudes pueden ser distintas, pero el patrón de la frontera irregular sigue siendo la lección útil.
Centauros, Cyborgs y los que se quedan dormidos al volante
La misma línea de investigación identificó tres formas de trabajar con IA:
- Centauros: dividen el trabajo con una línea clara. Le delegan a la IA solo lo que domina y se quedan con el resto.
- Cyborgs: trabajan entrelazados con la IA, iterando y corrigiendo cada salida.
- Auto-automatizadores: aceptan lo primero que devuelve el modelo y dejan de pensar.
Este último grupo cae en lo que se llama complacencia por automatización: la respuesta suena tan segura y está tan bien redactada que dejas de revisarla. Te quedas dormido al volante.
El síntoma más común en las empresas: informes de 40 o 50 páginas perfectamente formateados, pero llenos de redundancias, sin contexto y desconectados de lo que se acordó en la reunión. Y ahora que modelos como Gemini 4 Argon pueden escupir un millón de tokens en una sola respuesta, el riesgo de producir “volumen que parece trabajo” es todavía mayor. Las evaluaciones muestran que lo fluido y legible de un texto generado tiene poca relación con que sea preciso. Al final, alguien tiene que leerse ese ladrillo para encontrar las tres ideas útiles.
Complejidad esencial vs. complejidad accidental
En 1986, Frederick Brooks (en su ensayo No Silver Bullet) separó dos tipos de complejidad en el software, y esa distinción explica casi todo lo que pasa hoy con la IA:
- Complejidad accidental: la que viene de las herramientas. La sintaxis, configurar el entorno, escribir código repetitivo (boilerplate).
- Complejidad esencial: la que viene del problema mismo. Las reglas del negocio, las relaciones de causa y efecto, qué significa realmente cada número.
La IA es buenísima eliminando la complejidad accidental. Con la esencial no puede.
| Fase del análisis | Lo que resuelve la IA (accidental) | Lo que exige tu criterio (esencial) |
|---|---|---|
| Ingesta | Scripts de paginación de APIs, parsear JSON, mapear tipos | Qué latencia necesita el negocio, cortes contables, qué hacer si el proveedor se cae |
| Modelado | Escribir los CREATE TABLE y las vistas | Elegir entre modelo operacional o dimensional, separar hechos y dimensiones, manejar dimensiones que cambian en el tiempo |
| Métricas | Programar las fórmulas en SQL, DAX o Python | Distinguir ventas brutas, ingresos diferidos y facturación neta; resolver la atribución multicanal |
| Visualización | Renderizar gráficos bonitos y responsivos | Que el gráfico sirva para una decisión concreta y no caiga en trampas de agregación |
El ejemplo clásico: el dashboard que duplica la facturación
Imagina que le pasas a la IA una tabla plana donde cada pedido aparece repetido por cada producto que contiene, con el valor total del pedido en cada fila. Le pides «suma la facturación por mes».
La IA va a sumar todo asumiendo que cada fila es independiente. Un pedido de $100 con tres productos aparece tres veces y termina contando como $300. El gráfico se ve perfecto. Los números están inflados. Y alguien va a tomar una decisión de presupuesto con eso.
Eso no es un error de sintaxis; es un error de modelado (lo que en ingeniería de datos se llama fan-out en relaciones uno a muchos). La IA no tiene ni idea de la “verdad” de tu empresa: solo predice patrones a partir de lo que le das. Por eso, en mi propio experimento de clasificación de órdenes de mantenimiento, lo primero que me dio resultados fue el análisis exploratorio de los datos, no el prompt.
Con la arquitectura de software pasa lo mismo. La IA te puede armar una plataforma de microservicios con colas de mensajes y Kubernetes… para un sistema que van a usar dos personas una vez a la semana. O al revés: una solución simplona para algo con alta concurrencia que se va a caer el primer día de ventas. Decidir qué patrón usar, cuándo y por qué, sigue siendo tu trabajo.
El síndrome de la novedad y la valla de Chesterton
La IA hizo que reescribir cosas sea fácil, y eso alimenta un vicio viejo de la ingeniería: el desarrollo impulsado por el currículum (Resume-Driven Development) o por la moda (Hype-Driven Development). Elegir tecnología porque se ve bien en el CV del desarrollador, no porque le sirva a la empresa.
Tres ideas clásicas que conviene tener a mano:
1. Elige tecnología aburrida
Dan McKinley, en su ensayo Choose Boring Technology, propone que cada organización tiene un presupuesto limitado de “tokens de innovación” (más o menos tres). La tecnología “aburrida” es la que lleva años en producción y cuyos fallos ya todo el mundo conoce.
Si tienes un e-commerce en WooCommerce o WordPress que ya vende, reemplazarlo porque “existe algo teóricamente mejor” es gastarte un token de innovación en infraestructura en vez de en tu negocio. Cada tecnología nueva trae su equipaje: integraciones, monitoreo, parches de seguridad y la dificultad de contratar a alguien que la sepa manejar.
2. Nunca reescribas desde cero
Joel Spolsky lo contó con el caso de Netscape, que decidió reescribir su navegador desde cero y le regaló años de mercado a Microsoft. Su regla: es más difícil leer código que escribirlo. Por eso el código viejo siempre parece un desastre. Pero cada parche raro que ves encierra un bug que se corrigió después de meses con usuarios reales.
3. La valla de Chesterton
Si encuentras una valla en medio de un camino y no sabes para qué está, no la tumbes hasta averiguar por qué la pusieron. Reemplazar un sistema solo porque la IA hace fácil escribir uno nuevo es tumbar la valla sin preguntar.
La triple deuda: técnica, cognitiva y de intención
Margaret-Anne Storey y su equipo plantearon que la IA no elimina la complejidad del desarrollo: la mueve de lugar. Su modelo de triple deuda lo explica muy bien:
| Deuda | Dónde vive | Cómo se ve |
|---|---|---|
| Técnica | En el código y la infraestructura | Código generado sin optimizar, consultas lentas, atajos que después cuestan |
| Cognitiva | En la cabeza del equipo | Nadie entiende a fondo cómo funcionan los módulos; fatiga de revisión; miedo a tocar el código |
| De intención | En las especificaciones y decisiones | Sistemas que compilan pero no resuelven lo que el usuario necesitaba; dashboards con números sin propósito |
La deuda técnica la puedes detectar con linters y pruebas. La cognitiva es silenciosa: el equipo revisa código que no escribió durante horas, por desconfianza, y aun así no termina de entenderlo. Si alguien clave se va, nadie sabe cómo funciona el sistema.
Y la de intención es la más traicionera. Cuando una solución se arma encadenando prompts sin escribir nunca qué se quería resolver, llega el día en que hay un incidente a las 3 de la mañana o cambia una regulación… y nadie sabe qué supuestos de negocio tenía el sistema.
La metodología no es burocracia: es la forma de pensar en orden
Las metodologías funcionan como dispositivos para disciplinar el pensamiento: definen qué preguntas hay que responder, y en qué orden, antes de gastar recursos.
- En analítica, CRISP-DM (el estándar de facto en minería de datos) no arranca eligiendo un algoritmo ni haciendo gráficos. Arranca con la comprensión del negocio: convertir un pedido difuso en objetivos concretos, restricciones y criterios de éxito. Solo después vienen los datos, el modelo, la evaluación y el despliegue.
- En software, TDD y ATDD hacen lo mismo: primero defines el comportamiento esperado y los casos de fallo, y después se escribe el código. Es justo lo que te propuse en desarrollo modular con IA: la especificación y las pruebas encierran a la IA para que ejecute, no para que improvise.
“Pero los agentes van a hacer todo eso solos…”
Es la objeción de moda. La respuesta está en los benchmarks:
| Benchmark | Qué evalúa | Resultado |
|---|---|---|
| InfiAgent-DABench | Análisis de archivos tabulares con Python | Bien en preguntas cerradas; se cae en análisis exploratorios abiertos |
| DABstep | Razonamiento de varios pasos sobre pagos y conciliaciones | Solo 14,55% de acierto de los mejores agentes en las tareas más difíciles |
| DataClawEval | 100 tareas de ingeniería de datos (PySpark, SQL, Flink) | Máximo 74,9/100, con mucha variación entre ejecuciones idénticas |
| LiveSQLBench / BIRD | Consultas SQL sobre bases de datos empresariales reales | Apenas 44,81% de éxito; claves foráneas inventadas y joins mal hechos |
Los agentes no reemplazan la metodología. La necesitan: alguien tiene que definir antes los esquemas, las pruebas y los límites. Sin eso, la automatización solo hace que los errores lleguen más rápido a tu base de datos.
Cuatro reglas prácticas para usar la IA con criterio
- Confianza proporcional al riesgo. Un análisis exploratorio interno puede ir casi en automático. Un dashboard con el que se decide presupuesto, una auditoría o un sistema en producción necesita revisión humana formal: tipos, linaje de los datos y definiciones de negocio de cada métrica.
- Encuadra el problema sin IA. En la fase de entender el negocio (la “comprensión del negocio” de CRISP-DM o la toma de requerimientos), reúnete con la gente, contrasta hipótesis y define los indicadores antes de abrir el chat. Cuando ya tengas acotada la complejidad esencial, ahí sí, usa la IA para acelerar la accidental.
- Antes de migrar, cuenta tus tokens de innovación. No desmontes un sistema que funciona y factura sin documentar primero por qué existe como existe. Gasta la innovación donde te diferencia del competidor, no en reinventar la infraestructura.
- Deja por escrito el porqué. Usa registros de decisiones de arquitectura (ADR), glosarios de términos y diccionarios de métricas. Así el conocimiento queda en el equipo y no en artefactos que nadie entiende.
En resumen
La IA hizo que el conocimiento explícito sea abundante y barato. Eso no te quita valor, te lo cambia de lugar: de saber la sintaxis a saber qué problema estás resolviendo, con qué datos y bajo qué supuestos.
Usada con método, la IA es un acelerador brutal. Usada sin método, es una fábrica de entregables bonitos, números inflados y sistemas que nadie entiende.
La herramienta ya la tiene todo el mundo. El criterio, no.
Fuentes y lecturas recomendadas
- Dell’Acqua, F. et al. (Harvard Business School / BCG): Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality.
- Harvard Business School: Cyborgs, Centaurs and Self-Automators: The three modes of human-GenAI knowledge work.
- Agrawal, A., Gans, J. & Goldfarb, A.: Prediction Machines: The Simple Economics of Artificial Intelligence y A Theory of Decision-Making and Artificial Intelligence (NBER).
- Brooks, Frederick (1986): No Silver Bullet: Essence and Accidents of Software Engineering.
- Storey, M.-A. et al.: From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI.
- Dan McKinley: Choose Boring Technology.
- Joel Spolsky: Things You Should Never Do, Part I.
- Benchmarks de agentes de datos: InfiAgent-DABench, DataClawEval y BIRD-bench.
- Artículos relacionados en este blog:
- Instalar 40 skills no te hace programador: desarrollo modular con IA
- Clasificar Texto Sucio a Gran Escala con JEV y Modelos Flash
- JEV y el Paradigma System One: decisiones sin generar texto
- Gemini 4 Argon: el salto al millón de tokens de salida
- ¿El SEO murió con la IA?
- Vibe coding sin Git es manejar sin frenos: qué es un control de versiones
Ideas, herramientas y lecturas de IA que merecen ser probadas
Análisis sencillo del paper Transformer de 2017: qué problema resolvió, cómo funciona la atención (Query, Key, Value), por qué cambió la IA y cinco formas prácticas de aprovechar ese conocimiento para escribir mejores prompts.
Por qué llenar tu agente de código con skills y prompts genéricos empeora el resultado, y cómo construir aplicaciones modulares con IA usando especificaciones (SDD), contratos tipados, design tokens y TDD.
Puse a prueba a JEV (TypeSafe AI) frente a Laya (ConvAI / ModernBERT) sobre un conjunto real de datos ruidosos. Evalué precisión zero-shot, calibración, manejo de taxonomías densas y privacidad. Estas son mis lecciones para elegir el modelo correcto.