Programar y crear webs con IA: guía práctica con Claude Code

Programar con un asistente de IA es fácil de empezar y difícil de sostener. La primera tarde parece magia; la segunda semana aparecen los problemas de verdad: el asistente reescribe cosas que funcionaban, inventa una función que no existe, o te devuelve 300 líneas cuando hacían falta tres. Esta guía recoge las prácticas que marcan la diferencia entre las dos experiencias, con Claude Code como ejemplo principal porque es la herramienta con la que trabajamos a diario, aunque casi todo aplica a cualquier agente de programación.

1. El contexto es el recurso escaso, no el modelo

El error más común es tratar al asistente como un buscador: pedirle algo, aceptar lo que salga y seguir. Un agente de programación no falla normalmente por falta de inteligencia, falla por falta de contexto: no sabe cómo se llaman las cosas en tu proyecto, qué convenciones sigues o qué intentaste ya la semana pasada.

La consecuencia práctica: invierte el tiempo en el contexto, no en el prompt. Un prompt largo y florido rinde menos que una frase corta acompañada de los tres ficheros adecuados. Y cuando una conversación se alarga, la calidad baja: si llevas dos horas saltando entre temas, empezar de cero con un resumen escrito por ti suele ser más rápido que seguir tirando del hilo.

2. Un fichero de instrucciones del proyecto

Claude Code lee al arrancar un fichero CLAUDE.md en la raíz del repositorio (y respeta AGENTS.md, el formato que están adoptando varias herramientas). Ahí es donde se escribe lo que no se deduce del código: cómo se lanza el proyecto, qué comandos hay que ejecutar antes de dar algo por bueno, qué partes son delicadas, qué decisiones ya se tomaron y no hay que volver a discutir.

Dos reglas para que sirva de algo. La primera: que sea corto. UnCLAUDE.md de 400 líneas se lee entero en cada conversación y compite por espacio con el trabajo real. La segunda: que contenga hechos, no buenos deseos. “Escribe código limpio” no cambia nada; “los tests se lanzan conpnpm test:unit, y pnpm testarranca Docker y tarda diez minutos” cambia mucho.

3. Planifica antes de tocar código

Para cualquier cambio que toque más de un fichero, merece la pena pedir primero un plan y discutirlo. Claude Code tiene un modo de planificación en el que el agente investiga y propone sin editar nada. El valor no está en el documento: está en que los malentendidos aparecen antes de que haya 200 líneas escritas sobre una premisa equivocada.

Es el mismo motivo por el que en un equipo se revisa el enfoque antes que el pull request. Corregir un plan cuesta un minuto; corregir una implementación cuesta una tarde.

4. Exige verificación, no confianza

Esta es, con diferencia, la práctica que más errores evita. Un agente puede afirmar que algo funciona porque el código “parece” correcto. La única respuesta útil a “ya está arreglado” es “demuéstralo”: que ejecute los tests, que haga la petición HTTP, que lea el fichero generado, que abra la página.

Un patrón que funciona muy bien: pedirle que reproduzca el fallo primero. Si no es capaz de provocar el error, tampoco puede saber si lo ha arreglado. Y cuando el cambio afecta a algo que se ve, pedir una comprobación real —una captura, la salida del comando, la cabecera de la respuesta— en lugar de una descripción.

5. Trocea el trabajo en unidades verificables

“Hazme el panel de administración” es una petición que garantiza una sesión frustrante. “Añade el endpoint que lista usuarios paginado, con su test” es una petición que se puede revisar en dos minutos y aceptar o rechazar con criterio.

La regla práctica: si no sabes cómo comprobarías que está bien, la tarea es demasiado grande. Trocear también protege el contexto, porque cada unidad se abre y se cierra sin arrastrar el ruido de las anteriores.

6. Git es la red de seguridad, úsala de verdad

Trabajar con un agente sin commits frecuentes es trabajar sin deshacer. Conviene tener el árbol limpio antes de empezar algo nuevo, y hacer un commit en cuanto una pieza funciona, aunque sea pequeña. Así, cuando el agente se despiste, el coste de volver atrás esgit checkout y no una tarde de arqueología.

