- Los asistentes de programación con IA se consolidaron durante 2025 como una herramienta clave del desarrollo real, y para usarlos de forma efectiva son indispensables un flujo de trabajo estructurado y una intervención humana responsable
- En lugar de pedir generación de código de inmediato, primero conviene definir especificaciones y un plan claros; avanzar luego con una implementación por etapas mejora tanto la calidad como la productividad
- Cuanto más se descomponga el trabajo en unidades pequeñas y se proporcione suficiente contexto y restricciones, más se reducen los errores y los problemas de consistencia de los LLM
- En vez de depender de un solo modelo, se está extendiendo un enfoque de elegir varios LLM y herramientas según el objetivo y usar la IA como apoyo a lo largo de todo el ciclo de desarrollo
- En última instancia, cuando el ser humano mantiene el control mediante pruebas, revisión y control de versiones, la IA funciona como un potente multiplicador de productividad
Panorama general
- A lo largo de 2025, los asistentes de programación con IA comenzaron a usarse a gran escala para escribir código de productos reales
- Ingenieros de Anthropic adoptaron Claude Code de forma activa y llegaron al punto de que aproximadamente el 90% del código de Claude Code es escrito por el propio Claude Code
- Usar LLM para programar no es magia que ocurra con solo pulsar un botón; exige aprender nuevos patrones y mantener pensamiento crítico
- Se puede aprovechar la IA de forma agresiva, pero la responsabilidad por el software producido sigue siendo del desarrollador
- La clave es tratar al LLM no como un tomador autónomo de decisiones, sino como un poderoso programador en pareja que necesita dirección clara, contexto y supervisión
Empezar con un plan claro (primero la especificación, después el código)
- No hay que lanzar pedidos vagos al LLM; hay que empezar por definir el problema y planear la solución
- En proyectos nuevos, se explica la idea y se le pide al LLM que haga preguntas de forma iterativa para concretar requisitos y casos límite
- Al final, todo se organiza en un spec.md que incluya requisitos, decisiones de arquitectura, modelo de datos y estrategia de pruebas
- Luego se introduce la especificación en un modelo capaz de razonar para generar un plan de proyecto que divida la implementación en tareas lógicas y pequeñas
- Como lo expresa Les Orchard, pasar por una etapa rápida y estructurada de planificación tipo "waterfall en 15 minutos" hace que la programación posterior fluya mucho mejor
- Con una especificación y un plan claros, tanto la persona como el LLM entienden exactamente qué se está construyendo y por qué, lo que evita retrabajo y ciclos desperdiciados
Dividir el trabajo en bloques pequeños e iterativos
- En vez de pedirle al LLM una salida gigantesca de una sola vez, el proyecto se divide en etapas repetibles o tickets que se procesan de forma secuencial
- Ejemplo: dar prompts por unidades como “implementar el Paso 1 del plan”, probar el código y luego pasar al Paso 2
- Si se le da demasiado alcance de una sola vez, el modelo se enreda o entrega resultados desordenados, y el costo de corregirlo se dispara
- Al pedir que generara grandes partes de una app de una sola vez, se acumularon colapsos de consistencia y código duplicado, e incluso hubo quien dijo que “parecía hecho por 10 personas sin hablar entre sí”
- En cada iteración se reutiliza el contexto ya construido y se va agregando de forma incremental, lo que además encaja bien con un enfoque de TDD (desarrollo guiado por pruebas)
- Algunas herramientas de agentes de programación soportan explícitamente este flujo de trabajo por bloques y permiten crear archivos de prompt plan para ejecutarlos en secuencia
Proporcionar contexto y guía amplios
- Los LLM solo rinden hasta donde alcanza el contexto que se les da, por lo que hay que proporcionar suficiente código relevante, documentación y restricciones
- Claude puede cargar un repositorio completo de GitHub como contexto en el modo Projects, y asistentes de IDE como Cursor y Copilot incluyen automáticamente los archivos abiertos
- El enfoque de brain dump funciona bien: entregar por adelantado la información que el modelo necesita saber, incluyendo objetivos de alto nivel, ejemplos de soluciones deseables e incluso enfoques que deben evitarse
- Herramientas como gitingest o repo2txt permiten volcar en un archivo de texto las partes necesarias de una base de código para dárselas al LLM
- Claude Skills propone ir más allá de depender de prompts repetitivos, agrupando instrucciones, scripts y conocimiento de dominio en módulos duraderos y reutilizables
- También existe una colección de Skills curada por la comunidad
- La skill frontend-design incluso puede corregir la estética de diseño excesivamente morada que suele aparecer en las UI generadas por LLM
- También es muy útil incluir comentarios y reglas directamente dentro del prompt para guiar a la IA
- Ejemplo: “Aquí está la implementación actual de X. Extiéndela a Y sin romper Z”
- Como los LLM tienen una naturaleza literal y siguen las instrucciones al pie de la letra, cuanto más detalladas y contextualizadas sean, menos alucinaciones y propuestas fuera de lugar habrá
Elegir el modelo adecuado (y usar varios si hace falta)
- No todos los LLM para programación están al mismo nivel, y es importante elegir de forma intencional el modelo o servicio según la naturaleza de la tarea
- En algunos casos resulta efectivo usar dos o más LLM en paralelo para cruzar y validar enfoques distintos ante un mismo problema
- Cada modelo tiene tendencias y fortalezas propias, así que conviene cambiar a otro modelo cuando uno se atasca o entrega resultados mediocres
- También se puede evitar el punto ciego de un modelo con la técnica de “sillas musicales de modelos”, probando el mismo prompt tal cual en distintos servicios
- Si es posible, usar los modelos más recientes de nivel pro ofrece una ventaja clara en calidad
- Cuando se piensa en colaborar durante mucho tiempo, también importa la “vibra” del programador en pareja con IA: si el tono de respuesta y la sensación de interacción encajan con uno mismo
Usar la programación con IA a lo largo de todo el ciclo de vida
- En el entorno de línea de comandos han aparecido agentes de IA como Claude Code, OpenAI Codex CLI y Google Gemini CLI, capaces de leer archivos, ejecutar pruebas y hacer correcciones en varios pasos dentro del directorio de un proyecto
- Jules de Google y Copilot Agent de GitHub se usan como agentes de programación asíncronos que clonan un repo en una VM en la nube, trabajan ahí y luego abren un PR
- Estas herramientas no son perfectas, y es indispensable usarlas entendiendo sus límites
- En tareas mecánicas como generar boilerplate, aplicar cambios repetitivos o ejecutar pruebas automáticas muestran una gran aceleración, pero la calidad sigue dependiendo de la guía humana
- Al usar agentes, proporcionar desde el inicio un plan o una lista de tareas ayuda mucho a que reconozcan el orden correcto del trabajo
- Todavía no estamos en una etapa en la que un agente de IA pueda implementar una funcionalidad completa sin supervisión y producir un resultado perfecto; el uso supervisado sigue siendo el enfoque realista
- Se están haciendo experimentos con herramientas de orquestación como Conductor para ejecutar varios agentes en paralelo y manejar distintas funciones al mismo tiempo
Mantén al humano en el circuito: verifica, prueba y revisa a fondo
- La IA genera código plausible sin dudar, pero la responsabilidad por la calidad y el resultado recae por completo en el desarrollador
- Como lo expresa Simon Willison, hay que entender al programador en pareja basado en LLM como una entidad propensa al exceso de confianza y a equivocarse, que incluso escribe bugs o código sin sentido con total seguridad
- Los fragmentos de código generados por IA deben tratarse como el código de un desarrollador junior; hay que leerlos, ejecutarlos y probarlos directamente según sea necesario
- Integra las pruebas de forma natural dentro del flujo de trabajo y, desde la etapa de planificación, diseña junto con cada fase una lista de pruebas y un plan de testing
- A herramientas como Claude Code hay que indicarles explícitamente que ejecuten la suite de pruebas después de implementar una tarea, y si falla, que analicen la causa y la corrijan
- En la mayoría de los casos, quienes mejor aprovechan a los agentes de programación son equipos e individuos con una cultura de pruebas sólida
- En entornos sin pruebas, existe el riesgo de que el agente pase por alto cambios que en realidad rompieron varias partes, asumiendo que no hay problema
- Además de las pruebas automatizadas, mantén la revisión de código como un paso obligatorio, combinando revisión manual y revisión con IA
- Usa una sesión de IA separada u otro modelo para pedirle que critique o revise el código escrito por la primera IA
- Ejemplo: después de que Claude escriba el código, pedirle a Gemini que revise posibles errores o mejoras en esa función
- Usa Chrome DevTools MCP como herramienta clave del bucle de depuración y calidad para cerrar la brecha entre el análisis estático y la ejecución real en el navegador
- Dale al agente de IA acceso para observar directamente la estructura del DOM, trazas de rendimiento, logs de consola y solicitudes de red
- Así se pueden realizar pruebas automáticas de UI basadas en LLM sin tener que trasladar manualmente el contexto
- Esto permite un flujo para diagnosticar y corregir bugs con precisión basándose en datos reales de tiempo de ejecución
- Un desarrollador contó que el resultado de depender en exceso de la generación por IA en un proyecto urgente fue un desastre inconsistente
- Se acumularon lógica duplicada, nombres de métodos distintos entre sí y una arquitectura no integrada
- Reconoció que siguió generando sin detenerse a revisar la estructura completa que la IA había ido armando
- Al final llegó a la conclusión de hacer un refactor grande y de no volver a dejarla trabajar sin supervisión
- Sin importar cuánto uses IA, el desarrollador debe seguir siendo un ingeniero responsable hasta el final
- En la práctica, eso significa hacer merge o desplegar solo después de entender el código, y si la IA entrega una implementación compleja, pedirle comentarios explicativos o que la reescriba en una forma más simple
Haz commits frecuentes y usa el control de versiones como red de seguridad
- Cuanto más trabajas con una IA que puede producir grandes cantidades de código rápidamente, más necesitas hábitos de control de versiones más finos
- Cada vez que termines una tarea pequeña o una corrección automática salga bien, deja un commit de git con un mensaje claro y significativo para tener checkpoints a los que puedas volver de inmediato si el siguiente cambio causa problemas
- Trata los commits como puntos de guardado de un juego: si la sesión con el LLM se descarrila, siempre puedes volver al último estado estable
- El control de versiones también cumple un papel importante al colaborar con IA, y cuando por las limitaciones de la ventana de contexto no puede recordar todos los cambios, el historial de git se vuelve un registro de trabajo confiable
- Revisando los commits recientes puedes hacer un briefing rápido de los cambios, tanto para la IA como para ti mismo
- Si incluyes
git diff o el log de commits en el prompt, el LLM entiende con precisión el código nuevo y el estado anterior
- Los LLM son buenos interpretando diffs y usando herramientas como
git bisect, por lo que pueden seguir el historial de commits y rastrear con persistencia dónde se introdujo un bug
- Los commits pequeños y los mensajes claros documentan el proceso de desarrollo de forma natural, lo que ayuda mucho en la revisión de código
- Incluso cuando un agente de IA realiza varios cambios de una sola vez, si esos cambios están separados por commit, es mucho más fácil identificar con precisión el punto que causó el problema
- Usa branches o worktrees para aislar los experimentos con IA del código principal
- Inspirado en una práctica de Jesse Vincent, crea un git worktree nuevo para cada función nueva o subproyecto
- Luego ejecuta varias sesiones de programación con IA en paralelo dentro del mismo repo sin que interfieran entre sí, y haz merge de los resultados de forma selectiva
- Es como si cada tarea de IA estuviera en su propio branch sandbox, así que puedes descartar experimentos fallidos sin afectar
main
- Mantén la regla de nunca hacer commit de código que no entiendas ni puedas explicar
Personaliza el comportamiento de la IA con reglas y ejemplos
- En lugar de aceptar tal cual el estilo o enfoque predeterminado de la IA, darle lineamientos claros ya tiene un gran impacto en la calidad y consistencia de la salida
- Mantén periódicamente un archivo CLAUDE.md para dejar por escrito las reglas de proceso y preferencias que Claude debe seguir, y al usar Gemini CLI aplica el mismo método con GEMINI.md
- Ejemplo: escribir código alineado con el estilo del proyecto, respetar las reglas de lint, prohibir el uso de ciertas funciones, preferir estilo funcional sobre OOP, etc.
- La idea es entregar ese archivo a Claude al inicio de la sesión para que todo el trabajo se ajuste a esas reglas
- Según Jesse Vincent, este enfoque reduce la frecuencia con la que la IA se desvía hacia direcciones no deseadas o introduce patrones extraños
- Incluso sin un archivo de reglas aparte, puedes configurar el tono y el comportamiento general mediante custom instructions o system prompts
- Tanto GitHub Copilot como Cursor ofrecen funciones para configurar globalmente el comportamiento de la IA a nivel de proyecto
- Puedes especificar el estilo de programación en un párrafo corto: “Usa indentación de 4 espacios, evita funciones flecha en React, usa nombres de variables descriptivos, el código debe pasar ESLint”
- Ben Congdon comentó que le sorprendió que la función de custom instructions de Copilot se use tan poco, y señaló que basta con dar de antemano algunos ejemplos y preferencias para obtener código alineado con los modismos del equipo
- Proporcionar ejemplos inline es una técnica especialmente poderosa
- Si quieres que una función se implemente de cierta manera, primero muestra una función similar que ya exista en el codebase y guíalo con algo como: “X está implementado así, así que usa el mismo enfoque para Y”
- Si quieres igualar el estilo de los comentarios, escribe tú mismo una línea y luego pídele que continúe en ese estilo
- En el fondo, se trata de hacer priming del modelo con un patrón a seguir, y los LLM son muy buenos para ese tipo de imitación
- En la comunidad se comparten distintos conjuntos de reglas para refinar el comportamiento de los LLM
- Por ejemplo, las reglas de "Big Daddy" o agregar al prompt una cláusula de “prohibido alucinar o engañar”
- Son mecanismos para reducir la tendencia de la IA a inventar código inexistente o mostrarse excesivamente segura
- Ejemplo: agregar al inicio del prompt “Si no estás seguro o no tienes contexto del codebase, no inventes una respuesta y pide aclaración” para reducir alucinaciones
- Otra regla útil es “al corregir un bug, explica siempre brevemente el motivo en un comentario”; así la IA deja comentarios como
// Fixed: changed X to Y to prevent Z according to the spec
Adoptar las pruebas y la automatización como amplificadores de fuerza
- Cuanto más se aprovechen activamente CI/CD, los linters y los bots de revisión de código, mejor funciona la IA en un entorno que filtra automáticamente los errores
- Cuanto mayor sea la proporción de código generado por IA en un repositorio, más indispensable es contar con un entorno sólido de integración continua
- Ejecutar pruebas automáticas en cada commit o PR, exigir validaciones de estilo como ESLint y Prettier, e incluso incluir despliegues de staging por rama si es posible
- También se puede configurar para que la propia IA active estos procesos y evalúe los resultados
- Ejemplo: si Jules o GitHub Copilot Agent abre un PR, CI ejecuta las pruebas y reporta los fallos → se le pasa el log de errores a la IA para continuar con algo como “la prueba de integración falló en XYZ, depurémoslo juntos”
- El proceso de corrección de bugs se convierte en un bucle colaborativo con retroalimentación rápida, un escenario al que la IA responde especialmente bien
- Las validaciones automatizadas de calidad de código también sirven como timón para la IA
- Incluir tal cual la salida del linter en el prompt y, si la IA escribió código que no pasa el lint, copiar el mensaje de error y pedirle: “resuelve estos problemas”
- Es como si un profesor estricto estuviera observando a la IA por encima del hombro
- Cuando la IA percibe una salida de herramientas como un fallo de prueba o una advertencia del linter, intenta corregirlo con mucha insistencia
- Los propios agentes de codificación con IA cada vez incorporan más hooks de automatización
- Algunos agentes ni siquiera consideran que una tarea está “terminada” hasta que todas las pruebas pasan
- Los bots de revisión de código, ya sean de IA o humanos, también se pueden usar como un filtro adicional
- Los comentarios de revisión se pueden reutilizar tal cual como prompts de mejora
- Ejemplo: si CodeRabbit u otro revisor deja un comentario como “esta función hace X y no es lo ideal”, se le puede pedir a la IA: “¿puedes refactorizarlo incorporando esta retroalimentación?”
- Al combinar IA y automatización se forma un círculo virtuoso
- La IA escribe código → las herramientas automáticas detectan problemas → la IA corrige → se repite, mientras el desarrollador supervisa solo la dirección de alto nivel
- Se siente como tener a un desarrollador junior extremadamente rápido cuyo trabajo es validado al instante por un ingeniero de QA que nunca se cansa
- Eso sí, este entorno debe construirlo el propio desarrollador, y en proyectos sin pruebas ni automatización existe el riesgo de que los bugs sutiles o la degradación de calidad causada por la IA aparezcan mucho después
- Uno de los objetivos de cara a 2026 es reforzar las compuertas de calidad alrededor de las contribuciones de código hechas con IA
- Más pruebas, más monitoreo e incluso, si hace falta, estructuras en las que una IA revise a otra IA
- Ya se han observado casos reales en los que un modelo detecta problemas que otro dejó pasar
Aprendizaje y adaptación continuos (la IA amplifica las habilidades)
- Si cada sesión de programación con IA se trata como una oportunidad de aprendizaje, se crea un círculo virtuoso en el que, a medida que aumenta el conocimiento, también crece la ayuda que brinda la IA
- Usar LLM en el desarrollo expone de forma natural a nuevos lenguajes, frameworks y técnicas que normalmente no se habrían probado
- Cuando hay bases sólidas de ingeniería de software, la IA puede multiplicar la productividad varias veces, pero si faltan fundamentos, también multiplica la confusión
- Una observación común entre desarrolladores experimentados es que los LLM tienden a reforzar las mejores prácticas existentes
- Escribir especificaciones claras, contar con buenas pruebas y mantener revisiones de código constantes produce aún más efecto cuando la IA entra en juego
- Mientras la IA se encarga del boilerplate, el desarrollador puede concentrarse en abstracciones de alto nivel como diseño, interfaces y arquitectura, pero para eso esas capacidades deben existir de antemano
- Como señala Simon Willison, casi todo lo que forma a un ingeniero senior—diseño de sistemas, gestión de la complejidad, criterio para decidir entre automatización y trabajo manual—ahora conduce a los mejores resultados cuando se combina con IA
- El uso de IA realmente impulsa la mejora de las capacidades de ingeniería
- Uno se vuelve más riguroso en la etapa de planificación y piensa con más consciencia sobre la arquitectura
- Al asumir el rol de quien gestiona a una IA que codifica muy rápido pero a veces de forma ingenua, también se fortalece el criterio
- Frente a la preocupación de que la IA pueda deteriorar las capacidades, si se usa bien ocurre más bien lo contrario
- Aprender nuevos modismos y formas de resolver problemas a través de revisiones de código hechas por IA
- Profundizar la comprensión del lenguaje y del dominio del problema al depurar los errores de la IA
- Pedirle que explique el código o el motivo de los cambios, haciéndole preguntas constantes como si se entrevistara a un candidato, para obtener insights
- Cuando no está clara una librería o un enfoque, usar la IA como asistente de investigación para comparar opciones y trade-offs
- En el panorama general, las herramientas de IA amplifican la experiencia
- De cara a 2026, más que temer que quiten empleos, genera expectativa poder dedicar menos tiempo a tareas repetitivas y monótonas, y más a problemas creativos y complejos
- En cambio, sin una base sólida, también existe el riesgo de que la IA conduzca a un efecto Dunning-Kruger potenciado con esteroides
- Como consejo, hace falta un equilibrio intencional: seguir puliendo las habilidades técnicas, usar la IA para acelerar el aprendizaje y la productividad, y periódicamente programar sin IA para mantener afilados los fundamentos
- Al final, la combinación de desarrollador e IA es mucho más poderosa que cualquiera de los dos por separado, y dentro de esa combinación el lado humano debe cumplir bien su papel
Conclusión
- Aunque se ha incorporado activamente la IA en todo el flujo de trabajo de desarrollo, se mantiene un enfoque cuidadoso y guiado por expertos
- El enfoque que se busca no es un desarrollo donde la IA automatice todo, sino “ingeniería de software aumentada por IA”
- Los mejores resultados surgen cuando a la colaboración con IA se le aplican exactamente las mismas disciplinas clásicas de la ingeniería de software
- Todas las prácticas construidas con esfuerzo—como diseñar antes de codificar, escribir pruebas, usar control de versiones y mantener estándares de código—siguen plenamente vigentes, y se vuelven todavía más importantes cuando la IA escribe la mitad del código
- Las herramientas seguirán evolucionando, y el flujo de trabajo también evolucionará con ellas
- “Interns de desarrollo con IA” totalmente autónomos podrían encargarse de más tareas simples, mientras los humanos se concentran en problemas de alto nivel
- También podrían surgir nuevas formas de depuración y nuevos paradigmas para explorar código
- Pase lo que pase, se debe mantener siempre la actitud de seguir dentro del loop
- Guiar a la IA, verificar los resultados, aprender durante el proceso y ampliar la productividad con responsabilidad
- La conclusión final es clara: los asistentes de programación con IA son amplificadores poderosos, pero el director del escenario sigue siendo el ingeniero humano hasta el final
1 comentarios
Parece que cuanto más se abstrae, más importante se vuelve la ingeniería.