Ingeniería con IA · Proceso de ingeniería
Tiempo de lectura · 7 min
El cuello de botella cambió: cuando escribir código se volvió la parte barata
Cómo los agentes desplazaron el cuello de botella de producir código hacia especificación, arquitectura, revisión, verificación, contexto duradero, validación visual y aceptación.
Al empezar StackLiberate, la implementación ocupaba gran parte de nuestro tiempo de ingeniería.
Una función podía ser fácil de describir y difícil de producir. Dedicábamos horas a convertir requisitos en funciones, componentes, migraciones, pruebas, configuración y conexiones. Incluso entendida la arquitectura, quedaba mucho trabajo mecánico entre la idea y un sistema funcional.
Los agentes cambiaron esa ecuación.
Hoy, una vez comprendido un cambio, un agente puede inspeccionar el repositorio, modificar capas, actualizar tipos, escribir pruebas, validar, investigar fallos y revisar la implementación mucho más rápido de lo que podríamos repetir manualmente.
Parece que desapareció el cuello de botella.
No desapareció.
Cambió de lugar.
Cuando implementar se volvió barato, todo lo necesario para decidir si una implementación merecía existir cobró más importancia.
Ha sido uno de los cambios más relevantes en cómo construimos StackLiberate.
Programar más rápido no acelera proporcionalmente las entregas
Implementar más rápido no nos ha dado lanzamientos igual de rápidos. Producir un cambio puede ser breve y aun así exigir mucho para integrarlo, verificarlo y aceptarlo.
El software no pasa directamente de:
idea → código
Recorre algo más parecido a:
intención
↓
diseño
↓
implementación
↓
integración
↓
verificación
↓
revisión
↓
lanzamiento
↓
comportamiento real
Acelerar una etapa aumenta la presión sobre la siguiente.
Si implementar crece más rápido que revisar, se acumula trabajo esperando revisión.
Automatizar la revisión no resuelve necesariamente si se preserva la intención arquitectónica. Comprender el sistema puede volverse la restricción.
Si implementación y revisión son rápidas pero aceptar exige criterio humano cuidadoso, la aceptación se vuelve la restricción.
Acelerar la implementación hizo más visible el trabajo alrededor.
Lo notamos antes de ponerle nombre
Al principio, el flujo aún se parecía al desarrollo convencional.
Entender una función.
Escribirla.
Probarla.
Continuar.
Al mejorar los agentes, implementar dejó de dominar el esfuerzo total.
Empezó a pasar algo más.
Un agente producía un cambio importante sorprendentemente rápido.
Después dedicábamos mucho más tiempo a preguntar:
- ¿Es realmente la capa correcta?
- ¿Reutilizó el sistema o creó otro paralelo?
- ¿Sobrevive a recarga?
- ¿Otro recorrido reconstruye el mismo estado?
- ¿Un atajo inofensivo debilitó una invariante?
- ¿Cambió un componente compartido fuera de la función?
- ¿Se comporta bien la interfaz real, no solo el caso de prueba?
- ¿Sigue funcionando exportado?
- ¿Se amplió silenciosamente el alcance?
A veces la primera implementación era buena.
Otras era excelente localmente e incorrecta arquitectónicamente.
A veces la implementación más rápida generaba tanta investigación posterior que el camino «rápido» era más lento en conjunto.
Eso cambió lo que optimizábamos.
La pregunta dejó de ser:
¿Qué tan rápido produce el agente la función?
Y pasó a ser:
¿Qué tan rápido llegamos a un resultado que entendemos lo suficiente para aceptar?
No son la misma medida.
El código se volvió abundante; la confianza no
Es fácil subestimar esta parte del desarrollo con IA.
Un agente genera más implementación de la que una persona puede revisar profundamente.
Crea una asimetría:
Capacidad de generación ↑↑↑
Atención humana ───
Conocimiento arquitectónico ───
Tiempo de validación ───
Criterio de producto ───
El recurso escaso ya no son necesariamente las teclas.
Es la confianza.
No como sensación.
Sino respaldada por evidencia de que:
- Funciona el comportamiento pedido.
- Hay límites de responsabilidad coherentes.
- Se conserva el comportamiento existente.
- Se entienden los fallos.
- El cambio es mantenible.
- La implementación representa la decisión de producto prevista.
OpenAI describe cómo la verificación humana pasó a ser un cuello de botella al aumentar el código de agentes; reconocemos ese patrón.
Respondimos invirtiendo más en revisión y verificación.
Plan First también buscaba mejorar el flujo
A primera vista planificar antes parece lo contrario de avanzar rápido.
¿Por qué escribir un plan si el agente ya podría programar?
Porque ahora crear una mala implementación sale barato y deshacerla sale caro.
Antes escribir nos daba tiempo para descubrir incertidumbres. Los agentes comprimen ese intervalo.
Un supuesto débil se vuelve casi inmediatamente una implementación limpia en varios archivos.
Trasladamos más razonamiento al principio.
Para cambios que cruzan límites o alteran persistencia pedimos cada vez más exploración de solo lectura y un plan. Una pequeña corrección de texto no necesita el mismo proceso.
El plan debe identificar suficiente del sistema para responder:
¿Qué tiene autoridad?
¿Qué contrato es responsable de este comportamiento?
¿Qué debe permanecer invariable?
¿Cuál es el alcance de efectos previsto?
¿Cómo debe comportarse ante fallos?
¿Cómo validaremos el resultado?
Solo entonces empieza la implementación.
Planificar cuesta tiempo inicial. Lo usamos cuando resolver incertidumbre pronto probablemente cueste menos que corregir después.
Los contratos valen más que las instrucciones
Al crecer la capacidad de implementación, nos interesó menos decir exactamente cómo escribir cada cambio.
No escala.
La información valiosa pasó a ser restricciones que sobrevivan a implementaciones individuales.
Un contrato sólido establece:
- Una fuente de verdad.
- Una transición válida de estado.
- Una propiedad necesaria del ciclo de vida.
- Un límite de permisos.
- Un requisito de compatibilidad.
- Una regla determinista de reconstrucción.
El agente tiene espacio para implementar dentro de ellas.
Esto produce un cambio importante.
La persona no necesita prescribir:
escribe función A
luego auxiliar B
luego condición C
El sistema necesita comunicar:
estas propiedades deben seguir siendo ciertas
Es mucho más duradero.
También da sentido a la revisión.
Comparamos contra un contrato en lugar de preguntar solo si el agente implementó bien su propia idea.
Cuando programar se abarata, la claridad sobre lo que puede significar el código se vuelve costosa y valiosa.
El contexto se volvió infraestructura de ingeniería
Otro cuello de botella aparece con el tiempo.
La comprensión no crece automáticamente con el código generado.
Un agente puede entender bien un subsistema y perder después gran parte de ese contexto.
Otro modelo llega sin la historia.
Una tarea futura redescubre un atajo rechazado antes por buenas razones.
El sistema sigue creciendo mientras desaparece su razonamiento.
Crea una situación extraña:
Más código
Más pruebas
Más funciones
pero
Menos comprensión de por qué encajan
Parte de nuestra inversión posterior fue contexto duradero.
El conocimiento arquitectónico importante no debe depender solo de la conversación de ayer.
Planes, invariantes, decisiones, reglas de validación y límites relevantes necesitan lugares duraderos donde recuperarlos.
El contexto útil explica decisiones y restricciones que de otro modo habría que redescubrir.
Si cada agente debe redescubrir la arquitectura antes de trabajar, recuperar contexto es otro cuello de botella.
Si no se puede redescubrir, es peor.
La revisión pasó de corregir código a razonar sobre sistemas
La IA también cambió qué valoramos al revisar.
Cuando implementar es escaso, se dedica mucho esfuerzo a sus detalles.
¿Es correcta esta función auxiliar?
¿Se puede simplificar el bucle?
¿Es limpia la abstracción?
Siguen importando.
Pero nuestras preguntas más valiosas son cada vez más:
¿Este cambio colocó la responsabilidad correctamente?
¿Creó otro escritor?
¿Resolvió un síntoma visible en vez del contrato subyacente?
¿Las necesidades reales justifican generalizar?
¿Qué pasa fuera del caso exitoso?
¿Preservó la implementación el sistema previsto?
Es otra clase de revisión.
Se parece menos a corregir texto y más a inspeccionar una estructura tras una construcción muy rápida.
El equipo constructor puede ser excelente.
Aun así debes saber si el edificio tiene los cimientos correctos.
Por eso usamos cada vez más IA para revisar.
Generar no tiene por qué ser la única etapa que aceleren los agentes.
Pueden rastrear comportamientos independientemente, buscar responsabilidad duplicada, inspeccionar fallos, contrastar planes y cuestionar supuestos de otros agentes.
Si crece la generación, también debe crecer la capacidad de verificación.
Las pruebas automatizadas son necesarias, pero son una clase de evidencia
Esto cambió cómo interpretamos las pruebas en verde.
Son enormemente valiosas.
Pero si un agente genera función y pruebas, no debemos dejar que la implementación defina las únicas preguntas para evaluarse.
Una suite en verde puede establecer:
El comportamiento probado funciona.
No establece automáticamente:
Probamos el comportamiento correcto.
El estado vive donde corresponde.
Otro recorrido del ciclo sigue funcionando.
La arquitectura no se dividió silenciosamente.
La interacción es realmente aceptable.
Ampliamos nuestras capas de validación.
Según el cambio, la confianza puede requerir una combinación de:
Tipos
+
Pruebas unitarias
+
Pruebas de contrato
+
Pruebas de integración
+
Validación de compilación
+
Comportamiento real en navegador
+
Inspección visual
+
Revisión de arquitectura
+
Aceptación humana
Elegimos según el comportamiento cambiado y las consecuencias de equivocarse. Buscamos evidencia proporcional, no ejecutar todo para cada tarea.
Los productos visuales muestran pronto el problema
StackLiberate lo hace especialmente visible por ser visual.
Una prueba de navegador demuestra que se pulsó un botón.
Una unitaria demuestra que una operación produjo un estado.
Ninguna demuestra necesariamente que la edición se sienta correcta.
Algo puede ser técnicamente correcto y verse mal:
- un control superpuesto cubre el área equivocada;
- el diseño adaptable se comprime mal;
- una interacción funciona pero confunde;
- editor y exportación pasan pruebas aisladas y difieren en un detalle visual importante.
La validación visual sigue siendo parte de la aceptación.
Dejamos que los agentes ayuden.
Operan navegadores, inspeccionan capturas, reproducen secuencias y comparan lo esperado.
Pero alguien debe decidir:
¿Es realmente la experiencia que queríamos publicar?
Al acelerarse la generación, el criterio subjetivo de producto no se acelera automáticamente.
Se vuelve otro cuello de botella visible.
«Terminado» se volvió una palabra más costosa
Que el agente diga terminado significa menos de lo que podía parecer antes.
Puede informar honestamente:
- implementación completa;
- tipos correctos;
- pruebas aprobadas;
- compilación aprobada.
Es útil.
Pero describe el estado de implementación, no necesariamente el de ingeniería.
Para nosotros terminar significa más bien:
Implementado
↓
Validado
↓
Revisado contra invariantes
↓
Probado en el producto real
↓
Efectos inesperados resueltos
↓
Aceptado
Buscamos ese estándar con comprobaciones adecuadas al alcance.
No queremos producir cambios rápidamente.
Queremos evitar pasar el próximo mes reparando la velocidad de hoy.
El cuello de botella puede moverse otra vez
Nuestro flujo actual no es permanente.
Ya usamos agentes para inspeccionar, operar navegadores e investigar registros. Darles evidencia útil mejora verificación y generación.
Algunos cuellos de botella posteriores también pueden automatizarse.
Lo esperamos.
Pero moverlos no es eliminarlos.
Supongamos que los agentes llegan a gestionar:
implementación
+
pruebas
+
revisión
+
verificación visual
extraordinariamente bien.
El recurso escaso puede pasar a ser:
- definir intención del producto;
- decidir compromisos arquitectónicos;
- elegir concesiones aceptables;
- evaluar comportamientos nuevos de usuarios;
- decidir qué no construir.
En ese escenario, más restricciones restantes dependerían del criterio.
Por eso no creemos que el futuro sea simplemente «los agentes escriben más código».
Lo más interesante es:
A medida que la IA acelera una etapa, debemos reevaluar qué limita el flujo completo.
Todavía no lo medimos con precisión
Hay una salvedad importante.
No realizamos un experimento controlado del desarrollo de StackLiberate con y sin agentes.
No podemos afirmar que Plan First mejore el rendimiento en un porcentaje concreto.
No tenemos medidas formales del tiempo de revisión, retrabajo, carga cognitiva o tasas de defectos.
Tenemos experiencia operativa repetida construyendo así un producto cada vez más complejo.
Las observaciones han sido suficientemente consistentes para cambiar cómo planificamos, documentamos, revisamos y aceptamos. Son experiencia de un producto, no una afirmación de productividad medida para todo equipo.
La nueva unidad de productividad no es código
Por eso nos interesa menos medir ingeniería con IA por líneas de código o cantidad de cambios completados por un agente.
Producir más código es fácil.
Producir más software del que aceptemos depender es difícil.
La salida útil de nuestro proceso no es:
una diferencia de código
Es:
un cambio
que entendemos,
podemos verificar,
podemos mantener
y estamos dispuestos a publicar.
La IA abarató enormemente una parte de producir ese resultado.
Es una ventaja extraordinaria.
Pero el resto del proceso debe evolucionar.
Para nosotros significó descubrir algo inesperado:
Escribir el código se estaba volviendo la parte barata.
El trabajo valioso se trasladó a decidir, limitar, entender, verificar y aceptar lo que se construye.
El cuello de botella cambió de lugar.
Y nosotros cambiamos con él.