-
Notifications
You must be signed in to change notification settings - Fork 0
Tutorial 3 Your First Agent Task es
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
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.
endorseimprime de 5 a 7 líneas, cada una validando a una persona elegida al azar (reutiliza el poolNAMESexistente) por una habilidad de palabrería elegida al azar (un pool nuevo). Termina con una frase satírica. Debe ser accesible comolockedin endorse, como el/endorsedentro de la sesión, y aparecer enhelp. Toda la aleatoriedad debe usar los helperspick/shufflecon semilla para que la salida sea determinista.npm testdebe 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).
Empieza pidiendo un plan. Es tu oportunidad de detectar un mal enfoque antes de que cambie ningún archivo.
“Quiero agregar un comando
endorsea 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 comoconnect.”
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.
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 encli.test.jsde quelockedin endorsesale con 0 e imprime una validación. Usa una semilla fija. No implementesrenderEndorsetodaví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 testAhora da luz verde a la implementación:
“Ahora impleméntalo para que esas pruebas pasen, siguiendo el patrón de
connect. Agrega un poolSKILLSde ~25 habilidades de palabrería, unrenderEndorse()que devuelva un string, conectadispatchyhandleSlash, agrega una fila enhelpy exporta lo que agregaste. Usa solopick/shufflepara 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.
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 # reproducibleNunca 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, sinconsole.logdentro desrc/. -
¿Solo RNG con semilla? Busca
Math.randomen 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.
Haz el ciclo completo de arriba de verdad. Luego, como crédito extra, pídele al agente que lo extienda:
- “Haz que
endorseacepte un nombre opcional:lockedin endorse Adadeberí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
Tutorial
- 1 · Orientation
- 2 · How the Code Works
- 3 · Your First Agent Task
- 4 · Prompting & Reviewing
- 5 · Localization
Reference
Satire · Sátira · 風刺. Not affiliated with LinkedIn. GPL-3.0-or-later.