Elegir tecnología cuando programamos con agentes
Hace un tiempo me di cuenta de que habíamos dejado de discutir qué tecnología convenía usar. No hubo una reunión, un ADR ni una decisión explícita. Simplemente empezábamos con el stack que el agente manejaba mejor.
Next.js o Astro. Nest o algo más liviano. Una librería de componentes, otra para formularios, otra para validar datos. Muchas de esas decisiones ya venían tomadas dentro de la primera implementación.
No creo que esté mal tener un default. El problema es dejar de recordar que sigue siendo una decisión.
El nuevo integrante de la discusión
Siempre elegimos tecnologías con algún sesgo. Usamos lo que conoce el equipo, lo que podemos operar y lo que no exige explicar el universo cada vez que se suma alguien.
Los agentes agregan otra forma de familiaridad: preferimos también aquello que el modelo puede producir con menos contexto y menos correcciones.
Esa comodidad tiene valor. Si el agente conoce bien el stack, probablemente avancemos más rápido en tareas rutinarias. Pero su familiaridad es bastante más opaca que la nuestra: depende del entrenamiento, la documentación disponible, las herramientas conectadas y los defaults del entorno.
Cuando pedimos “armá una aplicación” sin aclarar restricciones, todo eso participa de la arquitectura. El agente arranca a escribir y, para cuando vemos el primer resultado, varias decisiones ya vienen empaquetadas ahí adentro.
Lo raro es que nadie lo decidió
Lo que me hizo ruido no fue usar Next.js, Tailwind o cualquier otra herramienta popular. Las usamos porque funcionan y porque las conocemos. Lo raro fue notar que ya no siempre llegábamos a esa elección después de una conversación.
El primer resultado aparecía rápido, bastante armado y con un stack coherente. Frenar para discutir Astro, Vite o una alternativa de backend empezaba a sentirse como tirar trabajo que ya estaba hecho. El default no ganaba por ser mejor: ganaba porque llegaba primero.
Después me puse a buscar si era solamente una sensación nuestra. No lo era.
Hay investigaciones que encontraron preferencias claras por ciertas librerías, lenguajes y hasta proveedores cloud. También hay pruebas donde distintos agentes terminan armando, una y otra vez, combinaciones muy parecidas de Next.js, TypeScript, Tailwind, PostgreSQL y Vercel.
Los números están en las fuentes del final para quien quiera meterse. Lo que me quedó de esa lectura es más simple:
Un agente puede producir una solución correcta y aun así elegir una tecnología por familiaridad, no porque sea la mejor para el problema.
El círculo se parece bastante a esto:
@render mermaid
flowchart LR
P["Tecnología popular<br/>Más código y ejemplos"]
M["El modelo aprende<br/>mejor sus patrones"]
A["El agente trabaja<br/>con menos fricción"]
E["Más equipos<br/>la vuelven a elegir"]
P --> M --> A --> E --> P
classDef accent fill:#fff1df,stroke:#d5672e,stroke-width:2px,color:#292522;
classDef neutral fill:#f4eee6,stroke:#a99b8e,stroke-width:1.5px,color:#292522;
class A accent;
class P,M,E neutral;No sabemos todavía cuánto está afectando esto a la adopción real de frameworks. Pero el mecanismo está ahí, y se parece bastante a lo que vemos en el trabajo cotidiano.
Tener un stack preferido está bien
Compartir un stack baja la carga cognitiva, facilita el onboarding, acelera revisiones y concentra experiencia operativa. Elegir algo nuevo en cada proyecto tampoco es una demostración de criterio técnico; muchas veces es solamente una forma cara de entretenernos.
El problema aparece cuando el default pasa por estas etapas:
es la opción que conocemos y soportamos;
es la opción que usamos salvo que haya una buena razón;
dejamos de buscar si hay una buena razón.
Ahí el stack preferido se vuelve obligatorio sin que nadie lo declare.
La fluidez del agente debería ser parte de la evaluación porque afecta el costo. Pero es un dato de costo, no una conclusión arquitectónica.
Que un agente escriba mejor Next.js que Astro no prueba que Next.js sea mejor para el producto. Prueba que, en ese contexto, va a exigir menos trabajo inicial. Después siguen existiendo rendimiento, seguridad, operación, mantenibilidad, lock-in y costo de salida.
Qué podemos hacer sin volvernos locos
Tampoco quiero que esto se convierta en volver a debatir veinte frameworks antes de instalar una dependencia. Sería cambiar una inercia por una ceremonia.
El punto medio que más sentido me hace —y que también aparece en las recomendaciones de DORA— es tener una base soportada y una puerta real para probar excepciones. Yo lo bajaría a cinco pasos.
@render mermaid
flowchart TB
R["1. Empezar por<br/>el problema"]
D["2. Usar un default con<br/>puerta de salida"]
S["3. Probar con<br/>un caso real"]
A["4. Dejar escrito<br/>el porqué"]
P["5. Hacer una<br/>prueba de salida"]
R --> D --> S --> A --> P
classDef accent fill:#fff1df,stroke:#d5672e,stroke-width:2px,color:#292522;
classDef neutral fill:#f4eee6,stroke:#a99b8e,stroke-width:1.5px,color:#292522;
class R,P accent;
class D,S,A neutral;1. Empezar por el problema
Antes de nombrar tecnologías, escribimos las restricciones importantes:
rendimiento y escala;
seguridad y privacidad;
accesibilidad;
despliegue y operación;
experiencia del equipo;
horizonte de vida y costo de salida.
Si arrancamos con “hacelo en Next.js”, la decisión ya ocurrió. El agente sólo va a justificarla con código.
2. Usar un default con puerta de salida
El stack preferido debería resolver la mayoría de los casos sin ceremonia y venir con tests, observabilidad, instrucciones y experiencia real.
Pero si otra tecnología satisface mejor una restricción importante, debería poder entrar. El equipo que la propone tiene que mostrar el beneficio y asumir el costo de mantenerla.
La pregunta no es “¿por qué no usamos lo de siempre?”. Es “¿el beneficio paga el costo de salir de lo conocido?”.
3. Probar con un caso real
Un hello world muestra sintaxis, no mantenibilidad.
Para una decisión importante, probamos algo que se parezca al trabajo de verdad: un flujo de negocio, una integración o persistencia, errores, tests, build y observabilidad. Después agregamos un cambio no previsto, porque ahí suelen aparecer las diferencias interesantes.
Medimos más que velocidad de generación:
tiempo de revisión;
errores y correcciones;
dependencias incorporadas;
facilidad de depuración;
capacidad de otra persona para explicar y modificar el resultado.
Si el agente no conoce una alternativa, primero le damos documentación oficial y ejemplos acotados. Hay evidencia de que los modelos pueden aprender librerías nuevas desde el contexto. De otro modo no estamos comparando tecnologías: estamos comparando la memoria previa del agente.
4. Dejar escrito el porqué
Un ADR corto alcanza para registrar:
qué problema queríamos resolver;
qué alternativas miramos;
qué evidencia usamos;
cuánto trabajo de revisión exigió;
qué evento nos haría revisar la decisión.
No es burocracia. Es la diferencia entre una decisión y una inercia que dentro de un año nadie sabe explicar.
5. Hacer una prueba de salida
No hace falta programar todo a mano para conservar autonomía. Hace falta que el equipo pueda operar y cambiar el sistema aunque mañana cambie el agente.
Una segunda persona debería poder explicar el flujo, ejecutar build y deploy, diagnosticar un fallo con logs y tests, y entender cómo reemplazar una pieza crítica si deja de servir.
Si cambiar de agente vuelve incomprensible el sistema, el lock-in no estaba solamente en la tecnología.
Algunas señales para prestar atención
No existe un porcentaje mágico de código generado que vuelva dependiente a un equipo. Hay señales más concretas:
nadie sabe por qué entró una librería;
una alternativa se descarta después del primer intento malo del agente;
la revisión termina cuando CI queda verde;
entran dependencias sin verificar origen ni mantenimiento;
cada incidente produce otro parche, pero no una explicación del problema;
el equipo genera más código mientras menos personas entienden el sistema.
Una sola señal no demuestra nada. Varias juntas merecen una charla.
La idea no es elegir contra el agente
Los humanos también elegimos por costumbre, moda o ganas de probar algo nuevo. No existe una decisión técnica pura a la que tengamos que volver.
Tampoco hace falta reabrir un torneo de frameworks por cada package.json. Las decisiones reversibles y de bajo impacto pueden usar el default. Cuanto más cara sea la salida, más explícitas deberían ser las razones de entrada.
Me quedo con tres ideas:
🧭 La familiaridad del agente importa, pero no reemplaza los requisitos del sistema.
🚪 Un stack preferido ayuda si conserva una puerta para experimentar.
🛠️ Tener control no es escribir todo a mano, sino poder explicar, operar y cambiar lo generado.
Para la próxima decisión, prueben algo simple: escriban primero las restricciones sin nombrar tecnologías. Después comparen lo que propone el agente con lo que el equipo habría considerado por su cuenta.
Tal vez terminen eligiendo exactamente el mismo stack. La diferencia es que esta vez va a ser una decisión.