Skip to content

De un commit a trabajo autónomo

Sobre este taller

Este es un taller muy introductorio que diseñamos en The Red Guild para darlo inicialmente en NodoSerrano. Tiene un formato práctico e improvisado. Vamos a probar, equivocarnos y detenernos a explicar lo que aparezca durante el recorrido.

Está pensado para quienes quieren sumar herramientas y práctica para mejorar sus posibilidades al buscar trabajo. Vamos a trabajar con tareas que aparecen en equipos de desarrollo y aprender a automatizar lo repetitivo, delegar con criterio y comprobar lo que recibimos.

Podés acompañar el recorrido con la presentación que usamos en clase.

Qué necesitás saber

Con algunas nociones de Git, GitHub, programación y conceptos generales de informática ya podés seguir el taller. No hace falta dominarlos. Vamos a retomar los conceptos que necesitemos a medida que aparezcan.

Como referencia, conviene que puedas reconocer archivos y carpetas de un proyecto, leer un fragmento sencillo de código y ubicar qué son un repositorio y un commit. No esperamos que memorices comandos ni que sepas construir una aplicación desde cero.

Si todavía no trabajaste con automatizaciones o agentes, no hay problema. Vamos a empezar por ahí.

Qué vas a aprender

Cuando hacemos un cambio en un proyecto, el trabajo no termina al guardar el archivo. Después tenemos que comprobar que todo siga funcionando, avisar y pedir una revisión. En este taller vamos a buscar una forma de resolver esas tareas sin depender de que alguien se acuerde de hacerlas una por una.

Para algunas alcanza con una automatización que siga reglas preparadas de antemano. Para otras vamos a usar un agente, al que podemos darle un objetivo sin definirle todo el recorrido. Eso también nos obliga a revisar lo que hace, porque puede equivocarse.

Antes de seguir, conviene distinguir el modelo, el harness y el agente. Es común encontrar esos nombres mezclados entre productos. Acá vamos a usarlos con este sentido.

El modelo recibe el contexto y genera una respuesta o propone una acción. No ejecuta por sí mismo los comandos de tu computadora.

Para que esas acciones ocurran necesitamos un Harness. Es el software que llama al modelo, mantiene el contexto, ejecuta las herramientas solicitadas y devuelve sus resultados. También puede aplicar límites y pedir aprobaciones.

Cuando configuramos esas piezas con instrucciones, herramientas y permisos para trabajar sobre un objetivo, tenemos un agente. Puede elegir pasos según lo que va encontrando. No es solamente el modelo ni es un tipo de harness.

En el taller vamos a usar Hermes para organizar ese trabajo y configurar el modelo por separado. El container será el entorno donde corre, no el harness. Al conjunto preparado para recibir un pedido, leer cambios y devolver observaciones lo llamaremos nuestro agente revisor.

Primero vamos a hacer cada parte para entender cómo funciona. Después vamos a automatizar las tareas repetitivas y decidir cuándo deben ejecutarse. También vamos a conectar acciones para que el resultado de una ponga en marcha el siguiente paso y observar qué ocurre ante cambios y errores.

Al delegarle trabajo al agente, vamos a darle un objetivo concreto, contexto y permisos limitados. Nos va a tocar comprobar sus resultados, detectar fallas y decidir cuándo intervenir. Así podremos distinguir qué se resuelve con reglas claras y qué necesita interpretación.

Al terminar, vas a tener un flujo que recibe un pedido de revisión, le permite al agente leer los cambios y devuelve sus observaciones. Vos vas a comprobarlas, corregir lo que corresponda y decidir si integrás el cambio. En este taller, esa decisión y la acción de integrar el código siguen en tus manos.

Recorrido del taller

CapítuloResultado que vas a comprobar
1. Proyecto y deployUna publicación principal desde main, llamada Production; una versión para probar cambios desde development, llamada Preview; y una propuesta de cambios, o pull request, revisada e integrada
2. Docker y runnerUna comprobación automática pasa, falla por un error deliberado y vuelve a pasar
3. Hermes y TelegramUna conversación por terminal y otra desde Telegram
4. El túnelLa misma respuesta local se consulta por una URL HTTPS pública
5. El webhookGitHub envía un evento firmado y el receptor responde sin IA
6. La reviewUna etiqueta solicita una revisión y la respuesta vuelve al PR
CierreHooks desactivados, procesos detenidos y tokens dedicados revocados

Empezar por los requisitos.

A lo largo del curso vas a encontrar capturas oficiales o públicas con su procedencia indicada. Sirven para orientarte, pero algunas muestran interfaces históricas y repositorios de ejemplo. Los diagramas son del taller y los SHA que aparecen dibujados son ilustrativos. Para comprobar tu ejercicio, mirá siempre tu repo, tu commit, tu URL y tu respuesta real.

Las opciones y diagnósticos quedan fuera de la secuencia principal. No hace falta recorrerlos todos. Cuando necesites uno, seguí su enlace de regreso para retomar el paso donde estabas.