Consigue que te generen miniproyectos calibrados, sin el código

Haz de la IA un cliente que redacta unas especificaciones a tu nivel, con hitos y criterios de éxito verificables, pero nunca el código.

8 min · 3 preguntas

Una vez superados los fundamentos, los tutoriales dejan de hacerte avanzar: te hacen copiar soluciones por un camino marcado. Lo que hace avanzar a un desarrollador competente es el proyecto ligeramente por encima de su nivel: lo bastante difícil para forzar decisiones, lo bastante acotado para no atascarse. El problema: calibrarte a ti mismo es casi imposible, eliges algo demasiado fácil o demasiado ambicioso. La IA sobresale en esa calibración, siempre que le des el papel adecuado. El enfoque equivocado: "prográmame una app de seguimiento de gastos"; obtienes el producto terminado y cero habilidad. El enfoque correcto: la IA hace de cliente que redacta las especificaciones; el desarrollador eres tú.

Eres un cliente de proyecto (product owner). Redactas especificaciones, NUNCA escribes código.

Mi perfil: practico [lenguaje/tecnología] con regularidad. Ya sé: [lista honesta]. Quiero mejorar en: [conceptos concretos, p. ej.: gestión de errores asíncronos, testing, división en módulos].
Tiempo disponible: unas [X] horas, repartidas a lo largo de [duración].

Redacta unas especificaciones para un miniproyecto:
- La necesidad en 5 líneas como máximo, formulada como lo haría un cliente real (el QUÉ, nunca el CÓMO).
- De 3 a 5 hitos ordenados, cada uno terminando en algo funcional y demostrable.
- Para cada hito: criterios de éxito OBSERVABLES ("el comando X muestra Y", "el caso Z se rechaza con un mensaje claro", no "el código está limpio").
- Una restricción técnica que me obligue a usar los conceptos concretos.
- 2 extensiones opcionales por si termino antes.

Prohibiciones: nada de fragmentos de código, ni nombres de funciones o bibliotecas impuestos, ni pistas de implementación. La implementación es cosa mía.

La calibración descansa sobre dos datos que solo tú tienes: lo que ya sabes (sé honesto, o el proyecto será demasiado fácil) y aquello en lo que quieres trabajar (uno o dos conceptos, no seis). Los hitos convierten el proyecto en un bucle de retroalimentación: cada paso entrega un comportamiento demostrable, lo que te impide atascarte construyendo una catedral de arquitectura. En cuanto a los criterios de éxito observables, lo cambian todo: "el código está limpio" no se puede verificar, "importar un archivo corrupto muestra un error explícito sin caerse" se puede verificar en diez segundos. Un criterio no observable es una opinión; un criterio observable es una prueba de aceptación.

Eres el cliente del siguiente proyecto: [reformula las especificaciones o pega el hito actual].

Creo que he terminado el hito [X]. Esto es lo que hace mi programa, desde el punto de vista del usuario: [describe el comportamiento observable, no el código].

1. Recorre cada criterio de éxito del hito: hazme preguntas precisas para verificar que se cumple de verdad, incluidos los casos límite (entrada vacía, valor fuera de rango, acción repetida dos veces).
2. Si un criterio no se cumple, di cuál y de qué manera, sin decirme cómo arreglarlo.
3. Si todo pasa, enuncia el siguiente hito, siempre sin código ni pistas de implementación.

Este ritual de validación reproduce la aceptación de un proyecto real: el cliente no lee tu código, interroga el comportamiento. Las preguntas sobre los casos límite son la parte valiosa: ahí es donde descubres lo que tu implementación no gestiona. Queda el momento crítico de todo proyecto en solitario: atascarse. La tentación de pasar a "escríbeme tú esta parte" está en su punto álgido. Resístela con un protocolo de pistas graduadas: cada nivel dice un poco más, y consumes solo el nivel que necesitas para volver a arrancar.

Estoy atascado en mi proyecto [contexto]. El bloqueo: [qué intentas hacer, qué has probado, dónde se rompe].

Dame pistas GRADUADAS, un nivel cada vez:
- Pista 1: la orientación general, un concepto que repasar o una dirección, en una frase.
- Pista 2 (solo si la pido): más precisa, qué parte de MI enfoque reconsiderar.
- Pista 3 (solo si la pido): el principio de la solución, explicado en lenguaje llano, sin código.

Empieza por la pista 1 y espera mi respuesta. Nunca te saltes un nivel, aunque me impaciente o insista.

Prueba de conocimientos

Comprueba que has retenido los puntos clave de esta lección.

1. ¿Qué papel debes darle a la IA para que un miniproyecto te haga avanzar de verdad?
   • Desarrollador: programa él, revisas tú
   • Cliente: redacta las especificaciones y valida los hitos, programas tú
   • Pareja: programa una mitad él, programas la otra tú
2. ¿Cuál de estos criterios de éxito está correctamente formulado?
   • "El código debe ser limpio y mantenible"
   • "La arquitectura debe ser sólida"
   • "Importar un archivo vacío muestra un error explícito sin caerse el programa"
   • "La aplicación debe ser eficiente"
3. A mitad de proyecto, llevas una hora atascado. ¿Qué reflejo preserva el aprendizaje?
   • Pedir el código de la parte que te bloquea para seguir adelante
   • Abandonar el proyecto y generar uno más fácil
   • Pedir pistas graduadas, un nivel cada vez, sin código