Hacer Pregunta

Análisis

RESUMEN

El video de Gentleman presenta cómo automatizar el proceso de Code Review utilizando un framework propio llamado 4R, combinado con la herramienta Skywork. El objetivo principal es resolver el cuello de botella que surge en los equipos de desarrollo cuando los seniors están sobrecargados, los PRs (Pull Requests) se acumulan y las revisiones se vuelven mediocres o no se realizan con profundidad. La solución propuesta no busca reemplazar el criterio técnico humano, sino convertirlo en un workflow automatizado y consistente que corre en la nube, permitiendo a los líderes técnicos enfocarse en decisiones importantes mientras la máquina se encarga de las revisiones iniciales y estructuradas.

El Problema Principal

Un viernes a las 5 de la tarde, con ocho PRs abiertos y juniors esperando feedback, mientras el senior está en una llamada. El resultado: reviews mediocres, PRs durmiendo todo el fin de semana y código saliendo a producción sin una verificación profunda.

IDEAS PRINCIPALES

El Framework 4R

Gentleman presenta un framework de cuatro puertas de calidad que todo PR debe atravesar:

  • Risk (Riesgo): ¿Este cambio puede introducir un riesgo de seguridad o romper producción? ¿Toca una zona sensible?
  • Readability (Legibilidad): ¿El código se entiende? ¿Respeta el presupuesto de complejidad? ¿No estamos aceptando una "bola de barro" generada por IA que "funciona pero es fea"?
  • Reliability (Confiabilidad): ¿Hay tests útiles? ¿Se están cubriendo casos edge, errores manejados y timeouts?
  • Resilience (Resiliencia): ¿Qué pasa si esto falla? ¿Hay retries, degradación elegante y observabilidad? ¿O una falla local generará una caída en cascada?

La Herramienta: Skywork

Skywork se describe como un "Cloud Workforce 24/7". A diferencia de los LLM tradicionales, no espera prompts, sino que recibe un objetivo y se ejecuta en background. Sus características clave son:

  • Cero configuración: No se necesita levantar servidores, infraestructura propia o scripts complejos.
  • Skills modulares: En lugar de prompts genéricos, se definen skills con reglas, criterios y comportamientos esperados. Se pueden apilar para crear workflows complejos.
  • Memoria contextual adaptativa: Mantiene el contexto del framework 4R, por lo que no improvisa cada review, sino que aplica el mismo criterio técnico de forma consistente.
  • Conexiones nativas: Se integra con GitHub, Slack, Notion, WhatsApp, Telegram y otras herramientas sin configuración manual.
  • Switch Model visible: No es una caja negra; el usuario puede elegir qué modelo de IA (ej. Claude Opus 4.5, Gemini 2.5 Pro) se usa para cada tarea.

INSIGHTS Y DEMOSTRACIÓN PRÁCTICA

Demostración en vivo

Gentleman ejecuta una demo real sobre un PR de su proyecto Engram (servidor de memoria persistente) que agrega soporte FTS5 con BM25. Conecta Skywork al repositorio vía OAuth y aplica la skill 4R. Los resultados son impresionantes:

  • Risk: Detecta que un parámetro (title_boost_float_64) se interpola directamente en SQL, lo que podría permitir SQL injection si el input cambia a futuro.
  • Readability: Encuentra un "número mágico" (8.0) sin comentarios, dificultando la comprensión del código para otros colaboradores.
  • Reliability: Identifica que la función de búsqueda aplica LIMIT pero luego itera todas las filas sin una capa adicional de optimización, lo que podría generar problemas de rendimiento.
  • Resilience: Señala que la query BM25 no tiene mecanismo de timeout, lo que podría congelar el sistema ante consultas costosas.

Además, la herramienta publica comentarios inline directamente en el PR de GitHub y puede enviar un resumen estructurado a un canal de Slack o guardar la revisión en Notion de forma automática.

Flujo de Trabajo Ideal

Gentleman propone que una vez configurado el workflow, el proceso sea transparente: el desarrollador sube un PR, Skywork lo revisa automáticamente con el framework 4R, publica comentarios, notifica al equipo por Slack y guarda un registro en Notion. Mientras tanto, el senior puede entrar a una llamada, y al volver ya tiene feedback estructurado y el autor del PR ya puede iterar sin esperar.

CONCLUSIÓN Y CIERRE

El video concluye con tres puntos clave:

  • Skill 4R completa: Gentleman promete subir la skill completa con reglas verificables a su web si los comentarios lo piden.
  • Prueba gratuita: Skywork permite probarlo gratis, con un link en la descripción del video.
  • Suscripción: El creador invita a suscribirse para seguir viendo contenido sobre Code Review y escalar calidad técnica sin perder velocidad.

La idea fundamental es que automatizar el Code Review con criterio no es delegar el pensamiento crítico, sino convertir una metodología técnica en un workflow cloud que corre 24/7, permitiendo que el equipo avance más rápido sin comprometer la calidad.

