Práctica de inicio: Un caso real desde la planificación a la entrega

📚 Navegación de la serie: El artículo anterior 38 Manual de referencia de plugins te enseñó a empaquetar y distribuir tu configuración. En este artículo cambiamos de marcha: los treinta y ocho artículos anteriores se centraron en detallar características individuales; en este uniremos todas las piezas en un flujo práctico real: desde analizar el repositorio, escribir CLAUDE.md, planificar la tarea, supervisar la edición de código, hasta la validación y entrega definitiva. Es hora de poner en práctica lo aprendido de forma integrada.

Seamos honestos: la mayoría de la gente cree que programar con IA consiste simplemente en "escribir una frase y esperar el resultado". Le pides la tarea, Claude la ejecuta y tú usas el código. Pero al primer fallo descubres dónde se rompe el flujo:

La IA toma el rumbo equivocado, modifica tres archivos que no debía tocar, o el código sigue fallando tras la corrección... Al final, el tiempo dedicado a solucionar desvíos supera al de escribir el código uno mismo.

La causa no es que la herramienta no sea inteligente; es que el flujo de trabajo carece de los puntos de control intermedios necesarios.

Hay una gran diferencia entre "conocer los comandos" y "saber coordinarlos en un desarrollo real". Puedes saber girar el volante, mirar por los espejos y frenar; pero para conducir de forma segura necesitas ejecutar estos movimientos en el orden correcto. Este artículo no presentará características nuevas; se centrará en conectar los recursos estudiados en un flujo de trabajo funcional.

Elegiremos una tarea sencilla pero ilustrativa: añadir una opción a un script en Python que contabiliza la frecuencia de palabras y corregir un fallo de entrada. La tarea es directa, pero incluye todos los pasos de un desarrollo real de principio a fin.

Al terminar de leer este artículo, obtendrás:

• La estructura de un flujo de trabajo estándar: "Inicio → Exploración → Planificación → Edición → Validación → Entrega", indicando qué comandos y comprobaciones realizar en cada fase.
• Un caso práctico real con comandos y resultados: añadir el parámetro --top N a un script de conteo de palabras y corregir la caída por argumentos vacíos.
• Por qué la directriz "explorar antes de modificar" es un hábito fundamental en el desarrollo con IA.
• Cómo utilizar el modo plan (plan mode) (ver artículo 20) para obligar a Claude a proponer planes de acción estructurados antes de editar, y cómo supervisar los cambios con git diff.
• Una tabla de comparación: "cómo trabaja un principiante frente a un desarrollador experimentado" para evitar desvíos y reprocesos de código.

---

01 Vista general: Las seis fases de una tarea de desarrollo

Antes de escribir código, analicemos el flujo de trabajo completo. Cualquier tarea de desarrollo, independientemente de su complejidad, se estructura en estas seis fases:

Analogía: El paso del testigo en una carrera de relevos. Las seis fases son como los corredores de un equipo: el corredor de exploración entrega la información del código al de planificación, este pasa el plan detallado al de edición, y este a su vez entrega las modificaciones al de validación. Si un corredor comete un fallo en el relevo, el equipo al completo tiene que volver a empezar. La mayoría de fallos al programar con IA ocurren por omitir una fase, típicamente al dar el salto directo de "Inicio" a "Edición" sin pasar por la "Exploración", iniciando la tarea sin asimilar las convenciones del repositorio.

Estas fases provienen de la combinación de las guías de inicio rápido y flujos de trabajo comunes descritas en la documentación de la herramienta. La recomendación de Anthropic es clara:

Permite que Claude asimile tu código antes de realizar modificaciones.

Puedes acortar los tiempos de las fases, pero no omitirlas. Los desarrolladores experimentados integran "Exploración + Planificación" en una única consulta, y "Validación + Entrega" en un solo paso; pero las fases se ejecutan. El error más común consiste en realizar un salto de dos pasos ("Prompt de entrada → Código generado"), lo que equivale a lanzar el testigo desde el inicio esperando que llegue solo a la meta. En este artículo recorreremos las seis fases en un ejercicio real, identificando qué herramientas de los capítulos anteriores aplicar en cada paso.

