grill (en espera)
me cuestiona el plan hasta que no quedan supuestos sueltos
$ grill-me "sección de agentes v2"
> ¿qué se rompe si no lo hacemos?
> ¿quién lo mantiene en seis meses?Fronteras explícitas y sistemas que se pueden explicar. Sin humo.
Situaciones reales que viví, el problema, la decisión que tomé y por qué.
contexto primero · spec antes que código · review humano
Uso spec-driven development para trabajar con agentes. El plan se discute, se pone a prueba y se escribe con sus restricciones antes de que exista una línea de código. La implementación se verifica contra ese plan, y lo que no pasa la revisión vuelve a planificarse. Estoy convirtiendo ese proceso en una cadena de agentes especializados, que hoy pruebo en mis propios proyectos.
me cuestiona el plan hasta que no quedan supuestos sueltos
$ grill-me "sección de agentes v2"
> ¿qué se rompe si no lo hacemos?
> ¿quién lo mantiene en seis meses?un planner redacta el plan y un critic intenta romperlo
$ endev-plan
✓ .plans/home-polish.md
critic · 0 bloqueanteslos agentes implementan por olas, cada uno en su área
$ endev-execute .plans/home-polish.md
✓ ola 1 · web-frontend ×2 · worker
✓ ola 2 · seo-aeotests de integración sobre las uniones entre tareas
$ endev-test .plans/home-polish.md
✓ e2e + axe · light y darkpuntúa de 0 a 100 contra el plan. Bajo 90 vuelve al plan y se corrige
$ endev-review .plans/home-polish.md
! ronda 1 · 84/100 · 3 hallazgos
✓ ronda 2 · 93/100valida, ordena los commits y hace push
$ endev-ship .plans/home-polish.md
✓ tsc · eslint · knip · tests
✓ pushedIncidentes reales, decisiones de arquitectura y herramientas de IA. Las escribo cuando ya sé por qué se rompió.
No solo lo de hoy: herramientas y patrones de proyectos y notas a lo largo de los años. No es un muro de logos — es un mapa de lo que usé, uso y seguiría eligiendo. Pasa el cursor para ver el patrón detrás.
04
Spec-driven development, agent skills, MCP servers — IA aplicada en producción, no solo RAG.
Spec-driven development, agent skills, MCP servers — IA aplicada en producción, no solo RAG.
Spec-Driven Development (SDD)
Escribo la spec antes de que el agente escriba código — Grill.me interroga el plan hasta resolver cada rama, después un agente nuevo construye contra esa spec.
pasa para inspeccionar
# spec.md
## Requirements
## Acceptance criteria
// the agent implements against this, not vibesClaude Code · Cursor
Código agéntico a diario — de Tab en Cursor a workflows de agentes completos con skills propias.
/anti-cliche # custom skill, runs before every commitMCP Servers
Conectar agentes a datos en vivo — el contenido de este sitio sale de un servidor MCP de Sanity.
claude mcp add Sanity -t http https://mcp.sanity.ioAgent Skills · Multi-agent
Flujos multi-agente estilo Grill.me — un agente interroga el plan, otro lo construye.
phase-1.md → new conversation → phase-2.md
# context reset between phasesContext Engineering
Dividir planes grandes en fases antes de que el contexto se llene a mitad de tarea.
# plan.md
## Phase 1: schema
## Phase 2: API
## Phase 3: UIRAG · LangChain
Búsqueda semántica sobre conocimiento interno.
const docs = await retriever.invoke(question);
return llm.stream({ docs, question });Vector Search
Embeddings + pgvector para discovery.
select 1 - (embedding <=> $1) as score
order by score desc;De frontend freelance a liderar producto, plataforma e IA aplicada. Cada paso dejó algo que sigo usando.
2026
Rol senior con foco en producto
Me interesa un rol donde el criterio técnico se traduzca en producto. Quiero construir cerca del cliente, tomar decisiones de arquitectura con contexto real y hacer crecer al equipo. Ya he liderado productos y equipos, y quiero que esa experiencia tenga más alcance.
Cerca del cliente, cerca del código
Si llegaste hasta aquí, probablemente quieras saber un poco más de mí. Llevo muchos años construyendo software y todavía me importa lo mismo que al principio, ver una idea convertirse en algo que realmente funciona.
El código es solo una parte del trabajo. A veces toca pensar producto, otras arquitectura, revisar un deploy o quedarme hasta entender por qué algo que funcionaba ayer dejó de funcionar hoy. Así es producción. Tiene personalidad propia.
También disfruto ayudar a otros a crecer. Un buen code review no solo dice qué está mal, deja a la otra persona entendiendo algo que antes no entendía.
Me interesa entender el problema, discutir las decisiones cuando hace falta y encontrar la forma más simple y sólida de llevarlo a producción.
Trabajo principalmente con TypeScript y Node.js, y sigo de cerca lo que pasa con IA y agentes porque el trabajo está cambiando rápido. Adopto herramientas nuevas cuando realmente mejoran el producto, el equipo o la forma en que trabajamos.
Estoy terminando Ingeniería de Sistemas, aunque mi carrera no esperó al título. La mayor parte de lo que sé lo aprendí construyendo y equivocándome en sistemas reales.
Abierto a nuevos proyectos, desafíos técnicos y colaboraciones donde el problema sea real, seas recruiter, founder o colega engineer. Escribe por el formulario o al email de esta página. Trabajo desde Buenos Aires (GMT-3) y respondo en español o inglés.