Prólogo: el momento del todo poderoso

En la película Bruce Almighty (2003), un periodista recibe los poderes de Dios por unos días. Lo primero que hace cuando se da cuenta es probarlos: mueve la luna, parte un mar de sopa con la cucharilla, escribe a la velocidad de la luz. Lo interesante no es el poder en sí. Lo interesante es cuánto tarda en dejar de tenerle miedo.

Cuando tienes un Coding Agent dirigido por instrucciones — Claude, Claude Code — estás en una posición parecida. No tan dramática, pero estructuralmente igual: tienes acceso a una capacidad de ejecución que hasta hace pocos años habría requerido un equipo de cinco o diez personas durante meses. Y lo único que falta para usarla es perder el miedo a dirigirla.

Esta es la primera parte de una serie de tres papers. Trata de cómo construir software completo con una IA como Claude — desde la primera conversación con el cliente hasta el servidor monitoreado en producción — y de las dos actitudes que hacen la diferencia entre quien queda paralizado y quien entrega. El campo es nuevo y se mueve rápido: una revisión sistemática reciente identificó cerca de 400 estudios empíricos sobre modelos de lenguaje grandes (LLMs) aplicados a ingeniería de software, publicados casi todos en los últimos cinco años (Hou et al., 2024).

Por eso este marco arranca con una invitación distinta a la habitual: sé tu propio equipo. Con un Coding Agent dirigido, una sola persona puede operar como si tuviera a su disposición un equipo entero de profesionales — arquitecto que define la estructura, desarrollador frontend que arma la interfaz, desarrollador backend que conecta las piezas, devops que despliega, technical writer que documenta, QA que prueba. Aprendes de todas esas disciplinas a la vez generando proyectos reales, que complementan lo que se estudia en el aula: la formación entrega el marco conceptual y los proyectos lo consolidan con experiencia. Cuanto más construyes, más god stack te vuelves — y este paper es la primera escalera para llegar ahí.

De la conversación con el cliente al sistema en producción

Lo primero que conviene entender es qué tan lejos puede llegar una IA bien dirigida hoy. La respuesta corta: todo el camino. La respuesta larga, en orden:

1. Levantar requerimientos con el cliente. El Tech Lead conversa con el stakeholder; el agente ayuda a estructurar las preguntas según el dominio (clínica veterinaria, ferretería, taller mecánico, fundación social), a sintetizar las respuestas dispersas, a ponderar las problemáticas y a producir un brief de visión en una página que el cliente firma.
2. Diseñar el modelo de datos. El Tech Lead describe en prosa qué entidades hay, qué relaciones existen, qué información es sensible; el agente materializa el esquema en SQL (Structured Query Language, lenguaje estándar para definir y consultar bases de datos) o DBML (Database Markup Language, un formato de texto pensado para describir esquemas de manera legible); el Tech Lead lo carga en un visualizador gráfico (dbdiagram.io, drawSQL) y lo revisa. Iteran hasta que el ERD (Entity-Relationship Diagram, diagrama entidad-relación que muestra tablas, atributos y cómo se conectan) aguante el peso del negocio real.
3. Construir la solución. Microsprints de 3 días. Funcionalidad por funcionalidad. El agente escribe el código, los tests, la documentación; el Tech Lead revisa cada cambio antes de aprobarlo y lo conecta con la arquitectura general. Despliegues automáticos al entorno de desarrollo en cada merge.
4. Validar con personas reales. Testers externos al equipo de construcción rompen lo que se construyó. Vuelve la lista de issues. El agente propone correcciones; el Tech Lead decide cuáles aplican y cuáles reabren conversación con el cliente.
5. Desplegar a producción. Mínimo tres días: uno para el despliegue técnico y monitoreo intensivo, otro para validar con tráfico real, otro para ajustes, capacitación y firma de cierre. Nunca un viernes. Nunca en un solo día.
6. Programar el soporte periódico. Backups automáticos con copia fuera del propio servidor. Monitoreo de uptime. Renovación automática de certificados. Ticketera embebida dentro del producto para que los usuarios reporten problemas. El agente también puede asistir la operación a futuro — no solo construir.

