La IA en el desarrollo de software acelera la "escritura" de código, pero no sustituye el criterio del equipo. En proyectos con años en producción, la ventaja real está en cómo se controla: contexto preciso, memoria de proyecto, cambios aditivos, revisión de cada diff y testing antes de desplegar. Así es como integramos la inteligencia artificial en Addmira.
Herramientas como Claude Code, GitHub Copilot o Cursor han cambiado la forma de escribir software. Sin embargo, tras aplicarlas en proyectos reales, en Addmira hemos aprendido algo: la ventaja no está en la herramienta, sino en la capacidad del desarrollador de ejercer un control crítico y constante sobre el proceso, desde la primera reunión con el cliente hasta la última prueba.
En este artículo explicamos cómo trabajamos con inteligencia artificial en aplicaciones que llevan años funcionando, qué técnicas aplicamos para no romper nada y por qué el testing y la revisión humana siguen siendo innegociables.
Qué significa usar IA en el desarrollo de software (y qué no)
Usar IA en el desarrollo de software significa apoyarse en asistentes de programación para analizar requisitos, proponer código, generar pruebas y detectar riesgos. No significa delegar decisiones: el asistente propone y el desarrollador valida, ajusta o descarta. Es, en el fondo, lo contrario del vibe coding: aquí el rol del desarrollador es decidir, no solo aceptar.
La distinción importa porque las encuestas del sector apuntan en la misma dirección: según la Stack Overflow Developer Survey 2025, más del 84% de los desarrolladores ya usa o planea usar herramientas de IA, pero solo el 29% confía en sus resultados (once puntos menos que el año anterior) y un 46% desconfía activamente de su precisión. Es decir, la adopción va por delante del control. Nuestro enfoque intenta cerrar esa brecha.
Antes de tocar código delicado: la "reunión" con la IA
Antes de intervenir sobre partes sensibles de un sistema, mantenemos una especie de reunión con la inteligencia artificial. No para que nos dé una solución mágica, sino para que trabaje como un miembro más del equipo de desarrollo.
En esta fase inicial:
- Revisamos transcripciones y actas de las reuniones con el cliente y contrastamos lo que ha entendido la IA con lo que hemos entendido nosotros. Si un detalle lo recordamos de forma vaga pero no aparece explícito en las notas, lo marcamos como duda a confirmar en lugar de darlo por bueno.
- Preparamos un listado de dudas para el cliente, priorizando las que definen el esquema del proyecto y las que afectan a decisiones de negocio. Es la misma lógica que aplicamos en cualquier proyecto: definir bien las necesidades antes de programar evita el caos después.
- Planificamos las fases de desarrollo, dividiendo el proyecto en bloques manejables y testeables.
A veces análisis y código avanzan en paralelo dentro de una misma sesión, pero el principio no cambia: alineamos antes de tocar lo delicado.
El reto real: IA en aplicaciones legacy
Introducir IA en un proyecto nuevo es relativamente sencillo. El verdadero desafío, donde se nota la experiencia, está en las aplicaciones legacy: sistemas que llevan años en producción, con dependencias, reglas de negocio acumuladas y una arquitectura que funciona aunque no siempre esté documentada.
En estos entornos la IA no puede improvisar. Necesita un guía que conozca el sistema en profundidad para evitar que una "solución rápida" rompa una funcionalidad crítica que lleva años operando con estabilidad. Es el tipo de trabajo que hacemos en nuestro servicio de mantenimiento y evolución de aplicaciones.
Instrucciones claras y con contexto
El secreto para que un asistente de programación sea útil en proyectos consolidados es el contexto. No basta con pedir "optimiza esta función". Hay que especificar:
- Qué parte exacta del sistema se va a tocar.
- Qué restricciones deben respetarse. Por ejemplo, mantener compatibilidad con una versión concreta de PHP sin usar sintaxis de versiones posteriores, algo que tenemos presente en cada sesión.
- Cuál es el objetivo de negocio del cambio. Por ejemplo, "un listado global sin necesidad de entrar en un centro concreto".
Saber traducir estas necesidades en instrucciones precisas marca la diferencia entre un código que funciona hoy y uno que es mantenible a largo plazo.
Memoria persistente: conservamos los "gotchas" del sistema
Uno de los diferenciales reales de nuestro flujo de trabajo es que no solo damos contexto a la IA en cada sesión: conservamos los gotchas del sistema. Llamamos así a esas particularidades técnicas (una dependencia oculta, un campo que se calcula de forma no evidente, una excepción de negocio) que solo se descubren después de años manteniendo una aplicación.
Estos detalles no están en la documentación oficial. Están en nuestra memoria de proyecto, y los preservamos entre sesiones para que la IA no proponga soluciones que, aunque correctas en teoría, romperían lo que lleva años funcionando en la práctica.Es la misma idea de memoria de proyecto acumulativa que usamos en el resto de la agencia, llevada al código.
Tres técnicas de seguridad para desarrollar con IA en proyectos legacy
Cuando trabajamos con aplicaciones consolidadas aplicamos principios que hemos validado en proyectos reales:
1. Estrategia aditiva: añadir en paralelo, no editar lo que funciona
En lugar de modificar código existente y probado en producción, preferimos añadir funcionalidad en paralelo y reutilizar lo que ya funciona. Un caso reciente: una nueva vista necesitaba acceder a datos por centro. En vez de reescribir el flujo existente, lo reutilizamos. Resultado: cero líneas borradas del flujo original.
2. Verificación por diff: cero borrados sin justificación
Antes de desplegar cualquier cambio revisamos el diff línea por línea. Si la IA propone eliminar código, lo analizamos con lupa. Solo aceptamos borrados cuando existe una justificación explícita y validada.
3. Disciplina con la base de datos: no tocar hasta cerrar el alcance
En módulos críticos no tocamos la base de datos hasta haber cerrado el alcance completo con el cliente. Una migración prematura o un cambio en la estructura de tablas puede tener consecuencias irreversibles. Primero definimos, luego implementamos.
| Sin control | Con control (nuestro enfoque) |
|---|---|
| "Optimiza esta función" | Instrucción con alcance, restricciones y objetivo de negocio |
| Contexto nuevo en cada sesión | Memoria de proyecto persistente con los gotchas del sistema |
| Reescribir lo que ya funciona | Añadir en paralelo y reutilizar |
| Aceptar el diff completo | Revisar línea a línea; ningún borrado sin justificar |
| Migrar la base de datos "sobre la marcha" | Alcance cerrado con el cliente antes de tocar tablas |
| Confiar en que compila | Tests unitarios + matriz de pruebas para el cliente |
Testing riguroso: tu negocio no puede permitirse errores
Una vez planificado el desarrollo, el testing no es opcional. Implementamos pruebas unitarias automatizadas para verificar que cada componente funciona de forma aislada, y preparamos matrices de prueba para los testers del cliente que validan la experiencia de usuario final.
La IA nos ayuda a generar casos de prueba y a identificar casos límite que podríamos pasar por alto: una dependencia oculta entre módulos o un bug que solo aparece al probar, nunca al asumir. Pero la decisión final sobre qué es aceptable siempre pasa por el criterio humano, revisando diffs, tests y decisiones una a una.
Nuestro enfoque en Addmira: estabilidad y criterio
Llevamos más de 25 años entregando proyectos digitales y sabemos que un negocio necesita fiabilidad por encima de la novedad. Por eso integramos la inteligencia artificial en nuestro flujo de desarrollo de aplicaciones a medida no para sustituir el criterio humano, sino para potenciarlo. Cada línea de código añadida a tu aplicación está justificada, probada y alineada con tus objetivos.
Preguntas frecuentes sobre IA en el desarrollo de software
¿Se puede usar IA en una aplicación antigua sin romperla?
Sí, siempre que exista un desarrollador que conozca el sistema y controle el proceso. La clave es dar contexto preciso al asistente, trabajar de forma aditiva, revisar cada diff antes de desplegar y no tocar la base de datos hasta cerrar el alcance.
¿La IA sustituye al equipo de desarrollo?
No. Los asistentes de programación aceleran tareas concretas (análisis, generación de código, casos de prueba), pero la decisión sobre qué cambios entran en producción sigue siendo humana. Sin ese criterio, la velocidad se convierte en riesgo.
¿Qué riesgos tiene desarrollar con IA sin supervisión?
Los principales son la eliminación de código que parecía innecesario pero cumplía una función, la incompatibilidad con versiones o dependencias del sistema y cambios prematuros en la base de datos. Todos se evitan con revisión por diff, restricciones explícitas y testing.
¿Cómo se da contexto a la IA en un proyecto legacy?
Con instrucciones que indiquen la parte exacta del sistema a tocar, las restricciones técnicas (versiones, compatibilidad) y el objetivo de negocio del cambio. Además, conviene conservar una memoria de proyecto con las particularidades del sistema entre sesiones.
¿Cuánto tiempo se ahorra usando IA en el desarrollo?
Depende del proyecto y del tipo de tarea. El mayor ahorro suele darse en análisis de requisitos, generación de pruebas y código repetitivo; en lógica de negocio crítica el ahorro es menor porque la revisión humana sigue siendo obligatoria.
Hablemos de la evolución de tu aplicación
Si tienes una aplicación o web que lleva tiempo en marcha y quieres mejorarla, optimizarla o añadir nuevas funcionalidades sin poner en riesgo lo que ya funciona, estamos aquí para ayudarte. La tecnología es el medio; la tranquilidad de tu negocio es el fin.
