PDD sin humo: mi workflow real para producir 3x más

¿Qué es PDD?

Prompt Driven Development no es magia. Es un método.

Ahora, la promesa: con Claude y Cursor produzco entre dos y tres veces más código: —el artefacto.

Cantidad y calidad no son lo mismo, pero si sabes lo que estás haciendo y no escribes prompts a lo loco, tu también puedes hacer lo mismo sin comprometer la calidad final.

Esta es mi forma real de trabajar con IA como Frontend senior. Sin hype, sin role prompting, sin copiar y pegar.

Y sí: funciona. Pero por supuesto, también tiene sus inconvenientes. Te hablaré de esto al final.

Andrew Ships popularizó el término "Prompt Driven Development", describiendo cómo construyó una aplicación completa sin escribir código.

Aquí voy más allá: cómo usar PDD desde la perspectiva del senior que necesita código mantenible, escalable y que encaje en proyectos reales.

Mi workflow

Este es mi proceso aproximado cuando me encargo de una tarea. Da igual su magnitud y complejidad.

flowchart LR
    A[Tarea recibida] --> B[Gestión de contexto]
    B --> C[Generar código]
    C --> D[Revisión pormenorizada]
    D --> E{¿Cumple estándares?}
    E -->|Sí| F[Integrar en proyecto]
    E -->|No| G[Refinar prompt]
    G --> H[Regenerar código]
    H --> D

Vamos a desglosarlo paso a paso.

Mi configuración

Trabajo con Vue 3, TypeScript y Composition API. Uso Cursor como editor principal, donde adjunto archivos y contexto directamente a los prompts, lo cual convierte cada interacción con el modelo en una conversación con contexto estructural real.

Nunca uso plantillas de prompts ni archivos de reglas genéricos. En mi experiencia, ese tipo de automatismos crean más rigidez que claridad. Prefiero construir cada prompt desde cero, con intención y conocimiento del proyecto. No automatizo el criterio: lo ejerzo.

Mi forma de interactuar con el LLM es exclusivamente a través del modo Agent, que mantiene continuidad conversacional. El modelo que uso (en el momento de escribir esto) es Claude Sonnet v4, y cuando la tarea lo exige, recurro a Claude MAX, de forma puntual.

Paso 1: Preparar el contexto

Como primer paso, dedico toda mi atención a construir el contexto más completo posible. Claude (o cualquier LLM) no adivina, razona si tiene contexto:

Historia completa

• Tarea de JIRA (u otro sistema) con imágenes (Claude las procesa y entiende sin problema).
• Criterios de aceptación.
• Implementaciones similares.
• Casos edge relevantes.
• Fricciones y problemas anteriores.
• Restricciones técnicas del entorno.
• …y cualquier información que considere apropiada.

Ejemplo de arquitectura del proyecto

• Composition API.
• Vuex como global state store.
• Nuestro custom validator para formularios.
• Estructura en capas: API - domain - UI.
• Coleccion de composables (multi-layer).
• Ejemplos de otras features que tienen relación.

Paso 2: Adjuntar el contexto

Es aquí donde comienza mi interacción real con el LLM.

Cursor permite adjuntar archivos directamente al prompt. Esto evita copiar y pegar y mejora drásticamente la coherencia del código generado. Siempre incluyo:

• Ejemplos reales: componentes o features similares (para referencia estructural).
• Diagramas y esquemas de flujo de datos.
• Capturas y representaciones de layouts UI (Figma, por ejemplo).
• Tipos TypeScript cuando el dominio es complejo o poco evidente.
• Archivos de configuración, variables de entorno o todo aquello que considere imprescindible para que el LLM se haga una idea global.

Hey Claude, I need to implement new AVO event actions to @useSetupGuideTracking.ts. Please remember what we recently did in @useSetupGuideDirector.ts because we need to follow the same pattern and composable structure. I've also added a mermaid diagram with the flow and a table detailing all events to implement.

Factory Functions -> Broadcast -> Reception -> Call AVO API

Technical context
- Use our AVO wrapper (@/utils/analytics/avo.ts)
- Event names: setupGuide_[action]_[context] convention
- Error handling: silent failures with fallback logging

Known issues to avoid
- Double event firing (see useSetupGuideDirector debouncing solution)

Acceptance criteria
1. Same pattern as Director composable
2. TypeScript types exported
3. Unit tests for factory functions
4. No breaking changes to existing tracking

BEFORE proceeding, do you fully understand what we have to do? Also, BEFORE starting, can you elaborate on how you will tackle this task? I would like it executed as atomically as possible, ideally each step should be an independent commit.

Al adjuntar archivos y contexto real (de la base de código) el modelo trabaja anclado a mi estilo y estructura.