Una observación importante sobre el segundo paso, antes de seguir. Detectar errores o elementos faltantes en el modelo de datos inicial ya no es grave. En la práctica tradicional, descubrir a la semana tres que faltaba una tabla pivote o que la cardinalidad de una relación estaba invertida significaba días — a veces semanas — de retrabajo: cambiar el esquema, regenerar migraciones, ajustar los servicios que consumían las tablas, actualizar la documentación, re-correr los tests, comunicar al cliente que el calendario se corría. Era el clásico costo del error compuesto.

Con un Coding Agent bien dirigido, esa misma corrección toma minutos. El Tech Lead describe el problema en lenguaje natural; el agente propone la migración con sus tests asociados, ajusta los modelos en código, actualiza los servicios afectados y documenta el cambio en el mismo flujo. El Tech Lead valida el resultado en el visualizador gráfico y mergea. El costo del error baja tanto que el modelo de datos deja de ser una fundación congelada y pasa a ser un artefacto vivo — algo que se puede iterar con confianza durante todo el proyecto. Esa libertad, aplicada bien, cambia profundamente cómo se conversa con el cliente en las primeras semanas: ya no hay miedo a "cerrar" prematuramente decisiones que después se vea que estaban incompletas.

Antes esto era un equipo. Hoy es una persona con criterio dirigiendo a una IA. La diferencia no es la herramienta: es saber qué pedirle, cuándo detenerse a pensar y cuándo apretar el acelerador. La velocidad no es una exageración de marketing: en un experimento controlado, los desarrolladores asistidos por Copilot completaron una tarea de implementación HTTP un 55,8 % más rápido que el grupo control (Peng et al., 2023). Esa ganancia, traducida a proyectos enteros, es lo que vuelve realista entregar en semanas lo que antes tomaba meses.

Una nota útil sobre cómo se interactúa con el agente en la práctica: Barke, James y Polikarpova (2023) observaron que los programadores que trabajan con asistentes IA oscilan entre dos modos durante una misma sesión — acceleration, cuando saben exactamente qué quieren y solo necesitan que la IA escriba más rápido, y exploration, cuando están descubriendo qué construir. Reconocer en qué modo estás te ayuda a dirigir mejor: el modo exploración pide más preguntas, el modo aceleración pide más revisión.

Del full stack al god stack developer

Hay un nombre que se ha quedado corto. Durante quince años, la figura estrella del software fue el full stack developer — alguien que manejaba frontend (HTML, CSS, JavaScript, frameworks), backend (lenguajes de servidor, lógica de negocio), base de datos y, a veces, un poco de despliegue. Era la "navaja suiza" del desarrollo. Pero la imagen, aunque seductora, siempre dejó cosas afuera: el levantamiento de requerimientos con el cliente, el diseño de experiencia de usuario, el modelado del negocio, la elección de arquitectura, las decisiones de infraestructura productiva, el monitoreo operativo, la atención de soporte, el marketing técnico. Eso lo cubrían otros oficios — product, design, business, DevOps, SRE, soporte, marketing.

Con un Coding Agent dirigido, una sola persona puede cubrir todo ese flujo. No porque sea genial en cada disciplina — sino porque la IA, dirigida desde la disciplina correcta, puede ejecutar lo que se le pide en cualquiera de ellas. A esa figura nueva conviene darle nombre propio. Lo llamamos god stack developer: el Tech Lead que se siente cómodo conduciendo al agente a lo largo del ciclo entero del producto, desde la primera reunión con el cliente hasta el monitoreo del servidor a las tres de la mañana.

No es marketing. Hay razones concretas por las que el god stack developer deja al full stack atrás:

1. Alcance del rol. El full stack cubría la implementación técnica: frontend, backend, base de datos. El god stack cubre el ciclo completo: requerimientos, modelado de datos y procesos, arquitectura, construcción, validación, despliegue, operación y soporte periódico. No se queda en el commit — entrega el producto vivo.
2. Velocidad por dirección, no por dactilografía. El full stack rendía por la profundidad técnica de su escritura. El god stack rinde por la calidad con que dirige una capacidad de ejecución muy alta. Un proyecto que solía tomar seis meses, con un god stack bien dirigido se entrega en dos a tres meses — y la parte de pura construcción, hasta cinco veces más rápido. La habilidad ya no es escribir más rápido: es decidir qué se escribe, en qué orden y con qué criterio.
3. Capacidad multidisciplinaria operativa. El full stack era cien por ciento técnico. El god stack puede dirigir desde cualquier disciplina del producto: finanzas (modelar cuentas y márgenes), contabilidad (factura electrónica, planes de cuentas), diseño (UX, identidad visual), legal (Ley 19.628, cumplimiento sectorial), marketing (SEO, conversión). Mira el sistema desde varios oficios sin tener que dominar cada uno a fondo.
4. "Saber preguntar" en vez de "tenerlo todo en la cabeza". El full stack vivía con la presión de tener que saberlo todo — algo imposible y agotador. El god stack tiene que saber preguntar bien, evaluar respuestas, pedir alternativas, exigir argumentos. Esa habilidad se transfiere a cualquier dominio nuevo en horas, no en años. Conecta directamente con el siguiente capítulo: el corazón metodológico es atreverse a quedar como un tonto.
5. Resiliencia ante cambios de stack. El full stack quedaba obsoleto cada vez que el ecosistema cambiaba — jQuery a React, REST a GraphQL, Webpack a Vite, monolitos a microservicios. El god stack vive en categorías (Coding Agent, repositorio, IDE, capa de borde, hosting, monitoreo, memoria del proyecto), no en productos. Cambia la herramienta de hosting o el framework frontend; el rol se mantiene intacto.
6. Entrega producto, no código. El full stack entregaba repositorios: código compilable, funcionando en localhost, requiriendo un equipo de operaciones para llevarlo a producción. El god stack entrega productos en producción: con su despliegue automatizado, su monitoreo activo, sus respaldos validados, su ticketera embebida para soporte, su documentación viva. Reduce drásticamente la dependencia perpetua del cliente hacia el desarrollador.

No es un superhéroe. Es alguien que aprendió a dirigir bien una herramienta nueva. Y cualquier persona con disciplina, curiosidad y disposición a preguntar puede llegar a ese rol. La barrera ya no es años de experiencia técnica acumulada — es la voluntad de tomar las riendas de la conversación.

Atrévete a quedar como un tonto

Si tuviera que reducir todo este paper a una sola frase, sería esta:

Atrévete a quedar como un tonto. Pregúntale al agente qué significa cada cosa que no entiendes del todo. Cada vez. Sin vergüenza.

El instinto del estudiante de ingeniería — y del ingeniero con años de oficio también — es disimular lo que no sabe. Aceptar la primera explicación. Asentir con la cabeza cuando el código compila y el comando devolvió algo plausible. Esa actitud, perfectamente humana, es el principal predictor de fracaso trabajando con una IA. Porque la IA no tiene problema en producir cosas que no entiendes. La cantidad de código que un agente escribe en una hora supera por amplio margen tu capacidad de revisarlo. Si no preguntas, pierdes el control.

Programar con una IA no es programar como antes. Sarkar y colegas (2022) sostienen que la interacción con modelos de lenguaje grandes constituye una clase de actividad cognitiva genuinamente nueva — distinta del autocompletado clásico y del copy-paste desde foros. Es un diálogo. Y en un diálogo, no preguntar no es modestia: es perder la conversación.

Cuando preguntas lo obvio pasan tres cosas:

• Aprendes. La IA actúa como tutor técnico síncrono: te explica qué hace un comando, qué implica una decisión de arquitectura, qué riesgo tiene una opción. Cada interacción deja un sedimento de conocimiento que se acumula.
• Descubres problemas. En la práctica real, los errores más caros se esconden detrás de cosas "obvias" que nadie cuestionó. Una base de datos expuesta a internet, un bind que abre un puerto que no tocaba, un default de seguridad invertido. Si no preguntas qué significa cada salida de un comando, no aparecen.
• Abres la conversación. Preguntar habilita pedir alternativas. Y pedir alternativas es donde se gana la batalla técnica.

Las preguntas que valen la pena

Cuando el agente te propone una decisión técnica, hay tres preguntas que tienes que poder hacerle siempre. No importa si te sientes inseguro haciéndolas. Si nadie te ve, mejor; si te ven, también:

1. "¿Qué significa exactamente esto?" — Aplica a salidas de comandos, errores, decisiones de configuración, librerías que va a usar, propiedades CSS que aparecieron de la nada. Cualquier cosa que no podrías explicar en voz alta a un compañero.
2. "¿Qué alternativas tengo?" — Casi nunca hay una sola forma de hacer algo. Pedirle al agente que liste 2 o 3 alternativas con sus pros y contras te da material para decidir con criterio en vez de aceptar el default. Esto vale especialmente para elecciones que vivirán mucho tiempo:

• Base de datos — ¿relacional o documental? Si relacional, ¿PostgreSQL, MySQL, SQL Server? ¿Por qué? ¿Qué pasa cuando la base crezca a millones de registros? ¿Soporta lo que necesito en términos de geolocalización, búsqueda full-text, transacciones?
• API (Application Programming Interface, la "puerta de entrada" programática a un sistema) y API gateway — ¿necesito un gateway? ¿Kong, Tyk, AWS API Gateway, nginx con módulos? ¿Qué problema concreto resuelve y a qué costo de complejidad operativa?
• Lenguaje de programación y framework — ¿Node.js con NestJS o Express? ¿Python con FastAPI o Django? ¿.NET con C#? ¿Go, Rust? ¿Qué sé yo mantener? ¿Qué comunidad y ecosistema hay en mi país para soporte y contratación?
• Frontend — ¿Next.js, Remix, Astro, SvelteKit? ¿SSR (Server-Side Rendering, el HTML se arma en el servidor y llega listo al navegador) o SPA (Single-Page Application, una sola página que el navegador rellena dinámicamente con JavaScript)? ¿Qué tan rápido carga? ¿Cómo se construye un sistema de componentes?

3. "¿Por qué la opción que elegiste es la mejor para este caso?" — Fuerza al agente a defender su recomendación. No te conformes con "es lo que se usa". Pídele criterios concretos relativos a tu proyecto: tamaño esperado, equipo de mantenimiento, presupuesto, restricciones legales, tiempo hasta producción.

Si te tomas en serio estas tres preguntas, cada decisión técnica importante de tu proyecto va a estar registrada como un ADR (Architecture Decision Record) en tu repositorio: qué decidimos, por qué, qué alternativas descartamos. Es uno de los hábitos que más valor añade.

Hacer preguntas "tontas" es, en realidad, el acto más sofisticado del Tech Lead. Long y Magerko (2020) identificaron 17 competencias de lo que llamaron AI literacy — alfabetización en IA —, y entre las más importantes están la capacidad de evaluar críticamente lo que un sistema de IA produce y la de colaborar con él de manera consciente. Esas competencias no se enseñan en una clase: se construyen preguntando.

Tienes el rol y la actitud. Falta saber dónde vive el producto.

Cubrimos en esta primera parte dos cosas que valen oro: el rol completo del god stack developer dirigiendo el ciclo entero del producto, y la actitud que sostiene ese rol — atreverse a quedar como un tonto, preguntar lo obvio cada vez. Con eso solo, una persona puede entregar software completo y profesional. Hasta hace poco, esa frase habría sonado a ciencia ficción.

Pero queda mucho por bajar al concreto. ¿Dónde vive el software que estás dirigiendo? ¿Qué pasa cuando el Coding Agent se equivoca — que se va a equivocar? ¿Qué piezas mínimas necesitas para llegar a producción? La segunda parte de esta serie responde esas tres preguntas en orden, con datos y ejemplos concretos.