Lección 3 de 5
Vídeo próximamente
No todas las tareas se le piden a Claude de la misma forma. Reconocer el tipo de tarea te ahorra tiempo y evita idas y vueltas innecesarias.
Construir algo nuevo desde cero. Sé específico sobre el resultado esperado (qué debe hacer, qué datos necesita, cómo se ve). Deja que Claude proponga la implementación técnica — tu trabajo es definir el "qué" y el "para quién", no necesariamente el "cómo" a nivel de código.
Arreglar un error o bug. Pega el mensaje de error completo, no un resumen tuyo del error. Describe qué esperabas que pasara versus qué pasó realmente, y en qué paso exacto ocurrió. Entre más contexto exacto, más rápida la solución — un resumen tipo "no funciona" obliga a Claude a hacer preguntas que ya podrías haber respondido en el primer mensaje.
Modificar algo que ya existe. Señala el archivo o la sección exacta a cambiar, y qué comportamiento debe mantenerse igual. Evita pedir cambios vagos como "mejora esto" — sé concreto sobre qué "mejor" significa aquí: ¿más rápido? ¿más simple visualmente? ¿con un caso de error que hoy no se maneja? Cada una de esas es una tarea distinta con una solución distinta.
Entender código que no escribiste tú. Pide una explicación en lenguaje simple antes de pedir cambios. Vas a tomar mejores decisiones si entiendes qué está pasando, no solo copiando y pegando resultados sin saber por qué funcionan — y cuando algo falle más adelante, vas a poder diagnosticarlo tú mismo en vez de depender de la IA para cada ajuste, por pequeño que sea.
En los cuatro casos, revisa lo que Claude genera antes de aceptarlo — tú sigues siendo responsable de lo que se publica, la IA es la herramienta, no quien decide. Leer el diff completo antes de aceptar un cambio no es paranoia, es el mismo criterio que aplicarías revisando el trabajo de cualquier colaborador antes de que llegue a producción.