Las 4 D de Anthropic: el marco de fluidez en IA

La IA generativa es un tipo de inteligencia artificial que crea contenido nuevo, en lugar de solo analizar datos existentes. La diferencia con la IA tradicional es clave: un clasificador de spam analiza y categoriza un mail que ya existe; un modelo generativo puede escribir un mail nuevo desde cero. El primer enfoque analiza y clasifica; el segundo crea algo que no existía.

Los modelos de lenguaje grandes (LLM, por large language models), son el tipo de IA generativa más conocido hoy. Se llaman “de lenguaje” porque están entrenados para predecir y generar lenguaje humano, y “grandes” porque contienen miles de millones de parámetros — valores matemáticos que determinan cómo el modelo procesa la información, de forma parecida a las conexiones sinápticas del cerebro.

Cómo se llegó hasta acá

El salto no fue repentino. Confluyeron tres desarrollos:

Arquitectura: la arquitectura transformer, presentada en 2017, cambió la forma en que los sistemas de IA procesan secuencias de texto manteniendo relaciones entre palabras a lo largo de pasajes largos — algo crítico para entender el lenguaje en contexto.
Datos: la explosión de datos digitales (webs, repositorios de código, texto de todo tipo) le dio a los modelos la materia prima para desarrollar una comprensión amplia y matizada del lenguaje y los conceptos.
Poder de cómputo: hardware especializado (GPUs, TPUs) y redes de cómputo distribuido (clusters) hicieron posible entrenar modelos sobre todos esos datos.

La combinación de estos tres factores llevó a un hallazgo importante: las leyes de escala (scaling laws). A medida que los modelos crecen y se entrenan con más datos y más cómputo, su rendimiento mejora de forma predecible — y, más sorprendente aún, aparecen capacidades emergentes que nadie programó explícitamente, como razonar paso a paso o adaptarse a tareas nuevas con instrucciones mínimas.

Cómo se entrena un modelo

El entrenamiento tiene dos fases:

Preentrenamiento: el modelo analiza patrones en miles de millones de ejemplos de texto, prediciendo qué palabra viene después una y otra vez. Al final de esta fase construye algo así como un mapa complejo del lenguaje y el conocimiento — pero es, literalmente, un “completador de documentos” muy competente, nada más.
Ajuste fino (fine-tuning): el modelo aprende a seguir instrucciones, dar respuestas útiles y evitar contenido dañino. Acá entra el feedback humano y el aprendizaje por refuerzo, que premia y penaliza comportamientos para hacer el modelo más útil, honesto e inofensivo.

Cómo funciona una interacción

Cuando le escribís a un LLM, le estás dando un prompt: texto que el modelo lee y continúa según los patrones que aprendió durante el entrenamiento. El modelo no busca respuestas prearmadas en una base de datos — genera texto nuevo que sigue estadísticamente a lo que escribiste.

Hay un límite práctico a cuánta información puede considerar un LLM a la vez: la ventana de contexto, algo así como su memoria de trabajo. Incluye tu prompt, las respuestas del modelo y todo lo demás que compartiste en la conversación. Aunque las empresas de IA la agrandan cada vez más, sigue siendo un límite real: el modelo no tiene acceso ilimitado a información y no puede usar contenido fuera de esa ventana sin herramientas especializadas (como búsqueda web).

Fortalezas y límites de los LLM

Lo que hace bien

Versatilidad lingüística: redactar mails con tu voz, condensar informes extensos, traducir, explicar temas complejos de cualquier campo.
Aprendizaje en contexto: puede pasar de ayudarte a escribir poesía a explicarte computación cuántica, sin entrenamiento adicional — solo con lo que le das en la conversación.
Memoria conversacional: mantiene el hilo de la charla, recuerda lo que se dijo antes y construye sobre eso.
Uso de herramientas externas: muchos LLM pueden conectarse a la web, procesar archivos o usar otras aplicaciones, lo que expande mucho lo que pueden ayudarte a hacer.

Dónde falla — y por qué

Cada límite se explica por cómo funciona el modelo por dentro:

Fecha de corte del conocimiento. El modelo no sabe nada de lo que pasó después de su fecha de entrenamiento. Necesita herramientas como búsqueda web para enterarse de novedades.
Alucinaciones. El entrenamiento no verifica cada dato, así que el modelo puede reproducir inexactitudes o combinar mal la información que aprendió, afirmando con total confianza algo que suena plausible pero es incorrecto. A diferencia de un buscador, que recupera documentos existentes, un LLM genera texto según patrones estadísticos — y ahí puede alucinar.
Límite de ventana de contexto. Si una conversación o documento la supera, el modelo deja de “ver” lo que quedó afuera (normalmente lo más viejo primero).
No determinismo. A diferencia del software tradicional, un LLM no siempre da la misma respuesta ante la misma pregunta — toma decisiones probabilísticas sobre qué texto sigue. Esto es útil para brainstorming, pero hay que tenerlo en cuenta cuando necesitás consistencia o precisión. Algunas interfaces exponen este control como “temperatura”.
Razonamiento complejo. Históricamente los LLM flaquean en problemas matemáticos o lógicos de varios pasos, aunque los modelos de razonamiento extendido (extended thinking) vienen mejorando mucho en esto.
Acceso a datos y herramientas específicas. Aunque un modelo pueda usar herramientas externas, si no tiene acceso a una fuente de datos o herramienta puntual, no va a poder ayudarte con eso — como un colega brillante sin acceso a la base de datos interna de tu empresa.

El marco 4D para la fluidez en IA

Usar bien la IA no es solo saber escribir un buen prompt. Es un conjunto de hábitos que se entrenan, y se puede resumir en cuatro competencias interconectadas: el marco 4D.

Las cuatro competencias son:

Descripción (Delineation)
Discernimiento (Discernment)
Delegación (Delegation)
Diligencia debida (Diligence)

Se organizan en dos ciclos que conviven todo el tiempo: uno interno, que pasa dentro de cada conversación con la IA, y uno externo, que pasa alrededor de esa conversación — en tu trabajo, tu equipo, tu responsabilidad.

Ciclo interno: Descripción + Discernimiento

Es el modo de interacción del día a día: el que ya conocés, aunque probablemente no lo estés explotando del todo.

Descripción

Describir es comunicarte eficazmente con la IA, y va mucho más allá de “escribir un buen prompt”. Implica definir:

qué resultado esperás,
el formato,
el público objetivo,
el estilo,
y el enfoque de razonamiento que querés que siga la IA.

No es lo mismo pedir “resumime este informe” que pedir “resumí este informe para un público ejecutivo no técnico, centrándote en los tres hallazgos de mayor impacto, en menos de 300 palabras”.

También podés moldear el rol que cumple la IA en la interacción:

¿necesitás un crítico que cuestione argumentos débiles?
¿un compañero de brainstorming?
¿un verificador de hechos que señale incertidumbre?

Se puede pedir todo eso — y combinarlo.

La descripción es la habilidad que la gente adquiere más naturalmente: especificar lo que quiere, dar ejemplos, refinar el pedido. Es un buen punto de partida, y mejora con la práctica.

Discernimiento

Es el complemento de la descripción: evaluar de forma crítica y reflexiva lo que la IA te devuelve.

¿Son precisas estas estadísticas?
¿El lenguaje refleja cómo habla realmente tu público sobre este tema?
¿La IA tuvo en cuenta todos los factores relevantes?

El discernimiento no es aceptar o rechazar el resultado en bloque. Es un proceso iterativo: describís, evaluás, ajustás la descripción según esa evaluación, y volvés a intentar — como afinar el entendimiento con un compañero de equipo humano.

Mientras que describir es algo que la mayoría ya hace con cierta naturalidad, el discernimiento es mucho más dificil de lograr porque necesita de un conocimiento del resultado que se quiere mucho más profundo. Cuestionar el razonamiento de la IA, verificar hechos, identificar qué contexto falta. Y justamente ahí es donde hay más margen de mejora, porque es lo que sostiene una colaboración real con la IA (no una delegación ciega).

Ciclo externo: Delegación + Diligencia debida

Usar bien la IA en una conversación puntual es solo una parte del problema. La otra parte es entender las implicancias de cómo y cuándo la usás en tu trabajo, tu equipo y tu contexto.

Delegación

