Claude Code en el día a día: cambios que se pueden revisar
Define contexto, límites y validación para una tarea real con Claude Code, desde la investigación inicial hasta el diff y las pruebas.
“Mejora este proyecto” deja casi todo abierto. El agente debe adivinar prioridad, comportamiento esperado y alcance. Una petición útil empieza por describir el problema, cómo reproducirlo y qué resultado será aceptable.
Imagina un formulario que pierde los datos cuando el servidor devuelve un error. Es un caso hipotético: el objetivo consiste en conservar la entrada y explicar el fallo, sin sustituir la biblioteca ni rediseñar la aplicación.
Fija el punto de partida antes de editar
Comprueba carpeta, rama y cambios existentes. Registra los comandos que funcionan. Separa credenciales y datos reales del material de pruebas. Ofrece contexto suficiente para investigar sin accesos innecesarios.
La documentación de Claude Code describe el modo de planificación para leer y proponer antes de editar, con claude --permission-mode plan.
Pide un diagnóstico con archivos relevantes y una hipótesis comprobable. Si no explica la reproducción, continúa investigando. Un plan convincente debe corresponder al código encontrado.
Delimita el cambio
Indica qué comportamiento conservar y qué módulos importan. Para el formulario, pide mantener valores tras un fallo, mostrar el error y permitir otro intento. Incluye un caso exitoso para evitar arreglar un estado rompiendo otro.
Decide qué acciones externas quedan fuera. Ejecutar pruebas locales es distinto de enviar mensajes, modificar una base compartida o publicar una versión. Los permisos deben corresponder a necesidades concretas.
Revisa cambio y evidencia
Lee el diff buscando modificaciones ajenas, código duplicado y tratamientos de error que solo oculten el fallo. Solicita las salidas de pruebas relevantes y comprueba qué casos se ejecutaron.
En el ejemplo, envía con un fallo simulado, confirma que los campos permanecen y repite con éxito. Una prueba unitaria verifica una función; navegar muestra cómo percibe el resultado una persona. Usa ambas cuando cubran riesgos distintos.
Deja una entrega que otra persona entienda
Registra problema corregido, comportamiento final, comandos y pendientes. Si una integración no estaba disponible, identifica qué parte no se validó. La ausencia de errores en el terminal no demuestra que funcione todo el recorrido.
La ganancia útil aparece cuando el cambio llega a revisión con contexto y pruebas. Cuanto menos tenga que reconstruir el siguiente desarrollador, más fácil será mantenerlo.
Continúa con cuándo repartir el trabajo entre agentes.
Sobre el autor
Tiago F SantiagoComentarios
Todavía no hay comentarios
Comparte una pregunta o una experiencia relacionada con el artículo.
Artículos relacionados