💡 Resumen en una frase: El desarrollo estructurado consta de seis fases: Inicio, Exploración, Planificación, Edición, Validación y Entrega, coordinadas paso a paso; omitir la fase de exploración inicial es la causa principal de fallos y desvíos de código.

---

02 Preparación: Creación del proyecto de pruebas

Para que puedas reproducir los pasos de forma exacta, no modificaremos un proyecto complejo; dedicaremos dos minutos a crear un entorno mínimo de pruebas. Se compone de un script en Python y un archivo de texto de muestra, sin librerías de terceros; basta con disponer de python3 (instalado de forma nativa en macOS/Linux y disponible en Windows).

Paso 1: Crear la carpeta de desarrollo e iniciar los archivos

En tu terminal de sistema (sin iniciar Claude Code todavía), ejecuta:

mkdir wordcount-demo && cd wordcount-demo

Crea el archivo wordcount.py e introduce este código (es el script que refactorizaremos; lo hemos escrito con algunas deficiencias de entrada a propósito):

import sys
from collections import Counter

def count_words(path):
    with open(path) as f:
        text = f.read()
    words = text.lower().split()
    return Counter(words)

def main():
    path = sys.argv[1]
    counts = count_words(path)
    for word, n in counts.items():
        print(f"{word}: {n}")

if __name__ == "__main__":
    main()

Crea el archivo sample.txt con este texto para usarlo como datos de pruebas:

the quick brown fox the lazy dog the fox

Paso 2: Ejecutar el script para comprobar su funcionamiento

python3 wordcount.py sample.txt

Resultado esperado (el orden de las palabras puede variar, pero el recuento de frecuencias debe ser el mismo):

the: 3
quick: 1
brown: 1
fox: 2
lazy: 1
dog: 1

Si el recuento coincide, el script está operativo. Este script presenta dos deficiencias que solucionaremos en el ejercicio:

• Falta de funcionalidad: queremos ver el ranking de las N palabras más comunes, pero actualmente el script muestra toda la lista sin filtros.
• Bug de robustez: si ejecutas el script sin pasar argumentos (python3 wordcount.py), la terminal mostrará un error del tipo IndexError en lugar de una advertencia amigable explicándote cómo usar la herramienta.

Paso 3: Comprometer el estado inicial en git (importante, no omitir)

git init && git add . && git commit -m "init: script inicial de conteo de palabras"

Resultado esperado: la consola informará de que se han comprometido dos archivos (wordcount.py y sample.txt). Dispones de un punto de retorno limpio; independientemente de los cambios de Claude, siempre podrás revertir el estado del repositorio a este punto.

Como explicamos en el artículo 37, los checkpoints de Claude ayudan a revertir ediciones locales, pero son herramientas diferentes a git. Tener un commit de partida en git te asegura poder regresar a la versión funcional si las ediciones automáticas desvían el rumbo del desarrollo. Acostúmbrate a crear un commit antes de iniciar tareas asistidas por IA.

💡 Resumen en una frase: Preparamos un entorno de pruebas con un script de Python de conteo y un archivo de datos, comprobando que funciona con python3; definimos dos tareas (añadir parámetro y corregir caída), e iniciamos un commit en git para disponer de un punto de retorno seguro.

---

03 Fase 1: Inicio de sesión y archivo de contexto CLAUDE.md

Con el entorno preparado, iniciamos la primera fase: Inicio. Cubre los conceptos de los artículos 02, 07, 12 y 18.

Paso 1: Iniciar Claude Code en la carpeta del ejercicio

Debes ejecutar la instrucción dentro de la carpeta wordcount-demo. Claude Code toma la carpeta de inicio como área de trabajo; si inicias en otra ruta, la IA no tendrá acceso al código del script.

claude

Resultado esperado: se iniciará el chat interactivo de Claude Code mostrando la ruta wordcount-demo en la barra inferior de estado.

Paso 2: Generar un archivo CLAUDE.md básico

En el artículo 18 explicamos que un archivo CLAUDE.md sobrecargado de instrucciones de cientos de líneas es ignorado por la IA. En proyectos pequeños, describe las convenciones en unas pocas líneas claras. En este caso, el script tiene dos reglas: el uso de bibliotecas y el método de validación. Pídele que lo cree desde el chat:

Crea un archivo CLAUDE.md en la raíz del proyecto que detalle las siguientes pautas:
1. Este es un script de Python que solo debe utilizar la biblioteca estándar, sin añadir dependencias de terceros.
2. Tras realizar cambios en el código, la validación se realiza ejecutando el comando: python3 wordcount.py sample.txt

Resultado esperado: Claude mostrará la propuesta de texto y te pedirá autorización para escribir el archivo (siguiendo las reglas del sistema de permisos explicadas en el artículo 20). Al aprobar, se creará el archivo CLAUDE.md en la raíz con un contenido similar a:

# wordcount-demo

Script de línea de comandos para la frecuencia de palabras.

## Restricciones técnicas
- Solo utilizar la biblioteca estándar de Python, **sin dependencias externas**.

## Validación
- Comprobar que no hay errores tras las ediciones ejecutando: `python3 wordcount.py sample.txt`

El archivo es corto y define las reglas clave. Para proyectos sencillos, esta síntesis es más efectiva que un archivo complejo.

Nota: en este caso hemos guiado la creación a mano al ser dos archivos. Para repositorios grandes, el comando slash /init (artículo 12) es el recomendado, ya que escanea los archivos y estructura la documentación de forma automática.

¿Por qué creamos el archivo CLAUDE.md al inicio? Define las directrices del resto de fases. Al añadir la funcionalidad, Claude consultará este archivo y recordará que no debe usar dependencias de terceros ni librerías adicionales, y sabrá cómo ejecutar la comprobación de errores sin que tengas que repetirlo en cada prompt.

💡 Resumen en una frase: La fase de inicio implica ejecutar claude en la carpeta del repositorio y crear un CLAUDE.md con las directrices básicas de desarrollo y validación, asegurando que las futuras ediciones respeten las restricciones de librerías.

---

04 Fase 2: Exploración del código del repositorio

Esta es la fase de relevo de información más importante y la que más suelen omitir los principiantes. Cubre las herramientas descritas en el artículo 16.

Regla de desarrollo: el primer prompt ante una tarea debe ser "analiza", nunca "modifica".

Si inicias el desarrollo pidiendo directamente "añade el parámetro --top al script", Claude modificará el código a ciegas intentando adivinar el comportamiento del archivo. Lo correcto es solicitar una exploración previa del entorno:

No realices cambios en el código todavía. Analiza el archivo @wordcount.py y explícame cómo funciona su flujo, el punto de entrada y si detectas algún fallo estructural o de entrada.

Detalles de la consulta:

• Añadimos la cláusula "no realices cambios en el código todavía" como límite de seguridad (artículo 15).
• Usamos la referencia @wordcount.py para inyectar el código del script directamente en el prompt (artículo 16 y 17), facilitando la lectura sin que Claude tenga que buscar el archivo.

Resultado esperado: Claude leerá el script y te presentará un análisis: explicará que el script utiliza Counter para procesar el conteo, que el punto de entrada es la función main() que toma el argumento de sys.argv[1], y señalará que el script caerá con un error IndexError si no se le pasa ningún argumento en la llamada.

La IA detectará la causa del error antes de que le pidas que lo solucione. La exploración te proporciona un análisis preciso y prepara el contexto del chat para la refactorización.

Nota para proyectos grandes: el análisis se inicia de forma jerárquica. La documentación oficial recomienda consultar primero la estructura general y después bajar a los archivos concretos:

Muestra la estructura general de este repositorio para entender qué archivos contiene (no realices modificaciones)

¿En qué archivos se gestiona el control de acceso de usuarios y cómo interactúan?

Este desglose evita que la IA cargue archivos innecesarios en el contexto. Para tareas extensas con decenas de archivos, puedes delegar el análisis de lectura en un subagente (subagent) (artículo 23) para que lea las carpetas en su ventana de chat y te entregue las conclusiones en tu conversación principal sin saturar el contexto. En nuestro script de conteo, al ser dos archivos, la lectura directa es suficiente.