Sabiduría

RESUMEN

Gentleman presenta un framework de 4R (Risk, Readability, Reliability, Resilience) para automatizar code reviews con criterio técnico usando Skywork, sin perder el control humano.

IDEAS

  • El code review se vuelve cuello de botella cuando los equipos escalan con IA.
  • Los viernes a las 5pm hay ocho PRs abiertos y seniors sobrecargados de llamadas.
  • Sin sistema, los reviews son mediocres o directamente no se hacen.
  • Los PRs duermen el fin de semana y salen a producción sin verificación profunda.
  • Skywork no reemplaza el criterio técnico, lo automatiza como workflow.
  • Las herramientas permiten convertir una metodología de review en un workflow automatizado.
  • El framework 4R son cuatro puertas de calidad para acelerar delivery sin comprometer mantenibilidad.
  • Risk: el cambio puede introducir riesgos de seguridad o romper producción.
  • Readability: el código debe tener estructura razonable y respetar el complexity budget.
  • Reliability: se requieren tests útiles, casos edge explícitos y errores manejados.
  • Resilience: hay que considerar retries, degradación elegante y observabilidad.
  • Skywork mantiene memoria contextual adaptativa con la metodología 4R predefinida.
  • La skill no arranca con un prompt genérico, sino con contexto adaptativo del equipo.
  • El criterio técnico puede ser consistente aunque el senior no revise cada PR en tiempo real.
  • La skill define reglas verificables para cada R con scanners, linters y hooks.
  • La memoria contextual evita que el criterio se pierda entre revisiones.
  • Una unidad de review ideal tiene entre 200 y 400 líneas de código como máximo.
  • Científicamente 400 líneas es el sweet spot para revisiones profundas sin quemarse.
  • Skywork detecta riesgos como SQL injection potencial por interpolación directa.
  • Detecta números mágicos sin comentarios que afectan la legibilidad del código.
  • Identifica funciones que iteran todas las filas sin aplicar límites adicionales.
  • Encuentra queries sin mecanismos de timeout que pueden colapsar por costo excesivo.
  • La skill no inventa criterios, aplica criterios definidos de antemano consistentemente.
  • Los comentarios inline se publican automáticamente en el PR de GitHub.
  • El autor puede iterar sobre observaciones sin esperar al review manual del senior.
  • Skywork permite programar tareas para revisar nuevos PRs automáticamente.
  • Las notificaciones llegan al Slack del equipo sin necesidad de pollear GitHub.
  • Skill stacking permite encadenar review, release notes y decks automáticamente.
  • Las conexiones nativas con GitHub, Slack, Notion y Drive eliminan silos de información.
  • El switch model visible evita la caja negra, eligiendo modelos específicos para cada tarea.

INSIGHTS

  • La automatización del criterio técnico libera a senior para decisiones estratégicas importantes.
  • La memoria contextual convierte metodologías abstractas en workflows consistentes y repetibles.
  • El review humano sigue siendo indispensable como loop de verificación final.
  • Las cuatro R funcionan como filtros de calidad que protegen mantenibilidad y producción.
  • Skills modulares permiten composición de flujos complejos sin repetir contexto constantemente.
  • La integración nativa con herramientas existentes elimina fricciones en la adopción del equipo.
  • PRs pequeños y contextuales facilitan revisiones profundas sin fatiga cognitiva del revisor.
  • La consistencia del criterio técnico se logra externalizando reglas a un orquestador.

CITAS

  • "El C review Review se vuelve un cuello de botella."
  • "Tienes cero reviews bien hechos o si lo haces son super mediocres porque lo estás haciendo apuradísimo."
  • "La idea no es la IA C review por mí, la idea es mi criterio de review puede correr como una automatización."
  • "Siempre tiene que haber un human in the loop. Acuérdense de eso."
  • "No es solamente automatizar cor review, es mostrar cómo podrías hacer que un criterio técnico sea consistente."
  • "La skill no arranca desde un pron genérico tipo 'rebutis code'. Arranca con un contexto adaptativo."
  • "El reviewer que pueda hacer una revisión profunda sin que se queme. Científicamente está comprobado que 400 líneas es el swit spot."
  • "La skill no inventó criterios, aplicó criterios que fueron definidos de antemano."
  • "No es un bot genérico de review tirando comentarios al azar."
  • "La persona que abrió el PR ya tiene comentarios estructurados mientras el señor termina otra cosa."
  • "Esto lo configuras una vez y la gracia es justamente esa, menos interacción casera, más workflow listo para ejecutar."
  • "La review alimenta lo que son las release notes. Las release notes alimentan el deck. Está todo concatenado."
  • "Vos como lead podrías definir las skills y que el equipo utilice bien todo ese mismo criterio."
  • "Todos estamos cansados de lo que es lo que llama el black box."
  • "Vos ves qué tipo de modelo estás trabajando en esa tarea o conversación."
  • "No es solamente un bot que hace cor review, es una forma de llevar una metodología técnica a un workflow."
  • "Si quieren que abra la skill de 4R completa con reglas, verificarse y todo el setup, déjenme en los comentarios."
  • "Skywar te va a dejar probarlo gratis, eso es lo que está bueno."
  • "Yo sigo subiendo contenido sobre C review Review que le hay workflow. Escalar calidad técnica."
  • "La idea es adelantar lo que es un review, pero siempre tiene que haber un human in the loop."

