AI Adoption Program 2026 · Desarrollo
Dejá de escribir código con ayuda. Diseñá el sistema que lo escribe.
Los conceptos que necesitás para construir tu propio ecosistema agéntico de desarrollo.
Punto de partida
De asistente a ecosistema
Arrastrá el divisor para comparar
- Le pedís un fragmento de código
- Copiás, pegás, probás… y volvés con el error
- El contexto lo explicás vos, cada vez
- Verificación 100% manual
- Agentes que leen el repo, editan y ejecutan
- El contexto del proyecto ya está escrito
- La IA verifica su trabajo con tests y build
- Vos decidís en los puntos que importan
El salto no es de herramienta.
Pasás de escribir código con ayuda a diseñar y supervisar un sistema que lo escribe.
El objetivo
Potenciar cada fase del ciclo de vida
Especificar
Planificar
Construir
Verificar
Documentar
Entregar
Ningún concepto es teoría suelta:
cada uno resuelve un problema real en alguna fase del desarrollo.
Bloque 00 · Fundamentos
Cómo piensa
un LLM
Antes de construir el ecosistema, entendé la materia prima.
Un LLM predice,
no consulta.
Genera texto pieza por pieza, eligiendo lo más probable. No busca en una base de datos ni "recuerda" tu proyecto.
Casi todo lo que vas a ver después existe para compensar estas tres consecuencias.
Tokens y ventana de contexto
Todo lo que sabe
entra acá.
- Token
- La unidad en que procesa texto: ≈ un fragmento de palabra.
- Ventana de contexto
- El máximo de tokens que puede considerar a la vez.
Scrolleá para llenar la ventana
Costo y velocidad se miden en tokens.
Más contexto: más caro y más lento.
Probabilístico vs. determinístico
Una instrucción es una sugerencia.
Un test es una garantía.
El modelo
Razona, interpreta y se adapta a lo nuevo. Puede variar, omitir un paso o equivocarse.
El código
Hace siempre exactamente lo mismo. No interpreta, no se olvida, no se cansa.
Regla de oro: si algo tiene que pasar siempre, no se lo pidas al modelo. Hacelo determinístico.
Alucinaciones
Si no tiene el dato,
inventa algo que suena bien.
// Reembolsar todos los pagos del cliente
import { payments } from '@acme/sdk'
const r = await payments.refundAll({
customerId, force: true
})Qué no funciona
Escribir "no inventes" en el promptConfiar en el tono seguro
Qué sí funciona
- Darle la fuente real: docs, código, MCP
- Que compile y corra tests: el error aparece solo
- Pedirle de dónde sale cada dato
- Revisión humana en los puntos críticos
Las alucinaciones no se evitan pidiendo: se controlan dando fuentes reales y formas de verificar.
Bloque 01 · El agente y su harness
Un modelo habla.
Un agente hace.
Para pasar de la palabra a la acción, el modelo necesita un loop y un cuerpo.
El loop agéntico
¿Quién hace
el loop?
Lee archivos, ejecuta, mira el resultado y sigue hasta terminar… o trabarse.
Tu rol cambia: de ejecutar cada paso a definir
Tool use y harness
Mismo modelo, distinto harness,
distintos resultados.
Tool use — el mecanismo por el que el modelo pasa de hablar a hacer: pide ejecutar una herramienta.
Configurar bien el harness es la mitad del trabajo.
Qué modelo para qué tarea
Poné el modelo más capaz
donde el error es más caro.
Un error en la spec se arrastra y crece en todo lo que sigue.
Bloque 02 · Contexto
¿Sabe lo que
necesita saber?
El agente ya puede actuar. Ahora, la pregunta es con qué información.
Context engineering · la habilidad central
Con agentes, lo segundo pesa mucho más.
Ante un mal resultado, preguntate primero: ¿el agente tenía la información para hacerlo bien?
logger.error, no console.loglogger.error, no console.log…- # Stack y qué hace el proyecto
- # Estructura de carpetas no obvia
- # Convenciones de código concretas
- # Comandos de build, test y lint
- # Lo que nunca se debe hacer
- + Errores:
logger.error, nuncaconsole.log
AGENTS.md · la memoria del proyecto
Si lo corregís dos veces,
va al AGENTS.md.
Un archivo en la raíz del repo que el agente lee siempre, antes de cualquier tarea. En Claude Code: CLAUDE.md.
Usamos buenas prácticas y código limpio.- Tests: Vitest, en __tests__/ junto al módulo
- Validar: npm run test && npm run lint
- Errores: try/catch + logger.error
- No modificar /legacy sin aprobaciónProgressive disclosure
Cargar solo lo necesario.
AGENTS.md corto y general. El detalle, en skills que se cargan solo cuando hacen falta. Así podés tener decenas sin llenar la ventana.
Bloque 03 · Spec-Driven Development
Especificar antes
de construir
Un agente ejecuta lo que le decís. No lo que quisiste decir.
La spec es el contrato
Todo lo que sigue se mide contra ella.
Qué tiene una buena spec
Seis piezas.
Sin huecos.
ya hecho
El puente con análisis funcional: si la historia de usuario ya trae estos seis puntos, el agente arranca con la mitad del trabajo hecho.
- Qué se construyeEn 2–5 oraciones, sin jerga interna.
- ActoresQuién lo usa, quién lo dispara, qué sistemas intervienen.
- Flujo principalLos pasos en orden, sin huecos.
- Casos bordeDatos inválidos, vacíos, límites.
- Fuera de scopeLo que explícitamente no se hace ahora.
- Criterios de aceptaciónVerificables: cómo sabemos que está bien.
Bloque 04 · Capturar conocimiento
"Cómo hacemos
las cosas acá"
Lo que sabe el equipo no puede depender de la memoria de nadie.
---
name: crear-endpoint
description: Convenciones para crear
endpoints REST en este proyecto.
Usar al agregar o modificar uno.
---
# Crear un endpoint
1. Controller en src/controllers/
2. Validar el input con el schema
3. Test de integración obligatorio
4. Documentar en docs/api.mdSkills
Conocimiento del equipo que cualquier agente aplica, siempre igual.
Jugá · ¿AGENTS.md, skill o hook?
¿Dónde va esta regla?
Siempre aplica: AGENTS.md. Aplica a una tarea: skill. No puede fallar nunca: hook.
Bloque 05 · MCP y seguridad
Conectar el agente
con tus sistemas
Tu código no vive solo. El agente tampoco debería.
Model Context Protocol
Una skill le enseña cómo.
Un MCP le da la capacidad.
Un estándar abierto. Cada servidor MCP expone herramientas —leer un ticket, correr una colección, abrir una página— que cualquier agente compatible puede usar.
$ codex mcp add chrome-devtools \
npx chrome-devtools-mcp@latestEl riesgo de conectar · prompt injection
Todo lo que lee es
potencialmente una orden.
El agente no distingue bien entre tus instrucciones y el texto que lee. Un ticket, un README o una web pueden traer instrucciones escondidas.
Agregar filtro por fecha en el listado de pagos
Como operador, quiero filtrar los pagos por rango de fechas para conciliar más rápido.
Con datos de clientes, esto no es opcional.
Bloque 06 · Delegar
Un equipo de agentes.
Con reglas.
Subagentes, permisos mínimos y los puntos donde decide una persona.
Subagentes y orquestación
Para aislar y especializar,
no para tener "más IA".
Qué aportan
Contexto aislado: el ruido queda afuera
Instrucciones, modelo y permisos propios
Qué cuidar
Consumen más tokens
No pueden preguntarte a mitad de tarea
Editar en paralelo genera conflictos
Sandbox y permisos
Mínimo privilegio.
Que alcance.
Dale a cada agente el permiso mínimo para su tarea, y verificá que ese mínimo alcance para completarla.
Human in the loop
¿Dónde decide el humano?
El checkpoint más valioso: aprobar el plan antes de que se escriba una sola línea de código.
Bloque 07 · Verificar y garantizar
De "confío en el modelo"
a "está garantizado"
Delegar sin verificar es apostar.
Feedback loop
Un agente que se verifica,
se corrige solo.
Uno que no puede, te entrega el error a vos.
Lo más valioso que le podés dar a un agente es una forma de saber si lo hizo bien.
Hooks
Garantías que no dependen del modelo.
Un hook ejecuta una acción automáticamente cuando ocurre un evento. No depende de que el modelo "se acuerde".
rm -rf · push directo a mainBLOQUEADOLas reglas que "nunca se rompen" no se escriben en un prompt: se implementan como hook.
Revisión
El agente no se
aprueba a sí mismo.
Quien escribió el código no es el mejor revisor. Tampoco cuando es un agente.
Bloque 08 · Medir, operar y compartir
Lo que no se mide
no mejora.
Y lo que no se comparte, no escala.
Evals
Cambiaste una skill.
¿Mejoró o empeoró?
Un eval es un conjunto de casos con el resultado esperado, que corrés antes y después de cada cambio.
Mismo puntaje… ¿da igual?
Operar agentes en serio
Si no se puede auditar ni costear,
no escala.
Agentes sin humano en el pipeline: revisar PRs, generar tests faltantes, triage de issues.
Reconstruir qué hizo el agente, con qué contexto y qué aprobó cada persona.
Cada token cuesta. Modelos grandes donde aportan; los subagentes multiplican el consumo.
Compartir
De configuración personal
a ecosistema de empresa.
Un plugin empaqueta skills, subagentes, hooks y MCPs en una unidad instalable y versionada.
Cada dev tiene su versión del kit
Las mejoras no se propagan
Nadie sabe cuál es la versión buena
El ecosistema de TSOFT se distribuye como un producto: versionado, instalable y con dueño.
Todo junto
El TSOFT AI Dev Kit
Cada pieza aplica los conceptos del recorrido
Ejercicio · aprender del propio kit
¿Qué está mal acá?
Cuatro problemas reales de la versión actual. Cada uno se entiende con un concepto del recorrido. Tocá cada tarjeta.
Diseñar un ecosistema es tomar decisiones como estas. Los conceptos te permiten detectarlas. Se corrigen en la próxima versión.
Por dónde empezar
Cinco pasos. Esta semana.
Completá el AGENTS.md de tu proyecto
Escribí la spec de tu próxima feature antes de pedir código
Asegurate de que el agente pueda correr tests y build
Convertí una convención de tu equipo en una skill
Recién ahí, usá el kit completo en una feature real
Lo que determina el resultado
El kit rinde en proporción
a lo que le das.
Movelo vos. Si una pieza falta, las otras no la compensan.
Simulador ilustrativo.
De escribir código con ayuda a diseñar y supervisar el sistema que lo escribe.
Contexto, specs y convenciones que cualquier agente aplica siempre igual.
El agente se verifica; hooks y revisiones cuidan lo que nunca puede fallar.
Armamos el ecosistema sobre un proyecto real.
El kit es el destino.
Los conceptos son el camino.
Dudas y consultas: canal del AI Adoption Program · TSOFT — MAKE IT REAL