El SDLC nativo de IA y el eslabón que falta: la infraestructura

Fuentes: The AI-Native SDLC Starts With Your Infrastructure

Anthropic publicó un manual para reorganizar el ciclo de vida del software en torno a agentes de codificación, estructurado en seis etapas que producen artefactos sucesivos: intent.md en planificación, spec.md en diseño, plan.md en construcción y REVIEW.md en despliegue. La etapa 4 —el bucle de verificación— es donde el agente valida su propio trabajo antes de que un ingeniero lo revise, mediante pruebas, compilaciones o capturas y con ganchos que impiden falsear tests rojos. El manual pide también tratar la configuración del agente como software, ejecutando evaluaciones en integración continua y convirtiendo cada incidente de producción en una evaluación permanente.

El problema, según el artículo, es que el manual da por sentado la existencia de pruebas y compilaciones ejecutables con un solo comando, pero no aborda un aspecto decisivo: contra qué debe ejecutarlas el agente. En sistemas reales que se comunican con docenas de servicios, bases de datos, colas y API de terceros, los mocks locales suelen quedar desfasados —el servicio de facturación cambió cabeceras, el de búsqueda pagina de forma distinta, ninguno simula límites de tasa ni latencia—. Un desarrollador percibe ese desfase; un agente no: ve los tests en verde y da la tarea por terminada.

Para cubrir ese hueco, MetalBear presenta mirrord, una herramienta de código abierto —con un operador comercial— que permite ejecutar el código del agente contra los servicios reales del clúster de staging, evitando los mocks. La conexión permite además observar qué devuelven realmente las API y qué contienen las colas. El operador, por su parte, aísla sesiones simultáneas —cabeçalhos de tráfico, colas seccionadas, bases de datos ramificadas— para que varios agentes operen sobre un mismo staging sin interferir entre sí ni con los ingenieros.