💡 Resumen en una frase: En la exploración, pide a Claude que analice el código con la regla "no realices cambios aún" y pasa el archivo como referencia con @; esto evitará suposiciones erróneas y preparará el terreno para la planificación.

---

05 Fase 3: Planificación de cambios en modo planificador

Tras explorar el código, Claude conoce el archivo. Ahora solicitaremos una propuesta técnica detallando qué cambios planea realizar en el código antes de autorizar la escritura. Haremos uso del Plan Mode (artículo 20).

Detener a Claude antes de que escriba te permite validar si la lógica que propone coincide con la arquitectura de tu aplicación, evitando que empiece a modificar archivos en caliente.

Opción 1: Instrucción directa de planificación en el chat

La vía más rápida consiste en pedirle el plan en el prompt de entrada:

Queremos añadir el parámetro opcional --top N al script para que muestre el ranking de las N palabras más comunes. También corregiremos el fallo de IndexError si no se introducen parámetros de entrada en la consola. Detalla tu propuesta de cambios y qué archivos modificarás, y espera a mi confirmación para proceder con la edición.

Resultado esperado: Claude presentará un plan detallado: propone sustituir la lectura manual de sys.argv por la librería estándar argparse, configurar un parámetro posicional para la ruta del archivo y una opción --top de tipo entero, procesar las frecuencias usando Counter.most_common(N) e imprimir el resultado. Claude se detendrá esperando tu autorización sin editar archivos.

Opción 2: Activación formal de Plan Mode

Para desarrollos complejos o repositorios compartidos, activa formalmente el modo planificador de permisos. Puedes hacerlo de dos formas (artículo 20):

• Iniciando la sesión de consola con el flag: claude --permission-mode plan
• Pulsando el atajo de teclado Shift+Tab hasta seleccionar la barra de estado plan.

La documentación oficial define este comportamiento:

...

Claude analiza los archivos y propone un plan, pero bloquea cualquier edición en el código fuente hasta que autorices los cambios.

Comparamos ambas opciones de planificación:

Estrategia	Método	Nivel de restricción	Ámbito óptimo
Petición en el prompt	Indicar en la consulta "explica el plan y no edites"	Laxo (Claude suele respetarlo, pero no hay bloqueo de software)	Pequeñas modificaciones en caliente.
Plan Mode de permisos	Activar por atajo o flag de inicio	Estricto (las herramientas de edición están bloqueadas por el software)	Refactorizaciones complejas, proyectos de equipo.

Para nuestro script --top la directriz en el prompt es suficiente; si la refactorización implicara múltiples carpetas o reescribir la lógica de validación, usa Shift+Tab para activar el modo plan formal en la terminal y asegurar el bloqueo de la edición hasta aprobar el plan.

💡 Resumen en una frase: En la fase de planificación, exige a Claude que te detalle la propuesta de edición antes de modificar archivos; para cambios sencillos basta con indicarlo en el prompt, y para tareas complejas activa el Plan Mode con Shift+Tab para bloquear las herramientas de escritura.

---

06 Fase 4: Edición supervisada y revisión de diferencias (diffs)

Una vez que validas el plan y apruebas su estructura, pasamos a la fase de Edición y Supervisión. Cubre el sistema de permisos interactivos del artículo 20.

Paso 1: Dar la orden de proceder

El plan es correcto. Procede a aplicar las modificaciones en el script.

Resultado esperado: Claude iniciará la refactorización de wordcount.py. En el modo de permisos por defecto, ante cada cambio propuesto, la consola se detendrá y te mostrará el diff (las diferencias de código) pidiendo tu confirmación.

Paso 2: Inspeccionar el diff detenidamente

Evita la pulsación rápida de la tecla y para aprobar cambios sin revisarlos. Haz una lectura crítica del diff. En este ejercicio, deberías ver cambios como:

- import sys
+ import argparse

- def main():
-     path = sys.argv[1]
-     counts = count_words(path)
-     for word, n in counts.items():
+ def main():
+     parser = argparse.ArgumentParser(description="Recuento de palabras en un archivo.")
+     parser.add_argument("path", help="Ruta del archivo de texto")
+     parser.add_argument("--top", type=int, default=None, help="Número de palabras más comunes a mostrar")
+     args = parser.parse_args()
+     counts = count_words(args.path)
+     items = counts.most_common(args.top) if args.top else counts.most_common()
+     for word, n in items:

Revisa las siguientes tres pautas al evaluar el diff:

• Estructura: ¿las modificaciones se corresponden con el plan acordado? (En nuestro caso: usa argparse y counts.most_common(args.top)).
• Aislamiento: ¿se limita a modificar las áreas indicadas? (No ha modificado la función count_words, que es la correcta).
• Políticas: ¿cumple con las restricciones de CLAUDE.md? (Usa la biblioteca estándar argparse y no introduce librerías externas).

Si los tres puntos son conformes, aprueba la modificación.

Nota sobre la configuración interactiva: en fases avanzadas de desarrollo puedes activar el modo acceptEdits (artículo 20) para que Claude aplique cambios en archivos sin detenerse a consultar. Sin embargo, te recomendamos usar la revisión interactiva por defecto durante tus primeros meses de desarrollo asistido. Te proporcionará control sobre el código generado y te ayudará a entender el comportamiento de la IA.

Aprobar el diff en la consola es tu filtro de control en caliente. Si detectas un error en el diff, cancela la edición y pídele la corrección en ese instante, lo cual es más rápido que tener que restaurar versiones después.

💡 Resumen en una frase: En la edición, deja que Claude modifique el código pero revisando cada diff que presente; comprueba que se ajusta a lo planificado y que respeta el CLAUDE.md antes de pulsar la confirmación, la cual actúa como tu filtro de control interactivo.

---

07 Fase 5: Validación real de la ejecución

Una vez que Claude informa de que el código ha sido modificado y los problemas están resueltos, pasamos a la fase de Validación. Cubre el uso de herramientas de consola y la regla de no asumir respuestas sin verificar de la serie.

Regla de desarrollo: la afirmación de la IA "hecho" es solo una hipótesis; la comprobación en consola es la confirmación real.

No des la tarea por concluida hasta verificar el funcionamiento del script con pruebas reales en tu máquina.

Paso 1: Validar el nuevo parámetro (--top)

Ejecuta el script solicitando únicamente el ranking de las tres palabras más comunes:

python3 wordcount.py sample.txt --top 3

Resultado esperado (ordenado de mayor a menor frecuencia, mostrando únicamente tres elementos):

the: 3
fox: 2
quick: 1

(El valor de la tercera palabra puede variar al tener varias con frecuencia 1; pero la longitud de la lista debe ser de tres y respetar el orden de frecuencia).

Paso 2: Validar el comportamiento anterior (regresión)

Comprueba que la llamada tradicional sin parámetros opcionales sigue funcionando de forma correcta:

python3 wordcount.py sample.txt

Resultado esperado: el listado de las seis palabras del archivo al completo, confirmando que la introducción del nuevo parámetro no ha roto la lógica heredada del script.

Paso 3: Validar la robustez ante la ausencia de argumentos

Ejecuta el script omitiendo la ruta del archivo para comprobar el control de errores:

python3 wordcount.py

Resultado esperado: la consola no mostrará la caída de IndexError, sino que presentará una advertencia limpia indicando que el argumento de la ruta es obligatorio, finalizando con un código de salida adecuado:

usage: wordcount.py [-h] [--top TOP] path
wordcount.py: error: the following arguments are required: path

La validación confirma el funcionamiento correcto de las dos refactorizaciones.

Validación avanzada: en desarrollos de producción, puedes pedirle a Claude que implemente pruebas unitarias automáticas para verificar el bug en el futuro (como se describe en los flujos de trabajo del artículo 16):

Escribe un script de pruebas unitarias usando unittest para comprobar que el script de conteo de palabras no se cae ante la ausencia de argumentos y que el parámetro --top filtra las palabras correctamente. Ejecuta el test y asegúrate de que pasa con éxito.

Para este ejercicio sencillo no es obligatorio añadir la clase de prueba, pero quédate con que la validación de fallos en desarrollo real debe acompañarse de pruebas automáticas para evitar que futuras modificaciones rompan la lógica del código.

