Ingeniería con IA · Proceso de ingeniería
Tiempo de lectura · 7 min
Las personas dirigen, los agentes ejecutan: nuestro ciclo de ingeniería con IA
Cómo usamos agentes como colaboradores activos manteniendo la responsabilidad humana sobre arquitectura, alcance, intención del producto, revisión y aceptación final.
Hay dos relatos fáciles sobre la IA y el desarrollo de software.
En el primero, es autocompletado con mejor marketing. Los ingenieros siguen haciendo casi todo y el modelo ahorra algunas teclas.
En el segundo, alguien describe un producto, un agente autónomo lo construye, las pruebas pasan y la ingeniería casi desaparece.
Ninguno describe cómo construimos StackLiberate.
La IA participa profundamente.
Los agentes inspeccionan el repositorio, rastrean comportamientos entre capas, proponen planes, escriben código de producción, refactorizan sistemas, añaden pruebas, operan navegadores, investigan fallos, cuestionan implementaciones anteriores y revisan trabajo de otros agentes.
A veces un agente realiza casi toda la implementación mecánica de una función.
Pero eso no traslada la responsabilidad de ingeniería junto con la escritura.
Nuestro principio de trabajo es:
Las personas dirigen. Los agentes ejecutan. La responsabilidad sigue vinculada al sistema, no a quien —o lo que— escribió el código.
La distinción importa más al aumentar la capacidad de los agentes.
La pregunta interesante ya no es quién escribió el código
Contar líneas humanas frente a líneas de IA describe cada vez peor el desarrollo actual.
Un ingeniero puede escribir manualmente diez mil líneas de una arquitectura débil.
Un agente puede generar una implementación sólida desde un contrato diseñado con cuidado.
También puede ocurrir lo contrario.
Las preguntas importantes son de mayor nivel:
- ¿Quién decidió qué debe hacer el sistema?
- ¿Quién eligió los límites?
- ¿Qué tiene autoridad?
- ¿Qué riesgos son aceptables?
- ¿Qué comportamiento debe ser invariable?
- ¿Cómo se valida la implementación?
- ¿Quién decide que está lista?
Esas decisiones determinan mucho más que si la sintaxis final vino de dedos o de un modelo.
La conversación profesional sobre agentes también se mueve hacia ahí.
Al completar tareas más largas de forma independiente, los agentes permiten dedicar menos tiempo a cada detalle de implementación y más a especificar intención, diseñar entornos, definir restricciones, revisar resultados y decidir dónde importa el criterio humano.
Reconocemos esa transición porque se parece a nuestra experiencia.
Dirigir no es escribir una instrucción gigante
«Dirección humana» puede sonar a dictar cada función sentado junto al agente.
Desperdiciaría buena parte del beneficio.
No necesitamos dirigir cada paso mecánico de un agente capaz:
Abre este archivo.
Añade esta función.
Crea esta variable.
Ahora modifica la línea 42.
Las instrucciones detalladas sirven cuando la tarea lo exige. Por defecto establecemos intención y restricciones y dejamos al agente decidir la implementación.
En trabajo importante de StackLiberate queremos establecer:
Intención del producto
↓
Límites del sistema
↓
Fuente de verdad
↓
Invariantes requeridas
↓
Alcance permitido
↓
Condiciones de aceptación
Dentro de esos límites puede explorar.
Puede identificar un mejor límite de responsabilidad, reutilizar una abstracción o mostrar que un diseño contradice una invariante. Esos hallazgos mejoran el plan antes de convertirse en compromisos de implementación.
Dirigir define el destino y las reglas del camino.
No exige elegir manualmente cada giro.
La intención del producto sigue siendo humana
Los agentes convierten muy bien objetivos explícitos en trabajo concreto.
Son menos adecuados para decidir en qué debe convertirse el producto.
Una solicitud como:
Permite mover secciones.
contiene mucha más política de producto de la que aparenta.
¿Se puede mover cualquier sección?
¿También el encabezado?
¿Qué pasa con la navegación?
¿Debe sobrevivir a recarga?
¿Participa en el historial?
¿Se puede exportar?
¿Qué ocurre en móviles?
¿Las plantillas deben declarar compatibilidad?
¿Qué pasa si un proyecto antiguo carece de la identidad necesaria?
Un agente ayuda a descubrir y analizar estas preguntas.
Pero elegir el comportamiento requiere criterio sobre el sistema que buscamos crear.
En StackLiberate esa responsabilidad sigue siendo humana.
Pedimos a los agentes cuestionar decisiones y revisamos la dirección cuando su análisis demuestra un enfoque mejor.
Pero el modelo no está autorizado implícitamente a convertir una comodidad de implementación en política del producto.
La arquitectura es un límite de decisión
La misma distinción se aplica a la arquitectura.
Con el contexto adecuado, los agentes razonan muy bien sobre ella. Rastrean escritores y lectores, inspeccionan contratos, identifican acoplamientos y proponen diseños sorprendentemente sólidos.
Usamos mucho esa capacidad.
Pero una propuesta y una decisión arquitectónicas son distintas.
Supongamos que un agente encuentra dos enfoques viables.
Uno introduce una abstracción que facilitará futuras funciones.
El otro reutiliza el sistema y tiene menos efectos.
Ninguno es correcto por naturaleza.
La elección depende de cosas que el repositorio quizá no sepa:
- ¿Qué está realmente en la hoja de ruta?
- ¿Se espera ampliar esta capacidad?
- ¿Aplazamos deliberadamente una abstracción mayor?
- ¿Importa aquí más la compatibilidad que la elegancia?
- ¿Los mecanismos adicionales justifican su complejidad?
Son decisiones de ingeniería influidas por la estrategia de producto.
Nuestro flujo permite proponer arquitectura sin conceder silenciosamente al agente su dirección.
Por eso usamos Plan First en cambios importantes.
Es más fácil evaluar la arquitectura antes de tener cientos de líneas que defender.
En la ejecución los agentes se vuelven extraordinarios
Una vez establecida la dirección, el equilibrio cambia.
Aquí pueden avanzar muy rápido.
Una tarea acotada puede requerir:
- Inspeccionar recorridos pertinentes del código.
- Modificar varias capas.
- Actualizar tipos.
- Ampliar validación.
- Añadir pruebas.
- Ejecutar suites existentes.
- Investigar fallos.
- Ajustar la implementación.
- Resumir los cambios finales.
Hacerlo mecánicamente ya no es tan escaso como antes.
Los agentes llevan un cambio por varias capas, ejecutan comprobaciones e investigan fallos en el mismo ciclo. Así delegamos trabajo importante revisando las decisiones y evidencias relevantes.
En lugar de consumir atención humana en cada transformación sintáctica, podemos decidir si el sistema resultante es coherente.
No hace poco importante la implementación.
La abarata respecto al criterio.
No suponemos que la ejecución sea infalible
Delegar solo sirve si confiamos apropiadamente en el resultado.
No significa confiar a ciegas.
Un agente puede producir una implementación:
- Correcta localmente.
- Bien tipada.
- Probada a fondo.
- Visualmente convincente.
Y aun así vulnerar la arquitectura prevista.
Puede duplicar responsabilidad.
Introducir un atajo.
Entender mal una restricción antigua de compatibilidad.
Resolver la interfaz actual y olvidar otro recorrido del ciclo.
Limpiar con confianza código aparentemente accidental que protegía una invariante importante.
Por eso nuestro ciclo no termina en:
El agente dice que terminó.
«Terminado» es una afirmación.
La aceptación es una etapa separada.
Cada etapa merece distintos tipos de inteligencia
No pensamos en la IA como un agente haciendo un trabajo continuo de la idea a producción.
Cada etapa se beneficia de perspectivas distintas.
La exploración debe ser curiosa y amplia.
La planificación debe cuestionar límites.
La implementación debe respetar el alcance.
La revisión debe evaluar independientemente contra requisitos y restricciones arquitectónicas.
La validación debe buscar evidencia observable.
Conceptualmente:
Intención humana
↓
Exploración del agente
↓
Plan del agente
↓
Revisión arquitectónica humana
↓
Implementación del agente
↓
Validación automatizada
↓
Revisión de ingeniería independiente
↓
Aceptación humana
El mismo modelo puede asumir varios roles.
A veces convienen agentes o modelos distintos.
Lo importante es separar responsabilidades.
La revisión independiente contrasta el resultado con los requisitos, no solo con los supuestos usados al construirlo.
Los agentes pueden discrepar
La responsabilidad humana no hace automáticamente correctas las ideas humanas.
Es una parte importante de la relación.
Si pedimos investigar y nuestra función vulnera un contrato, queremos que lo diga.
Si la implementación preferida exige infraestructura innecesaria, queremos que el plan lo señale.
Si los efectos son más amplios de lo previsto, queremos evidencia.
Si el repositorio contradice nuestro modelo mental, prevalece el repositorio hasta entender por qué.
Así la relación aporta más que una automatización de órdenes y control.
La persona aporta dirección.
El agente aporta ejecución y resistencia técnica.
Un buen agente a veces debería dificultar la decisión de dirección.
Normalmente significa que descubrió algo que merece consideración.
El alcance es una forma de control de ingeniería
Un agente capaz puede resolver fácilmente más de lo pedido.
Ve limpieza cercana.
Se podría generalizar una abstracción.
Modernizar una dependencia.
Refactorizar una herramienta de pruebas.
Aplicar la mejora a una función vecina.
Cada idea puede ser razonable.
Juntas convierten un cambio acotado en una migración arquitectónica que nadie quería iniciar.
Por eso el alcance sigue siendo un límite humano explícito.
A menudo importa tanto lo que una tarea no debe cambiar como lo que sí debe.
Da libertad dentro de un área conocida sin convertir cada función en excusa para rediseñar el repositorio.
Un alcance previsible hace útil la ejecución rápida: el resultado sigue siendo revisable, mantenible y alineado con el cambio previsto.
La aceptación pertenece a las personas
Las pruebas pueden pasar.
Los agentes revisores pueden aprobar.
Los controles estáticos pueden seguir en verde.
La función puede verse bien en el navegador.
Son evidencias importantes.
Alguien aún debe decidir si el resultado es aceptable.
La aceptación plantea más preguntas:
- ¿Resuelve realmente el problema del producto?
- ¿Se justifica la complejidad?
- ¿Son aceptables las concesiones?
- ¿Preservamos la arquitectura prevista?
- ¿Se siente correcta la interacción?
- ¿Estamos cómodos manteniéndolo?
- ¿Es la función que queríamos?
Combinan evidencia técnica y criterio de producto.
La IA puede contribuir a todas.
No puede asumir las consecuencias de la respuesta.
Esa es la línea importante.
La supervisión humana debe concentrarse donde aporta más
También hay una mala supervisión.
Si cada acción requiere aprobación, el agente se vuelve lento y la persona atiende interrupciones.
No buscamos mantener a las personas constantemente dentro del ciclo.
Las queremos en sus puntos importantes.
Para nosotros suelen ser:
Antes de implementar, cuando alcance y arquitectura aún cuestan poco cambiar.
Cuando fallan los supuestos, porque el plan aprobado quizá ya no describe la realidad.
Durante la revisión, especialmente en responsabilidad del estado, seguridad, comportamiento ante fallos y límites arquitectónicos.
En la aceptación, cuando decidimos si el comportamiento pertenece al producto.
Dentro del alcance acordado, los agentes resuelven decisiones rutinarias y completan validación independientemente. La revisión humana se enfoca en cambios de intención, arquitectura o riesgo con consecuencias importantes.
Es más escalable que cualquiera de los extremos:
La persona escribe todo
O:
El agente decide todo
La experiencia no desaparece al mejorar los agentes
Es atractiva la teoría de que agentes suficientemente capaces harán menos relevante la experiencia de ingeniería.
Nuestra experiencia apunta a lo contrario.
Mejores agentes amplían lo que logra un buen criterio.
Un ingeniero que entiende el sistema puede dar instrucciones de mayor nivel porque sabe qué detalles importan.
Reconoce cuándo una «simplificación» daña una invariante.
Distingue fallos de pruebas incidentales de los que revelan un diseño roto.
Distingue una abstracción que compensará su costo de una solo elegante.
La investigación emergente encuentra algo similar: quienes tienen más experiencia de dominio suelen delegar mejor, no menos.
La experiencia multiplica la capacidad.
En lugar de implementar manualmente cada decisión, el ingeniero toma decisiones relevantes y permite que los agentes las amplifiquen.
Un proceso de ingeniería amplificado por IA
Las instrucciones en lenguaje natural son la entrada. Exploración, arquitectura, validación y aceptación determinan si el cambio pertenece al sistema.
Nuestro ciclo conecta esas etapas:
Intención
↓
Exploración
↓
Arquitectura
↓
Plan
↓
Implementación
↓
Pruebas
↓
Revisión de invariantes
↓
Aceptación del producto
La IA escribe una parte importante de StackLiberate. Usamos esa capacidad dentro de un proceso que mantiene el sistema deliberado, verificable y mantenible.
El criterio no es:
Una persona escribió esto.
Es:
Entendemos por qué existe, dónde pertenece, qué puede hacer y qué evidencia nos permite publicarlo.
El ciclo sigue cambiando
Nuestro flujo actual no será permanente.
Los agentes mejoran planificando.
Mejoran ejecutando trabajos largos.
Mejoran revisando repositorios, usando herramientas, validando visualmente y coordinándose con otros agentes.
Algunas decisiones que hoy exigen intervención humana podrían volverse suficientemente rutinarias para delegarse.
Otras podrían importar más precisamente porque crece la capacidad de implementación.
No creemos que la respuesta sea fijar para siempre una frontera entre «trabajo humano» y «trabajo de IA».
Un principio mejor es:
Pon criterio humano donde los errores sean costosos y la intención importe. Pon ejecución de agentes donde velocidad, amplitud e iteración aporten más.
La frontera puede moverse al mejorar la tecnología.
La responsabilidad no.
Estamos desarrollando software, no generándolo
El producto final no es la transcripción de las instrucciones que lo crearon.
Es un sistema con arquitectura, estado, historia, restricciones, usuarios y consecuencias.
Usamos IA extensamente para investigar, planificar, implementar, probar y revisar. Los agentes también cuestionan nuestros supuestos y a veces demuestran que otro enfoque es mejor.
Las personas deciden qué debe ser StackLiberate, qué compromisos arquitectónicos asumimos, cuándo una solución supera su mandato y si el resultado cumple el criterio para publicarlo.
Ese es nuestro ciclo de ingeniería con IA.
Las personas dirigen. Los agentes ejecutan. El sistema sigue siendo nuestra responsabilidad.