Guía para principiantes: cómo crear apps con IA - Prompt Engineering para constructores

El mes pasado, una gerente de operaciones que conozco intentó crear una aplicación de onboarding para nuevos empleados con un constructor de IA. Su primer prompt: "Build an onboarding app for new employees." Lo que recibió fue una página de inicio genérica con un mensaje de bienvenida y un formulario que recopilaba nombre, correo electrónico y "departamento". Sin workflows, sin carga de documentos, sin listas de verificación de tareas, sin aprobaciones de gerentes. Pasó las siguientes dos horas agregando cosas que había asumido como obvias — y deshaciendo cosas que la IA había asumido por su cuenta.

Su segundo intento comenzó de manera diferente. Describió quiénes usarían la aplicación (nuevos empleados, coordinadores de RRHH y gerentes de departamento), lo que cada persona necesitaba hacer (completar documentación, asignar equipamiento, verificar formularios fiscales), qué sucede cuando algo sale mal (documentos faltantes activan un recordatorio, no un bloqueo), y cómo debería verse el resultado en cada etapa. Esa versión funcionó. No perfectamente — aún necesitó varias rondas de refinamiento — pero el primer borrador era reconociblemente la aplicación que tenía en mente.

La diferencia no fue un mejor modelo de IA. Fue un mejor prompt.

Esta guía trata sobre la brecha entre esos dos intentos. Cubre cómo escribir prompts que produzcan aplicaciones que coincidan con tu intención — ya sea que uses Chattee, Lovable, Bolt.new, Replit o cualquier otro constructor impulsado por IA. Los principios son los mismos en todas las plataformas, aunque los detalles varían.

Piensa en la IA como un contratista rápido y extremadamente literal

El modelo mental más útil para trabajar con constructores de IA: imagina contratar a un desarrollador que trabaja diez veces más rápido de lo normal, sigue las instrucciones al pie de la letra y nunca pide aclaraciones. Esa última parte es el problema. Un desarrollador humano se detendría y diría "espera, ¿qué quieres decir con controles de administración?" Un constructor de IA simplemente inventa algo.

Esto significa que los prompts para la creación de aplicaciones funcionan menos como consultas de búsqueda y más como documentos de requisitos. El prompt define el alcance, el comportamiento, los permisos y los casos límite — todo lo que normalmente contendría una especificación. Si omites cualquiera de estos, la IA llena los vacíos con suposiciones que suenan razonables pero pueden ser completamente equivocadas para tu situación.

Un estudio del MIT Sloan de 2025 lo confirmó cuantitativamente: solo aproximadamente la mitad de las ganancias de rendimiento por usar un mejor modelo de IA provenían del modelo en sí. La otra mitad provenía de cómo las personas adaptaban sus prompts. Invertir en una herramienta de IA poderosa ofrece un valor limitado a menos que también inviertas en aprender a dirigirla.

Frameworks de prompting que vale la pena conocer

Si nunca has escrito un prompt estructurado, los frameworks te dan una lista de verificación para que no olvides piezas importantes. Ninguno de ellos es mágico — son simplemente diferentes formas de recordarte qué información necesita la IA.

CO-STAR es el framework de propósito general más ampliamente utilizado. Significa Context, Objective, Style, Tone, Audience, Response. Se originó en una competencia de prompt engineering con GPT-4 en Singapur y funciona bien para cualquier cosa donde la audiencia y el tono importan tanto como el contenido. El elemento "Response" merece una nota: en los constructores de aplicaciones dedicados (Chattee, Lovable, Bolt.new), la plataforma maneja la creación de archivos y la estructura del proyecto automáticamente — describes qué construir, no qué tipo de archivo producir. Si estás generando código a través de una IA de propósito general como ChatGPT y pegándolo en tu proyecto, especificar el formato de salida exacto se vuelve esencial.

RISEN (Role, Instructions, Steps, End Goal, Narrowing) es más adecuado para tareas técnicas. El elemento "Steps" te obliga a descomponer lo que quieres en una secuencia — lo cual mapea directamente a cómo se construyen las aplicaciones. El elemento "Narrowing" es donde agregas restricciones: "sin dependencias externas", "mobile-first", "usar Supabase para autenticación."

TIDD-EC (Task, Instructions, Do, Don't, Examples, Content) vale la pena conocerlo por una razón: la sección explícita de "Don't". Los constructores de IA tienden a agregar funcionalidades que no pediste — paneles de analíticas, interruptores de modo oscuro, paneles de configuración — y decirles lo que no deben construir es sorprendentemente efectivo.

RACE (Role, Action, Context, Expectation) es el más simple. Cuatro elementos, rápido de escribir, funciona bien para solicitudes sencillas. Si estás escribiendo un prompt para un solo componente o una funcionalidad pequeña, esto a menudo es suficiente.

Una comparación rápida de cuándo usar cada uno:

Framework	Mejor para	Complejidad	Característica distintiva
CO-STAR	Contenido, textos de marketing, comunicaciones	Baja-Media	Enfoque en audiencia y tono
RISEN	Tareas técnicas de múltiples pasos	Media	Secuenciación explícita de pasos
TIDD-EC	Tareas donde necesitas prevenir fallos específicos	Media	Barreras "Do/Don't"
RACE	Solicitudes rápidas y enfocadas	Baja	Estructura mínima

En la práctica, la mayoría de los constructores experimentados no siguen ningún framework de manera rígida. Toman elementos prestados de varios — una asignación de rol aquí, restricciones explícitas allá, ejemplos cuando el formato importa. El valor no está en el acrónimo; está en el hábito de proporcionar información completa.

Ingeniería de contexto: la habilidad que importa más que la redacción del prompt

Algo importante cambió en 2025: la industria dejó de hablar de "prompt engineering" y comenzó a hablar de "context engineering". No es solo un cambio de etiqueta.

El prompt engineering trata sobre las palabras que escribes. La ingeniería de contexto trata sobre el entorno informativo total que el modelo de IA ve — instrucciones del sistema, archivos del proyecto, documentos recuperados, historial de conversación, salidas de herramientas y ejemplos. Como lo expresó el exinvestigador de OpenAI Andrej Karpathy: "In every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with the right information."

Este reencuadre explica algo práctico: por qué dos personas pueden escribir prompts casi idénticos y obtener resultados dramáticamente diferentes. La diferencia generalmente es el contexto, no la redacción. Una persona proporcionó su esquema de base de datos existente; la otra no. Una persona incluyó una captura de pantalla de su diseño; la otra lo describió con palabras. Una persona tenía un archivo de reglas configurado en su herramienta; la otra empezaba de cero cada sesión.

Para los constructores de aplicaciones con IA, la ingeniería de contexto significa pensar en tres cosas:

Contexto instruccional — prompts del sistema, reglas y ejemplos few-shot que le dicen a la IA cómo comportarse
Contexto de conocimiento — información del dominio, documentación, patrones de código existentes y datos del proyecto
Contexto de herramientas — información que el modelo recopila de su entorno: ejecutar código, consultar bases de datos, leer archivos

Así que antes de obsesionarte con la redacción del prompt, pregúntate si la IA realmente tiene acceso a la información que necesitaría para hacer bien el trabajo. A menudo no la tiene — y ninguna cantidad de redacción ingeniosa compensa la falta de contexto.

Qué decirle a la IA en cada etapa de construcción

Uno de los errores más comunes con los constructores de IA es volcar todos tus requisitos en un solo prompt y esperar lo mejor. Las diferentes etapas de la creación de aplicaciones necesitan contexto diferente. Un prompt que funciona genial para diseñar tu modelo de datos producirá resultados basura para construir tu interfaz si le falta contexto de diseño.

Esto es lo que importa en cada etapa — y qué incluir.

Al construir la interfaz y el frontend

La IA necesita saber cómo deben verse las cosas, no solo lo que deben hacer. Sin contexto visual, recurre a valores predeterminados genéricos — y esos valores predeterminados podrían ser Bootstrap circa 2019.

Incluye:

Paleta de colores con códigos hex específicos (colores primario, secundario, de acento, éxito/error/advertencia)
Tipografía — qué fuentes, qué pesos para encabezados vs cuerpo de texto, preferencias de altura de línea
Biblioteca de componentes — "Usar shadcn/ui y Tailwind" o "Usar componentes de Mantine" le da a la IA un vocabulario de diseño coherente
Preferencias de layout — navegación lateral vs navegación superior, layouts basados en tarjetas, cuántas columnas en escritorio vs móvil
Requisitos de accesibilidad — cumplimiento WCAG AA, HTML semántico, navegación por teclado

Un prompt que dice "crea una página de dashboard" sin nada de este contexto producirá algo que técnicamente funciona pero no se parece en nada a tu marca. Un prompt que incluye aunque sea una especificación básica de design tokens — colores, fuentes, espaciado — produce algo que realmente puedes publicar.

Build a dashboard page showing key metrics for an HR manager.

DESIGN CONTEXT:
- Component library: Mantine UI (React)
- Primary colour: #2563EB, secondary: #7C3AED, neutral backgrounds: #F8FAFC
- Typography: Inter for headings (600 weight), Inter for body (400 weight)
- Layout: sidebar navigation on the left (240px), main content area with 24px padding
- Cards for each metric, 8px border radius, subtle shadow (0 1px 3px rgba(0,0,0,0.1))
- Responsive: stack sidebar below content on screens under 768px
- WCAG AA colour contrast compliance required

METRICS TO DISPLAY:
- Open positions (count, trend arrow vs last month)
- Time-to-hire average (days, bar chart over last 6 months)
- Employee turnover rate (percentage, line chart over last 12 months)
- Pending onboarding tasks (list of next 5, with assignee and due date)

Al construir el modelo de datos

Los constructores de IA son particularmente propensos a crear esquemas excesivamente simplistas — una sola tabla users con veinte columnas en lugar de entidades correctamente normalizadas. La solución es ser meticuloso con la estructura. Detalla cada entidad, cada tipo de campo, cada restricción. Nombra tu convención de nomenclatura (¿snake_case? ¿camelCase? ¿tablas en singular o plural?). Si estás extendiendo una base de datos existente, pega el esquema actual — sin él, la IA inventará convenciones que chocan con lo que ya existe.

La indexación merece su propia sección en el prompt. La mayoría de los esquemas generados por IA omiten los índices por completo, lo cual está bien para un prototipo y es desastroso para producción. Dile a la IA qué consultas serán frecuentes y agregará los índices correctos.

Design a database for a project management tool.

NAMING: Use snake_case for everything, plural table names.
Every table should track when records were created and last updated.

ENTITIES AND RELATIONSHIPS:
- Teams: name, unique slug identifier
- Users: email (unique), display name, belongs to one team
- Projects: name, belongs to a team, has an owner (a user),
  status can be active, archived, or draft (defaults to draft)
- Tasks: title, optional description, belongs to a project,
  can be assigned to a user (optional), status is one of
  todo/in_progress/review/done, priority is low/medium/high/critical,
  optional due date

PERFORMANCE:
- Add a composite index on tasks for project + status (we'll filter
  task lists by project and then by status constantly)
- Index tasks by assignee (for "my tasks" views)
- Add a composite index on projects for team + status (for team
  project listings)

VALIDATION:
- Due dates must be in the future when first set
- Project status defaults to "draft" on creation

Al construir la lógica de negocio y el comportamiento del backend

Los prompts de backend fallan de una manera diferente a los de interfaz. En lugar de verse mal, se ven bien — hasta que te das cuenta de que la aplicación maneja errores de manera inconsistente, la verificación de autenticación falta en una página, o una acción fallida muestra un mensaje de error críptico en lugar de algo útil.

Lo que mejor funciona: describe lo que hace el usuario, lo que debería suceder detrás de escena, qué reglas aplican, y lo que el usuario debería ver cuando algo sale mal. Si estás añadiendo a una aplicación existente, muestra a la IA un ejemplo funcional de tu base de código — capta patrones más rápido a partir de ejemplos que de reglas escritas.

Build a task assignment feature for the project management tool.

USER FLOW:
- On the task detail page, managers and admins see an "Assign" button
- Clicking it opens a dropdown showing team members
- Selecting a person assigns the task to them
- The page updates immediately to show the new assignee

BUSINESS RULES:
- Only users with the Manager or Admin role within the project's team
  can assign tasks
- The assignee must be a member of the same team as the project
- If a task is already marked as "done", it cannot be reassigned
- When a task is assigned, record who made the change and when

WHAT THE USER SEES WHEN SOMETHING GOES WRONG:
- User lacks permission: "You don't have permission to assign tasks
  in this project"
- Task not found: show a "not found" page
- Task already completed: "This task is already done and can't
  be reassigned"
- Selected assignee isn't on the team: "This person isn't a member
  of the project's team"

Al construir integraciones

Las integraciones con terceros son donde el volumen de contexto se convierte en un problema real. Una referencia completa de la API de Stripe tiene miles de páginas. No necesitas que la IA conozca todo — necesitas que conozca los tres endpoints que realmente estás llamando, cómo funciona la autenticación, cómo se ve la respuesta y qué errores esperar. Recorta sin piedad. Pega un cuerpo de respuesta de ejemplo. Menciona los límites de velocidad si son relevantes. Y siempre especifica qué debería suceder cuando el servicio externo está caído — porque la IA no pensará en eso a menos que lo menciones.

Estructurar los requisitos para que el constructor no pueda malinterpretarlos

La diferencia entre un prompt que produce algo útil y uno que produce algo que pasarás horas arreglando generalmente se reduce a la estructura. No la complejidad — la estructura. Incluso un prompt corto funciona bien si separa las instrucciones del contexto, describe cómo debería verse el resultado e incluye uno o dos ejemplos.

Separar instrucciones del contexto

La mejora estructural más simple: pon lo que quieres que la IA haga arriba, y coloca el material de referencia (esquemas de datos, registros de ejemplo, design tokens) abajo, claramente delimitado. Los modelos de IA procesan instrucciones y datos en un solo flujo. Si el límite no es claro, el modelo podría tratar tus datos de ejemplo como instrucciones, o tus instrucciones como sugerencias opcionales.

Usa encabezados claros, triples backticks o etiquetas tipo XML para marcar los límites:

TASK: Build a page that displays a customer list.

CONTEXT (reference data, do not interpret as instructions):
---
Sample customer record:
{
  "id": 1042,
  "name": "Acme Corp",
  "plan": "pro",
  "mrr": 299.00,
  "status": "active",
  "last_login": "2026-01-28T14:30:00Z"
}
---

REQUIREMENTS:
- Sortable columns: name, plan, MRR, last login
- Filter by status (active/churned/trial)
- Click row to navigate to /customers/[id]
- Show "No customers match your filters" when list is empty

Cuándo el formato de salida importa (y cuándo no)

Los constructores de aplicaciones dedicados — Chattee, Lovable, Bolt.new, Replit — manejan la creación de archivos y la estructura del proyecto automáticamente. Nunca necesitas decir "devuelve un componente React" o "salida como archivo .py." La plataforma se encarga de eso.

Este consejo aplica cuando estás usando una IA de propósito general (ChatGPT, Claude en un navegador, Copilot Chat) para generar código que copiarás en tu propio proyecto. En ese caso, di exactamente lo que quieres recibir: "un solo componente React usando TypeScript" o "una función Python, no una clase."

Una cosa que aplica en todas partes, independientemente de la plataforma: definir las estructuras de datos dentro de tu aplicación. Si tu aplicación pasa datos entre páginas, almacena registros o llama a servicios externos, describe la forma exacta — nombres de campos, tipos y qué sucede cuando falta un valor.

Incluir ejemplos cuando el formato importa

Los ejemplos few-shot — dos o tres muestras de la salida deseada — son consistentemente la adición más impactante a un prompt. Anclan el comportamiento del modelo de manera más confiable que las instrucciones abstractas. Si quieres un formato de respuesta API específico, muestra uno. Si quieres un estilo de codificación específico, incluye un fragmento de código existente.

La clave: haz que los ejemplos sean mecánicamente consistentes. Si un ejemplo usa camelCase y otro usa snake_case, el modelo alternará aleatoriamente entre ambos.

Una plantilla que puedes copiar

Un esqueleto de propósito general para prompts de constructores de aplicaciones IA:

TITLE: [Feature or app name]

GOAL (one sentence): [What success looks like]

NON-GOALS:
- [What the app must NOT do]
- [Out of scope items]

USERS:
- [Role A] — [why they use this feature]
- [Role B] — [why they use this feature]

DATA:
- Inputs: [what the user provides]
- Sources: [databases, APIs, files the app reads from]
- Prohibited: [data the app must not access or display]

WORKFLOWS:
- Happy path: [step by step]
- Alternate paths: [what happens when X]
- Error path: [what happens when things fail]

RULES:
- [Rule 1 — unambiguous, testable]
- [Rule 2 — unambiguous, testable]

OUTPUT FORMAT (skip if your platform handles file generation automatically):
- [Structure, required fields, types]

ACCEPTANCE TESTS:
- Given [input], expect [output/behaviour]

Este no es un formato rígido — adáptalo a tu herramienta y tu proyecto. El punto es que cada sección fuerza una decisión que de otro modo dejarías a la imaginación de la IA.

Definir correctamente los roles y permisos

Los fallos de permisos son la categoría más peligrosa de "mala construcción" porque crean agujeros de seguridad, no solo molestias de UX. Y en las aplicaciones generadas por IA, el riesgo se amplifica: si no especificas quién puede hacer qué, la IA hará todo accesible para todos o aplicará permisos de manera inconsistente.

Hay dos conceptos separados que necesitas mantener claros:

Los roles de mensaje son la jerarquía de instrucciones a nivel de API — system, developer, user. Estos controlan qué instrucciones prioriza la IA. Tus reglas no negociables (límites de seguridad, límites de acceso a datos) deben ir al nivel más alto disponible.

Los roles de usuario de la aplicación son los roles del producto — admin, editor, visor, cliente. Estos determinan lo que una persona puede ver y hacer dentro de la aplicación que estás construyendo.

Un buen prompt aborda ambos. Establece límites estrictos en las instrucciones a nivel de sistema, y luego define un modelo de permisos concreto para la aplicación.

El principio que previene la mayoría de los bugs de permisos

Denegar por defecto. Ninguna acción está permitida a menos que se otorgue explícitamente. Esta es una práctica de seguridad estándar (OWASP la recomienda tanto para aplicaciones web tradicionales como para las impulsadas por LLM), y se traduce directamente en cómo escribes prompts:

En lugar de esto:

Admins can manage everything.
Support agents can help customers.
Customers can see their account.

Escribe esto:

ROLES: customer, support_agent, admin

PERMISSIONS (deny by default — no action unless listed here):

customer:
  CAN: read own profile (except payment_method field), create and view own tickets,
       read public knowledge base articles
  CANNOT: read other users' data, access internal KB, export data, modify roles

support_agent:
  CAN: read tickets where assigned_to = self, draft replies, read internal KB
  CANNOT: access billing data, delete users, change role assignments

admin:
  CAN: manage KB articles, configure routing rules, manage role assignments
  CANNOT: view ticket message content unless granted explicit "ticket_audit" permission

HIGH-RISK ACTIONS (require human approval regardless of role):
- Account deletion
- Bulk data export
- Role elevation

La primera versión son tres líneas de español que podrían significar casi cualquier cosa. La segunda versión es implementable — un desarrollador (o una IA) puede convertir cada línea en una verificación de base de datos, un guard de API o una regla de visibilidad de interfaz.

Qué modelo de control de acceso describir

Para la mayoría de los casos de uso de constructores de aplicaciones, RBAC (Role-Based Access Control) es la opción correcta. Se mapea limpiamente al formato "el Rol X puede hacer Y" que los modelos de IA manejan bien. Describe los roles, lista las acciones permitidas por rol y especifica el alcance de cada acción.

Si necesitas un control más fino — "los usuarios solo pueden editar tickets que crearon" o "los usuarios del plan Pro ven funcionalidades diferentes a los del plan gratuito" — te estás moviendo hacia ABAC (Attribute-Based Access Control). En los prompts, exprésalos como reglas condicionales:

CONDITIONAL PERMISSIONS:
- A user can edit a ticket IF ticket.creator_id = user.id
- A user can access the analytics dashboard IF user.plan IN ('pro', 'enterprise')
- A user can view salary data IF user.department = record.department AND user.role = 'manager'

En resumen: describe los permisos de una manera que pueda verificarse en código, no de una manera que requiera que la IA "recuerde" reglas durante una conversación. Los permisos aplicados solo por la IA no son confiables. Los permisos aplicados por código son testeables.

Describir la lógica condicional para que los workflows realmente funcionen

Aquí es donde las aplicaciones construidas por IA se rompen con más frecuencia. El happy path se ve genial. Pero la primera vez que un usuario envía un formulario con un campo faltante, o un pago falla, o alguien intenta acceder a una página que no debería ver — la aplicación se desmorona.

La causa raíz: si no describes lo que sucede en escenarios fuera del happy path, la IA asume que el happy path es el único camino.

Patrones que funcionan en los prompts

Las cláusulas de guardia evitan que la IA avance con información incompleta:

If required fields (order_id, customer_email) are missing,
ask the user to provide them. Do not proceed or guess.

Las tablas de decisión comunican la lógica de ramificación más claramente que la prosa:

Condición	Acción	Salida
Usuario no autenticado	Mostrar prompt de inicio de sesión, no cargar datos de cuenta	Sin llamadas API a endpoints de usuario
Autenticado, solicita restablecimiento de contraseña	Enviar email de restablecimiento a la dirección verificada	Mensaje de confirmación, sin contraseña visible
Autenticado, solicita eliminación de cuenta	Generar proposed_action para revisión humana	escalation_needed = true
La búsqueda devuelve cero resultados	Mostrar "No se encontraron resultados" con sugerencias	No mostrar estado de error
La llamada API expira después de 5 segundos	Mostrar botón de reintento y mensaje de disculpa	Registrar evento de timeout con request_id

Las máquinas de estados funcionan bien para workflows de múltiples pasos:

ONBOARDING WORKFLOW STATES:
- invite_sent -> form_incomplete -> form_complete -> documents_pending ->
  manager_review -> approved | rejected

TRANSITIONS:
- invite_sent -> form_incomplete: when new hire clicks invite link
- form_incomplete -> form_complete: when all required fields submitted
- form_complete -> documents_pending: automatic, after form validation passes
- documents_pending -> manager_review: when all required documents uploaded
- manager_review -> approved: when manager clicks "Approve"
- manager_review -> rejected: when manager clicks "Reject" (must provide reason)
- rejected -> form_incomplete: new hire can resubmit

RULES:
- No state transition can skip a step
- Rejected employees can resubmit up to 2 times, then escalate to HR director

Antes y después: hacer explícita la lógica condicional

Antes (el prompt que produce un workflow roto):

If the user asks for a refund, help them. If it's not possible, escalate.

Después (el prompt que produce un workflow funcional):

REFUND WORKFLOW (apply checks in this order):

1. Validation:
   - If order_id is missing, ask: "What is your order number?"
   - If no order found for that ID, say: "I couldn't find that order.
     Please double-check the number."

2. Authorisation:
   - If user_role = "customer", they can request, not execute. Produce
     a refund request for agent review.
   - If user_role = "support_agent", they can initiate. Proceed to step 3.

3. Business rules:
   - If purchase older than 30 days, refund not eligible. Offer store
     credit or escalation.
   - If order total exceeds 500 USD, route to senior agent regardless of role.
   - If customer has had more than 3 refunds in 90 days, flag for review.

4. Execution:
   - Generate proposed_action: { type: "refund", order_id, amount, reason }
   - Set escalation_needed = true (all refunds require human approval)

La segunda versión maneja datos faltantes, usuarios no autorizados, reglas de negocio y casos límite. Cada línea puede convertirse en un caso de prueba.

Casos límite: lo que realmente se rompe en producción

Los constructores de IA optimizan para el happy path a menos que les digas lo contrario. Entradas faltantes, fallos de API, acciones de usuario ambiguas y reglas contradictorias — estas son las cosas que causan problemas reales una vez que la gente comienza a usar la aplicación.

Un enfoque práctico: para cada funcionalidad, recorre estos escenarios e incluye las respuestas en tu prompt.

Entrada faltante o incompleta. ¿La aplicación debería pedir aclaración, mostrar un error de validación, o recurrir a un valor predeterminado? Explícalo — la IA no tomará la misma decisión que tú.

Los servicios externos se caen. Las bases de datos expiran. Los procesadores de pago rechazan tarjetas. Describe lo que el usuario ve cuando algo se rompe: si debe reintentarse automáticamente, mostrar un mensaje de error amigable, o escalar a un humano.

Las acciones no autorizadas siempre deben producir un mensaje claro y específico — nunca un fallo silencioso o un volcado de error sin procesar. Si alguien intenta acceder a una página que no debería ver, dile a la IA exactamente qué mostrar.

Las reglas contradictorias son sorprendentemente comunes. "Siempre sé servicial" combinado con "nunca compartas detalles de cuenta con usuarios no verificados" crea una paradoja que la IA no puede resolver por sí sola. Dale un orden de prioridad: "Las reglas de seguridad anulan las reglas de servicio."

Si tu aplicación espera datos estructurados de la IA, usa la aplicación de esquemas donde tu plataforma lo soporte. De lo contrario, especifica un respaldo: "Si la respuesta no coincide con el formato esperado, mostrar un error genérico y registrar la respuesta malformada para depuración."

Una lista de verificación que puedes pegar en cualquier prompt de funcionalidad:

EDGE CASE HANDLING:
- Missing required fields: ask clarifying questions; do not guess or use defaults
- External API timeout (over 5s): show user-friendly error + retry button; log event
- Permission denied: show "You don't have access to this action" with reason code
- Empty search results: show "No results found" message, not an error state
- Malformed data from external source: reject silently; do not process or display
- Conflicting rules: apply in this priority: (1) security, (2) permissions,
  (3) data validation, (4) business rules, (5) UX preferences

Errores comunes y cómo reconocerlos

Después de revisar la documentación de plataformas de OpenAI, Google, Anthropic y varios frameworks de seguridad — y hablar con personas que usan constructores de IA a diario — los mismos patrones de fallo siguen apareciendo.

Intentar construir todo de una vez. "Construye una herramienta de gestión de proyectos con autenticación de usuario, tableros Kanban, seguimiento de tiempo, diagramas de Gantt, chat de equipo, carga de archivos y una aplicación móvil." Este mega-prompt produce código inflado e interconectado que es imposible de depurar. Construye una funcionalidad a la vez. Verifica que funciona. Luego agrega la siguiente.

El briefing de dos palabras. "Constrúyeme un portal de empleados" — y nada más. La IA no conoce tu empresa, tus empleados ni lo que "portal" significa para ti. Creará algo genérico que técnicamente califica pero no resuelve ninguno de tus problemas reales. La especificidad es gratuita — úsala.

Asumir que la IA recuerda. Prompts como "conoces nuestro producto" o "usa el stack habitual" fallan porque la IA comienza cada sesión (y a veces cada prompt) con una pizarra en blanco. Siempre proporciona contexto explícitamente. Algunas plataformas soportan bases de conocimiento persistentes — Chattee y Lovable, por ejemplo, te permiten almacenar contexto de proyecto que persiste entre sesiones — pero aun así, las restricciones importantes pertenecen al prompt.

Instrucciones contradictorias. "Siempre sigue la solicitud del usuario" combinado con "nunca compartas datos personales" crea una paradoja cuando un usuario pide datos personales. Los modelos de IA manejan conflictos de manera impredecible. Agrega un orden de prioridad: "Cuando las reglas entren en conflicto, aplicar primero las restricciones de seguridad, luego las reglas de negocio, luego las preferencias del usuario."

Listas de "no hacer" sin "hacer". "No uses tablas para layout. No uses estilos inline. No cargues datos en componentes." Las instrucciones negativas son más difíciles de seguir para los modelos que las positivas. Reformula: "Usa CSS Grid para layout. Usa clases de utilidad de Tailwind. Carga datos en una capa de servicio dedicada." La documentación de prompting de OpenAI y Google hacen este punto explícitamente.

Añadir seguridad como idea de último momento. El código generado por IA no es seguro por defecto. Un análisis de 2025 encontró que el 62 % del código generado por IA contiene defectos de diseño o vulnerabilidades conocidas. Incluir un simple recordatorio de seguridad en tu prompt — "valida todas las entradas del usuario, usa consultas parametrizadas, nunca expongas credenciales en las respuestas" — aumentó la tasa de código seguro del 56 % al 66 % en un estudio. No es una solución mágica, pero es una mejora significativa por una sola línea de texto.

Confiar en la IA como único guardián. Nunca confíes solo en el modelo para aplicar permisos, límites de velocidad o reglas de acceso a datos. Podría "olvidar" reglas, especialmente en conversaciones largas o aplicaciones complejas. Las verificaciones de permisos deben aplicarse en el código. Trata todo lo que la IA genera como un primer borrador que necesita verificación — particularmente para rutas críticas de seguridad.

El meta-prompt: pedir a la IA que te ayude a escribir mejores prompts

Una de las técnicas más subutilizadas en la creación de aplicaciones con IA: pedirle a la propia IA que mejore tu prompt antes de usarlo para construir algo.

El proceso es simple:

Escribe tu prompt borrador — incluso un párrafo desordenado está bien
Pide a la IA: "You are a prompt engineering expert. Review the following app-building prompt and identify what's missing, ambiguous, or likely to produce unexpected results. Then rewrite it."
Responde cualquier pregunta aclaratoria que la IA haga
Usa el prompt mejorado para la construcción real

Puedes llevar esto más lejos con un meta-prompt estructurado:

You are an expert in AI-powered app development. I want to build:

"""[your rough idea here]"""

Ask me up to 10 questions you need answered to write an effective,
detailed prompt for an AI app builder. Focus on:
- Scope boundaries (what's in, what's out)
- User roles and permissions
- Data models and relationships
- Workflows and conditional logic
- Edge cases and error handling
- Design and UX preferences

After I answer, generate the final structured prompt I should use.

Esto funciona porque los modelos de IA son a menudo mejores identificando lo que falta en una especificación que adivinando los valores predeterminados correctos. El meta-prompt convierte a la IA en un analista de requisitos antes de que se convierta en constructor.

Probar e iterar: tratar los prompts como documentos vivos

El primer prompt que funciona raramente es el mejor. Como el código, los prompts necesitan pruebas, versionado y refinamiento.

Un ciclo de iteración práctico:

1. Define qué significa "correcto". Antes de ejecutar un prompt, anota de tres a cinco resultados concretos que aceptarías como exitosos. "La página de inicio de sesión tiene campos de correo electrónico y contraseña, un enlace de 'olvidé mi contraseña', y muestra un mensaje de error específico para credenciales inválidas."

2. Ejecuta el prompt y anota los fallos. No solo "no funciona" — categoriza qué salió mal. ¿Funcionalidad faltante? ¿Formato incorrecto? ¿Brecha de seguridad? ¿Lógica incorrecta? Cada tipo de fallo tiene una solución diferente.

3. Corrige una cosa a la vez. Resiste la tentación de reescribir todo el prompt después de un fallo. Agrega la restricción faltante, clarifica el término ambiguo o agrega un ejemplo. Luego ejecuta de nuevo. Cambiar demasiadas cosas a la vez hace imposible saber qué resolvió el problema.

4. Guarda los prompts que funcionan. Cuando un prompt produce buenos resultados, guárdalo como plantilla. Con el tiempo, acumularás una biblioteca de "prompts dorados" para patrones comunes — flujos de autenticación de usuario, interfaces CRUD, funcionalidades de búsqueda, sistemas de notificación.

5. Vuelve a probar al cambiar de modelo. Un prompt optimizado para un modelo de IA puede funcionar de manera diferente en otro. Si cambias de modelo (o tu plataforma actualiza el suyo), vuelve a ejecutar tus pruebas. La comunidad de prompt engineering ha observado repetidamente que las estrategias de prompting no son universalmente portables entre modelos — lo que funciona para Claude puede tener un rendimiento inferior en GPT-4, y viceversa.

Algunos equipos — especialmente agencias que construyen aplicaciones para múltiples clientes — usan herramientas dedicadas para la evaluación de prompts. Promptfoo (open source, basado en CLI) te permite definir casos de prueba en YAML y ejecutar prompts contra ellos en lote. DeepEval se integra en suites de prueba de Python. Para la mayoría de los constructores individuales, sin embargo, un simple documento que rastree "versión del prompt, resultados de prueba, cambios realizados" es suficiente para mantenerse en curso.

Consejos específicos por plataforma

Los diferentes constructores de IA manejan el contexto de maneras diferentes. Algunas notas sobre las plataformas que es más probable que encuentres:

Bolt.new le da a la IA control total sobre el sistema de archivos basado en navegador, el terminal y el servidor. Comienza estableciendo la arquitectura — elección de framework, estructura de layout, lenguaje de diseño — en tu primer prompt. Los prompts siguientes pueden entonces hacer referencia a "usando el mismo estilo" sin repetir todo. Ten en cuenta que la retención de contexto puede degradarse una vez que los proyectos crecen más allá de 15-20 componentes.

Lovable soporta una Base de Conocimiento persistente con categorías para directrices de proyecto, personas de usuario, assets de diseño y convenciones de codificación. También tiene un sistema de memoria de carpeta docs/ (memory.md, architecture.md, etc.) que persiste entre sesiones. Aprovecha esto para evitar repetir contexto en cada prompt. Una acción por prompt tiende a funcionar mejor que solicitudes de múltiples pasos.

Replit Agent ofrece un "modo Plan" donde puedes discutir la arquitectura antes de construir. Úsalo. El botón "Improve Prompt" también vale la pena probarlo — reformula tu prompt para hacerlo más específico. El sistema de checkpoints de Replit te permite revertir de forma segura, así que puedes experimentar más agresivamente.

v0 (Vercel) se especializa en generación de interfaces React/Next.js. Entiende componentes shadcn/ui de forma nativa y soporta un sistema de Registry para pasar design tokens al modelo. Si estás usando v0 para trabajo de frontend, proporcionar un archivo tailwind.config y globals.css da mejores resultados que describir colores en prosa.

Cursor usa archivos .cursor/rules/ (con extensión .mdc) para proporcionar contexto persistente a la IA. Configúralos antes de comenzar a construir — son más efectivos que repetir instrucciones en cada prompt. Inicia un nuevo chat para cada tarea; los hilos de conversación largos causan deriva de contexto.

Chattee adopta un enfoque de dos fases: primero una fase de planificación donde la IA crea un plan de implementación, luego una fase de ejecución donde construye. Este patrón de planificar-luego-ejecutar te da un punto de control para revisar la comprensión de la IA antes de que escriba código — capturando malinterpretaciones antes de que se conviertan en funcionalidades mal construidas. La plataforma genera aplicaciones full-stack (base de datos, autenticación, lógica de negocio e interfaz) a partir de lenguaje natural y maneja el despliegue a dominios personalizados.

Poniéndolo todo junto: un prompt real, de principio a fin

Para unir todo, imagina que eres un gerente de operaciones en una empresa mediana que necesita una herramienta interna para gestionar solicitudes de mantenimiento de equipos. El proceso completo de prompting podría verse algo así.

Paso 1: idea bruta (meta-prompt)

I need an internal web app for tracking equipment maintenance requests
at our manufacturing facility. About 200 employees, 50 pieces of major
equipment. Currently using spreadsheets and email, it's a mess.

Ask me the questions you need answered to write a detailed prompt for
an AI app builder.

La IA podría preguntar: ¿Quién envía las solicitudes? ¿Quién las aprueba? ¿Qué información se captura? ¿Hay niveles de prioridad? ¿Qué sucede cuando el mantenimiento se completa? ¿Hay un sistema de notificaciones? ¿Qué hay de los calendarios de mantenimiento recurrente?

Paso 2: responde las preguntas y obtén un prompt estructurado de vuelta

Después de responder, la IA genera algo como esto (que tú refinas):

TITLE: Equipment Maintenance Request Tracker

GOAL: Replace spreadsheet-based maintenance tracking with a web app
that lets floor staff report issues, maintenance teams triage and
resolve them, and managers see status at a glance.

USERS:
- Floor Staff (200 people): Submit requests, attach photos, check status
  of their submissions
- Maintenance Team (12 people): View queue, claim requests, update status,
  log resolution notes
- Facility Manager (3 people): Dashboard overview, approve high-cost
  repairs (over 2000 USD), export reports

DATA MODEL:
- equipment (id, name, location, type, installation_date, status)
- maintenance_requests (id, equipment_id FK, submitted_by FK,
  priority ENUM(low/medium/high/critical), description, photos[],
  status ENUM(submitted/triaged/in_progress/pending_approval/resolved/closed),
  created_at, resolved_at)
- resolution_notes (id, request_id FK, author_id FK, note_text, created_at)

PERMISSIONS (deny by default):
- floor_staff: create requests, view own requests, upload photos to
  own requests
- maintenance_team: view all requests, claim (assign to self), update
  status, add resolution notes
- facility_manager: all maintenance_team permissions + approve high-cost
  repairs + view dashboard + export CSV

WORKFLOWS:
- Submit request, auto-assign priority based on equipment type,
  maintenance team triages, claim, work, resolve
- If estimated_cost over 2000 USD, status moves to pending_approval,
  facility manager approves or rejects with comment
- If request not claimed within 4 hours and priority = critical,
  alert facility manager

EDGE CASES:
- Photo upload fails: show retry button, save request text without photos
- Duplicate request for same equipment within 24 hours: warn submitter,
  offer to add note to existing request instead
- Equipment not in system: allow "Other" selection with free-text
  description, flag for admin to add to equipment list

DESIGN:
- Clean, functional (not consumer-flashy — this is a factory floor tool)
- Large touch targets (used on tablets with gloves)
- High contrast colour scheme for visibility in bright environments
- Mobile-first for floor staff, desktop-optimised for manager dashboard

Paso 3: construir iterativamente

No pegues todo este prompt y digas "adelante." Aliméntalo por etapas:

Modelo de datos y esquema primero — verifica que tiene sentido
Flujo de envío del personal de planta — prueba con el happy path y un caso límite
Cola y workflow del equipo de mantenimiento — verifica la asignación y actualizaciones de estado
Dashboard del gerente y flujo de aprobación
Notificaciones y alertas

Cada etapa obtiene su propio prompt enfocado, con la especificación general como contexto.

Referencia rápida: principios que aplican en todas las plataformas

Instrucciones primero, contexto después. Pon lo que se debe hacer arriba. El material de referencia va abajo, claramente separado.
Sé específico con el formato. Si necesitas datos estructurados, muestra la forma. Si necesitas una interfaz, nombra la biblioteca de componentes. Si necesitas una base de datos, nombra la tecnología.
Mostrar, no solo decir. Dos o tres ejemplos de la salida deseada superan un párrafo de requisitos abstractos.
Di qué hacer, no solo qué no hacer. "Validar todas las entradas del usuario en el servidor" funciona mejor que "no confiar en los datos del lado del cliente."
Una tarea, un prompt. Las funcionalidades complejas construidas una porción a la vez producen resultados más limpios y depurables que los mega-prompts.
Formula los requisitos de seguridad explícitamente. Validación de entradas, verificaciones de autenticación, límites de acceso a datos — nunca asumas que la IA los agregará por sí sola.
Prueba los casos límite, no solo los happy paths. Para cada funcionalidad, describe al menos un escenario de fallo: entrada faltante, permiso denegado, servicio externo caído.
Guarda lo que funciona. Construye una biblioteca de prompts probados para patrones que uses repetidamente.
Verifica el trabajo de la IA. Revisa el código generado como revisarías el trabajo de un contratista. Verifica la lógica de permisos, el manejo de datos y los estados de error — especialmente antes de desplegar para usuarios reales.

La brecha entre una experiencia frustrante y una productiva con un constructor de IA casi nunca se debe a las capacidades de la herramienta. Se debe a la claridad de las instrucciones que le das. La buena noticia: a diferencia de aprender a programar, aprender a escribir prompts efectivos es algo que puedes mejorar significativamente en una tarde — y los rendimientos se acumulan con cada proyecto que construyes.