💡 Resumen en una frase: En la fase de validación, ejecuta las pruebas en consola (verificar el nuevo parámetro, confirmar que la lógica heredada no se ha roto y comprobar la robustez ante fallos de entrada); la validez del desarrollo depende de los resultados de la terminal, no de la respuesta textual de la IA.

---

08 Fase 6: Confirmación del cambio y entrega definitiva en git

Superadas las comprobaciones de validación, iniciamos la última fase: Entrega. Cubre el uso de herramientas de git del artículo 07.

Paso 1: Consultar la lista de cambios del repositorio

Pide a Claude una revisión final de los archivos modificados:

Muestra la lista de archivos que se han modificado y el estado de git.

Resultado esperado: Claude ejecutará git status y te confirmará que el único archivo con modificaciones pendientes es wordcount.py, junto al archivo CLAUDE.md que creamos en la fase de inicio.

Paso 2: Generar y aplicar el commit en git

Pídele que redacte el mensaje de confirmación y procese el commit:

Escribe un mensaje de commit normalizado describiendo los cambios aplicados en wordcount.py y procede a realizar el commit de git en local.

Resultado esperado: Claude propondrá un mensaje de commit estructurado (como feat: añadir opción --top y usar argparse para corregir la caída por argumentos vacíos) y te solicitará confirmación para ejecutar la acción de git commit en tu consola. Al aprobar la solicitud, confirmará los cambios en tu repositorio local.

Detalle de límites de seguridad: Claude Code puede procesar commits de git en tu local previa confirmación; sin embargo, no dejes en sus manos la publicación en repositorios remotos (git push). Realiza la subida a producción de forma manual (veremos esto detalladamente en el artículo 43).

Paso 3: Validar el registro en el histórico

Muestra el último commit registrado en el repositorio.

Resultado esperado: Claude ejecutará git log -1 y mostrará la información de tu commit, confirmando que los cambios de código y documentación se han consolidado en el histórico del proyecto de forma definitiva.

Con este último paso habrás completado las seis fases de una tarea de desarrollo: inicio, exploración, planificación, edición, validación y confirmación en el repositorio.

💡 Resumen en una frase: La fase de entrega implica revisar el listado de cambios de git, pedirle a Claude que redacte el commit y consolidar los archivos en local, dejando el comando git push a tu control manual.

---

09 Gestión de errores en la validación: Cómo retroceder de forma limpia

En el desarrollo de este ejercicio no hemos tenido problemas, pero en el día a día es común que en la fase de validación (fase 5) detectes fallos de lógica o sintaxis.

El error más común de los principiantes consiste en pedirle a Claude que intente corregir el código modificando el archivo que ya se ha desconfigurado. Tras varias iteraciones, el código se vuelve incomprensible al acumular parches sobre parches.

La estrategia recomendada consiste en retroceder al último estado limpio y volver a planificar.

Dispones de dos métodos de restauración según el momento en el que detectes la anomalía (artículo 37):

Nivel de restauración	Herramienta	Acción de sistema	Ámbito óptimo
Restauración local (ligera)	Checkpoints (/rewind o doble Esc)	Revierte los archivos a la captura previa al prompt que introdujo el fallo.	Corregir pequeños bugs en caliente dentro de la sesión.
Restauración persistente (completa)	Git (git checkout o git reset --hard)	Devuelve el repositorio al commit de partida que realizamos en la fase de preparación.	La lógica del desarrollo se ha desconfigurado y prefieres empezar desde cero.

Si tras la edición notas que el código de wordcount.py se ha desviado, escribe /rewind y revierte la sesión al checkpoint inicial. Si la desconfiguración es mayor, usa git checkout para limpiar los archivos. Una vez restaurado el estado limpio, analiza por qué falló la propuesta inicial y redefine el prompt de planificación añadiendo las restricciones necesarias antes de iniciar la edición de nuevo. El retroceso controlado ahorra tiempo y tokens en comparación con la depuración sobre código erróneo.

💡 Resumen en una frase: Si la validación devuelve fallos, revierte los cambios a un estado limpio usando /rewind o git en lugar de aplicar parches sobre código incorrecto; analiza las causas de la desviación y reformula el prompt de planificación antes de editar.

---

10 Tabla comparativa: Metodología de desarrollo

