Cómo Desarrollo con IA

Contexto

Quién soy

Soy Victor Martin Garcia. Llevo más de 25 años construyendo software. He escrito código, construido equipos, dado clases en la universidad y liderado empresas. Hoy lo que más me entusiasma es explorar cómo la IA está cambiando nuestra forma de trabajar como desarrolladores.

Lo que sigue es mi proceso real para desarrollar con IA. Lo que funciona, lo que no, y lo que he aprendido construyendo productos reales de esta manera.

Vibe coding vs. ingeniería con agentes

Hay una distinción que conviene hacer desde el principio, porque marca la diferencia entre resultados mediocres y resultados profesionales.

Vibe coding es lanzar prompts a un modelo, aceptar lo que devuelve, y seguir adelante sin revisarlo con profundidad. Funciona para prototipos rápidos y experimentos personales. No funciona para software que va a producción.

Ingeniería con agentes es otra cosa. Aquí la IA ejecuta tareas bajo supervisión humana rigurosa. Tú defines la intención, estableces estándares de calidad, revisas cada resultado, y mantienes el control arquitectónico del proyecto. El agente es un ejecutor muy capaz, pero tú sigues siendo el director.

Una nota para developers junior

Si aceptas código del agente sin entender lo que hace, no estás aprendiendo. Estás creando la ilusión de competencia. El código funciona, el test pasa, el PR se mergea. Pero si te preguntan por qué funciona, no tienes respuesta.

La IA es una herramienta de aprendizaje extraordinaria si la usas activamente. Pídele que te explique cada decisión. Pregúntale por qué eligió ese patrón y no otro. Pídele alternativas y compáralas. Usa el agente como un mentor paciente que responde a cualquier pregunta sin juzgarte.

Lo que no puedes hacer es usarla como atajo para saltarte el aprendizaje. Los fundamentos importan. Algoritmos, estructuras de datos, patrones de diseño, cómo funciona la red, cómo funcionan las bases de datos. Sin esa base, no puedes evaluar lo que el agente produce. Y si no puedes evaluarlo, no puedes dirigirlo.

El cambio de rol

Trabajar con agentes cambia fundamentalmente lo que haces como desarrollador. Pasas de ser quien implementa a ser quien dirige. Tu día a día se parece menos a escribir código y más a clarificar intención, revisar arquitectura, y refinar calidad.

Esto no significa que dejes de pensar técnicamente. Al contrario. Necesitas más criterio técnico que nunca, porque estás tomando decisiones de diseño constantemente y evaluando si lo que el agente produce es correcto, eficiente y mantenible.

La IA también te ayuda en partes del ciclo que antes ignorábamos o hacíamos con desgana: analizar requisitos, generar casos de test exhaustivos, escribir documentación, parsear logs de despliegue. No es solo una herramienta de implementación. Es un asistente en todo el ciclo de vida del software.

Sobre las herramientas

Ahora mismo uso Claude Code como mi asistente de código IA principal. Pero la herramienta no es lo importante. Todo en este espacio se mueve tan rápido que lo que uso hoy puede no ser lo que use el mes que viene.

No estoy afiliado a Anthropic, OpenAI, ni a ninguna empresa de IA. Simplemente uso lo que mejor me funciona ahora y comparto lo que voy descubriendo.

El proceso

Preparación

Lo que configuras una vez y te acompaña en cada proyecto. Estas decisiones definen cómo trabajarás con los agentes antes de escribir la primera línea de código.

1. Cómo pensar en los agentes

Antes de entrar en pasos concretos, vale la pena parar un momento a entender con qué estamos trabajando.

Tu trabajo es darles el contexto justo y necesario para que puedan tomar buenas decisiones con la información correcta. Ni demasiado (se pierden), ni demasiado poco (inventan).

La buena noticia es que el código ya contiene mucho contexto implícito. Los agentes son muy buenos navegando ficheros, leyendo código existente y extrayendo lo que necesitan por su cuenta. Muchas veces basta con apuntarles en la dirección correcta y dejar que ellos descubran el resto.

2. Capturar toda tu intención

