¿La IA escribe código mal? Domina estos 5 trucos de prompts y sube tu eficiencia un 50%

Un viernes a las cuatro y media de la tarde, el código que acababa de generar Cursor me dejó helado.

Solo quería un endpoint de login de usuario, y salió un monstruo de 300 líneas: tipos de parámetros incorrectos, conexión a base de datos hardcodeada y tres formas distintas de manejar errores. Respiré hondo, borré todo y empecé de nuevo. La segunda vez modificó archivos de configuración que no debía tocar.

Ahí entendí: el problema no era la IA, sino que no le había dicho qué hacer y qué no hacer.

Las herramientas de programación con IA están instaladas y la ilusión es alta, pero tras un tiempo el código sale desalineado o parece correcto y explota al ejecutar. Tras varias rondas de corrección, a veces es más rápido escribir a mano.

Un compañero con el mismo Cursor hace en diez minutos lo que a mí me lleva una hora. ¿La diferencia? Prompts estructurados, contexto completo y límites claros.

Este artículo te enseña 5 trucos de prompts en Cursor que funcionan al instante. No es teoría abstracta: son fórmulas prácticas. Al terminar sabrás cómo hacer que la IA entienda de verdad la necesidad y genere código usable.

Por qué tu prompt siempre “falla”

La IA no lee la mente: solo “ve” lo que le das

Muchos creen que la IA es tan lista que debería adivinar lo que quieren. Error. Por muy potente que sea, sigue siendo un “completador de texto avanzado”: solo razona con lo que le das. Lo que no dices, lo rellena adivinando.

Es como pedirle a un amigo que compre café por teléfono con solo “tráeme un café”. En la tienda no sabe si americano o latte, tamaño, azúcar. Compra lo que le parece. La IA hace lo mismo.

En proyectos grandes, el problema de “memoria” es peor. La ventana de contexto es limitada; no cabe todo el repositorio. Le pides cambiar una función y puede no saber que otros 20 sitios la llaman. Un cambio y todo se cae.

Tres desastres frecuentes con prompts

Desastre 1: demasiado vago

❌ “Ayúdame a implementar un ordenamiento”

Como decirle al GPS “quiero ir a Pekín” sin decir dónde, cómo ni cuándo. La IA puede escribir burbuja o usar una librería que no tienes.

✅ “En utils/array.ts, añade una función que ordene la lista de usuarios por fecha de registro descendente, con Array.sort() nativo, sin nuevas dependencias”

La diferencia: archivo, datos, método y límites explícitos.

Desastre 2: falta de contexto

❌ “Añade manejo de errores”

¿Dónde? ¿Qué error? ¿try-catch o códigos? ¿Qué formato de respuesta?

Como ir al médico y decir solo “me duele”. No puede diagnosticar.

✅ “En api/login.ts, en handleLogin, añade manejo de errores:

• Captura fallos de red (try-catch)
• Devuelve formato unificado { success: false, error: string }
• Sigue el patrón de api/register.ts”

Desastre 3: sin restricciones

❌ “Optimiza el rendimiento de este componente”

Puede reescribir todo: nuevas librerías, otro estado, otra arquitectura. Tú querías React.memo y te hace cirugía mayor.

✅ “Optimiza el rendimiento de UserList.tsx:

• Solo React.memo o useMemo
• No modifiques la interfaz de props
• No introduzcas nuevas bibliotecas de terceros”

La verdad sobre las “alucinaciones” de la IA

¿Te ha pasado que llama a funciones que no existen o variables inventadas? Eso es alucinación.

Según las mejores prácticas de Cursor, un contexto claro reduce un 70% de alucinaciones. ¿Por qué?

Con información incompleta, la IA “rellena”. Si no muestras el código actual, infiere patrones típicos. Pides login y asume authService.login() aunque no exista.

La solución: mostrar código relevante existente.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Antes de cada prompt me pregunto:

1. ¿Sabe en qué archivo trabajo?
2. ¿Conoce la estructura actual?
3. ¿Sabe qué puede y no puede cambiar?

Si no puedo responder, no envío el prompt aún.

La fórmula dorada del prompt estructurado

Marco 5W1H: que la IA entienda al instante

Los periodistas usan 5W1H (Who, What, When, Where, Why, How). Los prompts también.

• What (qué): ¿qué debe hacer la IA?
• Why (por qué): ¿para qué? (entiende la intención)
• Where (dónde): ¿qué archivo o módulo?
• When (cuándo): ¿en qué momento se dispara?
• Who (quién/qué objeto): ¿sobre qué datos?
• How (cómo): ¿qué stack o librería?

