DavidIglesias
DavidIglesias

Navegación

Todavía no hay best practices

Leer en inglés

Introducción

Quiero enseñar cómo trabajo con IA en el día a día. No es una guía sobre cómo tienes que trabajar tú: es mi experiencia después de probar muchas de las herramientas que salen cada semana.

Todavía no hay una receta

Una de mis tesis principales es que a día de hoy no existen best practices. Tampoco hay un tooling mejor ni un workflow perfecto. Aún tenemos que probar y descubrir qué funciona, para qué y para quién. Compartir lo que hacemos y lo que nos funciona puede ayudarnos a acercarnos a ese objetivo.

Tampoco hay buen alignment ni consenso sobre cómo obtener buenos resultados. Hay mucho ruido y mucho humo: tokenmaxxing, lo que se vuelve viral esa semana o cualquier cosa que alguien publica porque queda bien. Yo también sufro el shiny object syndrome y eso me lleva a querer probarlo todo.

Opino que los frontier labs, los principales actores de esta revolución, todavía no ofrecen una guía clara.

El problema no suele ser solo el modelo

Cuando un agente me da malos resultados, casi nunca culpo al modelo. Muchas veces el problema es que no tengo clara la visión de lo que estoy construyendo, que la arquitectura no está bien diseñada o algo parecido.

Un setup que sigo ajustando

Cada semana pienso lo mismo: me gusta mi setup de Agentic Engineering, pero no lo amo. Hay cosas que me gustan y otras que no. Intento mejorarlo moviendo piezas con una filosofía sencilla: poder llevarme todo lo que hago a cualquier harness y depender de lo mínimo posible.

Por ahora, tengo claras dos cosas que seguirán en mi setup durante este año: Pi y Cloudflare. No pongo la mano en el fuego por nada más.

Ahora mismo uso Orca, que me parece tan buena como Herdr. Recomiendo las dos. Prefiero la terminal, pero una app sencilla ayuda cuando surge una emergencia. Si tuviera algo en remoto, usaría Herdr al 100%.

Workspace

Trabajar a nivel de workspace

Uno de los cambios más grandes ha sido dejar de trabajar a nivel de proyecto individual y pasar a trabajar a nivel de workspace.

Este workspace sigue la filosofía de un monorepo: todos mis proyectos están en el mismo sitio, bajo un solo AGENTS.md y con skills globales o de proyecto.

Personalmente, pienso que el monorepo es la mejor forma de hacer agentic engineering ahora mismo.

Dar contexto al workspace

En la raíz tengo un projects.toml. Define los proyectos, el stack, los aliases, el progreso y otros datos. Puedes crear el formato que quieras, con los campos que te sirvan: YAML, TOML, JSON, JSONL. La idea es tener un archivo que mantenga el estado y dé al agente el contexto mínimo para entender y trabajar con los proyectos desde un único sitio.

El AGENTS.md es uno de los archivos más importantes de cualquier harness. Importa tanto su contenido como la forma de plantearlo.

No voy a publicar el mío. Buscaos un poco la vida: pensad cómo podría ser vuestro AGENTS.md o projects.toml con lo que he contado y construidlo. Así también aprenderéis.

Dejo unas líneas de una versión anterior para que tengáis por dónde empezar:

# Agent Workspace

`~/fff-workspace` is the local workspace. Every project lives in a folder here and all work happens locally.

# Routing

1. Read `projects.toml` and match the request against project `aliases`...
2. If several projects match, ask one short question...

- Keep each main checkout clean on its `default_branch` ...

# Tools, memory and skills

- Workspace skills are canonical in `.agents/skills/<name>/SKILL.md`. Skills named are referenced by name, not path; when adding one, write it to `.agents/skills`

# Changes and PRs

- Never expose customer-derived information on public or potentially public surfaces, including code, comments, commits, PRs, issues, and docs. Use synthetic placeholders instead.

Referencias

Dejo tres referencias que explican bien esta idea. Las leería en este orden:

  1. Under the River, de Shopify.
  2. The Article Was Not About a Slack Bot, sobre la infraestructura que hay debajo de River.
  3. Building a Public AI Agent Workspace for Organizational Learning, sobre lo que ocurre cuando el trabajo con agentes deja de ser privado.

Agentes, memoria y Executor

Agentes y contexto

Uso Pi con la sub de Codex. Es un setup sencillo: el primer prompt me carga unos 2,5k de contexto. También uso Grok Build gracias a la sub de X Premium.

Suelo usar Orca para enviar transcripciones de audio con fixes o ideas y pedirle que las escriba en Markdown o en Supermemory.

Memoria

Estoy usando Supermemory y, de momento, me gusta. Uso el plan gratuito y tengo una extensión propia en Pi, así que no gasto muchos tokens y solo consulto la memoria cuando hace falta. Solo la tengo conectada a Grok Bot y Pi; a nada más.

Executor

Con un solo MCP, Executor me permite conectar los demás mediante Code Mode. Me parece una maravilla y lo recomiendo al 100%. Creo que te equivocas si no lo usas o, al menos, no le echas un ojo.

El mío está en Cloudflare. Pablo R. explicó hace poco cómo lo tiene y me parece un muy buen camino:

Grok Bot

Me parece el primer producto que se siente como un compañero; en realidad, como un equipo de trabajadores, y de los buenos. Tengo mucho que contar sobre él.

Ahora lo uso poco porque no me da tiempo, pero intento mantenerlo simple. Lo tengo conectado a Executor con mis MCPs.

Los roles

Tengo un Chief que habla conmigo a nivel operativo, hace triage y delega en otros bots. Por ahora coordina dos agentes, además de algunos que voy probando a partir de templates que encuentro en X. También acaba de salir su Marketplace.

Uno de los agentes me ayuda con contenido: ideas, referencias, consejos y a organizar lo que se me ocurre. El otro es un engineer. Todos comparten ordenador y allí tienen Cursor instalado, para delegar a Cursor Cloud Agents las issues que dejo escritas en GitHub.

Lo que funciona y lo que echo en falta

La principal diferencia que noto frente a agentes como Hermes es que la comunicación entre agentes sí parece efectiva y aporta valor.

Lo que no me gusta —aunque no es realmente un problema— es lo opaco que resulta: no sabes cuánto contexto tienes, qué modelos se usan ni cómo funciona el loop del agente. No ves nada. Pero bueno, algo malo tenía que tener.

El workflow

Mi workflow para features y fixes es sencillo y parecido a lo que predica Matt Pocock. La mayoría de las veces uso sus skills. Recomiendo crear otras que las complementen porque agilizan el desarrollo.

Si no, uso pstack. Llevo poco probándolo, pero me está dando buenas sensaciones: buenos resultados, fácil de entender y un proceso más rápido.

Recomiendo esta guía para empezar.

Herramientas que uso

Por ahora, esta primera parte acaba aquí. En la siguiente hablaré un poco de las herramientas y de cómo usarlas según cada caso. Creo que empezaré por Pi o por cómo usar la infraestructura de Cloudflare para montar lo que necesitéis.

Si queréis preguntarme algo o darme feedback, tenéis mis redes.