Uno de los errores más comunes al empezar con agentes es lanzarse a pedirles código directamente. Antes de escribir una sola línea, necesitas tener claro qué quieres construir. No a nivel de “quiero una app de tareas”, sino a nivel de decisiones concretas: qué hace exactamente, qué no hace, cómo se comporta en cada caso.

La brecha entre lo que tienes en la cabeza y lo que el agente entiende es la fuente principal de problemas. Si algo es ambiguo o está poco especificado, el agente rellenará los huecos con sus propias suposiciones. A veces acierta. Muchas veces no.

La disciplina del spec-first. Antes de pedirle nada al agente, escribe un mini documento de diseño. No hace falta que sea formal. Basta con una descripción clara del problema, los requisitos funcionales, las restricciones técnicas, y los casos límite que te vengan a la mente. Piensa en ello como “una cascada en 15 minutos”: defines el qué antes de tocar el cómo. Este documento se convierte en contexto que puedes pasarle al agente junto con tu prompt.

La entrevista al revés. En vez de intentar anticipar cada posible duda de antemano, puedes pedirle al agente que te entreviste.

Es mucho más fácil responder preguntas concretas (sobre todo cuando el agente te ofrece varias opciones entre las que elegir) que pensar anticipadamente en cada posible ambigüedad. El agente saca a la luz dudas que no sabías que existían, y acabas con un entendimiento compartido mucho más preciso.

El plan mode. Algunos agentes, como Claude Code, tienen un modo donde el agente explora el código, piensa el problema, y presenta un plan de implementación detallado para que lo revises antes de que escriba nada. Lees el plan, lo apruebas, pides cambios, o lo rechazas por completo. Es como un code review pero antes de que el código exista.

Las tres técnicas buscan lo mismo: llegar a un entendimiento compartido antes de que empiece el trabajo real. El documento de diseño funciona bien cuando necesitas pensar el problema tú primero. La entrevista funciona cuando todavía estás dando forma a la idea. El plan mode funciona cuando la idea está clara pero la implementación es compleja.

3. Eligiendo las tecnologías

Antes de escribir código, hay una decisión que marca todo lo que viene después: elegir las tecnologías adecuadas. Esto no va de usar lo más nuevo ni lo más popular. Va de tener el criterio técnico para saber qué herramienta resuelve mejor el problema concreto que tienes delante.

La IA te puede ayudar a implementar cualquier cosa, pero no va a tomar esa decisión por ti. Si eliges mal la base, todo lo que construyas encima será más difícil de lo necesario. Dicho esto, si no tienes la experiencia necesaria en un área concreta, la propia IA es un buen punto de partida. Puedes preguntarle, explorar opciones con ella, pedirle que compare alternativas. No sustituye tu criterio, pero te ayuda a formarlo.

Hay un factor que antes no existía: conviene elegir tecnologías lo suficientemente conocidas y mainstream para que los agentes de IA las manejen con fluidez. Si usas algo muy nicho o muy nuevo, la IA va a tropezar más, inventar cosas, y ralentizarte en vez de ayudarte.

4. El fichero AGENTS.md

Cada agente de IA que conozco permite definir un fichero de contexto que se carga automáticamente cada vez que empieza a trabajar. En Claude Code se llama CLAUDE.md, en Cursor .cursorrules, en otros tendrá otro nombre. El nombre más extendido en la comunidad es AGENTS.md. El concepto es el mismo: un documento que le da al agente el contexto mínimo necesario para entender tu proyecto y tomar buenas decisiones.

Una buena forma de pensar en este fichero es preguntarte: ¿qué le contarías a un nuevo integrante del equipo su primer día de trabajo?

Normalmente le explicarías dos cosas. Primero, cómo está montado el proyecto: un diagrama técnico de las piezas principales, cómo se conectan, qué tecnologías se usan, dónde vive cada cosa. Segundo, los acuerdos del equipo: las reglas explícitas e implícitas que todos deben conocer para trabajar bien juntos. Qué procesos seguimos, qué estándares de calidad aplicamos, en qué idioma escribimos los commits, cómo nombramos las cosas, qué está prohibido.