Delegar es decidir qué trabajo hacen los humanos, qué trabajo hace la IA, y cómo se reparten las tareas. Requiere entender dos cosas:

El trabajo en sí. Antes de redactar un mail, preguntate: ¿es una actualización de estado rutinaria, donde la IA puede armar un primer borrador? ¿O es una negociación delicada donde el tono tiene que salir de vos?
Las herramientas. Si trabajás con datos sensibles, tenés que conocer las características de privacidad y seguridad del sistema de IA que estás usando.

Cuando entendés bien el trabajo y la herramienta, podés dividir tareas de forma inteligente, aprovechando las fortalezas de cada uno.

Diligencia debida

Es la contracara de la delegación: asumir la responsabilidad por cómo usás la IA.

Ser intencional sobre qué partes hace la IA y cuáles requieren tu propia experiencia.
Ser honesto sobre el rol de la IA frente a las personas que necesitan saberlo — tus colegas y stakeholders merecen entender cuándo y cómo se usó.
Verificar y avalar cada resultado antes de compartirlo: confirmar su exactitud y asegurarte de que el producto final represente fielmente tus objetivos y estándares.

[!No olvidar] Sos siempre responsable del resultado final, uses o no IA para llegar a él.

Delegación y diligencia también funcionan en ciclo: las decisiones que tomás sobre qué delegar tienen que ir acompañadas de una responsabilidad continua sobre cómo lo usás — y esa práctica diligente, con el tiempo, te hace tomar mejores decisiones de delegación.

Las 4D en acción

Delegación — decidís qué tareas gestiona la IA y cuáles hacés vos.
Descripción — usás descripciones detalladas para guiar el trabajo de la IA.
Discernimiento — evaluás críticamente los resultados.
Diligencia debida — elegís las herramientas adecuadas, sos transparente sobre el rol de la IA, y asumís la responsabilidad de la precisión.

El marco 4D aplicado a construir software

Delegación: el kit de herramientas del constructor

Si dedicaste tiempo a programar con IA, ya notaste esto: lo difícil no es lograr que la IA escriba código, sino saber qué código querés que escriba. Delegar no es una decisión de sí o no — es mucho más granular.

Imagínate liderando un proyecto donde la IA es tu equipo. Un buen líder no solo asigna tareas — plantea el problema para que todos entiendan qué están resolviendo, define qué significa un buen resultado, y decide qué tareas delega y cuáles se queda para sí. Eso empieza mucho antes de escribir la primera línea de código.

Todo constructor tiene un kit de herramientas de seis capacidades, y la IA no rinde igual en todas:

👀 Empatía — ¿qué necesita realmente la persona para la que estás construyendo? No lo que dice que quiere, sino lo que de verdad le va a servir. Esto sale de hablar con usuarios y observar, no de la IA.
📝 Diseño — ¿qué deberíamos construir y por qué? Decisiones de criterio (¿mensaje de texto o página web? ¿tiempos exactos o rangos?). La IA puede generar opciones; la decisión es tuya.
🏗️ Arquitectura — ¿cómo se estructura? La IA conoce patrones de miles de sistemas parecidos, pero no conoce tus restricciones ni hacia dónde va a crecer tu equipo. Acá la combinación humano+IA funciona muy bien.
💻 Implementación — escribir el código en sí. Acá la IA es más fuerte, siempre que ya sepas qué construir y cómo estructurarlo. Es la capacidad que más conviene delegar.
⚖️ Juicio — ¿funciona de verdad? ¿es bueno? ¿pondrías tu nombre? La IA te dice que el código corre, no si resolviste el problema real.
🚀 Despliegue — llevarlo a usuarios reales y aprender de lo que pasa: comunicación, medición, iteración. La IA puede redactar notas de lanzamiento, pero no interpreta por qué un usuario duda antes de hacer clic.

La forma de esta lista importa: la implementación está en el medio, y ahí es donde la IA es más fuerte. Empatía, juicio y envío están en los bordes, y ahí es donde la IA es más débil — y donde vive el valor del trabajo humano.

Los constructores que van a destacar no son los más rápidos, sino los que plantean bien el problema, saben cómo se ve un buen resultado antes de empezar, y distinguen entre código que funciona y código que importa.

Descripción: traducir la necesidad del usuario