HÁBITOS

  • Definir skills como bloques modulares con reglas y criterios específicos.
  • Revisar PRs de 200 a 400 líneas para mantener profundidad sin fatiga.
  • Mantener memoria contextual de la metodología del equipo para consistencia.
  • Usar herramientas que permitan revisar sin estar sentado en tiempo real.
  • Programar tareas automáticas para revisiones de PRs nuevos sin intervención manual.
  • Elegir modelos específicos para cada tarea evitando cajas negras genéricas.
  • Enlazar el code review con release notes y documentación automáticamente.
  • Notificar al equipo por Slack los hallazgos sin necesidad de pollear.
  • Publicar comentarios inline en GitHub directamente desde el workflow automatizado.
  • Priorizar severidad de hallazgos para atacar lo más urgente primero.
  • Revisar que el código respete el complexity budget en cada PR.
  • Verificar que los tests cubran casos edge y errores manejados explícitamente.
  • Asegurar que cada skill tenga reglas verificables y comportamientos esperados.
  • Configurar el orquestador una vez y dejar que ejecute workflows recurrentes.
  • Evitar que los miembros del equipo armen setups distintos de revisión.

HECHOS

  • 400 líneas de código es el sweet spot científico para revisiones profundas.
  • Parámetros interpolados en SQL pueden abrir puertas a inyección futura.
  • Números mágicos sin comentarios afectan la legibilidad del código base.
  • Funciones sin límites adicionales iteran todas las filas innecesariamente.
  • Queries sin timeout pueden colapsar la producción por costos excesivos.
  • Los viernes a las 5pm hay ocho PRs abiertos y seniors sobrecargados.
  • PRs sin verificación profunda salen a producción los lunes sin control.
  • Skills modulares evitan repetir contexto en cada nueva revisión de código.
  • La memoria contextual adaptativa mantiene continuidad entre revisiones.
  • Las conexiones nativas eliminan silos entre herramientas del equipo.
  • El switch model visible permite elegir modelos específicos por tarea.
  • La plataforma orquesta sola entre servicios sin configuraciones manuales.
  • Los comentarios inline se publican automáticamente en cada línea de código.
  • Las notificaciones llegan al teléfono sin necesidad de abrir el navegador.
  • El autor puede iterar sobre observaciones sin esperar al revisor senior.

REFERENCIAS

  • Skywork como plataforma Cloud WorkForce 24/7
  • GGA Gent Cardenal (CLI propio del presentador)
  • Framework 4R: Risk, Readability, Reliability, Resilience
  • Code Motion Madrid (evento donde presentó el framework)
  • Engram (servidor de memoria persistente)
  • FTS5 con BM25 para search en SQLite
  • GitHub OAuth para integración nativa
  • Slack como canal de comunicación
  • Notion como herramienta de documentación
  • Claude Opus 4.8 como modelo de lenguaje
  • Gemini 3.1 Pro como modelo de lenguaje
  • Skill stacking para encadenar tareas
  • MCP Tool para integración con Notion
  • Google Drive para almacenamiento
  • Gentle AI (repositorio del presentador)

CONCLUSIÓN EN UNA FRASE

Automatiza tu criterio técnico con 4R, pero siempre mantén un humano supervisando.

RECOMENDACIONES

  • Define skills modulares con reglas claras para cada dimensión de calidad.
  • Implementa memoria contextual adaptativa para mantener consistencia entre revisiones.
  • Limita los PRs a 200-400 líneas para revisiones profundas sin fatiga.
  • Usa herramientas con integraciones nativas a Slack, GitHub y Notion.
  • Configura el orquestador una vez y programa revisiones automáticas recurrentes.
  • Elige modelos visibles para cada tarea evitando cajas negras genéricas.
  • Enlaza code review con release notes y documentación automáticamente.
  • Notifica hallazgos por Slack para que el autor itere sin esperar.
  • Publica comentarios inline en GitHub directamente desde el workflow.
  • Prioriza hallazgos por severidad para atacar lo más urgente primero.
  • Verifica que el código no tenga números mágicos sin comentarios explicativos.
  • Asegura que todas las queries tengan mecanismos de timeout configurados.
  • Revisa que los tests cubran casos edge y errores manejados explícitamente.
  • Evita que cada miembro arme su propio setup de revisión inconsistentemente.
  • Mantén siempre un humano en el loop para decisiones finales importantes.

Abuela, salió video de Gentleman. Hay un<br>problema que aparece en casi todos los<br>equipos cuando empiezan a moverse más<br>rápido con IA. Bien, yo doy consultoría<br>a empresas además de todo lo que hago<br>para ustedes. Bien, pero es que el C<br>review Review se vuelve un cuello de<br>botella. Así no más. Piens en esto. Es<br>un viernes a las 5 de la tarde, tenés<br>ocho perros abiertos. Hay junior que<br>están esperando feedback y obviamente<br>tenés al senior que está entrando una<br>llamada con un cliente ahí metiéndose<br>las cosas, haciendo one on one, lo que<br>sea. ¿Cuál es el resultado de todo esto?<br>Es muy sencillo. Tienes cero reviews<br>bien hechos o si lo haces son super<br>mediocres porque lo estás haciendo<br>apuradísimo. Después tenés PR que están<br>durmiendo un fin de semana. También<br>tenés el lunes saliendo a producción con<br>cosas que nadie chequeó bien a<br>profundidad y ahí es cuando empieza a<br>tener sentido herramientas como la que<br>te voy a mostrar algo que se llama<br>Skywor que está muy buena y no porque<br>mágicamente te va a reemplazar el<br>criterio técnico que va todo así, sino<br>porque te va a permitir poder agarrar<br>una metodología de review y convertirla<br>en un workflow que está automatizado y<br>no tenés que andar customizando toda la<br>infraestructura a mano. Bien, entonces<br>esto va a ir a la par de muchas cosas<br>que te quiero mostrar que son, bueno, es<br>un framework, bien mis cuatro RS, ya lo<br>vamos a ver, pero la idea no es la IAC C<br>review por mí, la idea es mi criterio de<br>review puede correr como una<br>automatización de equipo en la nube<br>mientras yo sigo enfocando las<br>decisiones que son importantes. Bien, de<br>nuevo, todo esto está genial para<br>adelantar lo que es un review, pero<br>siempre tiene que haber un human in the<br>loop. Acuérdense de eso. Sí, vamos con<br>eso.<br>Antes de meternos, tengo que hacer una<br>aclaración rápida porque me la van a<br>preguntar, ya te la estoy viendo en los<br>comentarios y es que yo ahora tengo una<br>herramienta mía bien de cor review<br>individual, se llama GGA Gent Cardenal,<br>si no lo conocen, vayan a verlo, que es<br>un CLI que armé, lo utilizo dentro de mi<br>repositorio, se puede meter en la CLI,<br>por ejemplo, en el lo que es el GitHub<br>actions, bien, también en la terminal<br>antes de subir un PR. Entonces, eso está<br>genial para vos, que sos un de, que el<br>día a día, pero acá estamos hablando de<br>otra cosa. Bien, cuando el equipo esto<br>escala, el problema ya no es solamente<br>cómo reviso mejor yo, el problema es<br>cómo armas un team automation se llama,<br>que es algo que se dispara en eventos<br>del repo eh notifique al canal de Slack,<br>que respete una metodología que vos<br>definas y que también no te obliga a<br>mantener una integración casera.<br>Entonces, eso es lo que quiero mostrar<br>hoy con Skyw, bien, que es un ejemplo<br>concreto de cómo se podría ver ese<br>workflow. Vamos a empezar rápidamente<br>con qué es Skywar. Skyworks se vende,<br>bien como un Cloud War Force de 247. La<br>diferencia con el LM tradicional es que<br>no se queda esperando el próximo prom.<br>Bien, vos le das un objetivo y se<br>mantiene ejecutando en background,<br>incluso cuando vos estás durmiendo.<br>Entonces, la promesa de esto, que la<br>parte que más me interesa, es la de cero<br>configuración. Bien, espectacular. Nada<br>de levantar un BM, por ejemplo, nada de<br>setup técnico pesado, nada de mantener<br>infraestructura propia. Vos entrás a la<br>UI, configuras SkyClow como agente de<br>trabajo, conectas herramientas y empezas<br>a orquestar tareas como un campeón, como<br>un Yaster. Bien. Y la pieza clave que<br>nosotros necesitamos es que Skywor es<br>skills base. ¿Qué significa skill base?<br>Que en vez de tirarte una prom distinta<br>cada vez, vos definís skills como<br>bloques modulares de capacidad. Estos se<br>los voy a mostrar porque tengo el mío<br>que va con todo, pero bueno, cada skill<br>tiene reglas, criterios, comportamientos<br>esperados y después vos estaque skills<br>para armarflow complejos sin repetir<br>todo ese contexto todo el tiempo. Bien,<br>que es lo que yo siempre les enseño por<br>Además podés conectar canales de<br>comunicación como puede ser, por<br>ejemplo, Slack, WhatsApp, Telegram.<br>Bueno, no tenés que abrir el browser<br>para arrancar todo. ¿Ven? Vos agarrás,<br>mandas un voice Node o se dispara el<br>evento de repo y el Warflow arranque.<br>Bien, acá viene el tema. Si Skywk es el<br>orquestador, la pregunta es, ¿qué le<br>daría de input para que haga un review<br>automatizado con criterio y que no sea<br>un bot genérico así un asqueroso? Y es<br>cuando entra el framework mío, bien el<br>4R, que es más esto lo presenté en el<br>Code Motion de Madrid y también en otros<br>eventitos, pero acá lo importante es<br>esto, son cuatro RS, Cristian, me vas a<br>poner obviamente como siempre cuando yo<br>te diga así hac y pones uno y pones<br>explotas así bien espectacular. Si no lo<br>hacen, gente, ya saben, le bajamos el<br>sueldo siempre. Primero de todo, la<br>primer R, risk, riesgo. Segunda R,<br>readability. Tercer R, relability. Y la<br>última, resilence. Yo lo pienso como<br>cuatro puertas de calidad para que la I<br>acelere el delivery sin comprometer toda<br>la parte de mantenibilidad ni producción<br>ni nada. Bien, entonces vamos con la<br>primera. Cristian, pum, riesgo, risk.<br>Este cambio puede introducir un riesgo<br>de seguridad, puede romper producción,<br>toca una zona sensible si está mergiando<br>sin Grails suficientes. Segundo,<br>readability. El código se entiende,<br>tiene una estructura razonable, respeta<br>la lo que se llama el complexity budget,<br>¿bien? O estamos aceptando una bola de<br>barro que está generada con A porque<br>funciona el famoso is slap. Bien,<br>tercero, relability. ¿Estás testando de<br>verdad? No, te estoy hablando del famoso<br>vanity cobras y esas cosas. Deo cobras<br>útil. Bien. casos edge explícitos,<br>errores manejados, timeouts<br>considerados. Bien, y el último del do<br>resilence. ¿Qué pasa con esto falla?<br>¿Hay retries? ¿Hay degradación elegante?<br>¿Hay observabilidad? ¿O una falla local<br>termina generando una caída en cascada?<br>Estas son las cosas que tenés que tener<br>en cuenta. Ahora, lo interesante, en un<br>setup como este, no tendría que explicar<br>estas cuatro dimensiones desde cero cada<br>vez que aparece una P request. Entonces,<br>acá es cuando viene una parte<br>interesante que es la memoria contextual<br>adaptativa. Skybo puede mantener<br>contexto una metodología de review, las<br>4R, los criterios de sebilidad, el<br>formato de comentario, en qué señales<br>tiene que buscar cada PR. Entonces la<br>skill no arranca desde un pron genérico<br>tipo rebutis code. Arranca con un<br>contexto adaptativo. Este equipo revisa<br>con cuatro R. Primero risk, rability,<br>después relability y resilence. Estos<br>son cuatro gars. Este es el estándar de<br>calidad. Bien, entonces esto cambia todo<br>prácticamente. ¿Por qué? Porque no es<br>solamente automatizar cor review, es<br>mostrar cómo podrías hacer que un<br>criterio técnico sea consistente, aunque<br>el senior no esté sentado mirando cada<br>PR en tiempo real. Esa es la parte<br>interesante. La skill define reglas<br>verificables para cada R. Bien, tenemos<br>scanners y hooks para risk, linters y<br>complexity budget para readyability,<br>covers útiles y es casases para<br>reliability, retri degradación elegante<br>y observabilidad para lo que es<br>resilence. Y esa memoria contextual<br>ayuda a que criterio no se pierda. Bien,<br>esta la parte interesante. Miren como<br>acá yo tengo todo definido, espectacular<br>para que cada vez que yo tenga que hacer<br>un C review Review, lo tengo todo<br>hermoso, bien. Y desde una plataforma,<br>no desde una CI, lo tengo todo en un<br>lugar que es fácil de acceder y que<br>cualquiera lo puede editar. Bien, por<br>eso lo quería hacer también con esta<br>herramienta, porque la verdad es muy<br>potente para todas estas cosas.<br>Entonces, la skill le da criterio<br>workflow, la memoria contextual le da lo<br>que es la continuidad. Bien, entonces<br>Scawor no estaría improvisando un review<br>nuevo cada vez, estaría aplicando un<br>framework que ya está definido, que<br>tiene un contexto sobre cada pur request<br>del equipo. Vamos a unas demo. Esto es<br>lo que muestro bien ahora mismo en un PR<br>demo Garm sobre Engram, mi servidor de<br>memoria persistente y justamente agrega<br>soporte FTS5 con BM25 para search en SQ<br>Lite. A ver, esto es algo que más o<br>menos ya estaba bien, lo estamos ahí<br>simplificando un poco y demás, pero<br>claro, es un código, es una pur request,<br>es algo que va, ¿no?, a al equipo. Tiene<br>cambios en eh dos archivos alrededor más<br>o menos de cuánto será esto? Unas 100<br>líneas de código más o menos. Bueno, ese<br>número no es casualidad. En mi<br>framework, una unidad de review tiene<br>que ser humana, chica, contextual y<br>testeable. Idealmente tiene que estar<br>entre 200 y 400 líneas como máximo.<br>Podemos ir a 600 como una locura. ¿Para<br>qué? Para que el reviewer que pueda<br>hacer una revisión profunda sin que se<br>queme. Bien, científicamente está<br>comprobado que 400 líneas es el swit<br>spot para ese tipo de cosas. Eh,<br>realmente. Entonces, Skywor está<br>conectado a ese repositorio con la<br>integración nativa de Ghub utilizando<br>Out. Entonces, vos utilizas la app de<br>Skyw en tu cuenta, elegís el repositorio<br>y desde ahí ya puedes leer el PR y hacer<br>el dif directamente desde Git. Bien,<br>para esta demo entonces lo que voy a<br>hacer es ejecutar manualmente sobre el<br>PR porque quiero mostrar el flujo de<br>punta a punta sin publicar nada, sin<br>control. Bien, entonces la idea del<br>setup es bastante simple. Vamos a<br>decirle, mira, tomá este PR, aplica la<br>skill de 4R, h, generos<br>estructurados y déjame listo un resumen.<br>Y le vamos a pasar la por request. Le<br>damos un buen enter y ahí empieza a<br>laburar. Mira qué bonito. Y ojo, esto<br>simplifica muchísimo el setup. No tuve<br>que setear Westbooks de GitHub a mano,<br>no tuve que configurar un server, no<br>tuve que armar un GitHub actions. Vos<br>autorizás, como les digo, a GitHub por<br>out, corré la skill desde Skywor y tenés<br>el Wordfall listo para operar o<br>programar o s lo que sea. Ahora viene la<br>parte interesante porque Skywork lo que<br>hizo es justamente, ¿no?, agarra el dif<br>del PR y le aplica la skill 4R<br>justamente va a ser un summary de todo<br>lo que es el PR para que sepas más o<br>menos de qué va. Y acá están los<br>findings. Lo primero ya acaba de<br>encontrar lo que es el primer riesgo,<br>¿verdad? Fíjate que dice que el<br>parámetro ttel boost flow 64 se<br>interpola directamente en el stream SQL<br>mediante, o sea, me está ayudando<br>justamente justamente identificar que<br>nosotros podemos ahora no tener un SQL<br>injection, pero en el futuro si llega a<br>cambiar como dice acá, ¿no?, el title<br>boost desde el input del usuario una<br>configuración externa, sí que podría<br>estar la puerta abierta para ese<br>problema. Entonces te dice, por ejemplo,<br>en este caso, ¿no? Wying mothers, ¿cómo<br>lo podríamos arreglar? muchísimas otras<br>cosas más. Esto está buenísimo,<br>buenísimo. Después tenemos el de, como<br>les dije, readability. Entonces acá<br>detecta, por ejemplo, eh valor 8.0. Se<br>pasa como te el bus en la llamada de<br>search, que es un número mágico, sin<br>ningún comentario que explique por qué<br>el campo title recibe un peso. Eh, bien.<br>Entonces, de vuelta. ¿Por qué? Porque<br>cualquier colaborador que ajuste el<br>ranking en el futuro tendrá que inferir<br>el esquema de columna. En resumen, no es<br>legible. Problemita. Y no solamente<br>tengo uno, tengo varios. Acá hay un<br>readability 2, readability 3, ojo, eh.<br>Ahora vamos con reliability. Entonces,<br>vamos a ver que aparte estos findings<br>también tienen una severidad bien para<br>poder justamente identificar qué es lo<br>más importante atacar. Por ejemplo, acá<br>me está diciendo que el build BM25<br>search SQL aplica limit,<br>pero la función search itera todas las<br>filas de vuelta por la query sin aplicar<br>una capa adicional de ops limit.<br>Entonces, de vuelta me está dando un<br>finding muy importante, justamente,<br>¿para qué? Para que cumpla lo que es la<br>relability<br>nuevamente. Y me interesa muchísimo ver<br>el tema de la severidad, dónde está el<br>problema, cuál es el issue, por qué<br>importa de vuelta el fix, todo. Esto<br>está fantástico. Después tenemos, por<br>ejemplo, la de resilence. Y acá ahora<br>otra vez me está diciendo que la Query<br>BMW25 no tiene ningún mecanismo de<br>timeout. Terrible. ¿Ven? De vuelta.<br>Terrible. ¿Qué pasa si hay una query que<br>es muy costosa, lo que sea? Tenemos que<br>tener este tipo de cosas controladas. Y<br>si no sabes por qué, acá lo tenés. Wing<br>mothers. Y esto es lo importante es que<br>la skill no inventó criterios, aplicó<br>criterios que fueron definidos de<br>antemano y esa es la diferencia. No es<br>un bot genérico de review tirando<br>comentarios al azar. Es un ejemplo de,<br>por ejemplo, cómo podrías llevar una<br>metodología técnica a un Workflow Cloud<br>con memoria contextual, sin armar toda<br>la integración de lo que sería a mano,<br>¿no? Pero eso no va a terminar acá<br>porque esta skill que yo les dije por<br>ahí ya un poquitito spoiler, tiene una<br>cosa bastante interesante y vamos a<br>verla. Tiene conexión también, por<br>ejemplo, con Slack. Y acá me está dando<br>cuál es el mensaje que yo voy a mandar<br>por Slack. Todo espectacular. Bien. Y<br>miren, vamos a ver qué es lo que incluye<br>dentro. me está diciendo lo que es el<br>nombre de lo que es el P request, dónde<br>está no eh identificado, qué veredicto,<br>por ejemplo, si está bien, está mal, qué<br>problema hay. Acá están todos los<br>hallazgos por severidad, ojo con esto,<br>¿bien? ¿Qué cosas hay que atender<br>urgentemente? Ahí lo tenemos. Menores,<br>cosas que no pasa nada, ¿ven? Pero ojito<br>con esta parte y cada una también<br>sectorizada. Y está bueno que te diga<br>también un está bien, ¿sí? para poder<br>mantenerlo con el tiempo. Y acá, por<br>ejemplo, podemos ver que ya me dejó los<br>comentarios inline publicados para cada<br>partecito directamente del GitHub en el<br>P request. Así que vamos a verlo. Miren,<br>acá está cada uno de ellos. Sí, ahí<br>está. Esto está fantástico, totalmente<br>automatizado, totalmente todo. Y una<br>cosa que me gustó mucho es esto, que<br>automatizar este proceso, puedo<br>programar una tarea para revisar<br>automáticamente el nuevo Pull Request en<br>este repositorio usando la skill 4R o<br>enviarte un resumen diario de<br>actualizaciones Slack sin que pierdas el<br>hilo de desarrollo. Eso está buenísimo.<br>Entonces, ¿qué pasa en un equipo real?<br>Bien, esto te puede llegar al teléfono,<br>puede estar ahí una llamada, lo ves, ya<br>sabes, si hace falta entrar antes de<br>aprobar, puede hacen muchas cosas. Bien,<br>no tenés que estar justamente poleando<br>Gidha para ver si hay un PR nuevo o lo<br>que sea. Si este tema ya te lo trae a<br>vos. Y lo más importante es que la<br>persona que abrió el PR ya tiene<br>comentarios estructurados, mientras el<br>señor termina otra cosa, el autor ya<br>puede iterar sobre las observaciones sin<br>quedarse bloqueado esperando a lo que es<br>un review manual. Bien, entonces mira,<br>te voy a mostrar algo interesante. Por<br>ejemplo, yo estoy de vuelta acá, estoy<br>fuera del chat que estaba recién, no<br>pasa nada, pero fíjate que tengo la<br>integración, por ejemplo, de Notion.<br>Entonces yo le puedo decir, "Mira,<br>hermoso mío, guarda la última revisión<br>de PR que hicimos en Notion, en el canal<br>PR." Sí, que lo tengo muy bonito hecho.<br>Así. Pum, yo lo abro y como ven,<br>automáticamente esto tiene una memoria.<br>Sí, fíjate que dice, "Enconté la última<br>revisión del PR de repositorio, tal,<br>déjame ver los detalles." Y ahora va a<br>agarrar, le pega un MCP Tool, carga la<br>skill de Notion y lo va a guardar ahí.<br>Bien, entonces ahí dice, mira, ya tengo<br>toda la información, listo, hermoso. La<br>revisión quedó guardada en Notion, la<br>creo acá con todas sus cosas, todo.<br>Ahora, esto funciona por dos razones,<br>uno, esto es porque tiene lo que se<br>llama memoria contextual adaptativa,<br>bien, de Hermes justamente. Y si<br>nosotros vamos ahora al hermosísimo de<br>Notion, vamos a ver que acá ha creado la<br>información justamente sobre el PR con<br>todo lindo, formateado, espectacular,<br>por lo cual esto sirve muy bueno para<br>poder almacenar esta información. Y<br>nuevamente yo puedo directamente desde<br>acá, mira, hagamos una tarea schedule.<br>Entonces ahí está. ¿Cada cuánto querés<br>que se ejecute esto?<br>cada semana después de cada sesión de<br>per review, por ejemplo, tranquilamente.<br>Entonces, esto lo configuras una vez y<br>la gracia es justamente esa, menos<br>interacción casera, más workflow listo<br>para ejecutar. Entonces esto para lo que<br>es el C review Review, pero Skyw no se<br>queda ahí. ¿Por qué? Porque puedes<br>estackar más skills al mismo workflow.<br>Fíjate que acá tenés todo un conjunto de<br>skills, desde, por ejemplo, las slides,<br>documentaciones,<br>imágenes, eh sheets, lo que vos quieras.<br>Cuando el PR mergea, por ejemplo,<br>autogenera lo que es el entry de release<br>notes con descripción técnica, breaking<br>changing, referencias al isu. Esto lo<br>puedes poner en, como dijimos, un Google<br>Doc, lo puedes pusar en un repositorio<br>de documentos o el notion, como te<br>mostré recién. Claro que sí. También,<br>por ejemplo, ¿no? Lo que decíamos,<br>podrías tranquilamente una vez que<br>termina el sprint, no sé, agarrass todos<br>los perremergiados que los lea del<br>Notion, los capturas, los agrupas por<br>una feature, generas un deck de overview<br>para la review directamente con slides y<br>queda todo profesional, todo rebonito.<br>Entonces, ¿por qué este setup funciona?<br>Bien, por esto pega y otros no. Mira,<br>tiene cuatro razones que están muy<br>interesantes. Primero, tiene el skill<br>stacking, que es lo que vimos recién. La<br>review alimenta lo que son las release<br>notes. Las release notes alimentan el<br>deck. Está todo concatenado, no hay<br>silos de información. Después dos, tenés<br>conexiones nativas con tus herramientas.<br>Kithaub Out, Slack, eh, Drive, por<br>ejemplo, Noamp, lo que vos quieras.<br>Bien, tenés interacciones disponibles<br>por todos lados. Después, una vez que<br>está definido todo el flujo, la<br>plataforma orquesta sola entre<br>servicios. Bien, tres, cero config para<br>cualquier tipo de equipo. Vos como lead<br>podrías definir las skills y que el<br>equipo utilice bien todo ese mismo<br>criterio. Entonces, tenés consistencia<br>ya por defecto. Los miembros del equipo<br>no se arman cada uno en setup distinto.<br>Y también cuatro, y esta es importante<br>porque todos estamos cansados de lo que<br>es lo que llama el black box, bien, el<br>famoso caja negra es que en Skywar tenés<br>lo que se llama el switch model visible.<br>Entonces, vos podés elegir, no sé si lo<br>estuvieron viendo, eh, pero que sí, una<br>parte acá de automódel directamente para<br>que Skyw elija, ¿no?, la mezcla<br>inteligente según eh la tarea o podrías<br>tranquilamente ponerla acá y mira, tenés<br>hasta Cl Opus 4.8 o lo que quieras, ch.<br>Gemini 3.1 Pro. Entonces, vos podés<br>elegir para la tarea que vos quieras los<br>manual eh lo que serían los modelos<br>flagshet disponibles que están en la<br>plataforma. Y una de las cosas<br>impresionantes que también tiene es el<br>nuevo skills, bien, que es una<br>funcionalidad que pusieron ahora donde<br>vos podés tener directamente ya una<br>colección, bien, podés explorar y tenés<br>una colección ya de skills hechas y<br>derechas para lo que vos quieras, ¿bien?<br>Desde coding hasta creación de agentes,<br>lo que quieras, prácticamente<br>espectacular esta. La diferencia es que<br>no queda todo escondido en una caja<br>negra. Vos ves qué tipo de modelo estás<br>trabajando en esa tarea o conversación.<br>Y esto no es solamente un bot que hace<br>cor review, es una forma de llevar una<br>metodología técnica a un workflow que de<br>vuelta está 247, está en la nube, eh, no<br>tenés que pasarte semanas pegado, bien<br>ahí con herramientas, ni tenés que hacer<br>cosas raras. Eso es lo bueno que está. Y<br>tres cositas para cerrar. Una, si<br>quieren que abra la skill de 4R completa<br>con reglas, verificarse y todo el setup,<br>déjenme en los comentarios y te prometo<br>que lo voy a subir a Gentle AI. Sí, para<br>que lo tengamos ahí todo. Bu, dos,<br>Skywar te va a dejar probarlo gratis,<br>eso es lo que está bueno. Te voy a dejar<br>un link en la descripción, Bomic Code. Y<br>esto está bueno para Devs que están<br>armando un team automation. Bien, vale<br>la pena por si les sirve. Yo lo quería<br>también utilizar como modelo de ejemplo<br>para lo que es el framework de 4 porque<br>está buenísimo para eso. Y una tercera<br>cosa, suscribite papá porque yo sigo<br>subiendo contenido sobre C review Review<br>que le hay workflow. Escalar calidad<br>técnica.<br>de todo un equipo sin perder velocidad y<br>vos no lo habis ya tení a tu abuela.<br>¿Qué es eso? Vos tenés que decir,<br>"Abuela, llegó el video de Gentleman y<br>si vos no lo hacés, a mí me matá,<br>¿entendés?"<br>Y gente, nos vemos en el siguiente<br>video. No te olvides suscribirte, mandar<br>un mensajito, mandarle un like y abuela<br>nos vimos. Oh.