Para tareas largas o experimentales, los worktrees de Git permiten tener varias copias del repositorio en paralelo: el agente trabaja en la suya sin bloquear la tuya y sin riesgo de mezclar cambios a medias.

7. Dale acceso a tus herramientas (MCP), con cabeza

El protocolo MCP permite conectar el asistente a sistemas externos: una base de datos, un gestor de incidencias, tu plataforma de despliegue, tu herramienta de automatización. Es lo que convierte al asistente en algo que puedecomprobar el estado real en lugar de suponerlo.

Dos advertencias. Cada servidor conectado consume contexto con las descripciones de sus herramientas, así que conectar diez “por si acaso” sale caro. Y todo lo que llegue por esa vía —el contenido de una incidencia, una respuesta de una API, una página web— es dato, no instrucción: un agente no debería obedecer lo que ponga dentro de un ticket.

8. Crear webs con IA: dónde ayuda y dónde estorba

Es uno de los usos más buscados, y conviene ser preciso sobre qué funciona hoy. La IA es muy eficaz para arrancar (montar el esqueleto de un proyecto, componentes repetitivos, formularios, estilos, adaptación a móvil) y para tareas mecánicas(migrar una librería, renombrar en todo el repositorio, escribir tests de lo que ya existe).

Donde conviene no delegar a ciegas: decisiones de arquitectura, rendimiento, accesibilidad y cualquier cosa relacionada con seguridad, sesiones o pagos. No porque el modelo no sepa, sino porque el error ahí no es visible y no lo detectas mirando si “se ve bien”.

Un aviso práctico si trabajas con frameworks que cambian rápido: los modelos arrastran las convenciones de la versión que aprendieron. Si tu proyecto va por delante, dilo explícitamente y dale la documentación de tu versión; si no, obtendrás código correcto para un framework que ya no existe.

9. Revisa como revisarías a un compañero nuevo

El código generado se lee, no se acepta. Y se lee buscando cosas concretas: dependencias nuevas que no hacían falta, manejo de errores silenciado, casos límite ignorados, tests que comprueban lo que el código hace en lugar de lo que debería hacer, y “mejoras” que nadie pidió.

Esto último es más frecuente de lo que parece: un agente tiende a ampliar el encargo. Si pediste arreglar un bug y el diff toca ocho ficheros, la pregunta correcta no es “¿está bien?” sino “¿por qué toca ocho ficheros?”.

10. Automatiza lo repetitivo del propio flujo

Cuando una instrucción se repite en todas las sesiones, deja de escribirla y conviértela en parte del entorno. Claude Code permite definir comandos propios para tareas recurrentes yhooks que se ejecutan de forma determinista en momentos concretos —por ejemplo, pasar el formateador después de cada edición—. La diferencia es importante: un hook siempre se ejecuta; una instrucción en un fichero de contexto es solo una sugerencia que el modelo puede pasar por alto.

Los cinco errores que más tiempo cuestan

• Aceptar sin leer. Genera deuda invisible que aparece semanas después.
• Conversaciones eternas. A más ruido acumulado, peores decisiones. Abre una nueva.
• Pedir cosas enormes. Si no se puede verificar en unos minutos, es demasiado grande.
• Discutir con el modelo. Si algo se atasca dos veces, el problema suele ser el planteamiento, no la insistencia. Cambia el enfoque o aporta el dato que falta.
• Delegar lo que no sabes evaluar. Usar IA para escribir código que no entiendes es acumular un pasivo con intereses.

En resumen

Las prácticas que funcionan no van de prompts ingeniosos: van de contexto bien preparado, tareas pequeñas, verificación real y control de versiones. Con eso, un asistente de programación se convierte en un multiplicador estable; sin eso, en una fuente constante de trabajo de limpieza.

Si quieres seguir la actualidad de estas herramientas, publicamos a diario en Herramientas de IA y Agentes de IA.