Describir no es “prompt engineering”. Es una competencia de más alto nivel, que sigue siendo relevante aunque cambien los trucos de cada modelo puntual. Se puede pensar como una cadena de cuatro pasos, donde el constructor actúa como traductor:

Voz del usuario — lo que dice una persona real, con su tono, su emoción y todo el contexto que no dice en voz alta. Ej.: “quiero ver los tiempos de espera antes de ir a la clínica” — detrás puede haber dos horas de espera, un hijo enfermo en el auto, la duda entre esta clínica y la guardia del otro lado de la ciudad. Es materia prima real, pero todavía no construible.
Requisito de producto — tomás esa necesidad cruda y la volvés medible: “los pacientes pueden ver el tiempo de espera estimado en una web mobile-friendly, actualizada cada 5 minutos”. Cada palabra ahí es una decisión de criterio (mobile-friendly y no app, estimado y no exacto, cada 5 minutos y no en tiempo real) basada en tu propio trabajo de empatía.
Especificación técnica — ya es construible: “una web app que consulta la API de la clínica y muestra los tiempos con una UI responsive, actualizando cada 5 minutos”. Un ingeniero (o una IA) puede empezar a construir con eso, aunque todavía deja huecos: ¿qué stack? ¿cómo se manejan los errores?
Instrucción para la IA — específica, contextualizada, con restricciones y casos límite bien definidos: el stack, la forma de los datos, qué hacer si no hay datos, y los tests que tiene que pasar.

La IA no puede escuchar lo que el usuario no dijo, ni decidir que “estimado” es mejor que “exacto” porque un tiempo exacto pondría nervioso al personal de la clínica. Eso lo sabés vos, y tu trabajo es llevarlo intacto a través de los cuatro pasos.

Cuando la traducción se rompe en algún paso, aparece un tipo de falla específico: código que funciona, pero el producto no. Los tests pasan, el usuario sigue frustrado. Eso no es un bug — es una falla de descripción, y suele estar río arriba del prompt. Vale la pena diagnosticar en qué eslabón se rompió: ¿no entendiste al usuario? ¿lo entendiste pero definiste mal el requisito? ¿el requisito estaba bien pero la especificación técnica perdió algo? ¿o todo lo anterior estaba bien y simplemente instruiste mal a la IA?

[!Un detalle importante] Los tests de aceptación también son descripción — quizás la forma más potente, porque no se puede malinterpretar algo que pasa o no pasa. Darle a la IA un set de tests junto con el prompt no solo le dice qué construir, le dice cómo vas a saber si lo logró.

Discernimiento: cinco lentes para evaluar código

Un producto que funciona y un buen producto no son lo mismo. Cuando la IA puede producir algo funcional en minutos, distinguir esa diferencia se vuelve la habilidad más valiosa. Hay cinco lentes — la mayoría de la formación en ingeniería se queda en las primeras dos:

Integridad funcional — ¿funciona de verdad? Bugs, fallas, vulnerabilidades. Es donde suele terminar el code review tradicional; necesario, pero insuficiente. Hábito clave: pedile a la IA que escriba los tests junto con el código, no después — y corré esos tests, porque un test suite que nunca se ejecuta no es una red de seguridad, es una falsa sensación de seguridad.
Preparación para producción — ¿funciona bien? Rendimiento, escalabilidad, fiabilidad bajo carga. La IA tiene puntos ciegos acá. Conviene pedirle explícitamente que someta su propio código a prueba de estrés y que diga qué supuestos de producción hizo.
Ajuste (fit) — ¿es lo correcto? ¿resuelve el problema real del usuario o el problema que el usuario cree tener? El paciente preguntó por tiempos de espera, pero lo que realmente necesitaba saber era si había un pediatra disponible en 20 minutos. La IA resuelve el problema planteado — verificar si es el problema real es tuyo.
Calidad de experiencia — ¿es realmente bueno? ¿claro, intuitivo, accesible? La IA no tiene gusto, tiene patrones: te va a dar una interfaz competente que nadie disfruta usar. En un contexto clínico esto no es solo estética, es seguridad del paciente.
Impacto responsable — ¿es responsable? Sesgos, privacidad, consecuencias no buscadas. Si el algoritmo de tiempos de espera se entrena con datos históricos que reflejan desigualdades sistémicas, puede reproducir ese mismo patrón — y no te lo va a señalar, simplemente va a mostrar un número.

