La IA ayuda más cuando el proyecto está bien acotado
Pedir "crea una app completa" casi siempre termina en algo que no puedes revisar. Codex y Claude rinden mucho mejor cuando el encargo cabe en una tarde: un script, una página simple, una automatización o un prototipo interno que puedas probar tú mismo.
El error común es pedir el proyecto enorme sin explicar alcance, datos, pantallas ni criterios. Con un alcance corto, cada respuesta se puede leer, probar y corregir. Con un encargo enorme, cada respuesta se vuelve un bloque que nadie quiere abrir.
Empieza con algo que puedas revisar. Si el resultado sale mal, tiene que doler poco tirarlo y pedirlo de otra forma. Esa es la ventaja real de empezar chico: el costo de corregir es bajo y el aprendizaje es inmediato.
Define un proyecto pequeño
Buenos primeros proyectos: una página de captura; un script que limpia un CSV; una calculadora interna; una plantilla de email; un resumen de documentos; una herramienta pequeña para ordenar tareas.
La prueba es simple. Si no puedes explicar en dos frases qué entra y qué sale, el proyecto todavía es grande. "Entra un CSV de leads, sale un CSV limpio más un reporte" cabe en dos frases. "Un sistema para gestionar mi negocio" no cabe, y por eso falla: la IA tiene que adivinar qué significa gestionar, para quién, con qué datos y qué cuenta como terminado.
Elige algo verificable. Un buen primer proyecto tiene una entrada concreta que ya tienes, una salida que puedes mirar y un criterio que puedes comprobar sin ser experto. Esa combinación (alcance, archivos relevantes y criterios de aceptación) es lo que la IA necesita para rendir.
Da contexto antes de pedir código
Antes de pedir código, da contexto: objetivo, quién lo usará, entradas y salidas con ejemplo, tecnología preferida, restricciones y cómo se probará. Sin eso, la IA adivina.
Incluye siempre:
- objetivo del proyecto;
- usuario final;
- entradas y salidas, con formato y ejemplo;
- tecnología preferida;
- restricciones;
- cómo se probará.
No es burocracia. Cada punto evita una suposición. Decir "Python sin dependencias externas" evita que instale tres librerías para algo que el estándar resuelve. Decir "la prueba son 8 filas de ejemplo" evita un script que solo funciona con tu archivo perfecto.
Prompt base
Copia y adapta esta base:
Quiero crear una herramienta pequeña para [objetivo].
Usuario: [quién la usará].
Entrada: [datos que recibe, formato y ejemplo].
Salida: [resultado esperado y formato].
Tecnología: [por ejemplo, Python sin dependencias externas / HTML simple].
Restricciones: mantenerlo simple, fácil de revisar y sin dependencias innecesarias.
Antes de escribir código, propón el plan y los archivos que tocarías.
No escribas código hasta que confirme el plan.
Esa última línea cambia todo. Obliga a la IA a mostrar su interpretación antes de generar código, y te da una oportunidad barata de corregir el rumbo. Revisar un plan de diez líneas cuesta dos minutos; revisar trescientas líneas equivocadas cuesta una tarde.
Ejemplo ilustrativo: limpiar una lista de leads
Supón un archivo leads.csv con columnas nombre,email,origen,fecha. Quieres obtener leads_limpios.csv sin duplicados y un reporte.txt breve. Es el ejemplo perfecto: lo entiendes, lo puedes probar y sabes cuándo quedó bien.
Pide así:
Tengo `leads.csv` con columnas nombre,email,origen,fecha.
Crea un script en Python que lea el CSV, normalice emails a minúsculas sin espacios, elimine duplicados por email quedándose con la fila más reciente por fecha, valide formato básico de email y genere `leads_limpios.csv` con columnas limpias más `reporte.txt` con total leído, duplicados eliminados e inválidos.
Incluye instrucciones para ejecutarlo y una prueba con 8 filas de ejemplo.
Fíjate qué lleva dentro: entrada exacta, normalización explícita, regla de desempate por fecha, validación, salidas nombradas, instrucciones y prueba. Nada queda a interpretación.
Dalo por bueno solo si: no quedan duplicados por email normalizado; los inválidos quedan separados, no borrados en silencio; los conteos del reporte coinciden con el archivo; otra persona puede ejecutarlo siguiendo tus instrucciones; la prueba de ejemplo pasa.
Esos cinco puntos son tu criterio de aceptación. Sin ellos, "funciona" significa "corrió una vez en mi máquina". Con ellos, significa que otro humano puede repetirlo y que los números cuadran.
Trabaja por pasos
Pide plan, revisa alcance, luego pide una primera versión, ejecútala, corrige errores y documenta uso. Si algo falla, pega el mensaje de error completo y lo que esperabas. Avanzar en bloques cortos evita reescribir todo.
Un flujo recomendable:
- pedir plan;
- revisar alcance;
- implementar una primera versión;
- ejecutar pruebas;
- corregir errores;
- documentar uso.
El diagrama resume el hábito: primero el plan, después el contexto con datos reales, al final la prueba con criterio. Cuando el script de leads falla en la fila 6, no vuelvas a pedir "hazlo de nuevo". Pega el error, di qué esperabas y pide el cambio puntual. Probar el resultado es parte del trabajo, no un extra para después.
No aceptes cambios sin entenderlos
Aunque la IA escriba el código, revisa: qué archivos cambió y por qué; qué dependencias agregó y si son necesarias; cómo maneja errores y casos vacíos; si hay claves, tokens o datos personales expuestos; si funciona con tus datos de prueba. Si no puedes explicarlo, no lo unas a tu proyecto.
Esa revisión no exige ser programador experto. Exige leer el diff con calma: ¿tocó un solo script o cinco archivos que no pediste? ¿Agregó una librería para algo trivial? ¿Qué pasa si el CSV viene vacío o con una columna cambiada? ¿Quedó alguna clave pegada en el código? ¿Corre con tu prueba de 8 filas? Si alguna respuesta te incomoda, pide que lo simplifique antes de seguir.
Errores típicos al revisar (y cómo pedir el arreglo)
Tres patrones aparecen siempre. Archivos de más: pediste un script y tocó cuatro archivos. Respuesta: "limítalo a estos archivos, sin tocar el resto". Dependencia innecesaria: instaló una librería para algo que el estándar resuelve. Respuesta: "hazlo sin dependencias externas". Silencio ante casos borde: funciona con tu archivo perfecto y rompe con el real. Respuesta: "pruébalo con filas vacías, columnas cambiadas y archivo inexistente, y maneja cada caso".
Guarda estos tres pedidos como texto. Los vas a reutilizar en casi todos tus proyectos pequeños, con cualquier asistente de código.
Aprende con criterio
El objetivo de un proyecto pequeño es que puedas explicar qué recibe, qué entrega y cómo comprobaste el resultado. Repite el ciclo de pedir con contexto, probar y revisar antes de ampliar el alcance. Guarda el prompt, los datos de prueba y las instrucciones junto al script: así puedes volver a ejecutarlo y detectar si un cambio rompe lo que ya funcionaba.
Si quieres practicar con una clase guiada, Claude para Principiantes es gratuito e incluye una lección para crear una mini-app sin programar. Puedes consultar las lecciones y los archivos de práctica en la página del curso. Para conocer las opciones de acceso de la escuela, consulta los planes actuales.
Lee también: De la pregunta al resultado: pide con contexto y revisa y De 5 PDFs sueltos a una decisión en una tarde con NotebookLM y ChatGPT.