Eso es exactamente lo que debe contener tu fichero de agente. Ni más ni menos. Si lo sobrecargas con demasiado detalle, el agente pierde el foco. Si lo dejas demasiado vacío, tomará decisiones sin contexto y tendrás que corregirle constantemente.

Además del fichero base, puedes (y debes) empaquetar contexto adicional en tus prompts cuando sea relevante: fragmentos de código existente, documentación de APIs que necesite consumir, implementaciones de referencia, o ejemplos de cómo resolviste algo similar antes. Este context packing es lo que diferencia un prompt mediocre de uno que produce resultados excelentes a la primera.

5. Mantener los agentes actualizados

Cada LLM está entrenado con datos hasta una fecha de corte concreta. En la práctica, esto significa que el conocimiento del agente sobre frameworks y librerías está congelado en el tiempo, a menudo meses por detrás. Cuando le pides que escriba código, usará por defecto la versión que vio por última vez durante su entrenamiento. Esto puede llevar a APIs deprecadas, patrones obsoletos, o bugs sutiles difíciles de detectar.

La buena noticia es que los agentes modernos pueden buscar en internet. Si saben que su conocimiento puede estar desactualizado, pueden buscar documentación actualizada por su cuenta. La clave es hacerles conscientes del problema para que realmente lo hagan.

6. Tests, calidad y el bucle de feedback

Cuando un agente modifica código, necesitas una forma objetiva de saber si lo que hizo funciona o lo rompió. Sin tests automatizados, esa verificación recae enteramente en ti, revisando manualmente cada cambio. Eso no escala. Los tests son lo que te permite delegar con seguridad.

Pero los tests no son solo para ti. Son el mecanismo de feedback que el propio agente usa para corregirse. El agente escribe código, ejecuta los tests, ve qué falla, y corrige. Este ciclo funciona solo si los tests existen y son fiables. Sin ellos, el agente no tiene forma de saber si su código funciona más allá de que “compila sin errores”.

Define en tu AGENTS.md qué tipo de tests esperas (unitarios, integración, e2e), qué framework usas, y qué cobertura mínima es aceptable. El agente seguirá estas reglas consistentemente.

El mismo principio aplica al resto de estándares de calidad. Todo lo que normalmente pondrías en un pre-commit hook entra aquí: linters, formateo de código, chequeos de vulnerabilidades. La clave es entender que estos checks no son solo barreras de calidad. Son feedback automático que el agente consume. Si un linter falla, el agente corrige el código. Si un test no pasa, lo arregla antes de seguir. Si el análisis de seguridad detecta una vulnerabilidad, la resuelve.

El flujo completo funciona así: el agente escribe código, los checks se ejecutan, si algo falla el agente recibe el error y corrige, y repite hasta que todo pasa. Es un bucle cerrado donde los estándares de calidad actúan como señales que guían al agente hacia la solución correcta.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-merge-conflict
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.7.0
    hooks:
      - id: ruff          # linter
      - id: ruff-format   # formatter
  - repo: local
    hooks:
      - id: tests
        name: run tests
        entry: pytest --tb=short -q
        language: system
        pass_filenames: false
        always_run: true

La relación entre tu AGENTS.md y los estándares de calidad debe ser explícita. En el AGENTS.md defines las reglas (“usa Ruff para linting, pytest para tests, cobertura mínima del 80%”). En los pre-commit hooks las haces ejecutables. El agente lee las reglas y respeta los hooks. Ambas piezas trabajan juntas.

7. Skills

Los skills son herramientas o interacciones que defines para que el agente las tenga siempre disponibles y las use de forma consistente. En vez de explicarle cada vez cómo quieres que haga algo, lo defines una vez y a partir de ahí lo usa siempre igual.

# /commit skill
Cuando te pida hacer commit:
1. Ejecuta los tests (`yarn test`)
2. Si pasan, haz `git add` de los ficheros relevantes
3. Escribe un commit message en inglés, formato conventional commits
4. Haz push a la rama actual
5. Si los tests fallan, corrígelos antes de continuar

Estos son los tres que yo uso constantemente:

El día a día

