AI Fluency for Builders — Resumen de estudio

Paths: Developer · Architect · FDE · 10 lecciones, 9 videos (desarrollado con CodePath)
El 4D Framework aplicado a quien construye producto (PM, diseño, ingeniería), con un proyecto que recorre todo el curso: Clinic Wait Time Checker. (El quiz final no lo has presentado; hazlo en Skilljar.)

1. Ideas base

Los builders son dueños de todo el arco: del problema del cliente a la solución publicada.
AI Fluency = trabajar con IA de forma efectiva, eficiente, ética y segura.
Delegar la implementación suele ser seguro; delegar el juicio, no.
La mayoría de los fallos de la IA vienen de errores previos de description, discernment o diligence.
Builder brief: un documento de contexto reutilizable que pegas al inicio de cada proyecto: qué construyes y para quién, tu rol, restricciones (equipo, stack, plazos, no negociables), dónde quieres IA y dónde no.

2. El 4D Framework

D	Qué es	Loop
Delegation	Decidir qué hace la IA y qué te quedas tú	Externo (decisiones grandes)
Description	Comunicar con claridad qué necesitas y cómo quieres que lo aborde	Interno (interacciones diarias)
Discernment	Evaluar lo que devuelve antes de actuar	Interno
Diligence	Hacerte plenamente responsable del resultado, sin importar el papel de la IA	Externo

Modos de colaboración:
- Automation: la IA lo hace y tú revisas.
- Augmentation: lo trabajan juntos.
- Agency: la IA opera con libertad dentro de límites que tú defines.

3. Cómo funciona la IA (capacidades y límites)

Genera contenido nuevo (no solo analiza).
Tres avances la hicieron posible: la arquitectura transformer, enormes datos de entrenamiento y cómputo masivo.
Entrenamiento: pre-training (patrones) → fine-tuning (seguir instrucciones de forma útil).
Fortalezas: versatilidad, fluidez conversacional, tool use.
Límites: fecha de corte, alucinaciones (p. ej. librerías o APIs inventadas), razonamiento complejo poco fiable.
Lo mejor: tu juicio, creatividad y supervisión + la velocidad y escala de la IA.

4. Delegation y el toolkit del builder

Etapa	Fuerza de la IA
Empathy (entender para quién construyes)	Débil: puede sacar datos o personas, pero no siente la necesidad
Design	Moderada: genera patrones rápido; tú pones el gusto y el contexto
Architecture	Moderada: conoce patrones; tus restricciones las defines tú
Implementation	Fuerte: delega con libertad
Judgment (qué es correcto y suficiente para publicar)	Débil: lista opciones, no puede tomar la decisión
Shipping	Moderada: automatiza pasos; la responsabilidad es tuya

Primero descompón el problema y luego decide qué hace la IA en cada etapa.
Escribe los acceptance tests antes del código: son la definición compartida de "terminado".
- ✅ "Un paciente con un smartphone básico encuentra el tiempo de espera en menos de 30 s sin crear cuenta."
- ❌ "Es fácil de usar."
A medida que la IA acelera la implementación, tu valor está en plantear el problema y subir el estándar.

5. Description: la Description Chain

Voz del usuario → requisito → especificación técnica → instrucción a la IA. Prompt engineering es solo un eslabón.
El builder traduce en cada paso: la IA no puede oír lo que el usuario no dijo.
"El código funciona pero el producto no" = un fallo de description; busca el eslabón que se rompió.
Los tests son la forma más precisa de description. Si el test pasa y el usuario no está contento, describiste la intención equivocada.
Requisito: cada adjetivo es una decisión defendible ("rápido" = ¿cuánto?).
Tests de edge cases: clínica cerrada, sin datos, espera de cero.
Demo sin explicar ni ayudar (tu compañero hace de paciente con un niño enfermo y diez minutos).

6. Discernment para código: los 5 lentes

Functional Integrity (¿funciona?): salida correcta con datos reales. Fallo típico de la IA: pasa los unit tests pero falla con datos que el prompt no cubrió.
Production Readiness (¿funciona bien?): concurrencia, carga. Fallo: va bien en desarrollo y se rompe bajo carga o en la infraestructura real.
Problem Fit (¿es lo correcto?): resuelve la necesidad real. Fallo: cumple el prompt pero no la necesidad.
Experience Quality (¿es bueno?): se usa sin ayuda. Fallo: UI genérica que "funciona" pero no convence.
Responsible Impact (¿es responsable?): transparente sobre el papel de la IA. Fallo: contenido generado presentado como verificado, o un grupo excluido por defecto.

Puntos ciegos predecibles: concurrencia, seguridad y lo que solo falla a escala.
El gusto es una habilidad del builder: la IA entrega algo funcional; que valga la pena usarlo depende de ti.

7. Discernment para UX (4 principios)

Clarity: cada elemento comunica su propósito ("Place Order — $16.50" y no "Submit"; símbolo de moneda).
Hierarchy: el peso visual sigue la prioridad (el total y la hora de llegada destacan).
Accessibility: ~1 de cada 5 personas tiene alguna discapacidad. Evita señales solo por color, texto de 9px y jerga ("qty", "ETA", "T&C"). La IA no la resuelve bien por defecto: especifícala y audítala (contraste, lector de pantalla, teclado).
Feedback: ante un error, qué pasó, qué hacer y cómo pedir ayuda ("Error 503" no le dice nada al usuario).
"Make it look good" es un deseo, no una especificación. Describe la experiencia con la precisión de una función. Una buena crítica y una descripción ejecutable para la IA son artefactos distintos: aprende a traducir entre ellos.

8. Diligence: hazte responsable de lo que publicas

Eres dueño del resultado, no del output. "Lo escribió la IA" no explica ni justifica nada.
Al publicar aparece vocabulario técnico (migrations, versioning, rate limits, feature flags) que la IA no menciona si no preguntas.
Los tests hacen segura la iteración después del lanzamiento.
Prototipa con libertad, publica con criterio. Ten la disposición de retirar algo cuando la evidencia dice que no funciona.
El acceso es una decisión de diseño: ¿a quién excluyen tus supuestos?
Checklist antes de publicar: ¿entiendes qué hace el código? ¿pasan los tests (con edge cases)? ¿a quién no sirve bien? ¿se puede malinterpretar o usar mal, y fuiste transparente con la IA? ¿cómo sabrás si funciona después del lanzamiento?

9. Cierre

La IA es más fuerte en el centro del toolkit: delega la implementación y conserva la empatía, el juicio y el shipping.
Las 4D son dinámicas, no una secuencia: moverse con fluidez entre ellas es la fluidez real.
Tu siguiente proyecto: una tarea real y pendiente, recorrida con las 4D (cadena completa de description, 5 lentes, preguntas de diligence).