Paso 3: Elegir el marco de control

Dependiendo de mi experiencia en el sistema en el que tengo que trabajar, elijo entre estas dos opciones.

1. Claude toma la iniciativa y describe su propia aproximación.
2. Indicarle claramente cómo lo haría yo, aunque siempre esté abierto a un desafío.

Verás, para mí Claude (y de nuevo, cualquier otro LLM) es un Junior con una memoria prodigiosa. Debes cederle la iniciativa, pero siempre bajo tu supervisión. Confía, pero verifica.

Examinemos cada opción más detenidamente.

Explorar con el LLM

Si mi conocimiento es superficial (o, directamente, no tengo ningún conocimiento) dejo que Claude use su capacidad sobre humana para ir tirando del hilo y entender (y de paso, ayudarme a mí a entender) el sistema en el que tengo que operar.

Esta es una de las habilidades para mí más especiales de un LLM: la capacidad de analizar y llegar a conclusiones de forma infinitamente más rápida que un humano. Ojo, no estoy diciendo que las conclusiones tengan que ser las correctas. Hablo de un loop mucho más corto. Tocaré este tema más adelante.

Utilizar mi propio criterio como base

En el segundo caso —suponiendo que tenga experiencia en esa área del sistema— indico a Claude cómo lo resolvería, paso a paso. Una vez más, dando todos los detalles que pueda.

Así dejo claro mi criterio (es solo un ejemplo) antes de que escriba código:

+ Usaría `@vueuse/core` + `IntersectionObserver` si el número de filas supera las 1000 (virtualización).
+ Ordenaría localmente si `items.length < 1000`; en caso contrario, implementaría sorting en servidor vía `query params`.
+ Manejaría los estados `loading`, `error`, `empty` y `success` de forma explícita, controlados vía `computed` y `ref`.

Además, seguiría nuestro patrón habitual:
- Los datos llegarían desde un `composable` (`useProductsTable`) que encapsula lógica y estado.
- El componente `ProductTable.vue` recibiría props puras y emitiría eventos controlados (`update:sort`, `row:click`, etc).

Esto activa la IA como colaborador técnico, no como autocompletador.

Ver por qué funciona mejor que el role prompting vacío

Cómo evitar que el modelo se precipite

Uno de los patrones más habituales al trabajar con modelos como Claude es su tendencia a anticiparse. El modelo, por diseño, intenta ser útil cuanto antes. Eso a menudo se traduce en generar soluciones completas sin haber procesado del todo el contexto.

Esto puede parecer eficiencia, pero es ruido.

Para evitarlo, dejo muy claro desde el principio que no quiero propuestas hasta que esté seguro de que ha entendido cada punto. Le pido confirmación explícita. Si acepta, tratamos cada elemento como una unidad independiente (que puede ser un commit, por ejemplo).

Este es un ejemplo más o menos literal de cómo lo formulo (sin las palabras malsonantes):

... (resto de promt, que ya hemos generado)

Claude, ANTES de que me propongas nada NECESITO que me asegures que entiendes todo. Tómate tu tiempo.
Por otro lado, quiero tratar cada uno de estos puntos como TAREA INDEPENDIENTE.

¿Queda claro?. Necesito CONFIRMACIÓN. Gracias.

La experiencia mejora drásticamente cuando defines las reglas del intercambio desde el inicio. El objetivo no es que el modelo se adelante: es que te acompañe con precisión.

Delegación total, supervisión total

Para mi, una de las claves del Prompt Driven Development es saber qué puedes delegar… y qué no debes delegar jamás.

No se trata de “automatizar” tu trabajo. Se trata de identificar qué partes del proceso requieren juicio humano —arquitectura, intención, contexto— y cuáles pueden ser resueltas por un modelo con capacidad de síntesis y consistencia.

Qué delego sin dudar

Todo lo que sea estructurable, predecible y repetible puede pasar por manos de Claude. Especialmente:

• Boilerplate: componentes estructurales, hooks reutilizables, helpers. Si la lógica ya está definida en otro lugar del proyecto, que la IA se encargue de replicarla con coherencia.
• Transformaciones de datos: mapeos entre capas, parsers de estructuras anidadas, validadores. Aquí Claude brilla: no se salta reglas si se las das claras.
• Lógica de UI: visibilidad de elementos, estados visuales (loading, error, empty, etc.), eventos (@click, @keyup, etc.). Siempre que la lógica no dependa del negocio, es terreno seguro.
• Testing estructural: unit tests para funciones puras, mocks básicos, generación de fixtures. Le das un patrón y te devuelve una suite completa lista para pulir.