No hace falta llenar todo siempre. El núcleo: que no tenga que adivinar.

Ejemplo: validación de entrada de usuario.

❌ Versión vaga:

Añade validación de entrada de usuario

✅ Versión 5W1H:

**What**: Validar formulario de registro
**Where**: src/components/RegisterForm.tsx
**Who**: Usuario, email y contraseña
**How**: Librería Yup existente
**When**: Al pulsar enviar
**Why**: Evitar datos inválidos al backend

Con esto, la IA casi no se desvía.

Plantilla estructurada recomendada por Cursor

El equipo de Cursor resume una plantilla muy práctica:

## Goal (objetivo)
[Una frase con lo que quieres lograr]

## Context (contexto)
[Archivo actual, código relacionado, stack]

## Current Behavior (comportamiento actual)
[Estado actual]

## Desired Behavior (comportamiento deseado)
[Resultado esperado]

## Acceptance Criteria (criterios de aceptación)
[Cuándo está terminado]

## Constraints (restricciones)
[Qué no tocar, qué reglas cumplir]

Lo más valioso es Constraints: muchos dicen qué hacer, no qué evitar, y la IA se pasa de listo.

Caso práctico: login en React

Comparación real: añadir login a un proyecto React.

❌ Prompt vago (típico de principiante):

Ayúdame a implementar login de usuario

Puede devolver 200 líneas, librerías innecesarias e incluso APIs inventadas.

✅ Prompt estructurado (enfoque avanzado):

## Goal
Implementar login de usuario en proyecto React

## Context
- React 18 + TypeScript
- Estado: Redux Toolkit
- API existente: src/services/authService.ts (método login)
- UI: Ant Design 5.x

## Current Behavior
Login (src/pages/Login.tsx) solo tiene UI estática

## Desired Behavior
1. Usuario introduce credenciales y pulsa "Iniciar sesión"
2. Llama a authService.login()
3. Éxito: guarda token en Redux, va a /dashboard
4. Fallo: message.error de Ant Design

## Acceptance Criteria
- [ ] Usuario y contraseña obligatorios
- [ ] Loading durante login
- [ ] Contraseña con type="password"
- [ ] Pasa ESLint y TypeScript

## Constraints
- **No modificar** authService.ts
- **No introducir** nuevas bibliotecas
- **Usar** Redux slice existente (src/store/authSlice.ts)

Efecto en el código generado:

Primer prompt, resultado típico:

// ❌ Libertad excesiva de la IA
import { useState } from 'react';
import axios from 'axios'; // librería no pedida

function Login() {
  const [username, setUsername] = useState('');
  const [password, setPassword] = useState('');

  const handleLogin = async () => {
    const res = await axios.post('/api/auth/login', { username, password });
    localStorage.setItem('token', res.data.token); // sin Redux
  };

  // ... 150 líneas innecesarias
}

Segundo prompt, resultado alineado:

// ✅ Resultado con prompt estructurado
import { useState } from 'react';
import { Form, Input, Button, message } from 'antd';
import { useDispatch } from 'react-redux';
import { login } from '@/services/authService';
import { setToken } from '@/store/authSlice';
import { useNavigate } from 'react-router-dom';

export default function Login() {
  const [loading, setLoading] = useState(false);
  const dispatch = useDispatch();
  const navigate = useNavigate();

  const handleSubmit = async (values: { username: string; password: string }) => {
    setLoading(true);
    try {
      const { token } = await login(values.username, values.password);
      dispatch(setToken(token));
      navigate('/dashboard');
    } catch (error) {
      message.error('Error de inicio de sesión, revisa usuario y contraseña');
    } finally {
      setLoading(false);
    }
  };

  return (
    <Form onFinish={handleSubmit}>
      <Form.Item name="username" rules={[{ required: true, message: 'Introduce usuario' }]}>
        <Input placeholder="Usuario" />
      </Form.Item>
      <Form.Item name="password" rules={[{ required: true, message: 'Introduce contraseña' }]}>
        <Input.Password placeholder="Contraseña" />
      </Form.Item>
      <Button type="primary" htmlType="submit" loading={loading}>
        Iniciar sesión
      </Button>
    </Form>
  );
}

La segunda versión:

• Usa Ant Design como pediste
• Llama a authService existente
• Guarda token en Redux
• Tiene validación y loading
• Sin dependencias nuevas

Ese es el poder del prompt estructurado.

5 trucos de prompts que funcionan al instante

Truco 1: planificar antes de codificar (Plan Mode)

De lo que más me sorprendió al usarlo.

Antes pedía código directo y fallaba: archivos equivocados, código clave borrado, lógica caótica. Cursor tiene modo Plan (Shift+Tab) y cambió mi flujo.

La lógica: la IA piensa antes de actuar.

Flujo:

1. Describes la necesidad
2. Analiza el repo y pregunta (“¿mantener el manejo de errores actual?”)
3. Plan de acción (archivos y funciones)
4. Tú revisas y ajustas
5. Tras confirmar, escribe código

¿Por qué ayuda? Te da oportunidad de arrepentirte.

Ejemplo: internacionalización. En Plan Mode listó:

Plan:
1. Instalar i18next y react-i18next
2. Crear src/i18n/locales/
3. Modificar App.tsx con I18nProvider
4. Actualizar textos hardcodeados (~30 archivos)

Paré en el paso 4: “solo 3 páginas de prueba”. Ajusté el plan y entonces ejecutó.

Sin Plan Mode, 30 archivos ya cambiados y difícil revertir.

Valor práctico: evita destrozos en refactors grandes y funciones nuevas.

Truco 2: dar ejemplos de código concretos

La IA imita bien si le das modelos. Técnicamente es Few-shot Prompting.

Escenario: endpoint API con tu estilo de errores.

❌ Sin ejemplo:

Escribe un endpoint para listar usuarios

Puede salir:

app.get('/users', (req, res) => {
  const users = db.getUsers();
  res.json(users);
});

✅ Con ejemplo:

Escribe endpoint de lista de usuarios siguiendo este estilo:

**Ejemplo 1**:
\`\`\`typescript
export const getProductById = async (req: Request, res: Response) => {
  try {
    const { id } = req.params;
    const product = await productService.findById(id);

    if (!product) {
      return res.status(404).json({
        success: false,
        error: 'Product not found'
      });
    }

    res.json({ success: true, data: product });
  } catch (error) {
    logger.error('Error fetching product:', error);
    res.status(500).json({
      success: false,
      error: 'Internal server error'
    });
  }
};
\`\`\`

Implementa getUserList con el mismo estilo:
- async/await
- Manejo de errores unificado
- Respuesta { success, data/error }
- logger en errores

Resultado alineado:

export const getUserList = async (req: Request, res: Response) => {
  try {
    const users = await userService.findAll();
    res.json({ success: true, data: users });
  } catch (error) {
    logger.error('Error fetching users:', error);
    res.status(500).json({
      success: false,
      error: 'Internal server error'
    });
  }
};

Truco: prompts/templates.md en la raíz con ejemplos listos para copiar al prompt.

Truco 3: definir qué no hacer

Me salvó muchas veces.

La IA quiere “ayudar” y a veces optimiza de más. Pides arreglar un bug y reescribe media pantalla con nuevos problemas.

Según Cursor, restricciones explícitas reducen un 60% de cambios inesperados.

❌ Sin restricciones:

Arregla el bug de paginación en UserList

Puede cambiar props, reescribir paginación o añadir librerías.

✅ Con restricciones:

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Arregla paginación en UserList

**Restricciones**:
- **No modificar** interfaz de props (tipos TypeScript)
- **No introducir** nuevas bibliotecas
- **Solo modificar** lógica interna de handlePageChange
- **No tocar** estilos ni UI

Avanzado: pide suposiciones antes de actuar.

Antes de arreglar el bug, lista:
1. ¿Cuál crees que es la causa?
2. ¿Qué código cambiarás?
3. ¿Cambiarás dependencias o interfaces?

Revisas su entendimiento y luego ejecuta. Ideal en bugs complejos.

Truco 4: criterios de aceptación como ancla

Inspirado en desarrollo ágil.

Define criterios al inicio del prompt (no al final). La IA los usa como objetivo fijo.

❌ Sin criterios:

Refactoriza rendimiento de DataTable

¿Cuándo está listo? ¿Con qué métrica? Adivina.

✅ Con criterios:

Refactoriza rendimiento de DataTable

**Criterios de aceptación** (todos obligatorios):
- [ ] 1000 filas con FPS ≥ 55
- [ ] React.memo y useMemo
- [ ] API del componente intacta (props y callbacks)
- [ ] Pasan todos los tests existentes
- [ ] Pasa ESLint

**Problema actual**:
500 filas, FPS ~20, scroll entrecortado

La IA evita optimizaciones que rompen tests o la API.

Beneficio: menos cambios que “parecen útiles” pero no lo son.

Truco 5: distinguir Inline Edit y Agent Mode

Cursor tiene dos modos; usarlos bien duplica la eficiencia.

Inline Edit (Cmd+K):

• Para: cambios pequeños en un archivo, refactor local, bugs
• Características: rápido, preciso, no cruza archivos
• Ejemplos: renombrar función, parámetro nuevo, bug puntual

Agent Mode (Cmd+I o Chat):

• Para: razonamiento multiarchivo, funciones nuevas, arquitectura
• Características: analiza el repo, opera entre archivos, planifica
• Ejemplos: feature nueva, refactor grande, migración de stack

Antes usaba Agent para todo y era lento. Regla: Inline para simple, Agent para complejo.

Árbol de decisión:

¿Varios archivos?
├─ Sí → Agent Mode
└─ No → ¿Contexto complejo?
    ├─ Sí → Agent Mode
    └─ No → Inline Edit

Escenario 1: renombrar getUserData → fetchUserData
→ Inline Edit: seleccionar, Cmd+K, “renombrar a fetchUserData”, listo.

Escenario 2: permisos de usuario (Model, Controller, View, Config)
→ Agent Mode: analiza, pregunta, planifica, implementa entre archivos.

Elegir mal:

• Inline en tarea compleja → no ve el global, omite cambios relacionados
• Agent en tarea trivial → lento y puede sobre-optimizar

Truco: Plan en Agent para ver cuántos archivos; si son 1-2, vuelve a Inline.

Técnicas avanzadas: tu caja de herramientas de prompts

Plantillas de prompts reutilizables

Tras un tiempo, muchas tareas se repiten: endpoints, componentes, tests, migraciones.

Mejor plantillas que reescribir desde cero.

En mis proyectos hay prompts/:

prompts/
├── api-endpoint.md       # Endpoints API
├── react-component.md    # Componentes React
├── unit-test.md          # Tests unitarios
├── migration.md          # Migraciones de BD
└── refactor.md           # Refactorización

Ejemplo: plantilla de endpoint (prompts/api-endpoint.md)

# Plantilla de endpoint API

## Goal
Añadir endpoint de [descripción] en [módulo]

## Context
- Rutas: src/routes/[módulo].routes.ts
- Controlador: src/controllers/[módulo].controller.ts
- Servicio: src/services/[módulo].service.ts
- Modelo: src/models/[módulo].model.ts

## Desired Behavior
**Request**:
- Method: [GET/POST/PUT/DELETE]
- Path: /api/[ruta]
- Body/Query: [parámetros]

**Response**:
- Éxito: { success: true, data: [...] }
- Error: { success: false, error: "..." }

## Acceptance Criteria
- [ ] Mismo patrón de errores que otros endpoints
- [ ] async/await
- [ ] Validación de entrada (Joi o Zod)
- [ ] logger en errores
- [ ] Pasa TypeScript

## Constraints
- **No modificar** estructura de rutas existente
- **No introducir** librerías nuevas (salvo justificación)
- **Usar** conexión de BD existente

Copias, rellenas y listo.

En equipo: plantillas compartidas unifican estilo y aceleran onboarding.

Agent Skills (novedad 2026)

Tendencia fuerte en herramientas de programación con IA.

Agent Skills son “aplicaciones de IA” reutilizables: encapsulas buenas prácticas y las invocas como una función.

Ejemplo personal: al escribir posts, antes hacía imágenes a mano. Creé un Skill que:

1. Analiza el artículo
2. Detecta secciones que necesitan imagen
3. Genera prompts de imagen
4. Marca posiciones de inserción

Ahora ejecuto el Skill y termina el flujo.

¿Cómo crearlos?

En .cursor/skills/:

.cursor/
└── skills/
    ├── code-review.md
    ├── test-generator.md
    └── api-doc.md

Actualización: en diciembre de 2025, Agent Skills es especificación abierta; Claude Code, Cursor, VS Code y GitHub Copilot la soportan. Un Skill sirve en varias herramientas.

Al principio me pareció “sobre-ingeniería”, hasta un proyecto en equipo con Skills compartidos: calidad y velocidad subieron de golpe.

Optimizar estructura del proyecto para la IA

La IA no lee código como nosotros. Proyecto ordenado → mejor rendimiento.

Recomendaciones:

1. Carpeta /prompts
   Plantillas y ejemplos para copiar al prompt.

2. .cursor/context.md
   Stack, estilo de código, librerías habituales, convenciones (p. ej. métodos privados con _). La IA lo lee automáticamente.

3. Directorios y nombres claros
   utils.ts, helpers.ts, common.ts confunden. Mejor:

   utils/
   ├── date-formatter.ts
   ├── string-validator.ts
   └── array-helpers.ts
   

Experiencia: proyecto caótico = más alucinaciones. Orden ayuda a personas y a la IA.

Guía de errores frecuentes

Error 1: sobrecarga de información

Al empezar pegué requisitos, tres archivos y cinco artículos de referencia pensando “más es mejor”.

Resultado: la IA se ahoga.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Pierde el foco, entiende mal o hace timeout. Como contar diez cosas a la vez.

Solución: divulgación progresiva

1. Necesidad central primero
2. Detalles cuando la IA pregunte
3. Contexto por pasos

❌ Sobrecarga:

Refactoriza autenticación.
[500 líneas de código]
[documento de requisitos]
[tres artículos]
Rendimiento, seguridad, elegancia...

✅ Progresivo:

Ronda 1:
Quiero refactorizar autenticación por seguridad.
JWT actual sin refresh de token.
¿Qué necesitas saber?

[La IA pregunta expiración, almacenamiento...]

Ronda 2:
Token 1 hora en localStorage.
Lógica actual (50 líneas clave):
[código core]

¿Cómo mejorarías?

[Confirmas plan y entonces ejecuta]

La IA se enfoca y tú corriges a tiempo.

Error 2: confiar en la IA sin revisar

El peor tropiezo personal.

Una función de datos pasó tests y se veía limpia. La fusioné. En producción, casos límite devolvían datos incorrectos.

El código que “parece perfecto” es el más peligroso.

Regla: cuanto más rápido genera la IA, más debes revisar.

Tres preguntas habituales:

1. Casos límite: array vacío, null, undefined, extremos
2. Efectos secundarios: ¿impacto en otros módulos?
3. Rendimiento: bucles infinitos, fugas, cálculos redundantes

Truco: auto-revisión de la IA.

Revisa el código que generaste:
1. ¿Qué pasa si la entrada es un array vacío?
2. ¿Hay problemas de rendimiento?
3. ¿Qué suposiciones hiciste? ¿Siempre valen?

A menudo detecta sus propios fallos.

Error 3: esperar perfección a la primera

Muchos tratan la IA como botón mágico. No es realista.

Es colaboradora, no generador automático perfecto. Flujo óptimo: diálogo iterativo.

1. Describes necesidad
2. Propuesta o preguntas de la IA
3. Confirmas, corriges, complementas
4. Optimiza con tu feedback
5. Repite hasta satisfacción

Ejemplo:

Tú: Implementa búsqueda en lista de usuarios

IA: Añadiré caja de búsqueda con filtro en tiempo real.
    ¿Qué campos? ¿Usuario, email, otros?

Tú: Usuario y email, sin filtro en tiempo real;
    al pulsar "Buscar"

IA: ¿Filtro en frontend o petición al backend?

Tú: Frontend, poco volumen de datos

IA: Usaré Array.filter(), primero el plan...

Es conversación, no orden única.

Truco: activa “Show Work” en Cursor para ver el razonamiento paso a paso.

Extra: no pierdas tiempo “domando” el prompt

Consejo contraintuitivo: no persigas el prompt perfecto.

Vi a alguien gastar 30 minutos en un prompt para código que escribía en 5. Al revés del objetivo.

La ingeniería de prompts busca eficiencia, no exhibir redacción.

Si lo haces en 10 minutos, no inviertas 20 en el prompt.

¿Cuándo sí usar IA?

• ✅ Repetitivo (cambios masivos, plantillas)
• ✅ Dominio nuevo (stack o librería desconocida)
• ✅ Complejo pero con patrón (API, CRUD)

¿Cuándo no?

• ❌ Código trivial
• ❌ Algoritmos que requieren pensamiento profundo
• ❌ Código muy custom sin patrón

La IA es herramienta, no fin. Resolver rápido es lo que importa.

Conclusión

Buen prompt no es ciencia oculta: objetivo claro, contexto suficiente, límites definidos.

Resumen de los 5 trucos:

1. Plan Mode primero — oportunidad de arrepentirte
2. Ejemplos de código — que escriba a tu estilo
3. Restricciones explícitas — qué no tocar
4. Criterios de aceptación — meta clara
5. Modo correcto — Inline para simple, Agent para complejo

Con esto la IA deja de ser “asistente torpe” y se vuelve socio real. En mi caso, la precisión subió al menos un 50%; mucho trabajo repetitivo ahora son 10 minutos.

Abre Cursor y prueba la plantilla estructurada en la próxima función: Goal, Context, Desired Behavior, Constraints. Notarás la diferencia al instante.

El futuro no es “IA sustituye programadores”, sino “programadores que usan IA sustituyen a los que no”. Esa brecha empieza con tu primer prompt de calidad.