El flujo de trabajo que se repite cada vez que te sientas a construir algo con agentes.

1. El flujo iterativo de trabajo

Aquí es donde muchos principiantes se frustran. Lanzan un prompt largo, esperan que el agente devuelva código perfecto a la primera, y se decepcionan cuando no es así.

El flujo real es un bucle: prompt, revisión, corrección, refinamiento. Los primeros resultados casi nunca son perfectos, y eso es completamente normal. Lo importante es que cada iteración mejora el resultado, y normalmente converges en algo bueno en dos o tres ciclos.

La clave está en trabajar con rebanadas verticales pequeñas. En vez de pedir “implementa todo el sistema de autenticación”, pide primero el modelo de usuario, después el endpoint de registro, después el de login, después el middleware de sesión. Cada pieza es lo bastante pequeña para que el agente la haga bien, y lo bastante concreta para que puedas verificarla rápidamente.

2. Commits granulares como puntos de guardado

Trata cada commit como un punto de guardado en un videojuego. Cuando el agente completa una tarea pequeña y los tests pasan, haz commit. Si la siguiente tarea sale mal, puedes volver al último punto estable con un simple git checkout.

Este hábito es más importante de lo que parece. Los agentes a veces se desvían del camino correcto: empiezan a refactorizar cosas que no les pediste, cambian la firma de funciones existentes, o introducen abstracciones innecesarias. Si has ido haciendo commits frecuentes, el daño se limita al último paso. Si llevas una hora sin hacer commit, puedes perder todo ese progreso.

Una buena regla: un commit por cada tarea completada. No acumules cambios. El coste de hacer commit es prácticamente cero. El coste de perder trabajo no lo es.

3. Nunca mergees código que no entiendas

El código que produce el agente es tu responsabilidad. Si llega a producción y falla, no puedes decir “es que lo hizo la IA”. Tú firmas cada merge. Tú respondes por cada línea.

En la práctica esto significa: si lees código del agente y algo te parece confuso o innecesariamente complejo, no lo aceptes. Pídele que te lo explique. Si la explicación no te convence, pídele que lo reescriba de forma más clara. Si sigue sin convencerte, recházalo y escríbelo tú.

Esto aplica especialmente a patrones que el agente introduce sin que se los pidas. Si ves una abstracción que no entiendes por qué existe, pregunta. Si ves un patrón de diseño que te parece excesivo para el problema, simplifica. Tu criterio manda.

4. Verificar la salida del agente

Los agentes inventan cosas. Es un comportamiento conocido que se llama alucinación, y conviene entenderlo bien para saber detectarlo.

Las alucinaciones más peligrosas no son los errores obvios que rompen la compilación. Son las sutiles: el agente usa una API que parece correcta pero no existe en la versión que estás usando. Llama a un método con la firma correcta de la versión anterior. Importa un paquete que existió una vez pero ya está deprecado. Todo compila, los tipos cuadran, y el error solo aparece en runtime.

Cómo verificar:

• Tests. Son tu primera línea de defensa. Si el código del agente no pasa los tests, hay un problema claro.
• Revisión manual. Lee el código como lo harías en un code review de un compañero. Especialmente las importaciones, las llamadas a APIs externas, y la lógica de negocio.
• Revisión cruzada con otro modelo. Puedes usar un modelo diferente para revisar el código generado por el primero. Cada modelo tiene sesgos distintos, y un segundo par de ojos (aunque sea artificial) atrapa errores que el primero no ve.
• Ejecución real. Cuando es posible, ejecuta el código y pruébalo manualmente. Los tests cubren los casos que anticipaste. La ejecución real cubre los que no.

5. Gestión de contexto y modo multiagente

Las conversaciones largas con un agente degradan la calidad de sus respuestas. A medida que la ventana de contexto se llena, el agente empieza a “olvidar” decisiones anteriores, a contradecirse, y a perder el hilo de los detalles. Este fenómeno se llama context drift y es una de las razones principales por las que el trabajo con agentes se complica en tareas grandes.

La solución más simple: empieza conversaciones frescas para cada nueva funcionalidad. No intentes hacer todo en una sola sesión maratón. Cada conversación nueva arranca con la ventana de contexto limpia y el agente opera a su máxima capacidad.

La solución más potente: modo multiagente. Algunas herramientas lo soportan de forma nativa. En Claude Code, por ejemplo, puedes lanzar y coordinar múltiples agentes trabajando sobre un plan compartido.

La mejor forma de pensarlo es como liderar tu propio equipo. Defines el objetivo, lo descompones en roles, y asignas a cada agente una parte del trabajo. Uno se encarga del backend, otro del frontend, un tercero escribe tests. Trabajan simultáneamente, y tú coordinas desde arriba.

La ventaja obvia es la velocidad. Pero la ventaja real es que cada subagente recibe una porción más pequeña y enfocada del problema. Pueden ir mucho más a fondo en su tarea específica sin chocar con los límites de contexto. Es la misma razón por la que los equipos humanos funcionan mejor cuando cada persona es dueña de una pieza clara en vez de que todos intenten mantener la imagen completa en la cabeza.

No tienes que usar exactamente estos roles. Lo importante es que definir responsabilidades claras desde el principio le da a cada agente una misión bien acotada. Refleja cómo opera un equipo real, y los agentes entienden estos roles de forma natural.

6. Cuándo NO usar IA

La IA no es la respuesta para todo. Reconocer sus límites te ahorra tiempo y frustraciones.

• Código de seguridad crítica. Criptografía, autenticación personalizada, validación de tokens. Los errores aquí tienen consecuencias graves y los agentes no tienen el contexto completo de tu modelo de amenazas.
• Legacy fuertemente acoplado. Si el código tiene dependencias implícitas por todas partes y cambiar una línea rompe tres módulos, el agente necesitará más contexto del que puedes darle. A veces es más rápido hacerlo a mano.
• Hot paths de rendimiento. Cuando cada microsegundo importa, necesitas perfilar, medir, y optimizar con datos reales. El agente puede sugerir optimizaciones genéricas, pero las optimizaciones que importan de verdad requieren contexto de ejecución que el agente no tiene.
• Investigación exploratoria. Cuando ni tú sabes exactamente qué quieres construir y necesitas experimentar con ideas medio formadas, la conversación con el agente puede ser más lenta que pensar con lápiz y papel.

Riesgos y desafíos

Recuerda: esto no es magia. Trabajar con IA tiene riesgos reales que conviene conocer antes de que te encuentren a ti.

Relacionados con el equipo

Inherentes a la IA

Cierre

Si tuviera que resumir todo esto en pocas líneas, sería esto:

1. Entiende con qué estás trabajando. No es vibe coding. Es ingeniería con agentes: tú diriges, la IA ejecuta.
2. Prepara el terreno antes de escribir código. Intención clara, tecnologías bien elegidas, AGENTS.md, estándares de calidad automatizados.
3. Trabaja en rebanadas pequeñas. Prompt, revisión, corrección, commit. Repite.
4. Nunca mergees lo que no entiendas. Tú firmas cada línea. Verifica, pregunta, rechaza si hace falta.
5. Gestiona el contexto. Conversaciones frescas, modo multiagente para tareas grandes, y sabe cuándo la IA no es la herramienta correcta.

El desarrollo con IA no es magia. Es un oficio nuevo que requiere práctica, criterio, y disciplina. Las herramientas cambian cada mes, pero estos principios se mantienen.

Lecturas recomendadas

Si quieres profundizar en estos temas, estos son algunos recursos que me han resultado útiles:

• Build an AI-Native Engineering Team (OpenAI). Guía completa sobre cómo estructurar equipos de ingeniería alrededor de agentes de código.
• How Claude Code is Built (Pragmatic Engineer). Cómo Anthropic construye su propia herramienta de desarrollo con IA, desde dentro.
• My LLM Coding Workflow Going Into 2026 (Addy Osmani). Flujo de trabajo práctico de uno de los ingenieros más influyentes del ecosistema web.
• Claude Code: Best Practices (Anthropic). Documentación oficial con patrones y buenas prácticas.

Si tienes preguntas sobre algún punto concreto, puedes contactarme directamente.