Skip to content

Tutorial 3 Your First Agent Task es

James Morris edited this page Jul 29, 2026 · 1 revision

Tutorial 3 · Tu primera tarea con el agente

Meta: agregar un comando nuevo a la CLI — de principio a fin — dirigiendo a tu agente. Agregaremos lockedin endorse: valida a completos extraños por habilidades que casi seguro no tienen. Muy en la marca.

Este es el corazón del tutorial. Practicarás el ciclo real: especificación → pruebas → implementación → barrera en verde → revisión.

← Anterior: Tutorial 2 Cómo funciona el código · Siguiente: Tutorial 4 Prompting y revisión


Paso 0 — Decide cómo se ve “terminado”

Antes de escribir cualquier prompt, redacta tú la especificación en lenguaje sencillo. Las peticiones vagas producen código vago — de un humano o de un agente.

endorse imprime de 5 a 7 líneas, cada una validando a una persona elegida al azar (reutiliza el pool NAMES existente) por una habilidad de palabrería elegida al azar (un pool nuevo). Termina con una frase satírica. Debe ser accesible como lockedin endorse, como el /endorse dentro de la sesión, y aparecer en help. Toda la aleatoriedad debe usar los helpers pick/shuffle con semilla para que la salida sea determinista. npm test debe seguir en verde, y debe haber una prueba nueva que fije al menos una invariante.

Ese párrafo es lo que le entregarás al agente. Nota que nombra las restricciones del Capítulo 2 (RNG con semilla, la barrera de pruebas, el hábito de las invariantes).

Paso 1 — Pide un plan, no código

Empieza pidiendo un plan. Es tu oportunidad de detectar un mal enfoque antes de que cambie ningún archivo.

“Quiero agregar un comando endorse a LockedIn CLI. Aquí está la especificación: [paste your spec]. Antes de escribir código, dime qué archivos cambiarás y tu enfoque, para que lo apruebe. Sigue los patrones de un comando existente como connect.”

Un buen plan menciona: un pool nuevo SKILLS + un renderEndorse() en src/lockedin.js, conectarlo en dispatch() y handleSlash(), agregar una fila en renderHelp(), exportar lo nuevo y agregar pruebas en ambos archivos de test. Si el plan olvida la regla del RNG con semilla o las pruebas, dilo ahora.

Paso 2 — Las pruebas primero

Pídele al agente que escriba las pruebas antes de la implementación. Las pruebas primero convierten tu especificación en algo ejecutable y mantienen honesto al agente.

“Genial. Primero, agrega solo pruebas que fallen: una prueba unitaria de que renderEndorse() devuelve texto que menciona una habilidad conocida y al menos 5 validaciones, y una prueba en cli.test.js de que lockedin endorse sale con 0 e imprime una validación. Usa una semilla fija. No implementes renderEndorse todavía — veamos primero que las pruebas fallen.”

Córrelas y míralas fallar por la razón correcta (la función aún no existe):

npm test

Paso 3 — Deja que el agente implemente

Ahora da luz verde a la implementación:

“Ahora impleméntalo para que esas pruebas pasen, siguiendo el patrón de connect. Agrega un pool SKILLS de ~25 habilidades de palabrería, un renderEndorse() que devuelva un string, conecta dispatch y handleSlash, agrega una fila en help y exporta lo que agregaste. Usa solo pick/shuffle para la aleatoriedad.”

Lo que el agente produzca debería parecerse mucho al resto del archivo. Por ejemplo, un pool SKILLS y un renderizador:

const SKILLS = [
  'Liderazgo de Pensamiento', 'Sinergia', 'Vibras', 'Blockchain (en teoría)',
  'Ser Humillado', 'Retomar Temas', 'Aura Farming', /* ...~25 en total... */
];

function renderEndorse() {
  const people = shuffle(NAMES).slice(0, 5 + Math.floor(rand() * 3)); // 5–7
  const skills = shuffle(SKILLS);
  const out = [''];
  people.forEach((n, i) =>
    out.push('  ✔ Validaste a ' + n + ' por ' + skills[i % skills.length]));
  out.push('', '  Validaste a 6 extraños por habilidades que no puedes verificar. Te validarán de vuelta en una hora.');
  return out.join('\n');
}

…más una línea en dispatch() y en handleSlash(), una fila en renderHelp(), y SKILLS, renderEndorse agregados a module.exports.

Paso 4 — La barrera

npm test

¿Verde? Acabas de publicar una función con un agente, con las pruebas primero. ¿No verde? Eso es normal — ve al ciclo de iteración del Capítulo 4 y dile al agente exactamente qué falló.

Luego mira lo real (las pruebas revisan texto, pero igual deberías ver):

node bin/lockedin.js endorse
LOCKEDIN_SEED=1 node bin/lockedin.js endorse   # reproducible

Paso 5 — Revisa antes de aceptar

Nunca aceptes un diff que no has leído. Revisa específicamente estas cosas:

  • ¿Siguió el patrón? El comando nuevo debería reflejar a connect — sin dependencias nuevas, sin console.log dentro de src/.
  • ¿Solo RNG con semilla? Busca Math.random en el diff. No debería haber ninguno.
  • ¿Tocó algo que no debía? El cambio debería ser aditivo; líneas no relacionadas no deberían moverse.
  • ¿La prueba nueva es significativa? Debería fallar si alguien luego rompe la función — no solo verificar true.

Si algo está mal, pide un arreglo (Capítulo 4). Si está bien, terminaste.


✅ Pruébalo con tu agente

Haz el ciclo completo de arriba de verdad. Luego, como crédito extra, pídele al agente que lo extienda:

  • “Haz que endorse acepte un nombre opcional: lockedin endorse Ada debería validar a Ada específicamente. Agrega una prueba, mantén la barrera en verde.”

Ya construiste una función de principio a fin. El último capítulo trata de hacer esto sin fricción — hacer prompts y revisar como un ingeniero líder.

Siguiente: Tutorial 4 Prompting y revisión

📘 LockedIn CLI wiki

Tutorial

Reference


Satire · Sátira · 風刺. Not affiliated with LinkedIn. GPL-3.0-or-later.

Clone this wiki locally