Claude Code: cómo empezar con un proyecto real
Publicación original: · Sergey Zhadov
Este es un artículo de archivo traducido. La fecha y los precios se refieren a la publicación original, no a un anuncio nuevo de hoy.
Claude Code trabaja dentro de la carpeta del proyecto. Puede leer la estructura, seguir relaciones entre archivos, editar código y ejecutar comandos. Una primera sesión sensata empieza con una inspección, sigue con un plan pequeño y termina con un diff revisado y pruebas. Pedirle que mejore todo suele fabricar un bonito desastre.
Instalar sin brujería innecesaria
Anthropic recomienda actualmente la instalación nativa. En Windows documenta PowerShell, CMD y WinGet; macOS y Linux tienen sus propios métodos. npm sigue disponible, pero ya no es la única respuesta y sus requisitos de Node.js pueden cambiar.
Comprueba la instalación con claude --version. Si algo falla, claude doctor realiza un diagnóstico de solo lectura. Hace falta conexión a internet y una cuenta compatible. El plan gratuito de Claude.ai no garantiza acceso a Claude Code.
Abrirlo desde la raíz del repositorio
Abre la terminal en la carpeta del proyecto y ejecuta claude. Antes revisa git status y protege los cambios importantes sin commit. Esa tarea aburrida deja de serlo cuando una edición sale torcida.
La primera petición debe ser de lectura: explicar el propósito, localizar puntos de entrada, módulos principales y comandos de test y build, sin cambiar nada. Así se ve rápido si el agente entiende el proyecto o ya está soltando tonterías con seguridad.
Dar una tarea verificable
No escribas mejora la aplicación. Describe el fallo, el comportamiento esperado, los límites y la forma de comprobarlo. Por ejemplo: el formulario envía dos pedidos tras un doble clic; encuentra la causa, propone el cambio mínimo, conserva la API y muestra un plan antes de editar.
Una tarea decente tiene meta: pruebas correctas, tipos válidos, archivos ajenos intactos y fallo no reproducible. Sin eso, el agente puede escribir una montaña de código y arreglar casi nada.
Revisar el plan antes del parche
Pide la causa probable, los archivos afectados y las comprobaciones. Si un fallo pequeño exige rehacer medio proyecto, para el circo y reduce el alcance.
Permite cambios cortos y lee cada diff. Configuración, migraciones, dependencias, autenticación y pagos merecen atención especial. Un tono seguro no convierte un parche arriesgado en uno bueno.
Comprobar con comandos, no con fe
Ejecuta las pruebas, el linter, la comprobación de tipos y el build habituales. Repite tú mismo lo crítico. Si no hay pruebas, reproduce el fallo original y revisa un flujo vecino.
Lee git diff antes del commit. Quita comentarios sobrantes, formato accidental y cambios ajenos. Un commit debe explicar una corrección terminada, no un saco de basura variada.
No entregar todas las llaves
No pegues contraseñas, claves API, datos de clientes ni configuración de producción. Revisa .gitignore y la lista de archivos. Mantén confirmación para comandos arriesgados y limita herramientas cuando sea posible.
Saltar permisos para ahorrar unos clics es una idea bastante cutre. Crea primero un punto recuperable y después deja actuar al agente.
Conclusión: mapa primero, bisturí después
Claude Code resulta útil cuando sigue el contexto entre archivos. El flujo fiable es exploración, plan estrecho, diff pequeño, controles automáticos y revisión humana.
Empieza con un error reproducible. Amplía el alcance solo cuando entiende la estructura y supera las pruebas. Si quiere reescribirlo todo en el primer mensaje, frena ese disparate.
Traducción revisada:
