El momento Limitless

En Limitless (2011), un escritor fracasado prueba una pastilla experimental — NZT-48 — que le permite usar toda su capacidad cognitiva. En cuestión de días aprende idiomas, domina el mercado bursátil, recuerda conversaciones que apenas escuchó y termina libros que llevaba años atascados. La promesa es simple: tienes el potencial dentro, solo necesitas activarlo.

Cuando aprendiste, en la primera parte de esta serie, a dirigir a una IA de extremo a extremo, te entregaron tu pastilla. La capacidad de ejecución del Coding Agent hace por tu trabajo lo que NZT-48 hizo por el protagonista de la película: vuelve realista hacer en una semana lo que antes tomaba meses. Pero ahí no termina la historia. NZT-48 sin una rutina, un equipo de apoyo y un lugar donde aterrizar las ideas es solo una promesa volátil. La pastilla por sí sola no abre cuentas en bancos, no firma contratos, no encuentra abogados, no opera servidores.

Esta segunda parte trata de eso. De cómo construir alrededor de la capacidad del Coding Agent todo lo demás que un producto necesita para vivir: el entorno donde respira (físico o en la nube), las prácticas que lo mantienen en pie cuando la IA se equivoca — porque se va a equivocar —, y la caja de herramientas concreta que sostiene la operación día a día. Tener el poder es el comienzo. Saber dónde usarlo y con qué es lo que separa al producto real del experimento personal.

Todo producto vive en un entorno

Es fácil olvidarse, pero el software no flota en el aire. Vive en un lugar físico (al menos hasta que alguien invente otra cosa) y ese lugar tiene costo, energía y dueño. Como Tech Lead, elegir el entorno donde vive tu producto es una de las decisiones más importantes que vas a tomar — y tiene consecuencias a mediano y largo plazo.

Hay dos grandes caminos:

Entornos en la nube

La opción por defecto hoy. Le delegas a un proveedor (Google Cloud, AWS, Azure, Vultr, Hetzner, DigitalOcean, Cloudflare) los servidores, la red, la electricidad, el aire acondicionado, la conectividad, la seguridad física. A cambio, pagas mes a mes en función de uso. Pros:

• Cero inversión inicial en hardware.
• Escalas hacia arriba o hacia abajo según demanda.
• Geografía distribuida desde el primer día.
• Backups, snapshots y recuperación ante desastre nativos.

Contras:

• Costo creciente con el tiempo y con el uso.
• Dependencia de un proveedor que puede cambiar precios o cerrar.
• Tus datos viven en infraestructura que no controlas.

Entornos físicos / on-premise

Cuando el cliente tiene restricciones legales, presupuesto operacional propio o requisitos de soberanía de datos, a veces conviene comprar el hardware: computadores cliente, servidores, switches, routers, UPS, cableado. El sistema vive en una sala que puedes pisar. Pros:

• Costo predecible una vez hecha la inversión inicial.
• Control total sobre dónde y cómo viven los datos.
• Cero dependencia de proveedores externos para operar.

Contras:

• Inversión inicial alta.
• Mantenimiento físico (hardware se rompe, hay que reemplazarlo).
• Escalar implica comprar más, no solo apretar un botón.
• Riesgos físicos: incendio, inundación, robo, electricidad cortada.

La mayoría de los proyectos modernos usan una mezcla: la aplicación principal en la nube (web, API), pero clientes físicos del lado del usuario (computadores, lectores, impresoras, dispositivos GPS) que hablan con esa aplicación. El Tech Lead tiene que entender ambos lados, y el agente puede ayudarte a hacer la comparación con números, pero la decisión la tomas tú.

Esta decisión no se toma en el aire: se toma dentro de procesos, equipos y ciclos cortos. Monsalves y colegas (2024), en un trabajo publicado por la Revista Chilena de Ingeniería, argumentan que la inteligencia artificial-como-servicio se acopla de manera natural a las metodologías ágiles porque permite a equipos pequeños iterar sin requerir infraestructura ni conocimiento técnico avanzado de antemano. Y en contextos latinoamericanos esa adopción ya está documentada: Scrum y sus variantes son el marco más utilizado en los proyectos regionales de desarrollo de software estudiados por Zúñiga-Tinizaray et al. (2024).

La IA no es perfecta — y por eso tu trabajo tiene sentido

Hay que decirlo de frente: Claude se equivoca. Inventa funciones que no existen. Propone esquemas de base de datos con cardinalidades invertidas. Olvida cerrar conexiones. Genera código que compila pero no hace lo que se pidió. Si esperas que la IA produzca código perfecto a la primera, te vas a frustrar y vas a abandonar el experimento. Vaithilingam, Zhang y Glassman (2022) mostraron que, si bien los usuarios consideran a Copilot un buen punto de partida, completan menos tareas de las esperadas porque depurar el código generado consume tiempo significativo. La expectativa choca con la experiencia. La cura no es dejar la herramienta — es saber esperar el choque y planificarlo.

Y el problema no es solo de tiempo: también es de seguridad. Pearce y colegas (2022) auditaron 1.689 programas generados por Copilot y encontraron que aproximadamente el 40 % contenía vulnerabilidades del Top 25 de CWE (Common Weakness Enumeration, el catálogo estándar de debilidades de software). Esto no significa que la IA sea peor que tú escribiendo código: Sandoval et al. (2023) reportaron que los usuarios asistidos por LLMs introducían bugs críticos de seguridad a una tasa apenas un 10 % superior al grupo control. La conclusión honesta: el riesgo proviene tanto del agente como del Tech Lead que no revisa.

La buena noticia: con el bucle correcto, la IA puede llegar a software de calidad profesional. El bucle correcto es:

1. Tests automatizados. El agente escribe el código y los tests al mismo tiempo. Los tests fallan, el agente los lee, corrige el código, vuelve a correr los tests. Repetir hasta verde.
2. Auto-debugging. Cuando algo falla en runtime, el agente puede ver el stack trace, leer el log, ejecutar pruebas puntuales, formular hipótesis y probarlas. Es notablemente bueno en eso, siempre que tenga las herramientas a mano.
3. Revisión humana del diff. Antes de aceptar un cambio, el Tech Lead lee el diff completo. Si hay algo que no entiende, vuelve a la regla del paper anterior — pregunta lo obvio. Nada se mergea sin que un humano lo entienda.
4. Validación con testers externos. Personas que no escribieron el código rompen lo que se construyó. Aparecen bugs que la IA no anticipó porque no conoce el contexto humano del usuario.

Como Tech Lead, tu trabajo en este bucle es modelar los problemas que aparecen para que se transformen en soluciones. Un bug reportado por el cliente rara vez viene como una especificación técnica. Viene como "el sistema se cae cuando intento guardar el pedido del jueves". Tu trabajo es traducir eso a algo que el agente pueda atacar:

• Reproduce el problema localmente o pídele al agente que lo intente.
• Aísla las variables (¿qué pedido? ¿qué usuario? ¿qué versión?).
• Formula una hipótesis: "creo que es porque el endpoint POST /orders no valida cuando la fecha cae en un día festivo".
• Pídele al agente que verifique la hipótesis con un test específico.
• Si la hipótesis era correcta, ya tienes la corrección casi escrita.

Este ejercicio de "transformar problemas en soluciones" es lo que hace que proyectos lleguen a tiempo. Y respecto a "a tiempo": tu carta Gantt (cronograma) es un compromiso con el cliente. La velocidad del agente IA hace que sea realista entregar en semanas lo que antes tomaba meses, pero no se cumple solo. Se cumple porque alguien lleva registro de lo que se prometió, lo que está listo y lo que falta, y porque ese alguien sabe convertir cualquier sorpresa en un siguiente paso concreto.

La caja de herramientas del Tech Lead

Llegar a un sistema en producción con una IA dirigida exige una pequeña orquesta de herramientas que se hablan entre sí. Te muestro las categorías y un puñado de ejemplos concretos para que tengas referencias. Ninguna es obligatoria, pero la categoría sí lo es: si alguna capa no la cubres con una herramienta, vas a sentirla.

Mira esta lista de otra forma: cada categoría es un miembro del equipo que normalmente costaría contratar. Notion es la secretaria que recuerda todo lo que hablaste con el cliente. GitHub es el archivero que conserva cada versión del proyecto. Claude Code es el desarrollador senior que escribe el grueso del código. Cloudflare es el jefe de seguridad de borde. UptimeRobot es el operador de guardia que te despierta cuando algo se cae. Vultr o Hetzner es el hosting que paga el sysadmin. La diferencia es que tu staff completo cuesta menos de cincuenta dólares al mes y trabaja sin fricción entre roles. Aprender a coordinarlos es ser tu propio equipo.

1. El Coding Agent

El motor. Hoy, Claude (y especialmente Claude Code) es probablemente el más capaz para el flujo descrito en esta serie — dirige proyectos de software de extremo a extremo, lee archivos, ejecuta comandos, navega el repositorio. Hay alternativas: Cursor, Codex, Copilot. Prueba una, fórmate un criterio.

2. Repositorio de código

GitHub es el estándar. GitLab y Bitbucket son alternativas serias. Gitea si quieres autoalojarlo. Cualquiera sirve. Lo que no es opcional es tener un repositorio versionado desde el primer commit. Sin esto, todo lo que construyas con la IA está a un rm -rf de evaporarse.

3. IDE multilenguaje

IDE significa Integrated Development Environment — entorno integrado de desarrollo, el editor donde escribes, navegas y depuras código. Visual Studio Code es la elección razonable: gratuito, multiplataforma, extensible, con integración nativa para muchos de los asistentes IA. Si vienes de un mundo Java o C# clásico, JetBrains (IntelliJ, Rider) son alternativas más pesadas pero más completas. El punto es: el IDE es donde vas a leer y validar lo que el agente escribe. Tienes que sentirte cómodo en él.

4. Edge, DNS y seguridad de borde

Cloudflare resuelve cuatro problemas en uno:

• DNS (Domain Name System) — la "guía telefónica" de internet que traduce tu-dominio.cl a la dirección IP del servidor donde vive tu sitio.
• TLS (Transport Layer Security) automático — el cifrado que hace que la barra del navegador muestre el candado (HTTPS).
• WAF (Web Application Firewall) — un cortafuegos que filtra peticiones maliciosas antes de que lleguen al servidor.
• CDN (Content Delivery Network) — caché de contenido distribuido por el mundo para que los usuarios reciban tu sitio desde un nodo cercano.

Para casi cualquier proyecto público, Cloudflare es la opción por defecto y empieza gratis. Alternativas: Fastly, Bunny CDN, AWS CloudFront.

5. Hosting y entornos

Para servidores tradicionales con control total: Vultr, Hetzner, DigitalOcean ofrecen VPS (Virtual Private Server, una máquina virtual dedicada a la que entras por terminal) desde unos pocos dólares al mes. Para deploys "serverless" (donde el proveedor te abstrae el servidor y solo subes código) o más automatizados: Vercel (Next.js), Fly.io (contenedores), Railway. Para producción a escala o proyectos con cliente corporativo: AWS (Amazon Web Services), Google Cloud (GCP), Azure (Microsoft).

6. Monitoreo de uptime y alertas

UptimeRobot hace una cosa simple y la hace bien: revisa que tu sitio responda cada cierto tiempo y te avisa si se cae. Hay un plan gratuito que alcanza para los primeros proyectos. Alternativas con más funcionalidades: BetterStack, Pingdom, Healthchecks.io. Lo único no negociable: no enterarte por el cliente de que el sistema está caído.

7. Memoria del proyecto

Las conversaciones con la IA son por defecto efímeras: cada sesión arranca en blanco. Para construir productos serios necesitas una capa donde vive el contexto del proyecto y que la IA pueda consultar. Notion es el caballo de batalla aquí: brief, decisiones, actas, glosario, bitácora del Tech Lead. Alternativas: Confluence, Obsidian, Outline. Lo importante es que esté conectado al Coding Agent (vía integración, API o copia/pega estructurada) — sin eso, en cada sesión repites los mismos contextos.

8. Customización del Coding Agent — el caso de Claude Code

Las herramientas anteriores son las piezas externas que rodean al agente. Pero el agente mismo también se puede customizar — y mucho. Tomando como ejemplo concreto Claude Code (porque es el caso real que sostiene este marco), hay varios mecanismos de personalización que conviene conocer:

• CLAUDE.md — un archivo de instrucciones específicas que vive en la raíz del repositorio. Claude lo lee al inicio de cada sesión y lo usa como contexto permanente del proyecto. Allí van las convenciones del proyecto: stack tecnológico, reglas de naming, políticas de autorización, estructura de carpetas, comandos de build/test/deploy frecuentes, restricciones legales aplicables. Sin CLAUDE.md el agente funciona en frío; con un buen CLAUDE.md llega a entender el código como un miembro del equipo en su segunda semana.
• Memoria del usuario — preferencias estables del Tech Lead que Claude recuerda entre sesiones: lenguajes preferidos, estilo de comentarios, herramientas habituales, formato de respuestas. Se acumula con el uso y reduce la fricción de repetir contexto cada vez que abrís el editor.
• Skills — funcionalidades específicas que el agente activa según el contexto sin que tengas que pedírselas cada vez. Algunas nativas relevantes para el flujo del paper: navegación del código (lectura selectiva de archivos grandes), ejecución de comandos en shell, edición coordinada de múltiples archivos, búsqueda en la web, lectura de PDFs e imágenes, generación de presentaciones, documentos Word y planillas Excel, debugging asistido con reproducción de errores. Cada skill se invoca solo cuando hace falta — no saturan la conversación.
• MCP (Model Context Protocol) — el protocolo abierto que permite a Claude conectar con servidores externos para extender sus capacidades más allá del filesystem. Hay servidores MCP ya hechos para Notion (acceder a páginas, crear nuevas, actualizar contenido), GitHub (leer issues, abrir PRs), bases de datos (consultar y modificar tablas), Slack, Linear, Figma. También se pueden escribir servidores MCP propios para casos específicos del proyecto. Es la forma más potente de hacer que Claude opere realmente dentro de tu ecosistema, no solo con los archivos locales que ve.
• Hooks — scripts que se disparan automáticamente en eventos del flujo: ejecutar los tests cada vez que Claude edita un archivo, bloquear commits si el linter falla, escribir entradas en una bitácora del Tech Lead después de cada sesión, notificar a Slack cuando se mergea a main. Permiten codificar el "Bajo Revisión Activa" de la metodología OBRA en automatismos verificables.
• Slash commands personalizados — comandos cortos (/mi-comando) que ejecutan flujos repetitivos. Por ejemplo: /release que arma un changelog, sube la versión, genera el tag y abre el pull request — o /auditoria que corre una revisión de seguridad sobre los archivos modificados. Convierten rutinas largas en una sola pulsación.
• Subagentes — agentes especializados que el agente principal puede invocar para tareas específicas: un revisor de seguridad que audita código sensible, un investigador académico que busca papers verificables, un redactor técnico que escribe documentación con un estilo definido. Cada subagente tiene su propio system prompt y herramientas, y el agente principal los orquesta según el pedido del Tech Lead.
• Settings por proyecto — un archivo de configuración (settings.json en el directorio del proyecto o global) donde el Tech Lead puede ajustar permisos (qué comandos puede ejecutar la IA sin preguntar primero), allowlist de herramientas, modelo a usar, telemetría, ambientes de trabajo. Es donde se materializa concretamente cuánta autonomía tiene el agente para cada cliente.

No tienes que usar todas estas piezas para empezar. Pero conviene saber que existen. La diferencia entre un agente "de fábrica" y uno bien customizado para tu proyecto puede ser tan grande como la diferencia entre alquilar una oficina vacía y mudarte a una preparada con todas las conexiones, el catering y el equipo de soporte ya instalados. Y al igual que con la oficina, la customización vale más cuando la haces temprano — antes de acostumbrarte a las fricciones que cada herramienta te ahorra.

Tienes el entorno, tienes las herramientas. ¿Quién dirige?

Hasta acá vimos dónde vive el software (entornos), cómo convivir con la imperfección del agente (el bucle), y qué piezas mínimas conforman la caja de herramientas. Con eso, una persona sola puede entregar productos profesionales a clientes reales. Hasta hace poco, esa frase habría sonado a ciencia ficción.

Pero hay una pregunta que sigue abierta: ¿qué pasa cuando no eres una persona sola? La velocidad y el alcance del Coding Agent permiten algo que vale la pena nombrar: que un equipo multidisciplinario adopte el mismo patrón, cada miembro dirigiendo al agente desde su propia disciplina (finanzas, diseño, contabilidad, legal, marketing, operaciones). El poder no se suma — se multiplica. Y la coherencia del sistema final depende de cómo conversa el equipo, no de cuántos somos. De eso trata la tercera parte.