// workshop equipo de dev
IA en el equipo de dev
No una clase de teoría. Una serie de recetas que sales e implementas.
por qué importa
Sin sistema, la IA agrega ruido
- ✕Código que nadie entiende, mergeado igual.
- ✕Alucinaciones (APIs, precios) que se cuelan.
- ✕Refactors que nadie pidió.
La regla de toda la charla: gana el equipo con sistema, no el que tira más prompts.
analogía
Un cirujano brillante que a veces confunde el bisturí con la cuchara. Y no te avisa cuándo.
// el modelo es genial en unas tareas y peligroso en otras, verifica más donde eres junior
cómo leer esta charla
Cada tema es una receta
- →Título = la acción que vas a hacer.
- →Pasos numerados para seguir.
- →Un criterio de éxito al final.
Objetivo: que el lunes puedas implementar, no solo entender.
$_
manos a la obra
El kit, en comandos
Instala esto primero. Todo verificado contra la doc oficial.
el kit
Tres comandos y estás adentro
# Claude Code, mac / linux / wsl
$ curl -fsSL https://claude.ai/install.sh | bash
# Windows PowerShell
> irm https://claude.ai/install.ps1 | iex
$ cd tu-repo && claude
Codex CLI y Gemini CLI se instalan igual. El terminal es el punto de entrada.
el modelo
El modelo por tarea, en una tecla
› /model # selector, eliges con flechas
# fijarlo por proyecto → .claude/settings.json
{ "model": "claude-sonnet-5" }
$ claude --model opus-5 "..."
Tier alto para lo difícil, bajo para lo mecánico.
una skill
Una capacidad reusable: caveman
# .claude/skills/caveman/SKILL.md
---
name: caveman
description: Responde comprimido, sin relleno
---
Recorta preámbulo. Bullets, no párrafos.
Se comitea al repo, la usa el equipo. La invocas con /caveman.
spec-driven
Acuerda el qué antes del código: OpenSpec
$ npm i -g @fission-ai/openspec@latest
$ openspec init
› /opsx:propose add-rate-limiting
› /opsx:apply # implementa contra la spec
› /opsx:archive # registra lo hecho
La spec vive en git, no en un prompt que se pierde.
manos al modelo
Dale manos al modelo
$ claude mcp add --transport http docs https://mcp.ejemplo.com/mcp
$ claude mcp list
# o commiteable para el equipo → .mcp.json
{ "mcpServers": { "docs": { "type": "http", "url": "..." } } }
Dev y prod separados, secretos por variable de entorno.
comandos del día
Los que usas todo el tiempo
/plan
Plan mode: propone y lo revisas antes de ejecutar.
/clear · /compact
Limpiar o comprimir el contexto entre tareas.
/init · /agents
Crear el CLAUDE.md · subagentes para lo paralelo.
/context · /code-review
Ver contexto · revisar el diff con IA.
A
bloque a
Usar la IA con criterio
El loop de trabajo que evita el ruido.
el loop
Seis pasos por cada tarea
- 115 min de hipótesis propia, sin IA.
- 2Escribe la spec en bullets.
- 3Elige el modelo por tarea.
- 4Deja que implemente contra la spec.
- 5Lee cada línea del diff.
- 6Corre los tests, pide evidencia.
Si empiezas por la IA, tercerizas el pensamiento. La usas como challenger, no como solver.
analogía
No usas un martillo neumático para colgar un cuadro.
// cada tarea, su modelo. El grande por default es plata tirada
por tarea
Enruta por tarea, ahí está el ahorro
tier alto
Arquitectura, trade-offs
Acá sí pagas razonamiento.
tier medio
Endpoint contra un patrón
Rutina con contexto claro.
tier bajo
Renombrar 40 archivos, boilerplate
Mecánico, mucho volumen.
contexto masivo
Leer 200 páginas y comparar
Mucho input, poco razonamiento.
En producción lo hace un router (LiteLLM / OpenRouter) por request.
no confíes
El modelo alucina con total confianza
- 1Syntax de librería: contra la doc real, no de memoria.
- 2Precios, specs, versiones, fechas: búsqueda fresca.
- 3Si no verificaste, marca [unknown].
"Doble check" = leer la fuente, no volver a preguntarle al modelo.
analogía
Te da la hora con total seguridad. Con un reloj parado.
// verifica contra la fuente, no vuelvas a preguntarle al modelo
el plan primero
Research → Plan → Implement
- 1Research: el agente lee en solo-lectura, vuelca research.md.
- 2Plan: trocea en pasos verificables, sale plan.md revisable.
- 3Implement: ejecuta paso a paso corriendo tests.
Revisa el plan, no el código. Corregir un plan es barato; el código, caro.
analogía
Corregir el plano cuesta un borrador. Corregir la casa cuesta demoler.
// por eso el orden es research, plan, revisar el plan, implement
dos ojos
Dos capas antes del merge
- 1Tú lees cada línea. Si no la entiendes, no la mergeas.
- 2Un agente reviewer en contexto limpio audita el PR (/code-review).
El que escribe ≠ el que audita. Herramientas: CodeRabbit, Greptile, Graphite.
parsimonia
¿Agente o lo haces directo?
Agente sí
- >5 archivos
- Research multi-fuente
- Paralelo real e independiente
Agente no
- Single-file
- Lookup directo
- <3 llamadas
Si es más rápido hacerlo directo, hazlo directo.
aburrido a propósito
La IA tiende a lo verboso. Recorta.
- ·Comments solo donde el WHY no es obvio, nunca el WHAT.
- ·Naming semántico > comentario.
- ·Ifs planos (dicts, early return) > anidados.
Código aburrido > código clever.
B
bloque b
Construir features de IA
El LLM como componente no-determinista de tu sistema.
lo básico bien
Lo básico, bien hecho
- 1Elige modelo por tarea y costo, no el más grande.
- 2Pide structured output con schema, no parsees texto libre.
- 3Maneja tokens, latencia y rate limits desde el diseño.
El producto arranca en una necesidad real, no en "metamos IA".
recuperar bien
Implementar RAG
- 1Chunkea los documentos.
- 2Indexa con hybrid: BM25 + embeddings.
- 3Recupera un top amplio.
- 4Rerank a los 5 mejores (cross-encoder).
- 5Genera citando las fuentes.
El 80% de la calidad está en la recuperación. Mídelo con un golden set.
rag, cuándo subir de nivel
GraphRAG y memoria
- →GraphRAG: recupera sobre un grafo, para preguntas multi-hop entre entidades.
- →Memoria: short-term (la sesión) vs long-term (persistente).
Suman infra y costo. Úsalos cuando el RAG plano falla, no por default.
agente o cadena
Modelo + herramientas + loop
- 1¿Camino fijo? → una cadena, no un agente.
- 2¿Hay que decidir pasos? → agente con tool-use.
- 3¿Estado complejo? → framework: LangGraph, CrewAI, Pydantic AI.
No metas un agente donde una función alcanza. El no-determinismo se paga en debugging.
sin fe
Sin esto es fe, no ingeniería
- 1Arma un golden set: entradas + respuesta esperada.
- 2Corre el sistema sobre cada caso.
- 3Puntúa: exacto, o LLM-as-judge con criterio escrito.
- 4Gatea en CI: un cambio no debe bajar el score.
Tracing: Langfuse, LangSmith, Braintrust. El trace es el objeto primario.
sin datos, es fe
Sin evals, «funciona» es una opinión, no un dato.
// un golden set convierte la opinión en una métrica que se puede romper
los frenos
El no-determinismo es del modelo. La robustez, tuya.
- 1Grounding: cita fuentes, ancla a datos reales.
- 2PII: qué entra al prompt y qué nunca sale.
- 3Costo y latencia: presupuesto por request, fallback.
- 4Timeouts: qué pasa cuando el modelo falla o tarda.
analogía
El modelo es el motor. Los guardrails son los frenos. Nadie maneja sin frenos.
// el no-determinismo es del modelo; la robustez es tuya
caro o lento
Caro o lento no sirve, aunque funcione
- 1Routing: modelo chico por default.
- 2Caché: prompt caching y respuestas repetidas.
- 3Streaming: baja la latencia percibida.
- 4Presupuesto: tope por request + fallback.
último recurso
Último recurso, no el primero
- 1Prueba prompting.
- 2Si no alcanza, RAG.
- 3Solo entonces fine-tuning (LoRA / PEFT, barato).
Fine-tune si: estilo muy consistente, dominio cerrado, o un modelo chico que imite a uno grande.
a producción
De tu máquina a algo que aguanta usuarios
- 1Conteneriza: Docker, misma imagen en dev y prod.
- 2Deploy: serverless (Cloud Run) o K8s.
- 3Día uno: secretos, health checks, escalado, observabilidad.
GPU solo si sirves tu propio modelo; con APIs, no hace falta.
qué no delegar
La IA propone. El equipo decide y responde.
- ✕Decisiones de arquitectura.
- ✕Límites de datos y PII.
- ✕La verificación de correctitud.
C
bloque c
IA a escala: muchos proyectos
Cuando el equipo comparte el criterio, no cada uno el suyo.
el repo listo
Deja el proyecto listo para IA
- 1AGENTS.md / CLAUDE.md en la raíz: contexto y reglas.
- 2docs/adr/: decisiones cerradas que no reabre.
- 3docs/specs/: un SPEC.md por feature.
- 4.claude/skills/: skills del equipo versionadas.
AGENTS.md es estándar formal (Linux Foundation), 20+ herramientas lo leen.
nuevo o existente
Según el caso
Proyecto nuevo
- Docs-first: contexto antes que código
- AGENTS.md + un ADR de stack
- Una skill base
Proyecto existente
- Agrega la capa de contexto, no reescribas
- AGENTS.md corto + ADRs de lo decidido
- Skills para las tareas repetidas
el arnés
Infrastructure-first, antes del rollout
- 1Un CLAUDE.md/AGENTS.md por capas, comiteado.
- 2Skills del equipo en el repo, no dotfiles personales.
- 3MCP compartido: mismas herramientas para todos.
- 4Multi-repo: un bootstrap repo con el manifiesto de todos.
Los equipos que montaron el tooling antes adoptaron más rápido.
en paralelo
Fan-out → reduce → synthesize
- 1Subagentes: contexto propio, reportan el resultado.
- 2Verificador adversarial: ve solo el diff antes de mergear.
- 3Git worktrees: un working dir por agente, sin pisarse.
3-5 worktrees simultáneos: el mayor unlock de productividad, y casi nadie lo usa.
analogía
Dos carpinteros, un solo banco. Se pelean por el torno. Dale un banco a cada uno.
// un git worktree por agente: mismo repo, working dir propio
que no reabra
Que la IA no reabra lo que ya decidiste
- 1ADR ejecutable: gatea en CI/hook, no solo informa.
- 2Un dueño (DRI) del harness y las convenciones.
- 3Métricas: utilización · impacto · costo (DORA no basta).
código de terceros
Una skill o un MCP es código de terceros
Supply chain
~36% de skills con algún fallo; 30%+ de MCP con vuln. Vétalos como dependencia.
Prompt injection
Instrucciones ocultas que secuestran al agente. Filtra y loguea entre input y ejecución.
Aísla la ejecución
Código de agente en microVM (Firecracker) o gVisor, no en tu host.
Secrets
Nada de creds en el contexto; dev y prod nunca comparten.
analogía
Una skill sin vetar es una dependencia sin auditar.
// skill y MCP son código de terceros ejecutable, trátalos como tal
qué evitar al escalar
Mes 1 eléctrico, mes 6 más lento
- ✕Accept-without-read: la verificación colapsa en cascada.
- ✕El 80% problem: falta rate limiting, retries, observability, PII.
- ✕Kitchen sink session: tareas mezcladas → /clear.
analogía
La IA es una tarjeta de crédito. El gasto es hoy, la cuenta llega en el mes 6.
// velocidad prestada. El interés es deuda técnica sin criterio
Z
arranque
El lunes
Lo que el equipo aplica ya, sin permiso de nadie.
checklist, 10 reglas
Copiar y pegar en el README del equipo
0115 min de hipótesis propia antes de la IA.
02Modelo por tarea, no el más caro.
03Spec antes del prompt, aunque sean bullets.
04Imperativo: debe / nunca / pregunta.
05Verifica syntax, precios y fechas contra la fuente.
06Si no verificaste, marca [unknown].
07Lee cada línea del diff; si no la entiendes, no mergeas.
08Agente solo si >5 archivos o paralelo real.
09Código aburrido: sin comments de WHAT.
10Registra decisiones (ADR), no re-litigues.
profundiza
Esto fue el mapa. La profundidad, en el curso
Agentes, tools y MCP, RAG, evals y observabilidad, producción y deploy, paso a paso.
# curso completo
dev.jotive.com.co/learn/ai-agents
cierre
El sistema > la herramienta
Empieza chico: una tarea real esta semana con spec + verificación + leer el diff.
seguimos en contacto
Sígueme
# notas técnicas y proyectos
web dev.jotive.com.co
# instagram
ig @jotive.dev