Los problemas más grandes casi nunca aparecen en la lente uno. La IA es buena generando código que corre; necesita tu supervisión para producir algo que de verdad importe. Y hay una señal útil sobre tu propio proceso: cuando algo no está lo bastante bien, ¿lo arreglás vos mismo o volvés atrás y describís mejor lo que necesitabas? Ese patrón te dice si estás desarrollando discernimiento o solo construyendo.

Diligencia debida: hacerte cargo de lo que compartís

Con IA podés terminar siendo dueño de código que no escribiste. La diligencia es ponerte al día con ese código, entenderlo, someterlo a prueba y detectar los errores que se escapan.

Tres hábitos de un buen ingeniero:

Recrear el paso de “¿qué no pensé?” Cuando programás vos mismo, en el camino notás casos límite y decisiones que no habías anticipado. Con IA, esas decisiones a veces se toman sin que te enteres — así que preguntale explícitamente: “¿podés verificar que los usuarios no puedan ver archivos de otros usuarios?”
Preguntar qué supuestos y concesiones hizo. Después de que la IA construya algo sustancial: “¿qué suposiciones hiciste? ¿de qué riesgos de seguridad debería estar al tanto?”.
Divulgar el uso de IA como información, no como disclaimer. Si la IA escribió la mayor parte de un PR, decirlo en la descripción — porque la IA se equivoca distinto a como se equivocan los humanos (APIs obsoletas usadas con confianza, código prolijo localmente pero inconsistente con el resto del codebase, comportamiento inventado para casos que nunca especificaste). Un revisor que sabe eso puede ajustar mejor su revisión.

==Las buenas prácticas de ingeniería de antes de la IA siguen valiendo== — quizás más, porque ahora enviás más rápido y entendés una fracción menor de lo que enviaste. Tests sólidos, observabilidad (logs, tracking de errores, dashboards) y feature flags no desaparecieron: son lo que te permite ir rápido con seguridad.

Cómo se aplican las 4D juntas

Delegá primero. Antes de abrir el editor, desglosá el problema. Implementación, andamiaje, plantillas, primeros borradores: candidatos sólidos para la IA. Las decisiones de criterio, entender al usuario real, y decidir si lo construido es lo correcto: eso es tuyo.
Describí con cuidado. No es solo “qué programar” — es la voz del usuario, el requisito de producto, la especificación técnica, la instrucción y los tests. Una tarea bien descrita, con criterios de aceptación claros, trata a la IA como a un colaborador junior competente con instrucciones precisas.
Aplicá discernimiento mientras trabajás. ¿Funciona? ¿Funciona bien? ¿Es lo correcto? ¿Es responsable? A veces la IA construye exactamente lo que describiste, pero no lo que resuelve el problema.
Practicá diligencia antes de enviar. Prototipá libre — así se aprende — pero enviá selectivamente. Antes de que algo llegue a usuarios reales: ¿entendés qué hace? ¿podés explicarlo? ¿hay forma de saber si funciona? Y hay que estar dispuesto a frenar algo propio cuando las pruebas dicen que no anda — el costo hundido es de lo más difícil de soltar, pero el trabajo del desarrollador está al servicio del usuario, no de defender el software.

Las cuatro D no son un checklist lineal: son dinámicas. Vas a pasar de delegación a descripción, de ahí a discernimiento, y vas a terminar delegando distinto la próxima vez. Esa es la fluidez en IA desarrollándose en la práctica.

Por qué importa

El objetivo del marco no es “aprender a usar IA” como fin en sí mismo. Es liberar tiempo y cabeza para el trabajo que de verdad importa: el que requiere criterio humano, creatividad y conocimiento profundo del contexto. Eso no lo reemplaza la IA — lo protegés desarrollando estas cuatro competencias.

Fuentes: Anthropic (Anthropic Academy) — “What is generative AI”, “The 4D Framework for AI Fluency”, “Delegation & the builder’s toolkit”, “Describing what users need”, “Discernment for code”, “Diligence & sharing your work” y “Looking forward”.