Compara cómo aborda el desarrollo de un caso práctico un desarrollador principiante frente a uno experimentado:

Fase	Metodología de principiante (desvíos)	Metodología experimentada (control)
Inicio	Inicia Claude en cualquier carpeta sin reglas claras de desarrollo.	Inicia en la raíz del proyecto y define un CLAUDE.md con las restricciones y validaciones.
Exploración	Pide la edición directa en el primer mensaje de la conversación.	Exige un análisis de lectura previo del código con la cláusula "no modifiques".
Planificación	Deja que la IA empiece a escribir código sin proponer la solución previamente.	Exige la descripción del plan de acción y utiliza el Plan Mode para validar la arquitectura.
Edición	Aprueba los diffs de forma automática pulsando y sin leer el código.	Revisa cada diff de forma crítica comprobando el aislamiento de los cambios y reglas de CLAUDE.md.
Validación	Confía en la confirmación textual de la IA de que el cambio funciona.	Ejecuta comprobaciones manuales y automáticas en la consola para validar cada caso de uso.
Entrega	Mantiene los cambios en disco sin registrar versiones en el repositorio.	Comprueba el estado de git y consolida las modificaciones con un commit local estructurado.

La diferencia radica en no saltarse los relevos de información. Aplicar la metodología experimentada te asegurará desarrollos más rápidos, seguros y libres de errores colaterales.

💡 Resumen en una frase: Los desarrolladores experimentados aseguran el control en cada paso (CLAUDE.md, plan previo, revisión de diffs y pruebas en consola), mientras que los principiantes confían en la automatización directa de la IA, lo que suele derivar en reprocesos de código.

---

11 Resumen

En este artículo hemos recorrido un flujo de desarrollo completo aplicando las herramientas estudiadas de forma integrada.

Repasemos los pasos seguidos en la práctica:

Fase	Acción ejecutada en el ejercicio	Herramientas aplicadas
Inicio	Iniciamos en wordcount-demo y creamos las pautas en CLAUDE.md.	Comandos de consola y estructura del proyecto.
Exploración	Pedimos un análisis del código sin editar para identificar el bug de IndexError.	Consultas de lectura e inyecciones de contexto con @.
Planificación	Solicitamos el plan de acción para usar argparse y Counter.most_common.	Estrategias de prompts y uso de Plan Mode.
Edición	Autorizamos los cambios y supervisamos la modificación en el diff interactivo.	Sistema de confirmación de permisos.
Validación	Ejecutamos el script comprobando el parámetro --top y la respuesta ante argumentos vacíos.	Herramientas de terminal y verificación de ejecución.
Entrega	Verificamos las diferencias de git y consolidamos los cambios con un commit local.	Integración con git y control de versiones.

Ahora deberías ser capaz de: estructurar una tarea de desarrollo de principio a fin siguiendo las seis fases recomendadas, redactar archivos CLAUDE.md funcionales para tus proyectos de pruebas, guiar a Claude para analizar el código antes de modificarlo, validar propuestas en el modo de planificación, supervisar diffs en caliente identificando posibles desviaciones, comprobar de forma física la robustez del código en la consola, y consolidar tus desarrollos de forma limpia en el control de versiones. Coordinar estas fases te permitirá programar con soltura, velocidad y seguridad asistido por Claude Code.

Aplica este flujo de trabajo en tu próxima sesión de desarrollo.

---

En el próximo artículo, 40 "Uso de Chrome (Browser Subagent)", daremos el salto al desarrollo frontend. En esta práctica hemos trabajado en la consola y sobre archivos locales. En la siguiente sección explicaremos cómo Claude utiliza el navegador de forma autónoma, cómo interactúa con elementos web para rellenar campos, validar renders y capturar datos, y cómo te ayuda a probar desarrollos web de forma automatizada. Piensa en esto: ¿cómo puede Claude comprobar que un formulario web funciona correctamente y que el diseño se renderiza bien? Lo analizaremos en el próximo artículo.

---

Lecturas recomendadas

• Uso de JetBrains: Integración de la herramienta
• Estilos de salida: Modificar el comportamiento y tono de Claude
• Flujos de trabajo comunes: Análisis, depuración y pruebas