La evolución del desarrollo de software con IA: De copiar y pegar al desarrollo síncrono dirigido por especificaciones

El panorama de la programación ha cambiado radicalmente en los últimos dos años. Lo que empezó como una interacción básica con un chatbot se ha transformado en un ecosistema complejo de agentes autónomos, flujos de trabajo asíncronos y metodologías estructuradas.

A lo largo de mi carrera he visto pasar muchas tecnologías, pero la velocidad de esta última ola es inédita. A continuación, me gustaría explicar cómo he vivido en primera persona la evolución de este viaje tecnológico desde mediados de 2024 hasta la actualidad, y cómo los desarrolladores senior estamos adaptando nuestras metodologías para no perder el control de la base de código.

1. La era del "Copiar y Pegar" (Mediados de 2024)

Hace apenas un par de años (ya hablé sobre esto en un artículo anterior), la integración de la Inteligencia Artificial en nuestro día a día era puramente manual y externa. El flujo de trabajo estándar de cualquier ingeniero consistía en una interacción biodireccional, fragmentada y bastante rudimentaria:

• De la IDE al Chatbot: Seleccionábamos un fragmento de código en editores como Visual Studio Code, lo copiábamos y lo pegábamos directamente en la interfaz web de modelos como GPT.
• Las peticiones típicas: Nuestros prompts se limitaban a revisiones superficiales: "¿Puedes revisar este código?", "¿Cómo puedo mejorarlo?" o "Genera un script en Python que haga X cosa".
• Del Chatbot a la IDE: Una vez que la IA generaba la respuesta, copiábamos el código de vuelta a nuestro entorno local para compilarlo, ejecutarlo y testearlo.

Si bien este método ya representaba una mejora sustancial frente a programar en absoluta soledad, distaba mucho de ser un flujo de trabajo óptimo, fluido o integrado en el ciclo de vida del software.

2. El salto a los Agentes de Código integrados

Hoy en día, el panorama es completamente distinto gracias a la integración directa de los Modelos de Lenguaje (LLMs) en nuestros entornos de desarrollo a través de plugins y, especialmente, mediante agentes de código (coding agents).

Para los desarrolladores que, como yo, preferimos la terminal, herramientas de línea de comandos como Claude Code (que lo normal es ejecutarla sobre la infraestructura segura de AWS Bedrock) u opciones de código abierto como OpenCode han cambiado las reglas del juego. La gran diferencia radica en la autonomía del agente: ahora la IA puede leer la base de código completa y modificar archivos directamente en el sistema de archivos.

El factor seguridad y los Guardrails

Darle autonomía a un agente para inspeccionar archivos mediante comandos de terminal (ls, grep, find) puede parecer una locura peligrosa. Por ello, a nivel de ingeniería de plataforma, implementamos barreras de seguridad estrictas (guardrails):

Nota de experiencia: Para evitar acciones imprevistas o destructivas, ciertos comandos críticos ejecutados por el agente requieren obligatoriamente de nuestra intervención e inspección humana antes de aplicarse en el entorno.

A diferencia de las herramientas comerciales ligadas a un solo proveedor (como las herramientas de Anthropic y sus modelos Claude), alternativas open-source como OpenCode permiten a los equipos conectar sus flujos de trabajo a cualquier proveedor de LLM del mercado, algo crucial para evitar el vendor lock-in.

3. Desarrollo Dirigido por Especificaciones (Spec-Driven Development)

Con la llegada de la autonomía de los agentes, los ingenieros senior nos enfrentamos pronto a un nuevo problema: el consumo desmedido de tokens y el riesgo de que la IA tomara direcciones de arquitectura equivocadas. Para solucionar esto, ha ganado fuerza el Desarrollo Dirigido por Especificaciones, una metodología que reintroduce el criterio humano en el bucle de decisión mediante dos frameworks principales:

• SpecKit: Ideal para proyectos que nacen desde cero (Greenfield projects).
• OpenSpecs: El que yo prefiero para trabajar en entornos reales con código ya existente y sistemas legados (Brownfield projects).

¿Cómo funciona el flujo con OpenSpecs?

El proceso no consiste en lanzar al agente a picar código a ciegas. Seguimos una serie de fases estructuradas mediante archivos Markdown (.md) que sirven como contratos de diseño. Escribiré más detalladamente sobre esto en otro artículo.

La estrategia clave: Como arquitectos o ingenieros principales, no debemos permitir que el agente implemente todo el proyecto de golpe. Mi recomendación es guiarlo para que realice la implementación fase por fase. Esto genera Pull Requests (PRs) más pequeños, limpios y acotados. En la actualidad, el cuello de botella ya no está en la velocidad de generación de código, sino en la verificación humana y la revisión del mismo (code review).

4. Gestión de Costes, Modelos y Ventana de Contexto

El uso de agentes no es gratuito y requiere una gestión de recursos tan inteligente como la del propio software. Tomando como ejemplo nuestro uso de Claude Code, categorizamos las tareas según su complejidad para optimizar el gasto de la organización:

Complejidad Baja (Modelo: Haiku)

Lo usamos para tareas simples, refactorizaciones menores, automatizaciones rápidas y bajo coste.

Complejidad Alta (Modelo: Sonnet / Opus)

Lo reservamos para tareas complejas y lógica de negocio core con requerimientos cognitivos elevados.

Además, como desarrolladores debemos monitorizar activamente el consumo de tokens y el llenado de la ventana de contexto. En mi experiencia, al alcanzar aproximadamente el 60% de la capacidad del contexto, es vital compactarlo o limpiarlo; de lo contrario, el modelo empieza a perder el hilo de las dependencias y aumentan drásticamente las posibilidades de sufrir alucinaciones en el código.

5. El paso hacia un modelo de trabajo Asíncrono

Quizás el cambio cultural y metodológico más grande en mi rutina diaria es la transición hacia un modelo de trabajo puramente asíncrono.

Agentes modernos como Jules (el agente de código de Google) se sincronizan directamente con plataformas como GitHub. Puedo asignarle una tarea compleja al agente (como la creación de una nueva funcionalidad secundaria), indicarle que trabaje en una rama independiente (branch) y que levante un Pull Request al finalizar.

Esto cambia radicalmente cómo gestiono mi tiempo: ya no tengo que mantener el 100% de mi atención fija en la pantalla viendo cómo la IA escribe línea por línea. Puedo delegar la tarea, ponerme a diseñar otra parte del sistema o atender una reunión de arquitectura, y regresar más tarde a revisar, testear y aprobar el código resultante. La IA ha dejado de ser un mero asistente de copia y pega para convertirse, efectivamente, en un ingeniero junior asíncrono en mi equipo.

Reflexión final: El nuevo rol del ingeniero

Este viaje de dos años me ha enseñado que la Inteligencia Artificial no viene a reemplazarnos, sino a obligarnos a subir de nivel. Nuestro valor ya no se mide por las líneas de código que somos capaces de picar por minuto, sino por nuestra capacidad para diseñar buenas arquitecturas, definir especificaciones precisas en proyectos complejos y mantener un criterio técnico riguroso durante las revisiones. Al final del día, la IA puede escribir el código, pero la responsabilidad última de la robustez del software sigue siendo, y siempre será, nuestra.