Claude es rápido, consistente y no se distrae. Pero eso no lo hace infalible.

Qué superviso siempre

Todo lo que tiene impacto directo en la calidad del producto o en el entendimiento futuro del código debe pasar por mis manos:

• Lógica de negocio: reglas que no están en la documentación, que cambian según el cliente, que definen el core del proyecto. Claude puede escribir código funcional… pero no puede leer entre líneas de negocio.
• Integraciones con APIs: autenticación, headers, paginación, gestión de errores, acuerdos contractuales entre servicios. Aquí cualquier asunción errónea puede romper producción o exponer datos.
• Rendimiento: evitar renders innecesarios, reducir payloads, dividir bundles, memoizar cálculos. Claude no tiene métricas. Tú sí.
• Accesibilidad: navegación por teclado, etiquetas aria-*, focus management, roles correctos. La accesibilidad no se improvisa. Se conoce, se aplica y se valida.

El superpoder invisible: tu base de código indexada

Otro de los cambios más notables es mi capacidad de respuesta y ayuda en mi día a día como profesional que trabaja en un equipo (bastante grande). Antes, cuando alguien en Slack preguntaba:

¿Dónde está esto en el código?.

¿Por qué se hace así esta parte?.

¿Quién sabe qué devuelve esta función?.

…tenías que tirar del hilo manualmente: grep, abrir archivos, buscar a mano.

Ahora, si tu base de código está bien indexada (por ejemplo, en Cursor), eso se acabó.

Puedes preguntar directamente al modelo:

Hey Claude, en @UserProfile.vue ¿qué hace useUserSession y por qué inyecta legacyToken en lugar de accessToken?.

Y tienes una respuesta en segundos. No perfecta, pero increíblemente útil como punto de partida.

Eso cambia el juego.

El contexto estructural de tu base de código es, probablemente, el mayor multiplicador de velocidad real que un LLM puede ofrecer en equipos con proyectos grandes.

Acorta el tiempo entre duda y pista.

Acorta el tiempo entre sospecha y evidencia.

Y no es magia: es tener 4.823 archivos indexados y preguntarle al modelo como si llevara años en tu equipo.

Esta funcionalidad no te da respuestas definitivas, pero reduce la fricción cognitiva brutalmente.

• Como senior, lo notas enseguida: el loop de validación se acelera.
• Como junior, te da independencia y reduces el tiempo muerto entre bloqueos.

Eso sí: el modelo no razona por ti. Solo te da atajos hacia el razonamiento.

Validar sigue siendo tu trabajo.

El ROI del tiempo invertido en prompts

Un prompt bien construido no es una pérdida de tiempo: es una inversión de alto rendimiento.

Cuando trabajas con modelos como Claude, el resultado depende casi por completo del contexto que entregas. Si le das una descripción vaga, obtendrás código genérico, mal adaptado y lleno de suposiciones. Y corregir eso —aunque parezca “más rápido” al principio— se convierte en un pozo de tiempo y energía.

La diferencia real no está en escribir el prompt o no escribirlo. Está en cuándo vas a pagar el precio: ahora, en la fase de planificación… o después, en forma de debugging, pruebas fallidas, adaptaciones forzadas y código que no se integra con lo que ya existe.

La diferencia no es solo de tiempo. Es de energía cognitiva y de desgaste técnico.

Cada error cuesta más si no entiendes de dónde salió el código.

Cada refactor es más doloroso si el modelo asumió cosas que tú nunca dijiste.

Invertir 20 minutos en construir un prompt sólido puede reducir en un 80% el coste total de una tarea, y además deja un artefacto reutilizable para futuras tareas similares.

No es escribir más. Es pensar mejor, una vez.

El miedo que hay que superar

Este es el elefante en la habitación, ya que, aunque no se quiera hablar de ello, existe una ansiedad legítima:

¿Soy profesional si no escribo todo el código?.

Y una duda social:

¿Estoy engañando a mi equipo?.

Créeme, he pasado por ahí.

Te cuento una anécdota, un poco bochornosa pero 100% real.

Una de mis primeras experiencias con AI en producción fue generar un mapper (API → Domain). En serio, un puto mapper. Lo integré casi sin mirar. Una semana después, en una review, me preguntaron por qué funcionaba así, y no supe responder…

Resulta que, aunque funcionaba, había un montón de complejidad innecesaria.

Desde entonces, no integro nada que no entienda como si lo hubiera escrito yo.

La realidad que tienes que aceptar

Entiende esto: Tu valor no está en mecanografiar, igual que no lo está en escribir código máquina. No eres menos profesional por usar una abstracción de alto nivel como JavaScript.

Tu valor radica en:

• Tomar decisiones arquitectónicas.
• Dar contexto técnico real.
• Evaluar calidad y encaje.
• Integrar bien en la base de código.

De nuevo: igual que usar un framework no te hace menos desarrollador/a, usar IA de forma responsable, tampoco.

Control de calidad en la era PDD

La IA no sustituye tu responsabilidad. La amplifica.

Automatizar la escritura de código no implica automatizar el criterio.

Eso sigue siendo tu trabajo.

El flujo real de control empieza mucho antes de que aparezca una línea de código. Empieza con el prompt.

flowchart LR
    A[Prompt crafting] --> B[Código generado]
    B --> C[Revisión manual]
    C --> D{¿Entiendo la solución?}
    D -->|No| E[Clarificar o rechazar]
    D -->|Sí| F[Tests automáticos]
    F --> G[Pipeline CI/CD]
    G --> H[Tests E2E]
    H --> I[Producción]

Ese ¿Entiendes la solución? no es retórica. Es un filtro definitivo.

Si no sabes explicar lo que el modelo ha hecho:

– No lo aceptas.

– No lo testéas.

– No lo integras.

No importa si pasa los tests. Si no pasa por tu cabeza, no pasa.

Checklist de revisión real

• ¿Puedo explicar la intención del código?.
• ¿Sigue nuestras convenciones (nombres, estructura, composición)?.
• ¿Gestiona correctamente cualquier estado o edge case conocido?.
• ¿Está desacoplado y testeable? (te sorprenderías).
• Etc…

Que quede claro:

• Prompt bien hecho → código explicable → control de calidad posible.
• Prompt débil → código ilegible → deuda técnica invisible.

La IA escribe. Tú evalúas y te haces responsable. Sin comprensión, no hay integración.

El precio de no pensar

Todo esto funciona. Y multiplica tu capacidad.

Pero también puede degradarla, si no sabes lo que estás haciendo.

Un estudio del MIT Media Lab —Your Brain on ChatGPT— lo deja claro: cuanto más delegas en un LLM, menos piensas.

Literalmente.

Cuando usamos IA para resolver problemas técnicos, no solo reducimos el esfuerzo cognitivo: también empezamos a fallar más.

Incluso cuando sabemos la respuesta correcta, si el modelo sugiere otra, dudamos o la aceptamos sin cuestionarla.

Ese es el peligro real:

Cuanto menos piensas, menos puedes pensar.

Conozco profesionales que han decidido evitar asistentes embebidos en el editor.

No quieren que el modelo complete el código mientras ellos se desconectan de forma pasiva.

Prefieren trabajar en paralelo: dan contexto, razonan, deciden.

No quieren que la IA piense por ellos. Y mucho menos que escriba por ellos.

Otra forma de mantener la capacidad crítica activa es programar por placer. Por exploración. Por creatividad.

No porque haga falta, sino porque lo necesitas. Porque te construye.

Si para ti programar es solo un trabajo mecánico, querrás automatizarlo todo.

Pero si lo entiendes como un proceso creativo, necesitas tocar barro.

Necesitas fricción. Y dirección.

La IA es un arma de doble filo. Puede elevarte o puede atrofiarte.

Depende de cómo la uses, de cuánto estés dispuesto a seguir pensando.

Y de cuánto revises de verdad lo que genera.

Este es un ejemplo real:

Claude genera un fragmento con un error de principiante. Yo se lo señalo. Él lo admite.

¿Y si no me hubiera fijado? ¿Cuántas veces pasa esto sin que nadie lo revise?.

Eso es lo que está en juego.

No es que la IA se equivoque. Es que tú dejes de mirar.

Lo que no usas, se pierde.

Y si dejas de pensar, ya no estás programando. Estás obedeciendo.

Takeaways

• Prompt Driven Development no es magia. Es método. Y si no tienes método, vas a multiplicar tu deuda técnica, no tu productividad.
• Lo que no defines en el prompt, el modelo lo asume. Y lo que el modelo asume, tú acabarás pagando.
• La calidad del output depende casi por completo del contexto que entregas. Cuanto más concreto, mejor resultado.
• Delegar código no es el problema. El problema es delegar criterio. Puedes dejar que la IA escriba, pero nunca que decida por ti.
• La IA no sustituye tu responsabilidad técnica. La amplifica. El control de calidad empieza en el prompt, no en los tests.
• Código que no entiendes es código que no puedes mantener. Y si no puedes mantenerlo, no deberías integrarlo.
• Lo que se puede automatizar, se automatiza. Lo que requiere pensamiento, se protege.
• La IA puede elevarte o atrofiarte. Depende de cómo la uses y de cuánto estés dispuesto a seguir pensando.